Integration Peoplesoft HCM – Tasper

Integration Peoplesoft HCM – Tasper

Tasper is a Dutch application in which employee’s can choose their own package of secondary conditions of labour. For clients it can be interesting to bye a package like this from the shelf rather than making it all yourself as ESS. These clients would need to integrate Tasper with their own HCM module, by means of synchronization. We have chosen to synchronize Peoplesoft HCM with Tasper by means of synchronous XML messaging.

The Choice for Messaging.

An alternative to messaging would be using a databaselink. Using the databaselink it would be possible to use the databaselink in combination with Oracle triggers. If I would commit a change in Tasper it would immediately would be inserted in the relevant record in PeopleSoft. This choice would bring along with it the risk that errors in one system would affect the other system. Instead it would also be possible to synchronize only during a batch update. Then the synchronization would have a delay of up to 1 day. Besides in the near further there will probably be a tendency to connect all relevant applications to each other by means of a BUS and/or BPEL, which would work by means of messaging as well. These are all reasons to choose for messaging as a means of synchronization.

Logging on from PeopleSoft to Tasper

When logging on to Tasper PeopleSoft posts a URL followed by the encrypted PeopleSoft username and encrypted password. The URL is a URL of Tasper. In Peoplesoft you can encrypt en decrypt with the command encrypt() and decrypt(). Tasper reacts on the post by means of sending a synchronous message to PeopleSoft with the still encrypted username and password. PeopleSoft decrypts the username and password and finds out if it is a valid combination. If so PeopleSoft answers the sync message with a collection of all relevant information about the employee. This could be name, salary components, weekly hours etc. In our case we also calculate the budget that can be used for choosing options. Among this information is also the employee status (active or terminated for instance) and the labour agreement valid for the employee. With this information Tasper can deside if this is a person that is allowed into Tasper. The layout and colors of Tasper are adjusted to the screens of PeopleSoft, so that the look and feel and are pretty close.

Transaction in Tasper

When an employee make a choice in Tasper, for instance a bicycle from work, this will lead to an insert of the deduction into the record GENL_DEDUCT_NLD. A sync message from Tasper contains the Employee Id, the date, the deduction, the product and some other info that had to be inserted. We have a setup table to link the products with certain deductions and allowances. The messages answers whether the insert, update or delete was successful. The contents of the message involved is also stored in a separate transaction table.

Workflow

There are also choices of employees that need approval from their manager, of from an HCM expert. Therefor there are two types of messages send by Tasper to generate workflow in PeopleSoft. PeopleSoft answers the sync messages by telling wether the worklfow item was successfully generated by peoplecode. When the manager hits the workflowitem, he is routed back to a special Tasper Page, on which he can approve or refuse the request. The workflow for the HCM experts is special because ot doesn’t generate normal workflow, but a case in CRM instead. The expert open the case, and in the case is a fast link to Tasper, where the expert can approve or refuse the request of the employee.

Night Batch

There are two reason for synchronization with a night batch as well. The first is that we want all the information of all employees involved, available in Tasper. Individual employees can choose to not singing in into Tasper, and the get the default package. With only only synchronization we would miss this group. Further more we would like to like to have the most update to date info in Tasper rather than info that might be one month old – when the person involved didn’t log on anymore since then. Experts could make adjustments in Tasper via the backdoor. If that would happen based on old data that would not be right and could lead to corruption of the data. The third reason is backwards calculation (see below).

The Night Batch is an application engine in PeopleSoft HCM that make an XML-file containing all relevant data of the valid population. There is a special process in the Tasper application that can import these data.

Historic Info

Tasper is in our case only available for people with a certain labour agreement. When an employee is under an other labour agreement for a part of the year, in this period Tasper is not available for him. For instance his labour agreement goes along with access to Tasper in the month Januari, Februari, November and December. In March his labour agreement is not valid, and thus there is no synchronization of his data anymore. Later, in November, the synchronization starts again together with the access to Tasper. But now for some calculations it is needed to have info about the data of the period in between. Therefor in the synchronization messages as well as in the nightly batch, there is a flag in the XML that point out that this is a person for who this specific situation is the case. Then, when this flag is up, Tasper send a messages requesting al of the data for this person of the period in between.

Backwards Calculation

There are two aspects of backwards calculation supported. There first one is the budget. The budget is calculated on basis of the hourly rate and some allowances. When someone hourly rate of two month ago is changes today in PeopleSoft HCM, that budget in Tasper of two month ago, one month ago and this month are changes as well. We keep track of backwards changes in a special table. These cases are evaluated in the night batch and then recalculation the the budgets takes place.

When someone has bought free hours from his salary, the deduction involved is also based on the hourly rate.  So when in the previous example the hourly rate of two months ago is changed today and this person has bought hours two months ago, then these deductions have to be recalculated as well. If an employee exists in the special table with these cases, there is a recalculation flag up in the synchronization message as well as in the night batch. This leads to a new message which requests backwards recalculation of transactions. For this person then, the peoplecode of the message will recalculate the relevant transactions and their deductions in PeopleSoft.