Очень простая задача - послать email со списком возникших в программе ошибок. Т.к. attachment'ов никаких не надо, то пользуюсь SO_NEW_DOCUMENT_SEND_API1. Все работает, но вот почему-то когда приходит email, то строки с сообщениями все собраны в кучу. В таблице ФМ все передается правильно - одна запись на каждую строчку. T.e.:

CONTENTS_TXT:

Line 1
Line 2

Email:

Line 1 Line 2

Пробовала поиграть doc_size - ничего не меняется. Пробовала воспользоваться SO_NEW_DOCUMENT_ATT_SEND_API1 - тот же результат.

Не пойму - это баг или фича? И как от этого избавиться? В поиске что-то ничего по этому поводу не нашла.

У этого ф.м. нет параметра CONTENTS_TXT, а есть OBJECT_CONTENT.
Наверное, просто спутали с SO_DOCUMENT_SEND_API1.



Попробуйте передавать CONTENTS_HEX и/или разделить строки с помощью cl_abap_char_utilities=>cr_lf.

А где наблюдается склеивание строчек? Может просто почтовый клиент-получатель так форматрирует?

В предыдущем ответе правильное решение ,
а вообще я пользуюсь другой функцией.
лови подпрограммку

тут с atachment .

*&---------------------------------------------------------------------*
*& Form send_mail_remind
*&---------------------------------------------------------------------*
FORM send_mail_remind USING p_email.
DATA: message_content LIKE soli OCCURS 10 WITH HEADER LINE,
receiver_list LIKE soos1 OCCURS 5 WITH HEADER LINE,
listobject LIKE abaplist OCCURS 5 WITH HEADER LINE,
packing_list LIKE soxpl OCCURS 2 WITH HEADER LINE,
attachment LIKE soli OCCURS 100 WITH HEADER LINE,
object_hd_change LIKE sood1.
DATA ln type i.

receiver_list-recextnam = p_email.
receiver_list-recesc = 'E'.
receiver_list-sndart = 'INT'.
receiver_list-sndpri = '1'.
APPEND receiver_list.


object_hd_change-objla = sy-langu.
object_hd_change-objnam = 'Object name'.
object_hd_change-objsns = 'P'.
object_hd_change-objdes = 'Message subject'.



MOVE '____________' TO message_content.
APPEND message_content.

CALL FUNCTION 'SAVE_LIST'
EXPORTING
list_index = '0'
TABLES
listobject = listobject.


CALL FUNCTION 'WWW_HTML_FROM_LISTOBJECT'
EXPORTING
template_name = 'WEBREPORTING_REPORT'
TABLES
html = attachment
listobject = listobject.

DESCRIBE TABLE attachment.
CLEAR packing_list.
packing_list-transf_bin = 'X'.
packing_list-head_start = 0.
packing_list-head_num = 0.
packing_list-body_start = 1.
packing_list-body_num = sy-tfill.
packing_list-objtp = 'HTML'.
packing_list-objnam = 'Object name'.
packing_list-objdes = 'таблица проводок'.
APPEND packing_list.
g_tfill = sy-tfill .
CALL FUNCTION 'SO_OBJECT_SEND'
EXPORTING
object_hd_change = object_hd_change
object_type = 'RAW'
owner = sy-uname
TABLES
objcont = message_content
receivers = receiver_list
packing_list = packing_list
att_cont = attachment.

ENDFORM. " send_mail_remind

Вы правы - перепутала с другим ФМ.

Проблема разрешилась (в некотором роде). История почти детективная. Пошла глянуть на SO_DOCUMENT_SEND_API1. (Пример из его документации почему-то содержит CALL FUNCTION 'SO_NEW_DOCUMENT_ATT_SEND_API1'.) Ради прикола скопировала полностью пример, кое-что убрала, запустила - все работает нормально, т.е. одна запись в табличке = одна строка. Хм... Скопировала тот же код в программу, подставила свои переменные - не работает! Т.е. та же фигня - строки сливаются.

В программе табличка с сообщениями (тип solisti1) заполнялась по-разному - где-то просто передавались целые строки, а где-то нужно было "собрать" сообщение, зная класс, номер и т.д. Для этого я использовала вот такой код (основу когда-то где-то списала):



Так вот, оказалось, что чудит REPLACE ! Причем здесь используется obsolete version, пробовала заменить на новый синтаксис (REPLACE FIRST OCCURRENCE ...) - один черт. Пока проблему решила тем, что в SE91 просто понадобавляла точки ко всем сообщениям (к счастью, в этой программе использовала только свои). Например, вместо 'Error in document &' стало 'Error in document &.'. Сейчас уже нету больше времени с этим возиться, но надо, конечно, придумать что-нибудь fool-proof. А вообще интересный такой эффект...

Да, попробовала CR_LF - это добавляет лишнюю строку между сообщениями. То же самое с NEWLINE. Это, конечно лучше, чем все в одной строке, но хотелось бы, чтобы просто каждое сообщение было в своей строке. Так что "будем искать" пока.

Попробуйте добавить только один символ с шестнадцатеричным кодом или 0A или 0D

Видимо сервер приложений у Вас на юниксе, возможно REPLACE отрезает последний символ.

На юниксе 0A.

Этот код неправильно в некоторых случаях будет отрабатывать. Лучше использовать ф.м. FORMAT_MESSAGE.

Как он может чудить? Казалось бы, REPLACE так же стар, как Вселенная...

Я попробовал пример SO_NEW_DOCUMENT_ATT_SEND_API1 без изменения. В SAP Office все 3 строчки по-отдельности.
А на e-mail на сервере mail.ru тоже всё нормально. А вот на ящик под управлением MS Exchange пришло письмо, где последние две строчки склеились. При этом под заголовком письма предупреждение: "Дополнительне разрывы строк в сообщении были удалены", нажав на которое получаем возможность "Восстановить разрывы строк"!

Вы немного не поняли, о чем я написал. Речь не о структуре файлов в unix, в которой для перевода строки используется один символ 0A, а о работе оператора REPLACE. Его реализация на C, скорей всего использует стандартные функции работы со строками из <string.h>, которых зависят от платформы, на которой крутится сервер приложений у Елены. Возможно с этим связаны некоторые особенности работы REPLACE в данном конкрентом случае.
На уровне ABAP, думаю, для перевода строки независимо от платформы используется комбинация из двух символов 0D0A (константа cl_abap_char_utilities=>cr_lf от платформы сервера приложений не зависит). Поэтому, если предположить что сглючил REPLACE, удалив один из этих символов, то не понятно, какой из этих символов был удален, поэтому нужно проанализировать конец строки и добавить или 0D или 0A, чтобы строка заканчивалась cl_abap_char_utilities=>cr_lf.

Хотя, в глючность REPLACE слабо верится.

Можно вместо этого

Да не, очевидно же, что дело в Outlook'e. Outlook и не удаляет лишние разрывы строк после точки. Поэтому, когда Елена в конце сообщений точки ставила, то ничего не сливалось. А replace тут явно ни при чём: как видно из примера, он применялся к строке, в которой не было ни одного 0D или 0A.


Там нужно сообщение на языке, отличном от языка логона.

Если на отличном от языка логона, то согласен - не подойдёт. Но Jelena писала, поэтому и предложил для упрощения.

Да уж, я даже предположить не мог, что так бывает.
Может message ... into отсутствует в старых версиях, типа 4.0.

Спасибо за подсказку - честно говоря, даже не догадывалась о такой опции. Прогнала еще несколько тестов - похоже что-то происходит с текстом либо в Outlook, либо где-то между ним и моей программой (SAP или Exchange Server?).

Сегодня стала пробовать вариант с MESSAGE INTO (предварительно в SE91 убрав точку в конце сообщения), но это опять закончилось слиянием строк.

А теперь - фокус! Eсли вообще почистить таблицу перед вызовом FM и заменить на такую вот вещь, то работает просто замечательно:



НО! В таком варианте строки опять сливаются:



НЕ сливаются строки, если к 'Error in document 90038288 company 0011 year 2008' добавить точку или если заменить на 'Error in document & company & year &'. Очевидно, имеет какое-то значение либо длина сообщения, либо конкретный текст (кстати, ради интереса попробовала - upper/lowercase значения не имеет). Я офигеваю, дорогая редакция...

Сервер не на Unix.

Обратите внимание, что длина строки четная или не четная.
Попробуйте это связать с юникодностью системы и корректностью обрабоки символов конца строки на каком-то этапе обработки.