Skip to Content

HRMD_ABA HR -> CRM ruins data UPDATE / INSERT mode


one of our customers use ALE synchronization of HR data (logical message HRMD_ABA) to CRM system. This never worked correctly without problems, but we always were able to solve it by some combinations of criteria in PFAL to replicate the current data.

Now we have a situation like this:

- running PFAL with INSERT mode and some evaluation path (usually OS-CP) leads to a deletion of all the objects in this evaluation path before the sent data is inserted. For that reason, if we want to replicate the current status of whole org. unit (O), this is not possible, as it can lead to deletion of relationships for position (S), that was re-delegated to a different org. unit (O).

- running PFAL with UPDATE mode leads to changing the name of an employee (in target = CRM = Central Person / HRP1000) to the name, that is not valid anymore (due to the logic that evaluates, what should be done - we debugged that and it is clue-less). Running this again repairs it. And running it again ruins it again (and etc.).

These are just two issues that happen regularly (but are not the only ones)..

So we are in a situation, where both modes lead to different problems. To "repair" a single person (P) we use PFAL with INSERT mode without any evaluation path (or the path is inserted, but meaningless, as P is usually "at the end" of the path - e.g. OS-CP). To repair whole org. unit, we can't use INSERT, because we would ruin other's Org. unit's data. If we use UPDATE here, we ruin e.g. the name of the employees (e.g. women, that changed their names after marriage).

We know, that the initial load was not made absolutely flawless (but that also is a question, whether there is one customer, that would be able to stop it's systems for so many days just to sync the data). However, we struggle with the problems of HR/ALE distribution for more than two years now. We went through many (MANY!) information / best practises / notes / KBs from dosens of sources, that quite often oppose each other. We tried to debugg the scenarios with different data sets, but that was not helpful.

So the question is:

Once we are aware, that this is not going to be solved easily, but still we have users, that bring up incidents because of incorrect / lack of data - what should be the ultimate way how to run PFAL to replicate the state in CRM without losing / ruining the (other) data there? E.g. - if there is a set / combination of parameters in PFAL, that will always lead to a correct synchronization in CRM, that would be our WIN.

Thanks in advance for any inputs / help.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

0 Answers