This is a follow up to part 2 of my series. If you haven’t read it yet, you can do so at the following link. Part 3 will address some of the advanced integration tips and tricks to allow you to replicate data from Employee Central back to your SAP on-premise environment using the Business Integration Builder framework.
In the previous blog post, we covered the basics of the Business Integration Builder (BIB) framework and how to map SAP infotypes against Employee Central (EC) objects. In this post we will dive deeper into some of the configuration options and how to handle more complicated mapping requirements that are frequently required in implementations. Many times, mappings between the two systems will not be a 1-to-1 association. A single field in EC may map to multiple locations in SAP, or require logic to parse or convert the value in EC to the corresponding SAP value. There are also commonly different object types for portlets in EC that need to map to subtypes of infotypes in SAP, thus the mapping must be reused for each subtype. We will cover all these scenarios in this post. The assumption for this topic is that you have a basic understanding of BIB mapping tables in the IMG. If you aren’t yet familiar with BIB mappings, you can refer to the previous blog post for a quick overview.
In the first scenario, you have one EC field that needs to map to more than one field on the SAP system. In this case, you can map one of the SAP fields directly to the EC data element, and you must use a Generic Value Conversion on a different unmapped EC field to map the same component to the second SAP field. Let’s use an example where a single Employee Subgroup field in EC must map and set values for both Employee Group and Employee Subgroup in SAP. First, map the EC subgroup field directly to the SAP IT0001-PERSK field. Note that we have included a value-mapping entity to convert the EC values to the SAP employee subgroups. This is a normal BIB mapping with a value mapping in place that you should already be familiar with. Note that EC field 56 is the Employee Subgroup field; you will need this later.
Below are sample value mappings for this field from EC back to SAP.
Next, map to the SAP Employee Group field using a Generic Value Conversion rule. To do this, you must select an unused mapping field from EC. This should be a field that you will never map to SAP in the future (Changed On, Changed By, Created On, Created By, etc.). In our example, we aren’t using Employment Type from EC in any mapping to SAP, so use that as your dummy mapping field and then overwrite it. Note that if you specify a Value Mapping Entity here, it will get applied to the value you set in the Generic Value Conversion rules after all the rules have run and values have been replaced, so you can remap the output of the rules using the value map here if needed.
Now, click on the Generic Value Conversion section in the left menu to remap the SAP EE group based on EC field 56 (EE Subgroup). Here you have specified the conversion rule “Check and replace,” which looks at another EC field, checks the value against parameter 1, and if they are equal, sets the value of the infotype field from the screen above (IT0001-PERSG) in the mapping to the value in parameter 2.
As you can see, we have mapped the value conversion to EC field 56; it is checking the subgroup IDs in that field against parameter 1 and mapping them to corresponding SAP EE group IDs in parameter 2. In this example, if field 56 has a value of EE_1, then the mapped value for IT0001-PERSG is 5. This trick allows you to bypass the fact that field 56 can normally be assigned only to a single SAP infotype field, and reuse it to map to multiple places in SAP. Similarly, you can identify country-specific value conversions using the “Country Specific Value Conversion” section on the upper left menu. The only difference between Generic and Country Specific is the inclusion of the Country Grouping column in the configuration that allows you to specify rules by country; all other columns are the same.
The second scenario uses value conversion rules to parse the value in the EC and extract a portion of it as the SAP value for the infotype field. The example shows the value conversions for pay scale group and level on SAP infotype 8. We will use the same approach as in example 1 to map the same pay scale field in EC to both SAP infotype fields. The difference is that both will have value conversion logic to parse out their respective components of the pay scale. First, map the EC legacy pay scale field (EC field 130 in this example) directly to IT0008-TRFGR for the pay scale group.
In the Generic Value Conversion section on the left menu, we have specified a processing sequence for the parsing. In this scenario, data is in the following format: <PS Type> – <PS Area> – <PS Group> – <PS Level>. Each pay scale attribute is separated by a dash – character (for example, NA-US-GRD11-03 where NA is the pay scale type, US is the pay scale area, GRD11 is the pay scale group, and 03 is the pay scale level).
As shown, there are three rows in the sequence with three Split rules. The first two split rules are to grab the data after the string/character in parameter 1. The third split rule is different; it specifies to grab the data before the string/character in parameter 1. This allows you to:
- Strip off <PS Type> from before the dash with the first split rule.
- Remove <PS Area> with the second split rule.
- Grab the data before the dash with the remaining <PS Group> – <PS Level> data format using the third split rule.
These steps leave you with just the value in the <PS Group> spot in the ID format.
Similarly, we will map the pay scale area field using Generic Value Conversion rules. First, map the IT0008-TRFST field to the EC Field “Created On” that is not used in any mappings and never needs to be.
The value conversion rules are similar to the pay scale group. The main difference is that we start with the value in the legacy pay scale EC Field (field 130) and then use similar split operations to parse out the <PS Level> component.
The first rule is “Replace with string/EC field,” where we specify that we really want the value from EC Field 130 in this mapping, not the value from EC Field 32 “createdOn.” In the second rule, we perform the same split operation that we had in the previous field example, parsing out the <PS type> component. The third rule is also a split that parses out the <PS area> component. And finally, the fourth rule is also a split operation, but unlike the previous field where we did a split before the string/character in parameter 1, we are instead doing another split after the string/character in parameter 1. This gives us the remainder of the string, which would be <PS Level> data we are looking for. This type of parsing logic is useful when using the BIB framework to allow for calculated fields to be mapped using only configuration without the need to code and maintain the same logic in a BADI.
Our final example is mapping portlets that can have more than one record at the same time in Employee Central with a record type field indicating what kind of data record it is. Examples of this include Phone numbers/phone types, Addresses/Address types, Bank Accounts/Bank types, and Email Addresses/Email types. These portlets in EC can have multiple entries with a type field that indicates what kind of phone (home/cell), address (home/mailing), bank (main/expenses), or email (work/personal) is being stored. These structures tend to store the same fields no matter the type of record it is, and they correspond to an infotype/subtype combination on the SAP system that needs to be mapped to BIB. This is done using infotype cloning configuration in the framework.
First, create a transformation template for the EC entity you are trying to map multiple types for. In our example, we will do this for the PerPhone entity in Employee Central.
Now that the WS_8 template has been created in the template group, go to the IMG and specify the infotype and subtypes to clone. Under Employee Data Integration is a subfolder called Clone Transformation Templates. In that folder are two configuration options. Either define the infotype cloning configuration globally using the first IMG entry or per country using the second IMG entry. The second option is useful when you have certain countries that use different subtypes than the rest of the world within SAP, allowing you to configure a different subtype list for that country and letting the rest of the world use the global cloning configuration.
The example below specifies that PerPhone will map to infotype 0105 with five different subtypes that are possible. Every subtype here will be evaluated by the mapping and the BADI logic to determine if it has data to feed to SAP. Note that you can specify only one infotype number per transformation template that is cloned. You cannot clone another infotype along with 0105 in this template due to this limitation.
Now that we have specified the subtypes to clone the configuration for, we need to specify the fields that are being mapped and cloned in that WS_8 PerPhone template. Go back to the field mapping configuration Primary mapping; the subtype field is now grayed out because you specified the subtypes that are valid in the cloning configuration earlier.
In the example, we are mapping the USRID_LONG and the USRTY fields. The Phone number can be mapped directly to the data field (USRID or USRID_LONG for this infotype). Include the mapping from Phone Type in EC to the USRTY field, which is the subtype field for infotype 0105. This is what tells the BIB mapping that this particular phone type in EC maps to a specific subtype in SAP from the list specified in cloning. Below is the Primary Mapping entry for this field.
Note that a value mapping entity is included here; this allows us to map the EC phone types to the corresponding SAP subtype from our cloning list. We have every EC phone type listed in the EC Key and the matching SAP subtype on the ERP Key column.
This allows the system to match up the EC portlet types to SAP automatically and generate only the infotype/subtype records in SAP that have matching data in EC.
Conclusion
In summary, there are many options for mapping more complicated data transformations from Employee Central back to SAP using just the standard BIB mapping capabilities. The Generic Value Conversion functionality is especially helpful for calculating fields and mappings via configuration without the need to write ABAP code in a BADI. Cloning configuration allows you to use one set of field mappings for multiple infotype/subtype combinations, greatly reducing the amount of configuration and maintenance required in the replication.
The next entry in the series will be the setup of Cloud Platform Integration (CPI) and how to configure the connection from SAP to your CPI instance. If you have questions or need assistance with your company’s BIB configuration, feel free to contact me at mwhite@gpstrategies.com.
About the Authors
