Nonrowset-Based Message Structures

This section discusses nonrowset-based message structures that you can use with PeopleSoft Integration Broker. This section discusses:

XML messages.
SOAP-compliant messages.
Non-XML files.

The World Wide Web Consortium (W3C) has established a Document Object Model (DOM) for accessing and manipulating structured data. The DOM specifies a standardized application programming interface (API) that provides a consistent, familiar way to work with almost any XML data. This API—the XML DOM—enables you to create, retrieve, navigate, and modify messages.

You define an XML message in the PeopleSoft Pure Internet Architecture by either uploading an XML file or entering an XML schema definition. The following example shows an XML message schema:

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace=
"http://xmlns.oracle.com/Common/schemas/COMPANY" xmlns="http://xmlns.
oracle.com/Common/schemas/COMPANY" elementFormDefault="qualified">
  <xsd:element name="Company" type="CompanyType"/>
  <xsd:complexType name="CompanyType">
     <xsd:sequence>
        <xsd:element name="Person" type="PersonType"/>
        <xsd:element name="Product" type="ProductType"/>
     </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="PersonType">
     <xsd:sequence>
        <xsd:element name="Name" type="xsd:string"/>
        <xsd:element name="SSN" type="xsd:string"/>
     </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="ProductType">
     <xsd:sequence>
        <xsd:element name="Type" type="xsd:string"/>
     </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

Then populate the message and manipulate its contents by using the PeopleCode XmlDoc class and built-in functions, which reflect the XML DOM.

Note: You can use the XmlDoc class to access inbound, rowset-based messages; however, the PeopleCode Message and Rowset classes handle the PeopleSoft native format more easily.

Use the XmlDoc class if any of the following is true:

The message structure doesn’t fit the PeopleSoft rowset model.
The message data doesn’t come from PeopleSoft database records.
The third-party source or target node requires non-XML message data.

Although you can use the XmlDoc class to generate or process messages that use the SOAP protocol, the PeopleCode SoapDoc class is more efficient and is strongly recommended.

Note: Non-XML message data must be embedded in an XML wrapper, which you send and receive by using the XmlDoc class.

Note: Due to the way in which the parser constructs content models for elements with complex content, specifying large values forthe minOccurs or maxOccurs attributes may cause the parser to throw a StackOverflowError. Large values for minOccurs should be avoided, andunbounded should be used instead of a large value for maxOccurs.

The W3C SOAP specification defines synchronous transactions in a distributed web environment. SOAP is appropriate for Universal Description, Discovery, and Integration (UDDI) interactions, or to interact with SOAP-compliant servers.

You define a message in PeopleSoft Application Designer without inserting any records to define its structure, then populate the message and manipulate its contents by using the PeopleCode SoapDoc class and built-in functions, which comply with the W3C SOAP specification. The SoapDoc class is well-suited for messages that are populated with SOAP-compliant XML data.

SoapDoc complies with the W3C XML DOM specification. The SoapDoc class is based on the PeopleCode XmlDoc class, with some identical methods and properties. To send and receive SoapDoc messages, you must convert them to XmlDoc objects and use the XMLDoc built-in functions, SyncRequestXmlDoc and GetMessageXmlDoc. SoapDoc provides a property for handling the conversion easily.

Use the SoapDoc class if all of the following are true:

The third-party source or target node requires SOAP-compliant messages.
The third-party source or target node requires synchronous transactions.
The message conforms to the SOAP specification.

To send non-XML files through PeopleSoft Integration Broker to their destination, you must wrap them in the PeopleSoft non-XML message element, CDATA. However, when you send messages to third-party systems, the recipient systems may not be able to interpret that element.

The Message class features a method, SetXMLDoc, that you can use to remove the tags upon execution of the method. Another alternative to removing the tags is to write a transformation to do so. If you do not use either option, the data remains in the wrapper through to the destination.

The following code example shows a non-XML file wrapped in the PeopleSoft non-XML message element, PsNonXmL, for transport through PeopleSoft Integration Broker:

Note: The element PsNonXml is not case-sensitive.

<?xml version="1.0"?>
<AsyncRequest>
  <data PsNonXml="Yes">
    <![CDATA[<?xml version="1.0"?>101 123456789 
    12345678902 0510145 60094101First Bank First Bank 5200 University 
    000001 PPDDIRECT PAY020510020510000112345678000000162200000111 222
    0000001000USA0000001 USA0000001 0000001110000001627123456
    789131415511 0000001000 University 0123456780000
    002 82000000020012345789000000001000000000001000 123456780000001
    90000010000010000000200123457890000000010000000000010009999999999
    99999999999999999999999999999999999999999999999999999999999999999
    99999999999999999999999999999999999999999999999999999999999999999
    99999999999999999999999999999999999999999999999999999999999999999
    99999999999999999999999999999999999999999999999999999999999999999
    99999999999999999999999999999999999999999999999999999999999999999
    99999999999999999999999999999999999999999
   ]]>
    </data>
</AsyncRequest>

The following example shows an alternative way to wrap a non-XML file in the PeopleSoft non-XML message element for transport through PeopleSoft Integration Broker:

<?xml version="1.0"?>
<AsyncRequest PsNonXml = ’Yes’>
<![CDATA[<?xml version="1.0"?>101 123456789 12345678902
0510145 60094101First Bank First Bank 5200 University 000001 PPDDIRECT 
PAY020510020510000112345678000000162200000111 222
0000001000USA0000001 USA0000001 0000001110000001627123456
789131415511 0000001000 University 0123456780000
002 82000000020012345789000000001000000000001000 123456780000001
900000100000100000002001234578900000000100000000000100099999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
99999999999999999999999999999999999999999999999999999999999999999999999
]]>
</AsyncRequest>

The following example shows using the SetXMLDoc method to remove the PsNonXML wrapper from a message:

// create xmldoc with PSNonXml tag and load it into the message 

// create an instance of the Message object  
&MSG = CreateMessage(OPERATION.QE_F18_ASYNC_XMLDOC);

// Load the Message object via the SetXmlDoc method with the xmldoc data. 
// This will also remove the PSNonXml wrapper
&MSG.SetXmlDoc(&XmlDoc); 

// perform a publish for the nonrowset-based message
%IntBroker.Publish(&MSG);

As stated previously in this section, if you do not use the SetXMLDoc method to remove the PsNonXml wrapper, you must write a transformation to physically remove the tags.

If a nonrowset-based message is used in a service operation which will be exposed as a WSDL to third parties, the schema cannot be empty. The schema has to have at least the header elements, as shown in the following example:

<?xml version="1.0"?> 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>

Nonrowset-Based Message Structures

XML Messages

SOAP-Compliant Messages

Non-XML Files

Using Nonrowset-Based Messages in Service Operations Exposed as WSDL