Getting Integration Broker Code to Run as a Different User

I have been doing some development lately where I needed to have a long running task queued to a background job after a certain business event was triggered in the database. In my specific case, the user updated some rows in the database. I then needed to do some intensive processing on each row that would take too long to do at save time. I chose to create an integration broker message and have a local subscription run to do the long processing. If you are running on PeopleTools 8.48 or later, the subscription code will normally be running as the user who triggered the business event which can cause problems.

I ran into an issue that can come up in this scenario. The user who triggered the business event did not have the appropriate component interface and row level security to actually do the processing. It was not an option to give the user this security. In my case, it was a student saving some data on a self service page. We needed to call some 3c component interfaces. However, the student should not have the 3c application level security (similar to row level security) to open data in that component.

Luckily PeopleTools gives us a method on the %intBroker class to handle this. You just need to call the SwitchAsyncEventUserContext method which will change the user context from the student’s security to any user you wish.

Here is what the call looks like to switch the user context to the user “PS”. (Obviously, you would not want to hard-code this user id.)

  Local boolean &bswitchUserReturn = %IntBroker.SwitchAsyncEventUserContext("PS", "ENG");

You can only use this in asynchronous messages. You can read more about it in the IntBroker Class Methods section of the Message Class API Documents.

Additional Reading

Using SwitchUser in Integration Broker Subscriptions