on 08-13-2012 12:46 AM
Hello All,
My scenario is a simple File-->PI-->Proxy scenario with attachments.
The options I have for this scenario are:
1-->
Create 2 separate files - one with main XML data and another containing the Attachment data. Then use Sender File Adapter to pick main XML file and include the Attachment files using Advanced Mode in File Adapter and pass the message to Proxy .
OR
2-->
Convert the Attachment data into Binary format(Base64 encoding) and include this also in the main XML file. Thus I will have only 1 XML containing both data and Binary(Attachment) and hence only 1 file to deal with in Proxy.
Since both these alternatives are possible, I wanted to understand if they score better than the other on the following criteria:
1> Which alternative has faster message processing time in PI. Assume no mapping is needed.
2> Will encoding(Base64) increase the file Size and hence increase file transfer time within PI
3> On the Proxy side, is it easier to handle attachments or Binary(Base64) content
4> Again on Proxy side, are their any known issues while de-coding the binary Data. Do we have standard SAP Methods/Functions to decode encoded binary data and if they are dependent on SP of ECC..
Apart from these are their any other issues/factors which I should consider in deciding the better alternative.
Many Thanks
RK
Hello,
For 1, you need to use the AdditionalFile(s) option in the File Sender Channel
http://help.sap.com/saphelp_nwpi71/helpdata/en/44/692ab8a4b633eae10000000a1553f6/content.htm
and the name of your attachment (except for the file extension) should be the same as the name of your filename.
Since both these alternatives are possible, I wanted to understand if they score better than the other on the following criteria:
1> Which alternative has faster message processing time in PI. Assume no mapping is needed.
Option 1 should be faster since only the main XML will be parsed as opposed to Option 2.
2> Will encoding(Base64) increase the file Size and hence increase file transfer time within PI
Yes, it would increase both the fileSize and processing time.
3> On the Proxy side, is it easier to handle attachments or Binary(Base64) content
I would prefer that an attachment is sent as is and not base64 encoded.
4> Again on Proxy side, are their any known issues while de-coding the binary Data. Do we have standard SAP Methods/Functions to decode encoded binary data and if they are dependent on SP of ECC..
Well for reading attachments, you can use GUI_DOWNLOAD. For reading base64 data to string, you can use SCMS_BASE64_DECODE_STR, these are just examples.
Hope this helps,
Mark
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Rajiv,
I do not see a case for base64 encoding approach. You should be able to handle using the attachment approach, encoding and decoding adds to processing time. In addition, it also adds to parsing time if it is included in the main payload.
If your scenario demands to have all the data in main payload, why not use cdata field?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Rajiv,
could you please tell me how you implemented the step "Convert the Attachment data into Binary format(Base64 encoding)" of your 2nd scenario.
Did you implemented a new module for File Adapter which makes the encoding to base64? If yes, can you please send me an example code?
Thank you.
Regards
Mario
Hi,
You can easily handle attachments in proxies (and that's the reason why SAP has given those methods) so why to go for reading attachments, then encoding the same (while doing mapping) and eventually decoding it again in SAP system...option 1 is the advisable solution.
Thanks
Amit Srivastava
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
95 | |
11 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.