SAP HR/HCM provisioning modify rule

[#1]

When integrating with SAP HR/HCM, one of the typical use cases is to write back attributes such as sAMAccountName, email, telephoneNumber, etc...to the Communication Table. In the examplerules.xml file that comes with IdentityIQ, is the SapHrOperationProvisioning rule "Example SAP HRMS Modify Rule". When examining that out of the box example rule, you'll see in the modifyCommunicationData method the following:

JCoFunction jcoFunctionObject;

if (begDate.length() > 1 ) { //If date is alreday present then use BAPI_EMPLCOMM_CHANGE to modify data

   jcoFunctionObject = connector.getFunction(destination,"BAPI_EMPLCOMM_CHANGE");

} else { //If date is not present then use BAPI_EMPLCOMM_CREATE to add data

   jcoFunctionObject = connector.getFunction(destination,"BAPI_EMPLCOMM_CREATE");

}

This code handles two use cases for SAP HR write back:

1. For new attribute values that doesn't exist already in the Communications table, it will use the BAPI_EMPLCOMM_CREATE function, which works as expected.
2. For existing attribute values it uses the BAPI_EMPLCOMM_CHANGE method, which will modify the existing value with the new value and update the begin/end date values for that entry.

The problem with #2 is that it over rides the existing entry so the history of that value is lost in SAP HR/HCM.  What you ideally want to do is end date the existing attribute entry and create a new entry for the new value.  In order to do so, you'll need to modify the out of the box SAP HRMS Modify Rule.  The best way I've found to handle this use case is to utilize the BAPI_EMPLCOMM_CREATESUCCESSOR method:

JCoFunction jcoFunctionObject;

jcoFunctionObject = connector.getFunction(destination,"BAPI_EMPLCOMM_CREATESUCCESSOR");

Date today = new Date();

Calendar cal = Calendar.getInstance();

cal.setTime(today);

cal.add(Calendar.DATE, -1);

SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd");

String startDateVal = sdf.format(cal.getTime());

jcoFunctionObject.getImportParameterList().setValue("VALIDITYBEGIN", startDateVal); // Begin Date

A couple of things to point out:

1. The BAPI_EMPLCOMM_CREATESUCCESSOR method will create a new entry if the existing attribute doesn't exist, and it will properly end date the existing attribute entry and create a new one if the attribute does exist.  Handling both use cases as needed.
2. One last thing to note is that the existing example rule gets the VALIDITYBEGIN and VALIDITYEND values from the existing entry (If it exists).  The problem with using the existing VALIDITYBEGIN value for attributes that exist is that you'll end up over riding the existing entry even though you are using the BAPI_EMPLCOMM_CREATESUCCESSOR method because you have the start date being set to the same date.  Which is why I added calculating the VALIDITYBEGIN date as well to that method.

[drodriguezacevedo]

Hi @jom

Thanks a lot for this post, this has been really helpful. I know the thread is from a while ago but I am seeing an issue with this, as the createsuccessor function is not by default setting the previous value VALIDITYEND correctly (actually is not modifying it).

Do you know if it is necessary to previously call another function to modify the validityend of another value?

Thanks in advanced