User synchronization between M3 and IPA – Part 3

Now I will do the incremental backup of M3 users and roles.

Refer to part 1 and part 2 for the background.

Design decisions: Pull or Push?

We can either make IPA pull the data from M3, or make M3 push the data to IPA.

Pull

We can make a process flow with SQL queries that pull data from M3, creates or updates the respective record in IPA, scheduled to run at a certain frequency, e.g. once an hour.

It is the simplest strategy to implement. But it is not efficient because it re-processes so frequently thousands of records that have already been processed. And it does not reflect the changes of M3 sooner than the scheduled frequency. And each iteration causes unnecessary noise in the IPA logs and database, so the less iterations the better. And IPA is already slow and inefficient for some reason, so the less work in IPA the faster it is. And after an undetermined amount of work, IPA becomes unstable and stops responding after which we have to restart it, so the less work in IPA the more stable it is.

Push

We can also make a series of Event Hub subscriptions and a process flow with Landmark activity nodes. It will reflect the changes in IPA virtually immediately, faster. And it will operate only on the record being affected, not all, which is efficient.

Mix

I will use a mix: I used the pull strategy for the initial mass load (see part 2), and here below I will use the push strategy for the incremental backup.

Process flow

Here is my process flow that does the incremental backup:

• The top section handles the M3 user (MNS150, CMNUSR) and the respective IPA identity, actor, actor-identity, actor-role, in the gen data area, and the user in the environment data area (e.g. DEV, TST).
• The second section handles the M3 email address (CRS111, CEMAIL, EMTP=4) and the respective IPA actor email address.
• The third section handles the M3 role (MNS405, CMNROL) and the respective IPA task.
• The bottom section handles the M3 user-roles (MNS410, CMNRUS) and the respective IPA user-tasks.
• Each section handles the M3 operations: create, update, and delete.
• I merged everything in one big flow, but we could split it in individual flows too.
• I upload the process with logs disabled to avoid polluting the logs and database.

Source code

You can download the process flow source code on my GitHub here.

Event Hub subscriptions

I created the corresponding Event Hub subscriptions in the IPA Channels Administrator:

• M3:CMNUSR:CUD
• M3:CEMAIL:CUD
• M3:CMNROL:CUD
• M3:CMNRUS:CUD

Result

Here are the resulting WorkUnits:

Repeat per environment

Deploy the process flow, and setup the event hub subscriptions on each environment data area (e.g. DEV, TST).

IMPORTANT

Refer to the challenges section in part 1 for the limitations, notably the data model dissonance which will cause collisions, the out-of-order execution which will cause inconsistencies, and the constraint mismatch which will cause failures.

Future work

• Prevent deleting the administrative users M3SRVADM and lawson.
• Recursively delete dependencies (e.g. in IPA we cannot delete a user that has pending WorkUnits)

Conclusion

This three-part blog post was a complete solution to do unidirectional synchronization of users between M3 and IPA, by means of an initial mass load via the command line, and an incremental backup via a process flow and Event Hub subscriptions. Unfortunately, Infor does not have complete documentation about this, there are serious shortcomings, and IPA is defunct anyway. Also, check out the valuable comments of Alain Tallieu whom takes user synchronization to the next level.

Related articles

• Part 1, overview of user synchronization between M3 and IPA
• Part 2, initial mass load
• Part 3, incremental backup
• Comments by Alain Tallieu where he shares his experience and valuable tips
• Event Hub for Infor Process Automation (IPA)

That’s it!

Please like, comment, follow, share, and come author with us.