Skip to Content
Technical Articles
Author's profile photo Soumyasanta Rakshit

An Easy Solution To Filter Out Termination Cases Under Changes Scenario For A Payroll Integration In CPI Where Termination Event/Event Reasons Are More Than One


This blog is containing a very easy solution to filter out the Termination files under a Payroll integration system in CPI under changes scenario where event or event reasons for Terminations are more than one.

Some Points to Remember Before The Solution:

A Payroll integration system is containing three segments. They are-
1. Hire/Rehire 2. Termination 3. Changes Scenario.

After seeing the names we can understand what are the goals of those segments. In a very simple words Hire/Rehire is containing the full files of the newly hired or rehired employees. Similarly Termination file is containing terminated employee’s files and Changes Scenario files are containing those file when any kind of changes are happened under an employee profile.

When Termination occurrs for an employee as event, event reason, effective dates are changed under employment information and job information, so in this point the termination details come in the changes scenario along with the Termination segment. But in most of the scenario the termination details are not required under changes scenario.
Also where the Termination segment is creating the proper termination file, there getting the same termination details under changes scenario is not the best case scenario.

Here comes the actual need to filer out the Termination details under change case scenario.


Solution With Example Scenario:

To avoid the redundancy it’s our common intention to use the filter after getting the full payload from SuccessFactors before the field mapping to filter out the same data in CPI. Naturally we filter out the data using employee status or event/event reason. But the complexity arises when more than one event/event reason are there for Termination event or same employee status ( In many of the cases the termination status and global assignment status can same.) are there for similar kind of event.

We can use only a single field with data in Filter in CPI. So here if we want to filtrate out the repeated data then we have to use more than one filter along with content modifier to maintain the root tag. That can make the integration flow more complex and also the I-flow will take more time than usual.

Here the easy solution comes where we can filtrate out the termination data after the field mapping.
We have to implement a groovy script after the field mapping to check the output of the field mapping and after the groovy script we can use the filter.
But how the filter will work here to filter out only the Termination data ?

We are just two steps away from that.

Step 1:

Let us consider “Action” is the output field where event from job information is mapped.
And there are four events/event reasons A,B,C,D which can occur after the Termination of an employee.
Now we have to implement a groovy in the action field of mapping.

Considering the groovy function containing the script is “Movementcode”. And the groovy will be –


Groovy Which Is Used In Field Mapping


And the final field mapping is like –


Final Field Mapping

Here we are combining all of the Termination events into a single one named “Termination” under the field mapping of Changes Scenario. Result “Data Change” will reflect the data of changes scenario.

Step 2:

Now we have to use the filter after the groovy script which is implemented after the field mapping. This script is combining the output of the field mapping. And from this output filer will terminate out the Termination data from the Changes scenario output.


The Filter Condition

After that we have to implement a content modifier and have to fill the body with –
” <root>${in.body}</root> ” to maintain the root tag in the final xml output.


In this way using a single filter we can terminate the Termination Data from the Changes Scenario segment under a payroll integration process. And the Changes Scenario segment will give the output of only Changes scenario data.

Please let me know if you will face any kind of problem in the comment section, I will clear your confusions.

If the blog is helping you anyway then please don’t forget to like the post and also press the follow button for more updates.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Avinash Paul Ullamparhti
      Avinash Paul Ullamparhti

      Great Insigt..Thank you Rakshit for the blog

      Author's profile photo Soumyasanta Rakshit
      Soumyasanta Rakshit
      Blog Post Author

      Thanks Avinash for appreciating.

      Author's profile photo Bernd Herbold
      Bernd Herbold

      Hi Soumyasanta,

      Instead of the Groovy Script I would use a fix value mapping.


      Author's profile photo Soumyasanta Rakshit
      Soumyasanta Rakshit
      Blog Post Author

      Hi Bernd,

      Fix Value mapping has some barriers. Under the groovy "else part" will fetch the data of Changes Scenario, which can be required in the output.
      Using Groovy we can enjoy the flexibility.

      Thanks & Regards