Accessing Transform Message Data
When PeopleSoft Integration Broker invokes a transform program, it inserts the message content into a PeopleCode system variable, %TransformData, which remains in scope throughout the program. Each step can access the variable in turn and modify its content, which then becomes available to the next step.
XSLT and PeopleCode steps access %TransformData differently:
In XSLT, the data is automatically made available to your program. The XSLT program is literally a presentation of the output structure and data, which includes xsltags that reference, process and incorporate the input data into the output structure. There’s no need to explicitly refer to %TransformData, which automatically receives the interpreted result of the XSLT.
In PeopleCode, use the PeopleCode TransformData class to access %TransformData. You then access the XML data as a property of the TransformData object called XmlDoc, which you assign to an XmlDoc object and process normally. Because the XmlDoc object is a reference to the data portion of %TransformData, your modifications are automatically passed back to the system variable.
Using the TransformData Class
The PeopleCode TransformData class has several properties:
|
Property |
Description |
|---|---|
|
XmlDoc |
Contains the XML message data. You can assign this to an XmlDoc object and process the data using the XmlDoc class methods and properties. This property is read/write. |
|
Status |
Communicates the success or failure of the transform program step to PeopleSoft Integration Broker. Set to 0 for success, the default value. Set to 1 to indicate that the message failed a filtering step. Set to 2 to indicate an error occurred. This property is read/write. See Filtering Messages. |
|
SourceNode |
The name of the node sending the message. This property is read only. |
|
DestNode |
The name of the node receiving the message. This property is read only. |
|
SourceMsgName |
The name of the message at the sending node. This property is read only. |
|
DestMsgName |
The name of the message at the receiving node. This property is read only. |
|
SourceMsgVersion |
The name of the message version at the sending node. This property is read only. |
|
DestMsgVersion |
The name of the message version at the receiving node. This property is read only. |
|
routingDefnName |
Retrieves the routing definition name for the transaction. You can then programmatically retrieve the routing properties specified on the Routings - Routing Properties page. |
|
rejectTransform |
Terminates the transaction for asynchronous service operation types. If you set this property for a transform in inbound asynchronous transaction the system will not create a subscription contract. In the Service Operation Monitor Details page for the transaction an informational message will be part of the error message link indicating that the transaction was terminated. If you set this property for an outbound asynchronous transactions the publication contract status in the Service Operation Monitor will be updated to Done. The message will not be sent out and an error message will once again be part of the Service Operation Monitor Details page for the transaction indicating the transaction was terminated. |
Note: Because transform programs can apply to both request and synchronous response messages, the node sending the message could be a synchronous transaction target node that’s sending a response back to the synchronous transaction source node, which in this case is the receiving node.
Handling Non-XML Data
Because they work only with XML DOM-compliant data, neither XSLT nor PeopleCode transform steps can process non-XML data. The XML DOM provides a way to incorporate such data into an XML structure so your transform programs won’t produce errors.
If you’re generating a non-XML outbound message in your PeopleSoft application, it’s up to you to insert your message content into a special element containing a CDATA tag, as follows:
<any_tag psnonxml="yes">
<![CDATA[your_nonXML_message_content]]>
</any_tag>
Note: Any_tag can be any tag you want to use.
The following restrictions apply to the content of inbound non-XML messages, such as those in CSV or PDF format, sent by third-party applications:
Inbound non-XML text messages must be encoded as UTF-8-compliant characters.
Inbound non-text, or binary, messages must be encoded in base64 format.