INTRODUCTION: This document covers the details of custom adapter module developed to populate an IDoc flat file into an XML tag which would be sent to 3rd Party system for outbound scenarios & to extract the IDoc flat file sent from an XML tag from the XML file sent by 3rd party system for Inbound scenarios. The requirement was such that the IDoc’s will be triggered from ECC & the IDoc XML will not undergo any mapping transformation & will be converted into an IDoc flat file using the standard IDOCXmlToFlatConvertor module. However, the 3rd party system did not accept a flat file format & required the flat file to be sent into a single XML tag. Apart from the tag which would contain the Idoc flat file, there were a few more tags which would be populated from the control record of the Idoc such as Idoc Type, SNDLAD, RCVLAD etc. In case of inbound scenarios, the 3rd party system would send IDoc flat file embedded into the same XML tag. In PI, the standard module IDOCFlatToXmlConvertor would be used to convert IDoc flat file into XML, but for this, the IDoc flat file had to be extracted from the XML tag.

Outbound Scenario:

Inbound Scenario:

PROBLEM: The problem was that as such an IDoc XML could be converted into a flat file using the standard module, but since the 3rd party system was unable to read IDoc flat files, the entire flat file which may consist of 1 or more IDoc’s, had to be sent in an XML tag. Also the 3rd party would send an IDoc flat file embedded into an XML tag, which had to be extracted in order to convert into an IDoc XML.           

SOLUTION: Since the above requirement was not being met with the standard adapter modules, the solution was to develop a custom adapter module which would be used in conjunction with the standard adapter modules IDOCXmlToFlatConvertor & IDOCFlatToXmlConvertor.


Outbound Scenario:

Sender Communication Channel:

Receiver Communication Channel:

Inbound Scenario:

Sender Communication Channel:

When the parameter value for ConversionType: Add or Remove is Add, as provided in the Outbound scenario, the IDoc flat file obtained from standard module IDOCXmlToFlatConvertor is embedded into the XML tag as shown below:


When the value of this parameter is provided as Remove as in the Inbound scenario, the IDoc flat file within the XML tag is extracted from the XML tag & is sent to next module in the module chain i.e IDOCFlatToXmlConvertor module, which then converts this flat file into an IDoc XML. Thus an Idoc was created using this Idoc XML as shown below. The Idoc is in status 51 due to data issue.

Issue with Audit Log Entries in Message Monitoring:

An issue was faced by us when the sequence of entries in audit log was different from the sequence maintained in the module code for these entries. The XML which was constructed for the outbound scenario would contain the Idoc control record fields extracted from Idoc flat file, a single field containing the Idoc flat file and some other fields, whose values would be provided as parameters in the communication channel(Using Module Text). For each of the steps such as starting & completion of extraction of Idoc control record, reading parameters, extracting Idoc flat file from module chain etc., an entry had to be added in the audit log. A randomly occurring issue was discovered in the audit log entries such that the entries of completion of a step would appear before the starting of a particular step. On further investigation, it came to our notice that when the timestamp of two or more entries in audit log is the same, the entries are sorted alphabetically because of which the entry of completion of a step would occur before its starting.

As shown above, when the timestamp of audit log entries is the same i.e 23.02.2014 15:07:53.004, the audit log entries of completion of a step came before starting & the entry showing that the custom module has been called came in the end. Ideally these steps should be in sequence of the steps i.e Calling the custom Module followed by starting & completion of each of the sub-steps & then successful execution of the custom module.The sequence of entries maintained in module code was as per the steps of processing as shown in the code snippet below:

Resolution: The resolution was to provide the entries which were in alphabetical order such as:

1. Custom Adapter Module IdocFLatFileWrapper called.

2. Custom Adapter Module Processing Step1: Starting extracting Idoc flat file.

3. Custom Adapter Module Processing Step2: Completed extracting Idoc flat file.

& so on.


The code used for writing the module can be found in the attachments section.


To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply