PayloadZipBean + MessageTransformBean

[Former Member]

Hi all,

This is my first post on SCN. I hope to be a positive resource to this community. 🙂 I wanted to ask a question I have been riddled with for some time. We had the requirement to use a sender file adapter for zipped plain text files (sort of CSV file).

Issues I encountered:

1. GZip is not really supported by the PayloadZipBean: I assume there is no way around this (Question 1), so we decided to switch to normal Zip files
2. Using File Content Conversion:
   • Apparently this is not possible, as it tries to convert the inbound zip file into an XML: replaced this by the MessageTransformBean.
   • So at this time, the modules set up are: PayloadZipBean with mode set to unzip, afterwards, the MessageTransformBean with all the parameters set up correctly. This was working fine, as long as the input did not contain any special characters. So on to the next issue.
3. The plain text files are in codepage ISO-8859-1. I have tried TextCodepageConversionBean with the conversion.charset set to utf-8. I have also tried to use the XMLAnonymizerBean (and changing the charset of the XML to ISO, but no result) before the MessageTransformBean. However, this still results in special characters being replaced by ï?n or question marks. I assume this is because the TextCodepageConversionBean only works on payloads of type plain/text, while the result of the PayloadZipBean is "application/octet-stream". Is there any way to do this properly? (Question 2)
4. My workaround is quite simple. I use the PayloadZipBean module in a first sender adapter. Drop this file with a file receiver adapter and then use a second file sender adapter with normal FCC with the Encoding set to ISO-8859-1. This works fine - special characters are read correctly. However, I would prefer doing it all in one sender adapter.

If anyone has any answer to my questions or is maybe doing something similar and has questions, please feel free to answer my post! Also thanks to Stefan Grube for his great post working-with-the-payloadzipbean-module-of-the-xi-adapter-framework.

My regards,

Aerv

[stefan_grube · Accepted solution]

The TextCodepageConversionBean does not work properly, when the ContentType of the source is not known.

As work around you can set the ContentType with the MessageTransformBean. For this purpose you have to put the MessageTransformbean twice in the module chain.

The parameters for the first MessageTransformBean would be:

Transform.ContentType     text/plain;charset=iso-8859-1

The second appearance of the MessageTransformBean does the conversion, as you have already set.

[Former Member · Accepted solution]

Hi Stefan,

Thanks a lot. Inserting a MessageTransformBean prior to the Conversion MessageTransformBean with the parameter Transform.ContentType set to text/plain;charset=iso-8859-1 indeed does the trick. For other people doing this, make sure that your second MessageTransformBean (the conversion one) still contains the Transform.ContentType parameter, this time set to text/xml;charset=utf-8.

Thanks all for your assistance!

[Former Member · Accepted solution]

Hi Aerv,

Can you please provide me the screen shot or the code as I am facing the same problem and want to convert my email attachment to UTF-8.

Waiting for your reply.

Thanks,

Iqbal

[Former Member · Accepted solution]

Hi Iqbal,

This should do the trick:

However, if you are working with an attachment, then I believe you might have to use the PayloadSwapBean:

http://help.sap.com/saphelp_nw04/helpdata/en/2e/bf37423cf7ab04e10000000a1550b0/content.htm

That should allow you to swap your attachment with your main payload and then do the unzip. Because as you can see in the documentation of PayloadZipBean:

• zip.mode

Specify the processing mode:

• To decompress the main payload, use unzip.

This will only decompress the main payload.

Regards,

Aerv

[Former Member · Accepted solution]

Hi Aerv,

Thank you so much for your reply.

Basically, I have an Email Attachment to iDoc scenario but I am struggling to read the special character in the email attachment.

XML Contains this

<Eisenhüttenstr. 99>

When PI reads the email it will change the character to

<Eisenhüttenstr. 99>

I can see 2 payload in ABAP Stack

MailMessage (text/xml;charset="utf-8")

MailAttachment-1 (application/octet-stream;name="file1")

Is there anyway I can change the MailAttachment-1 (application/octet-stream;name="file") to MailAttachment-1 (text/xml;charset="utf-8")

I have tried MessageTransformBean but it didn't change the MailAttachment encoding.

Adapter Module

localejbs/AF_Modules/MessageTransformBean         Local Enterprise Bean     contentType

contentType          Transform.ContentType         text/xml;charset="utf-8"

Thanks,

Iqbal

[Former Member · Accepted solution]

I believe you will have to use the PayloadSwapBean first, then afterwards you can use the MessageTransformBean to change it to UTF-8. But I have not used the PayloadSwapBean yet, so you might have to do some research:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0964d7c-e66e-2910-24bb-ac535e4a5...

That one seems to have a topic on it.

[Former Member · Accepted solution]

Hi Aerv,

Do you know if I can use PayloadSwapBean for different file names.

Basically the file name is not constant and it will be based on Material number and Name so can we we use this bean for different file names as well.

Thanks,

Iqbal

[Former Member · Accepted solution]

Hi Iqbal,

I am not sure, if you find out, please let us know. 🙂

[former_member184681]

Hi,

1: You are right, gzip is not supported by this bean, so switching to zip was a good decision.

2: Did you try using the following attribute of MessageTransformBean:

Transform.ContentType     text/xml;charset=iso-8859-1

It should help you make PI understand the input as iso-encoded. Special characters should be converted to unicode properly in this case, for further PI processing.

Regards,

Greg

[Former Member]

Hi Greg,

Thanks for your feedback. I have already tried using the Transform.ContentType set to iso-8859-1, as well as the xml.conversion parameter. However, I still had the same issue when it comes to the special characters (è, é, ...). They arrive in the integration engine like this: � - indicating a missing character.

Regards,

Aerv

[former_member184681]

Dear Aerv,

Just a few more ideas:

- Did you use Transform.ContentType = iso-8859-1, or the whole value that I mentioned? Most probably it does make a difference.

- You could try using Transform.ContentType = text/xml;charset=utf-8. I have no idea why whould it work, but it seems worth trying .

- Are you sure your file is ISO-8859-1 encoded? You can try experimenting with this online tool to confirm that: http://kanjidict.stc.cx/recode.php

Regards,

Greg

[rajasekhar_reddy14]

Hi Aerv,

After reading your post i learned many things, i would prefer 4th point solution to achieve your requirement. Because doing in one scenario may be big risky

But solution is use OS Command script to zip your file and call OS command in File channel with option beofore message processing then use otehr module(code page conversion).

Regards,

Raj

[Former Member]

Hi Raj,

Thank you for your feedback. I know that using an OS command to unzip (I'm not zipping the file) would also work. But would prefer to do it all in the adapter.

Regards,

Aerv

[baskar_gopalakrishnan2]

while the result of the PayloadZipBean is "application/octet-stream". Is there any way to do this properly? (Question 2)

Thanks for the elaborate description on this topic.  I see in the help link for the payloadzipbean module as well as Stefan's blog for how to set the content type as text/plain. is that you want?

http://help.sap.com/saphelp_nw04/helpdata/en/45/da9358a1772e97e10000000a155369/content.htm

http://scn.sap.com/people/stefan.grube/blog/2007/02/20/working-with-the-payloadzipbean-module-of-the...

or is special character stops you to convert into text/plain?

[Former Member]

Hi Baskar,

I believe this contentType is only for zipping. Not for unzipping, as the help page says:

"This parameter is only relevant for compressing"

So I don't think this is an option...

Regards,

Aerv