Custom Data replication iflow and Abap Design

[sameergovekar]

Requirement :-

This is just a contribution i thought should be shared. We had an scenario where we wanted to replicate EC [Custom MDF] data to on premise infotype as the standard configuration was not supporting the replication configuration

 

Problem:-

The Custom MDF object had non-effective dated configuration at the EC side . Standard BIB configuration does not support this for replication

 

Solution:-

Technical artefacts to be created

1. Abap [One service consumer webservice and One service provider webservice]


2. CPI side , one Iflow is needed


3. Trigger program to invoke the CPI iflow


4. WSDL file for interface -> this is to be utilized in the CPI side and the ABAP webservice

Over all Design flow

Step1:-

Abap Consumer proxy  needs to be created to trigger CPI Iflow. This will need a WSDL file to be created . In this example we have used a non parametric WSDL file.

Configure the consumer proxy in SOAMANAGER to trigger CPI iflow , map the end point URL of the CPI iflow in this configuration.

Create an Abap program to call the above webservice .This program can be scheduled to call the iflow as per required intervals.

Design a Custom Iflow in CPI to fetch data from SF Custom MDF entities , a pre-requisite to this step is to generate a WSDL file from the ABAP side with a structure definition of the infotype you want to update

 

 

Step2 :-

Create a Service Provider proxy using WSDL file , the file should contain the structure of the data which is needed to transferred between EC to SAP on premise.

Configure the Provider proxy  in SOAMANAGER to return data to SAP on premise system. Provide the provider end point URL to CPI iflow and configure it in CPI receiver configuration.

Step3:-

Develop a CPI iflow to fetch the data from Custom MDF using OData api(s) and return it to SAP on premise as per he defined WSDL structure.

The interface is triggered via SAP, after which Custom MDF data is fetched from Success Factors based on last modified date filter. The fetched data is then mapped with the target structure using the WSDL provided and data is posted to SOAP service. After successful completion of the above process, the current date and time is stored to be used in next trigger to fetch data from MDF using last modified date.

Step4:-

In provider Proxy , code the logic to handle the payload from the CPI service

In our case , we have updated infotypes in the backend. Therefore the standard SAP HR functions were used for data update.

Then use HR_INFOTYPE_OPERATION to push the data , either modify or insert new records based on the payload that you get in the CPI iflow payload.

Conclusion

The custom MDF with non-effective dated configuration is successfully working with the custom iflow and Abap service.

 

The above efforts also are contributed by Aparna Alashe , Shipra Tripathi , Bhuvaneswari Mani and Fatama Ahmed who are my colleagues at LTI