Skip to Content

EDI (ANSIX12)-Integration with SAP XI/PI (The alternate to bypass third party adapters)

Processing EDI documents (ANSIX12) would have been an easy task, if XI/PI provides a standard adapter. Though we have third party adapters (like SEEBURGER etc..) available to fulfill the requirement, but it costs for the client.

In this blog we will look into the custom approach to process and validate the incoming EDI (ANSIX12) flat file that comes in as a single line string at XI/PI level.

Business case:

We need to process the EDI documents that reside in sender business system at XI/PI level and map it to IDOC structure. Sounds simple, but here incoming EDI ANSIX12 document is a flat file with a single line string and irrespective of incoming document type, source structure should remain same at XI/PI level.

For instance the incoming EDI flat file (ANSIX12 850 transaction-PurchaseOrder) is of the following format.

ISA00          00          ZZBKCTONPEST     ZZSECC           0709221424U004010000000020TGSPO001292192SECC2007092214242X004010ST85020001BEG00KN4501259102*20070822TXITX46.457~SCH629EA*00220070926AMT1663.6PO1201EA410*CBpainting plateVCpainting platePIDF***printingplateSCH1EA**00220070926AMT1410SE3420001GE12IEA1000000002~ISA00          00          ZZBKCTONPEST     ZZSECC      




63.6PO1201EA410*CBpainting plateVCprinting platePIDF**paintingplateSCH1EA*00220070926AMT1410SE1020001GE12IEA1000000002

Challenges faced:

    • Validating the incoming EDI flat file based on ANSIX12 guidelines document, any exceptions raised during the validation should terminate the process.

    • Reusability, i.e. dynamically process ANSIX12 transactions (850,856…etc).

*Implementation: *

A custom module is a best approach to over come these challenges, we have designed a frame work that is reusable and dynamic. Configuring this module at sender communication channel with file adapter enables to process and validate the incoming EDI documents at adapter engine level. Due to this any invalid EDI format will raise the exception, stops the further process  and the error entry is made at audit log.    


Fig:1 Illustration of EDITransformerBean framework

EDITransformerBean framework consists a bean class that implements SeesionBean and Module interfaces and it is the parent class of the frame work. In order to provide modularity we have defined two other classes, one to hold all the constant static attributes that hold the exception string for validations and the other to validate specific transaction sets. This frame work enables you to add separate class for validating each transaction set without making much modification in the bean class.

The following jars are used to implement the EDITransformerBean frame work.

org.w3c.dom.Document; org.w3c.dom.Element;org.w3c.dom.Node;org.w3c.dom.NodeList;org.w3c.dom.Text;;;;;;;;;;;;;

The following are the processing steps that take place in EDITransformerBean.

Processing Steps:

Following are the processing steps that take place in EDITransformerBean.

1.Create references for Message, AuditMessageKey classes. Assign Message’s reference with incoming principle data, and create instance for AuditMessageKey’s reference in order to add the entries in audit log.

Eg:- Message msg=(Message)inputModuleData.getPrincipalData();

       AuditMessageKey aMsgKey=new AuditMessageKey(msg.getmessageId(),


To log the entries into auditlog,


                                      AuditLogStatus.SUCCESS,”EDIProcess:Module Called”);  

2.From Message’s instance get the payload in the form of text and assign it to reference of TextPayload and then assign the String’s variable reference with payload text by using getText() method of TextPayload.

Eg:-TextPayload txtpayload=msg.getDocument();

      String edi_str=txtpayload.getText();

3.Once we have the content, we can process it by applying our own logic. For instance we can split the entire content with segment separator and define specific methods to validate the header segments according to ANSIX12 standards.

4.Once we have finished with header validations we can drill down to specific transaction set validations, in order to provide modularity we have defined a separate class (i.e. com.edi.EDI850Validate validates transaction set 850 segments according to guide lines document).

5.After successfully validating the entire documents, we need to create xml structure based on our source data type structure using JAVA DOM library.

Once we have gone through these implementation steps, build the EAR and deploy using the SDM. Once the deployment is successful, add your custom module to the sender communication channel as shown in the following figure.


You must be Logged on to comment or reply to a post.
  • You have provided a nice exlpanation to write EDI to xml conversion module. I am sure people must be missing the actual code here 😉
    Conversion of EDI is one of the function that a third party adapter performs. One another important point is the message protocol that an adapter supports. A module cannot replace that advantage. You may look at these points here
    Seeburger – Part 1 – The Basics


  • Approach looks good .. but there are couple of gaps which would be good if you would have explained..
    Validation of Incoming EDI structure…
    Generation of Ack of file…


    • Hi Rajesh,

      Validation of EDI is done based on EDI ANSIX12 guidelines document. For header segments the validation remain same for any EDI ANSIX12 standard document, only transaction set validations vary.