Problem with attachment using SO_NEW_DOCUMENT_ATT_SEND_API1

[Former Member]

Hi,

I'm using function module SO_NEW_DOCUMENT_ATT_SEND_API1 to send emails from SAP (to Outlook - but the problem can already be observed when checking the email attachment in transaction SOST) with attachments.

My attachment is a tab delimited file (so that I can open with MS Excel) with a line size of approx. 1600 characters. I mean, concatenating all fields of the output table into a 1600 character field, separated by tabstops (cl_abap_char_utilities=>horizontal_tab)

I am using function module SCMS_STRING_TO_FTEXT to convert the internal table that I want to send to the line size as accepted by function module SO_NEW_DOCUMENT_ATT_SEND_API1, tables parameter contents_bin. Due to function module SCMS_STRING_TO_FTEXT this happens line by line, using a string variable. I make sure to remove any exess blanks that appear in the process due to not completey filled character fields. And for all rows bar the first the string is prefixed with (cl_abap_char_utilities=>cr_lf). I believe that's required so that SAP knows to put the lines back together. So far so good.

When checking the email's attachment via SOST (and the same happens in Outlook) there are extra blanks in certain fields. Like:

Annual Base

92,928. 00

or

Email

First L ast

In debugging it appears that these excess spaces (sometimes 1, sometimes several) appear where the 1600 character data line is split into the 255 character pieces in 'contents_bin'. But then it happens quite randomly and cannot be observed in all data rows.

Is there a better way of splitting my internal table into 255 character chunks so that what is one field will never get split up into two rows. For the above example, the two fields would show like this in contents_bin

.... 92,928.

00

and

First_L

ast

Or where else lies the problem?

Thanks in advance!

Philipp

[Former Member]

Hi,

I am not sure whether this will work for you or not but please have a look at the logic in the function module "SO_RAW_72_TO_255" where they have handled to convert the data into 256 chanracters.

Regards,

SRinivas

[Former Member]

Hi Srinivas,

Thanks for this. Tried this now, but this cuts off all my data lines at 72 characters I'm afraid as the input table of that function module gets shifted into a table with 72 character line length.

Regards,

Philipp

[Former Member]

hai friend,

<removed by moderator>

regards,

anji.

Moderator message: please stop giving this redundant reply to anybody who has a problem with SO_NEW_DOCUMENT_ATT_SEND_API1, rather try helping with the actual problem.

Edited by: Thomas Zloch on Nov 19, 2010 1:26 PM

[MrWhan]

I've used this FM to create the table needed for the send function:

CALL FUNCTION 'CONVERT_STRING_TO_TABLE'
  EXPORTING
    i_string               = whatstring
    i_tabline_length       = 255
  tables
    et_table               = objbin.

Other snippets I used before calling that function:

DESCRIBE TABLE objbin LINES tab_lines.

OBJPACK-BODY_NUM = TAB_LINES.

OBJPACK-DOC_SIZE = TAB_LINES * 255.

In the send function I used parameters PACKING_LIST = OBJPACK and CONTENTS_BIN = OBJBIN.

[Former Member]

Ron,

Thank you for the suggestion. Just tried but issue remains exactly the same. The function module you have suggested builds the table in the same way.

But, after a few more rounds of debugging and scratching my head it occured to me that my problem is self inflicted. I was using the condense statement in an attempt to get rid of the trailing blanks at the end of a row causing the last column to be filled with lots of spaces at the end. But it wasn't working anyway and I have since inserted a dummy column at the end to take all those trailing blanks. What this condense statement did though was creating trailing blanks in some of those rows with 255 characters fixed length and those trailing blanks then showed up as additional blanks in some columns in the attachment that the emailing function module created by putting those lines back to it's original length of close to 1600 characters.

Problem solved!

Regards,

Philipp