Java mapping risks in ICO configuration
Risks in migrating to ICO- there are chances that your java code will not work as expected even after successfully test within abap engine configuration
We have been asked to promote ICO usage and we heard many wonderful statements about how fast it is.
Unfortunately migration to ICO is not painless and often you will discover ICO limitation especially in handling the Java code embedded in your mapping.
I therefore decided to share all my findings that has been already shared with SAP through proper SAP messages and in some cases fixed with patch releases.
Attachment name and content type change (recognized as bug .Note 1852011 might solve it)
Pseudo code reported below could be used to change the content type and the name of the attachments or even only 1 of the attributes :
- OutputAttachments.getOutputAttachments().setAttachment(OutputAttachments.getOutputAttachments().create(<new name>,<new content type>,data);
Attachment could be retrieved through
InputAttachments inputAttachments = globalContainer.getInputAttachments();
scanning the entire vector of content IDs we could easily get the content ID of every single attachment
Attachment attachment = inputAttachments.getAttachment(contentId);
and therefore its content and content type
similar code is referenced here:
Attachment name (still not recognized as bug)
The attachment name is not reflected in the SOAP attachment name,as result missing the information about name and extension. Test has been performed with Advanco SFTP adpter.
Attachment handling resulting in doubled attachment( Note 1852011 should solve it)
The attachment handling might result in doubled attachment if using below reported instruction