Technology Blog Posts by Members
cancel
Showing results for 
Search instead for 
Did you mean: 

Introduction

In this blog post, we’ll explore how to design a single CPI interface that will work with scheduled based and also on demand trigger based.

Business Scenario

In most SuccessFactors integrations, we often need to schedule interfaces based on a timer. These interfaces read messages from SuccessFactors using the last modified date timestamp and process the data to target applications. Once the data is sent to the target application, we update the last modified date and store it in a variable. During the next run, the interface reads data based on the timestamp and processes the records.

We design the interface to avoid updating the timestamp if any errors occur. For example:

  • If the target application is down or there are connection issues.
  • If mandatory data is missing for some cases.

This approach works well if the target application processes all records as a single message. However, there are situations where we need to read all employee data during a specific time interval and process each employee's data individually employee by employee. In the Splitter:

  • If we enable stop on exception it will halt all record processing.
  • If we do not enable stop on exception we might miss processing some records.

For example, if we apply a last modified date query to employment data and encounter an issue, we can correct it, and the next run will process the modified data.

In another case, if we navigate to emergency contact data from the employment portlet and apply the last modified date query on employment data, any error in the emergency contact data will prevent the record from being processed to the target. Even after updating the emergency contact, it will not process because the query's last modified date is based on employment and not on emergency contact. To handle this, we can create another integration process with a trigger-based approach in the same iFlow to query and retrieve the data, then process it from the local integration. With this trigger we can manually run the integration by passing the employee id.

Solution Architecture

TriggerSchedule.drawio.svg

 

 

SAP CPI Development 

RameshVaranganti_0-1750432910304.png

 

In the above SAP CPI screenshot we have two integration Process

  1. Time Based Integration: This will execute based on the pre-defined time interval Steps are below explained
    • Content Modifier for Schedule Query: This one will be used to read time stamp and also scheduled query to pass in next step.
    • Local Integration Process: This one will be main local integration process, based on the query received, it will call SF and do mapping and send details to the target application.
    • Write Time stamp in the variable. This will store last modified date to process in next run.
    • Application Id, this is optional , used for additional monitoring to know from and last modified date.
    • Below is Externalized Content Modifier

RameshVaranganti_2-1750433794997.png

 

  1. Trigger Based Integration: This will have HTTP sender and it is trigger based. An Ad-Hoc basic, team will call this end point. We can use this in some UI and give it to business to run themselves
    • Content Modifier for Trigger Query: This one will be used read parameters from trigger and form the query to next step.
    • Local Integration Process: This one will be main local integration process, based on the query received, it will call SF and do mapping and send details to the target application.
    • Additional logging.
    • Below is externalized query in Content Modifier 

RameshVaranganti_1-1750433653201.png

 

 

Once iflow deployed it will looks like below

  • Trigger endpoint URL
  • Timer execution for schedule.

 

RameshVaranganti_0-1750445986913.png

 

Testing

Schedule Run

RameshVaranganti_1-1750446194110.png

In the Timer I have used Application message id to know the time interval.

Trigger Run

postman for trigger

RameshVaranganti_2-1750446347574.png

Monitoring

RameshVaranganti_3-1750446594226.png

 

Note in the Trigger content modifier I have used ${header.SapAuthenticatedUserName} to know who triggered iflow.

RameshVaranganti_4-1750446690964.png

Conclusion

We can design SAP CPI ilfows to work with  both Timer based and also trigger based approaches. Depending on the requirements we can modify these as needed. Additionally,  we can provide a trigger endpoint to API or UI application for business team use.

SAP Integration Suite API Management SAP SuccessFactors Platform 

 

 

 

 

 

Labels in this area