Overview:
Here i want to share an idea on HCM outbound interfaces which we extensively used in our project.
This blog gives you a basic idea on how we designed our HCM interfaces and please pour in your thoughts as well if you have alternative ideas and suggestions.
In SAP HCM, we often need to send HR Delta data (details of the changes from last run date) to third party interfaces on regular basis. For example, many companies want to secure the services of third party tools like HRG, BENEFEX, PeopleFluent etc to streamline their HCM related jobs. Since the requirements are specific to the third party tool, we often need to develop bespoke interfaces. In our project we have developed a standard template for all the HR interfaces with which we can send ‘Full load’ i.e. current data of all the employees for the initial run to the third party interface and ‘Delta load’ i.e. sends data whenever there is a change in data from the last run date.
This template is flexible and with the minimal code (can be re-used both for ‘Delta Load’ and ‘Full Load’ as well) which we will discuss as we go in to more technical detail and this can be re-used in SAP HCM interfaces which use PNP LDB and require to send data on timely basis.
Technical Details:
Two blocks along with the standard PNP screen are added on the selection screen like below (refer screenshot1) with one facilitating the type of Run and the other having Last Run Details (which is not editable) and another option called ‘Override Last Run Date’ to give the flexibility to change the date from which this interface has to consider the changes.
- Advantages of Run Details Block:
Same program can be used to schedule the jobs with the slight changes in variants. Code in the program can be common for both the Delta run and Full load with the exception being Full load runs for whole population while delta load runs only for the employee who has the changes in the desired infotypes since last run date.
- Advantages of Last Run Details block:
Administrator can always have a look at the last run date on which the program was scheduled and the changes are expected only from that date only. Last run date can be changed by overriding it by placing another date in Override last run date field.
This block is visible only when the radio button “Delta Load” is selected. (Refer Screenshot 2)
A custom table has to be created to store the values of the interface names and their last run dates which will be updated whenever the program is scheduled. Last run date will be picked up from this table. For the first time, full load has to be scheduled for whole population and the date will be updated.
Code Snippets
Piece of code which can be used to find the changes in the infotype for delta load when using PNP. If the flag is set, particular employee’s data will appended to final internal table to be sent.
Flag has to be cleared after GET Pernr statement.
In HCM, there is a scope of “future dated” records, so for them, the begin date is checked and for normal records, the change date is checked if it falls in specific intervals.
LOOP AT pxxxx WHERE aedtm GE p_last OR begda GE p_last.
IF pxxxx-aedtm < pxxxx-begda AND
pxxxx-begda BETWEEN p_last AND sy-datum.
gv_flag = abap_true.
RETURN.
ELSEIF pxxxx-aedtm BETWEEN p_last AND sy-datum AND pxxxx-begda LE pxxxx-aedtm.
gv_flag = abap_true.
RETURN.
ENDIF.
ENDLOOP.
For Delta Load
See if the flag is checked then append the data
Wa_final-person = pxxxx-data.
Append wa_final to it_final.
For Full Load
Wa_final-person = pxxxx-data.
Append wa_final to it_final.
So, the code in blue can be re-used for both the processes instead of writing two separate programs. Data can be sent via PI or GI to third party systems.
Full load can be scheduled on need basis.
Limitations
Here, we aren't checking if the specific field which was asked (by third party tool) got changed or not. We are checking if there is a change in whole infotype. The reason is as you guessed performance. As we thought there is no harm in sending the same data again to third party tool as these records can be very few when compared to actual population.
We encountered one more problem with this approach. The requirement is to send the records of the employee if there is a change in manager details. As the details of the manager are not stored in any specific table and checking for the change in HRP tables in PNP LDB is time consuming, we went for a separate solution to tackle this problem which i will try to explain in the continuation blog.
Please let me know your thoughts to improve this idea or other approaches which you might have implemented to solve these kind of scenarios.
