PeopleCode is always running under some user ID context. In integration broker handlers, the user context is typically the “default user ID” from the node definition. There are times when you may need to change the user context, for example when invoking a component interface that has application-level security or search records with data security.
If you need to switch user context in a synchronous OnRequest handler, you can use the SwitchUser built-in function with a PS_TOKEN cookie value:
import PS_PT:Integration:IRequestHandler;
class INBOUND_TESTER implements PS_PT:Integration:IRequestHandler
method onRequest(&MSG As Message) Returns Message;
method getCookieFromRequest(&MSG As Message, &cookieName As string) Returns string;
end-class;
method onRequest
/+ &MSG as Message +/
/+ Returns Message +/
/+ Extends/implements PS_PT:Integration:IRequestHandler.OnRequest +/
Local XmlDoc &xmlDocInbound;
Local XmlNode &requestRootNode;
&xmlDocInbound = &MSG.GetXmlDoc();
&requestRootNode = &xmlDocInbound.DocumentElement;
/* Setup response xml body */
Local Message &response;
&response = CreateMessage(Operation.CHG_TEST, %IntBroker_Response);
Local XmlDoc &xmlout;
Local XmlNode &childNode;
&xmlout = CreateXmlDoc("");
&childNode = &xmlout.DocumentElement.AddElement("user_before").AddText(%OperatorId);
Local string &cValue;
&cValue = %This.getCookieFromRequest(&MSG, "PS_TOKEN");
If SwitchUser("", "", &cValue, "") Then
&childNode = &xmlout.DocumentElement.AddElement("message").AddText("User Switched");
Else
/* SwitchUser Failed - Token probably invalid */
&childNode = &xmlout.DocumentElement.AddElement("message").AddText("Could not Switch to user identified by token");
End-If;
&childNode = &xmlout.DocumentElement.AddElement("user_after_switch").AddText(%OperatorId);
&response.SetXmlDoc(&xmlout);
Return &response;
end-method;After a successful switch, you can invoke component interfaces as the switched user and any audits or security in the underlying code will execute under that user’s context.
getCookieFromRequest method implementation.For asynchronous messages, PeopleTools provides a method on the %IntBroker class to change the user context. This is useful when subscription PeopleCode needs to run component interfaces that require different security than what the triggering user has.
For example, a student saving data on a self-service page may trigger an integration broker message, but the subscription code needs component interface and row-level security that the student should not have.
Local boolean &bswitchUserReturn = %IntBroker.SwitchAsyncEventUserContext("PS", "ENG");SwitchAsyncEventUserContext can only be used in asynchronous messages. It will not work in synchronous handlers.Starting in PeopleTools 8.48, subscription code runs as the user who triggered the business event. Before 8.48, it ran as the default node user. The SwitchAsyncEventUserContext method lets you override this behavior when needed.
Chris Malek is a PeopleTools® Technical Consultant with over two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.
Work with ChrisSWS turns SQL into production REST APIs — ready for AI, modern apps, and partner integrations. One install, unlimited potential.
A powerful PeopleSoft bolt-on that makes REST web services easy. You bring the SQL, SWS handles the rest.
Traditional PeopleSoft web services cost $3,600–$13,000 each to develop. SWS deploys production REST APIs in under 5 minutes through configuration alone.
Turn PeopleSoft data into clean REST APIs for AI integrations, modern applications, and vendor data feeds. Configuration-driven — no PeopleCode required.