Skip to Content
Technical Articles

Using Integration Center and/or Intelligent Services Centre to update Background Elements or MDF with Employee Central data

In this blog post, you can learn how to create an integration to populate the Employee Profile background elements with Employee Central data, using the Integration Center tool.

A common customer requirement is to have some Employee Profile background elements populated automatically based on Employee Central data. Based on this requirement, we documented a proposal solution, using the Background Element ‘Inside Work Experience’ as an example of destination data and the Job Information as of the Source data. In Summary, we will be sending from Job Information the following information: Job Title, Department and effective date.

The detailed solution is explained below:

Step 1. Create a new Integration by clicking in ‘+ Create’ and selecting ‘More Integration types’.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center Creation page

Step 2. Define the type of integration that you want to create. In our use case, we have selected the below, because we aim to read data from Employee Central and populate it to an Employee Profile Background element.

After definition, click ‘Create’.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Integration definition

Step 3. Select the table that you want to use to read data from. For our use case, we are using Job Information as this is where the Job Title, Start and End dates, and Department are stored.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Selecting the main entity

Step 4. Define the Name and the Description of your new Integration in the ‘Options’ tab and do not forget to Save.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Defining integration name and description

Step 5. In the ‘Configure Fields’ tab, switch to the mapping view as shown below:

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Mapping page view

Step 6. You will notice that both, source and destination fields are considering the same table (Job Information). Now we need to add the Inside work Experience Background element as the Destination. To do it, select the Job Information table, as highlighted below, and click in the delete icon.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Deleting current destination entity

Step 7. Now click in the ‘+’ icon, search and select the background element that will be used as the Destination.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Selecting the Destination entity

Step 8. Now we need to do the mapping between the Job information fields and the background element. For this, you just need to drag and drop the source field into the destination field (example below). Once it is mapped, you will see the mapping icon beside each destination field.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Mapping source and destination fields

The field ‘BackgroundElementId64’ doesn’t need to have any mapping because it is an autogenerated code from the system.

Step 9. After the fields are mapped, back to the ‘Detail View’, we have made the ‘End Date’ as a calculated field, because for the employee’s current record, it will not need any end date, but for past records, it should populate the effective end date based on the job info record. To achieve this requirement, in the calculated screen, we set up the rule to leave the ‘End Date’ empty in case the job information record is equal to 9999-12-31, as shown below:

Image%20from%20Demo%3A%20Integration%20Center

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Calculated field definition

The integration template is set up, and you can run to a sample user to check the results and after to all employees.

Step 10. After the first full run, you will need to set up the filter to only consider delta changes, otherwise, the system will keep creating the same value multiple times. For this, you have to go to the ‘Filter and Sort’ tab and select the ‘Time-Based Filters’. There you need to define the delta updates, by selecting the below set up.

Image%20from%20Demo%3A%20Integration%20Center

Image from Demo: Integration Center – Filter Time-based definition

Please remember to save the integration every time you conclude a step.

The scheduling is something that you need to agree with the customer, but we normally do not recommend running more than once a day.

Below we can see the result of the integration where the background element Inside Work Experience has been populated by the job information data:

Image%20from%20the%20demo%3A%20Job%20Information%20change%20record

Image from the demo: Job Information change record

Image%20from%20the%20demo%3A%20Background%20Element%20records

Image from the demo: Background Element records

This proposed integration also works for MDF Objects. The building idea is the same, maybe some additional set up would be required, depending on the customer requirement.

In the following link you can find a sample of the above Integration definition template to help you as a starting point.

Alternatively, you can use the Intelligent Services Centre (ISC) to trigger this Integration Job instead of scheduling it. In this case, you can use the ‘Change in Job Classification’ or ‘Change in Job Title’ events to trigger the background element update.

Step 1. Go to ISC and search for the ‘Change in Job Classification’ or ‘Change in Job Title’ event:

Image%20from%20Demo%3A

Image from Demo: Intelligent Services Centre Initial Page

Step 2. In the ‘Change in Job Classification’ event, click in the ‘Integration’ option in the left side and prepare the IC job as described before.

Demo%20Image

Image from Demo: Intelligent Services Centre –

Every time that there is a job classification the ISC will trigger the IC job updating the Inside Work Experience background. The result will be de same, but you need to analyze if the customer requirements fits the IC job schedule or the IC + ICS setup.

CONCLUSION

 

This blog post described how we can create an integration between Employee Central data and an Employee Profile background element.

With the solution proposed we aim to avoid having to update the system in two different places (Job information changes and Employee Profile background element update) within the same information.

For more information about when to use Integration Center and when CPI, I would definitely recommend checking out the SAP SuccessFactors Integrations: Integration Center and SAP Cloud Integration IDP (Implementation Design Principle).

Looking forward to your comments and questions.

13 Comments
You must be Logged on to comment or reply to a post.
  • Interesting read Karen – Thankyou!

    Can we also use this approach to get some transient field data (like Time in Position) from EC to EP – where we get the data of Position Start Date in Integration Centre from EC. Do the calculation (Today’s Date minus Position Start Date) in Integration Centre itself and then push this data to an EP custom field?

    • Thank you Ankita.

      To be honest, I didn’t try this scenario, but I can already confirm that the transient fields are not available to be selected in the Integration Center, so maybe the best would be to try a calculation using the Position Entry Date as you mentioned. I will try to reserve some time to test it and provide feedback.

      Best Regards,

      Karen Perez

  • Thanks Karen for the blog well articulated!

    However, I have implemented it for one of the customers, but it failed in scenarios where there is a back-dated entry in Job Info (EC). I have played around with time filters, but that led to another challenge where everytime all the previous records will also be created in Background elements.

    Please let me know if you have any workaround to above scenarios? thanks!

    • Thank you, Sudheer.

      I replicated this scenario, changing the employee data in a past date (Sept 1st), and I was able to get it updated in the profile. I used the ISC ‘Change in Job Title’ with the below definition and any filter in the Integration. It works perfectly.

      Image%20from%20Demo%3A%20ISC

      Image from Demo: ISC

      One additional information is that before the customer goes live, a recommended approach would be to have this job created in IC, without ISC link, and you can run for all employees, to capture all their existing (past or current) jobs in the portlet. After go-live you can setup to be triggered by the ISC event.

      Can you try in your demo and if you are not getting the same result, we can talk offline if needed.

      Best Regards,

      Karen Perez

      /
      Image%20from%20Demo%3A%20ISC
  • Hi Karen,

    Thanks for the sharing the article on IC + ISC with standard solutions.  Had also designed and work on similar requirements and on Bidirectional data flows using Integration center.

    The share the example of Job Classification.  Ideally inside work experience covers other event as well hence would like to add upon an additional point to the above article.  to bring in the additional events like promotion or pay grade or suspension etc. we can write a onsaverule in Job information and call the ISC event trigger.

    Regards

    Sreelatha N

    • Hi Sreelatha,

      Thank you. The intention was precisely to show a use case, as described above, and from there to help others to build scenarios for other cases, like yours, so thank you so much for sharing here in the comments, it will be for sure useful for the readers.

      Best Regards,

      Karen Perez

  • Hi there Karen Perez

    Great work on the Blog!

    I am attempting something similar with SF as the Source and Destination and Intelligent Services (ISC) as the Trigger. The task is to update the loginMethod to PWD. I have set up a Rule and connected the Integration Centre with ISC.

    My issue is when I run the IC in isolation it only updates the 1st record successfully in the Preview payload. It ignores the rest of the items.

    So I created a second IC with Trigger as Scheduled and SF as the Source and Destination and exact same mapping as the above and it picked up all the records in the system.

    Why does IC exhibit different behaviour based on the Trigger? Any reason why this would be the case?

    Thanking you

    Arijit Das

    • Hi Arijit,

      Thanks a lot for pointing this new use case, this for sure will be very useful to others. Can you give more details about how you did and the results as I was not able to understand fully.

      Thank you.

      Best Regards,

      Karen Perez

      • Hello Karen Perez

        So the use case is to update the loginMethod of factory workers who do not have a Business Email to PWD. This is because the Business Integration Builder sets the loginMethod to SSO (while replicating Employees from SAP HCM to SF) and factory workers cannot SSO as they do not have an Active Directory account nor a Business Email.

        For this a Rule is set up in the ISC for Employee Hire that checks that the New Hire does not have a Business Email i.e. is a factory worker. Then it calls the IC with Trigger as ISC and Source and Destination as SF, Event as Employee Hire, and Base entity as EmpJob. We then map the mandatory fields in the User entity and update the loginMethod to PWD. Now when I run the IC it just picks up the first record from the Preview.

        However, when I create another IC with Trigger as Scheduled and all else same it picks up all the records in the system.

        So it seems that the behaviour is based on the Trigger. Of course, when triggered from the ISC there will ever be only a single record for Employee Hire, so it is perfectly fine but I would still like to know if this is indeed the reason for this behaviour.

        Thanks

        Arijit

        • Hi Arijit,
          Thank you for the detailed explanation and yes, you are right in relation to the ISC behavior. It will only run the IC for the employee that triggered the ISC, so do not expect to have a full run through the ISC. For this reason I normally run the IC as a first time separated (for go live) and after this I leave the ISC to care about new cases.

          I hope this answers your question. If this is not the case, please let me know.

          Thank you again,

          Karen Perez

          • Thank you Karen for the response!

            Of course, the ISC would run the IC only for a single Employee as the New Hire Event that triggers the ISC is raised for an instance of an Employee.

            However, I was surprised to see that when I tested the IC independently of ISC it emulated the expected behaviour as if it was being tested within the ISC framework and ran for just 1 record and not all the records.

            So the Trigger setting of Scheduled or ISC for an IC dictates its behaviour when you test it in isolation and independent of the ISC. You can create 2 similar ICs – one with a Trigger of Scheduled and another with a Trigger of ISC – and test them in parallel and you will see the difference in the number of records processed in Execution Manager. The IC with Trigger as Scheduled will run for all the recs in the instance whereas the IC with Trigger as ISC will run for just 1 record.

            Hope this helps to clarify the different behaviours of an IC with different Trigger settings.

            Thanks!

            Arijit