SAP Integration

Integrations are developed to exchange data between sap to sap system (ECC to SAP BI/BW) or sap to non sap system (Example: SAP-MES) as well.

Integrations work on either of the below data sharing mechanisms:

Push data (event trigger happens in sap ecc or hana) to non sap system [suppose if we are to share material master records to non-sap system, then the message can be triggered upon save event of material code] or 

Pull data (request for data is sent by non-SAP system to send data).[Such requests are scheduled in nature and triggered by scheduler]. 

Types of messages based on direction of data flow:

Inbound: Message is called as inbound, if the segment is incoming for SAP, standard SAP tables are updated with the data in the segment.

Outbound: Message is called as outbound, if the segment is outgoing for SAP, Standard tables are not updated using this data.

Integrations are triggered based on predefined events. Events are finalized by discussing with business. 

Ex.: Event to trigger a data exchange can be an order release.

Scheme of data transfer: 

Data transfer between 2 systems, take place through a middle ware. Generally middleware will be PI/PO system, there are other middleware also. 

Flow is: data packet will reach to middleware and from there to the required system. 

Features of PI/PO system: 

Field names may be different between 2 systems like AUFNR and Order_no for order number in sap and other system. Mapping of these 2 fields will be done in middleware. 

While sending or receiving data, input segments can contain extra fields and only required can be sent further. Control can be exercised in PI/PO. 

Some standard strings or symbols can be replaced before sending the data segment or if a string is to be added either at the beginning or at the end of the segment can also be done. 

Data format whether in JSON / XML etc will be handled at PO.

Synchronous and Asynchronous messages : 

Synchronous: Message is called as synchronous, if the message is triggered on real time basis, that is at the time of the event. 

Asynchronous: if the message is triggered on a scheduled basis. Generally outbound can be a scheduled task. 

Ex: To push the released orders to non sap system. 

Integrations can be of different types like Idoc, web service (API)/RFC. 

How are the different integration types selected: 

If in the same project few messages have to be triggered on real time and few messages are scheduled (will be done by scheduler, scheduler can be arranged on sap or non sap system) , then web services are used.

If the messages are triggered on real time only. Then we can use idoc or webservice

If the message is to be triggered on command from external system, then RFC is used. RFC is remote function call. 

Ex: RFC is used to download inspection lot in released status on LIMS application. Here, lot will be processed further after download. This way of sending data is neither scheduled nor real time basis. Message is sent on RFC call made by user. 

 Overview of SAP integrations: Part-2: 

Difference between Idoc, web service and RFC function module: 

As discussed above, depending on project requirement different type of interfaces will be selected. 

Idoc: 

For checking idoc WE series tcodes to be used. WE02 tcode gives an overview of all the message types (each idoc will have individual name).

Every message type would have a segment, with a predefined set of fields and the order of the fields is fixed.

Data is shared in XML format.

Idocs can be standard -SAP provided like iord, into in PM, Matmas in MM , batmas in PP etc. 

Whether standard or custom idocs to be used depends upon the business requirement, if the fields of standard idoc suffice the requirement and the events are also ok, then standard idocs can be used, else the custom idocs ro be used. 

Example: For PM scenario, a custom idoc is to be triggered with a custom status to be sent based on different system status of orders in sap.

Webservice: 

There are standard and custom web services.  

But if we are trying to connect a non sap application for results recording with SAP, then in such cases custom web services are developed. 

Procedure to create a custom web service: 

First step is to create a service in PO or middleware , where in SAP and non SAP fields are mapped. 

ABAP code will be written in the service based on the business requirement.

Application side programming will be done in the same web service.

Error handling also becomes an important aspect. Failures can be handled either at SAP side or application side or at both systems.