Understanding Local Integration Broker Routings

The Integration Broker (IB) in PeopleTools is mostly used as an integration platform to send and received messages to other systems. These systems can be other PeopleTools instances or an external web service over HTTPS. The technology works well and has seen continued improvement by Oracle over the years.

One usage scenario that is not as commonly understood from a design standpoint is the “local-to-local” routing. This is a usage scenario where a business event in the local database creates a service operation and the same local database “subscribes” to that message/service operation and does some processing. Let’s explore why we would design a service operation like this.

Delivered Example of a Local-to-Local Routings

In HCM, the USER_PROFILE service operation has a local subscription which runs the following application class method: USER_PROFILE1:HCM_Refresh_SJT_OPR_CLS:onNotify

The purpose of this subscription code is to “watch” for changes on a user profile and update some “flattened” row level security tables. This would only apply in an HCM database and the HCM application can hook into PeopleTools object changes without modifying the PeopleTools code.

In this case, the HCM development group could have modified the USERMAINT.GBL.SavePostChange component PeopleCode to accomplish the same tasks that the USER_PROFILE1:HCM_Refresh_SJT_OPR_CLS:onNotify method performs. However, that would require the HCM group to modify a PeopleTools object. Having worked in the HCM Development group when I was an employee at PeopleSoft, I know that this would cause problems. The PeopleTools objects should generally be identical between different applications like FS, HCM, IH, CRM, etc.

The local-to-local service operation allowed the HCM group to “watch” for changes to the user profile and take some action when a user profile changes.

Advantage: Allows you to “watch” for changes to business events and take action elsewhere in the system without intrusive customizations.

Since activating a routing is really just an entry in an Integration Broker setup table it is not really a customization. A routing tells the integration engine to “run this code when you get a message like x”. Of course, USER_PROFILE service operations can also be posted to HCM from other PeopleSoft systems and HCM could run the “SJT” code in response to that if it was needed.

Custom Example of a Local-to-Local Routing

In my project work for the Secure Message Center, I used a local-to-local routing to update the Campus Solutions 3C table in an asynchronous fashion. The Message Center allowed the user to upload a file of student ids. This could include thousands of IDs. The user had the option to log those messages to the Campus Solutions 3C tables.

I did not want to update those tables during the component save transactions because it would have timed out. Additionally, the 3C updates were not an important part of the Component Transaction. I decided to implement a local service operation to perform the updates asynchronously.

At save time, a service operation was generated and the subscription code would update the 3C tables using a Component Interface. This could have been technically implemented using an Application Engine but it would have required that the user remember to run the process and it would have taken up limited process scheduler slots. So by having these 3C updates happen in the Integration Broker, the data gets updated automatically in the background. This is kind of like Lesson 7 from the Reddit Infrastructure Lessons Learned talk.

Advantage: Allows background task to occur outside of the Process Scheduler.

I used a local-to-local routing as a Queue. This allowed me to offload the back end processing to a background “thread” and quickly return a response to the user (a saved page).

I have personally implemented hundreds of customizations where I placed code in the Component SavePostChange event which called a Component Interface at save time. For example, when an employee gets terminated in HR, the system calls a CI to lockout all their User IDs automatically. The terminating of the employee should not really be tightly coupled to the locking of the security profile. One technical option would be to "subscribe" to the WORKFORCE\_SYNC message and have some subscription code inspect the message and terminate accounts in response to certain events. This would all happen in the background and would not require the HR person to have CI security. If for some reason this functionality was no longer wanted, then you could just de-activate the Subscription Handler instead of migrate a code change.

Advantage: Allows a loosely coupled architecture between modules.