This section discusses a subtle practice that can add immense value for production support and debugging. It adds a metadata node to return data about the context of the request.
Let’s imagine that you have a simple request/reply asynchronous service operation.
It takes in EMPLID as a parameter
It returns the name associated with the EMPLID.
This service is XML based but this can easily be ported over to JSON.
The important part I want to highlight here is the meta element where we return:
dbname - The name of the database this ran in.
toolsVer - The tools version that this ran in.
psftTransactionId - The PeopleTools Integration Broker GUID that can be used to lookup the request in the IB monitoring tables.
currentUser - The OPRID running the PeopleCode.
responseDTTM - The date-time this was run
dbType - The database type.
request* - A singular node or nested node that contains the request parameters. This may not be feasible for large payloads.
I have code running at many different clients. When one of them experiences an issues all that information can be extremely useful and expedite troubleshooting. I often get a pasted response or screenshot of the PeopleSoft output from a user mentioning an issue. When these metadata elements are present, I have found it can answer many up front questions that may not have been provided. A user may just say “the web service is not working” and send a screenshot of the response. This response metadata can quickly provide that information up front without any back and forth. Perhaps the person has the wrong URL and is connecting to the wrong system. If you have they database name and the user they are authenticating as you can rule that out straight away. Additionally, if you echo back the request parameters typos and other simple but inevitable errors are quickly spotted.