Beginning Your Journey: Migrating From SAP On Premise to Employee Central in the Cloud, Part 2
This is a follow-up to my previous blog post. If you haven’t read it yet, you can do so at gpstrategies.com. Part 2 will address the integration functionality available to migrate your data to Employee Central or transfer your cloud data back to your SAP on premise environment.
As I mentioned in my previous blog post, there are two approaches to maintaining your employee data. “Core Hybrid” is where your entire population is live on Employee Central and you only need to send changes back to the SAP on premise environment. This requires an initial data load into EC, but only one direction of integration for subsequent employee data changes. Alternately, “Side-by-Side” is where part of your population is live in Employee Central and the rest retain SAP as the system of record. This approach will require ongoing bidirectional integration.
The good news is that no matter which integration approach you choose, the newest Business Integration Builder (BIB) framework available with the “SAP and EC integration add on 3.0” allows you to configure both directions in one location. It provides the easiest and most reusable platform to facilitate EC and SAP data transfer. Let’s dig into its advantages versus the previous integration framework.
Advantages of Business Integration Builder (BIB)
- The SAP infotype mapping can be done mostly via a configuration table tying fields from EC to corresponding infotype/subtype/field combinations
– This means you can map and update infotypes via configuration that required ABAP development under the previous framework
– Repeating structures like infotype 41 and time constraint 3 infotypes are included in this configuration
- Value conversion can be easily added to a configuration table that is tied into the EC to SAP mapping and can be reused for similar fields in different configuration mappings
- Value mapping conversions can also be reused between the transfer of data to Employee Central from SAP as well as the transfer of data to SAP from Employee Central. They are designed to be reversible for exactly this purpose. This was not the case in the previous framework.
- Mappings for Action/Reason dynamic determination can be done entirely via BADI, including dynamically remapping the Hire/Rehire actions and reasons. This was not previously possible as the BADI was not called until after the hire action/reason mapping.
- All data sent in the replication to SAP is available in all Infotype BADI mapping calls, so you can easily grab any of the EC data sections from the EC Payload to evaluate and dynamically map fields. Previously, not all of the replication data was available when trying to perform BADI mappings.
- All infotypes share the same BADI call now instead of three different BADI sections depending on which infotype you were processing. This makes it easier to track down code updates/issues and provide a consistent look and feel to all infotype mapping logic and coding structures.
- Any mapping configured to a component of the compound employee API now will automatically include that component in the query to Employee Central. Previously, the list was statically defined in Boomi/HCI and was not expandable.
As you can see, this gives you the most configurability before you must start developing ABAP code to map and update infotypes. To illustrate this, see the example job information mapping below. It shows how easily the EC data structure can be mapped to many infotype/subtype/field combinations in a single configuration table.
Example Job Information mapping in Business Integration Builder
If a field needs a value mapping conversion, it can be plugged into one of the rows of the table using the Value Mapping Entity field in the details as shown below.
Example mapping for Event Reason using Value Mapping to the MASSG field in SAP
You can also click on the Define Value Mapping Entries button from that configuration screen to go directly to the value conversion configuration table. It allows you to define both the EC and ERP keys for the mapping.
Example Event Reason mapping table showing both the ERP and EC key values that can be used to integrate in either direction
The fact that the same mapping structures can be reused between the outbound and inbound integrations allows you to minimize the amount of rework that occurs if the mapping requirements change. Additionally, since the query for the compound employee API from Employee Central for the replication back to SAP is dynamically generated based on your mapping configuration, you can query components of the API that were previously unavailable by including them in this configuration framework.
An additional capability of BIB is to allow both CSV (Comma Separated File) and web service-based integration. When configuring your transformation template group, you can specify if it is a Web Service or CSV file-based transfer.
Once your mapping is defined, the extraction of Employee data from SAP is done using the standard extraction program ECPAO_EMPL_EXTRACTION, where you select the mapping template group and file or web service transfer.
The import of data from Employee Central into SAP is done via the import program ECPAO_EE_ORG_REPL_QUERY, which will query the compound employee API to pull employee data from EC and load it into SAP based on the template group mappings.
In summary, no matter if you want to send data from SAP to Employee Central or if you are replicating data from Employee Central to SAP (or both), the Business Integration Builder framework is a powerful tool that facilitates this process. The ability to configure reusable mappings between both integrations and configure most infotype replications as a mapping instead of having to develop code to import them makes the integration process far more seamless than it has ever been. This functionality is constantly being expanded by SAP to make your transition to the cloud as simple and painless as possible. Hopefully you have found this blog informative as you consider your cloud transition. If you have questions or want to follow up with GP Strategies, please contact me at firstname.lastname@example.org.