Understanding Supported Message Structures

This chapter discusses the message structures used by PeopleSoft Integration Broker to exchange request and response messages between the integration gateway and the application server, between other PeopleSoft systems, and between third-party integration partners. This chapter discusses:

• Internal message format for request messages.

• Internal message format for response messages.

• Accessing IBInfo elements using PeopleCode.

• Rowset-based message structure.

• PSCAMA.

• Identifying changes to field-level attributes.

• Nonrowset-based message structures.

• XML DOM-Compliant messages.

• SOAP-Compliant messages.

• Non-XML messages.

• Message part structures.

• Message container structures.

Integration Broker Message Structures

This section discusses the internal message formats for request messages and response messages, local compression, and how to access IBInfo elements.

Internal Message Format for Request Messages

This section discusses the format used to exchange request messages between the integration gateway and the application server. These messages are frequently referred to as IBRequest messages.

The Multipurpose Internet Mail Extension standard (MIME) is used as the basic structure for internal messaging. MIME has several advantages in that the standard is well-known and supported, and because it is text-based, it is human readable and easily serializable.

Messages using the internal format display in the integration gateway log file. Since the log file is a valuable tool for debugging, anyone reading the file will need to understand how the messages are structured.

Every request message contains three parts:

The following is an example of a request message in the PeopleSoft internal MIME format:

Message-ID: <-123.123.123.123@nowhere >
Mime-Version: 1.0
Content-Type: multipart/related; boundary="Integration_Server_MIME_Boundary"
Content-ID: PeopleSoft-Internal-Mime-Message
PeopleSoft-ToolsRelease: 8.51

--Integration_Server_MIME_Boundary
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: IBInfo
Content-Disposition: inline

<?xml version="1.0" ?> 
  <IBInfo>
   <TransactionID>
     <![CDATA[ caa3a040-bde5-11da-914c-ecaede80d83b]]> 
  </TransactionID>
  <ExternalOperationName>
  <![CDATA[ QE_FLIGHTPLAN_TRANSFORM.VERSION_1]]> 
  </ExternalOperationName>
  <OperationType>async</OperationType> 
  <From>
    <RequestingNode>
       <![CDATA[ QE_LOCAL]]> 
    </RequestingNode>
    <RequestingNodeDescription>
       <![CDATA[ ]]> 
    </RequestingNodeDescription>
    <NodePassword>
       <![CDATA[ password]]> 
    </NodePassword>
    <ExternalUserName>
    <![CDATA[ ]]> 
    </ExternalUserName>
    <ExternalUserPassword>
    <![CDATA[ ]]> 
    </ExternalUserPassword>
    <AuthToken>
       <![CDATA[ owAAAAQDAgEBAAAAvAIAAAAAAAAsAAAABABTaGRyAk4AbQg4AC4AMQ
        AwABTFZOonLEjJaPtR6v02oadvRUoSq2MAAAAFAFNkYXRhV3icHYhNDkAwGERfEQ
        srFyFN0cZSaGz8xAmcwA0dzug3yZv53gMUeWaM+s1IV11EFnZOysjBSv2bm01mZl
        L3Dqt4GrETHSHtQCs6cWBM2ybr9fMBbP0LSQ==]]> 
    </AuthToken>
    <WSA-ReplyTo>
       <![CDATA[ ]]> 
    </WSA-ReplyTo>
    <NodeDN>
       <![CDATA[ ]]> 
    </NodeDN>
    <OrigUser>
       <![CDATA[ QEDMO]]> 
    </OrigUser>
    <OrigNode>
       <![CDATA[ QE_LOCAL]]> 
    </OrigNode>
    <OrigProcess>
       <![CDATA[ QE_FLIGHTDATA]]> 
    </OrigProcess>
    <OrigTimeStamp>2006-03-27T15:02:39.280000-0800</OrigTimeStamp> 
    <DirectGatewayRequest /> 
    <SyncServiceTimeout /> 
    <ExternalMessageID>
       <![CDATA[ ]]> 
    </ExternalMessageID>
    <SegmentsUnOrder>N</SegmentsUnOrder> 
    <ConversationID>
       <![CDATA[ ]]> 
    </ConversationID>
    <WSA-MessageID>
       <![CDATA[ ]]> 
    </WSA-MessageID>
    <InReplyToID>
       <![CDATA[ ]]> 
    </InReplyToID>
    <DataChunk>
       <![CDATA[ ]]> 
    </DataChunk>
    <DataChunkCount>
       <![CDATA[ ]]> 
    </DataChunkCount>
    </From>
    <WS-Security>
      <WSTokenType>
         <![CDATA[ ]]> 
      </WSTokenType>
    </WS-Security>
    <To>
      <DestinationNode>
          <![CDATA[ QE_IBTGT]]> 
      </DestinationNode>
      <FinalDestinationNode>
         <![CDATA[ ]]> 
      </FinalDestinationNode>
      <AppServerDomain>
         <![CDATA[ ]]> 
      </AppServerDomain>
    </To>
    <Cookies>
       <![CDATA[ ]]> 
    </Cookies>
    <PathInfo>
       <![CDATA[ ]]> 
    </PathInfo>
    <HttpSession>
      <SessionID>
         <![CDATA[ ]]> 
      </SessionID>
    </HttpSession>
    <QStrArgs /> 
    <ContentSections>
       <ContentSection>
          <ID>ContentSection0</ID> 
          <NonRepudiation>N</NonRepudiation> 
          <Headers>
            <version>
               <![CDATA[ VERSION_1]]> 
            </version>
            <encoding>
               <![CDATA[ base64(deflate)]]> 
            </encoding>
            <encodedlength>
               <![CDATA[ 948(709)]]> 
            </encodedlength>
            <length>
               <![CDATA[ 2840]]> 
            </length>
          </Headers>
       </ContentSection>
     </ContentSections>
    <PublishNode>
       <![CDATA[ QE_LOCAL]]> 
    </PublishNode>
    <Queue>
       <![CDATA[ QE_FLIGHTPLAN_CHNL]]> 
    </Queue>
    <SubQueue>
       <![CDATA[ c9de8110-bde5-11da-be79-846b4e717ebf]]> 
    </SubQueue>
    <VisitedNodes>
       <![CDATA[ QE_LOCAL|]]> 
    </VisitedNodes>
    <Connector>
       <ConnectorName>
          <![CDATA[ PSFTTARGET]]> 
       </ConnectorName>
       <ConnectorClassName>
          <![CDATA[ PeopleSoftTargetConnector]]> 
       </ConnectorClassName>
       <RemoteFrameworkURL>
          <![CDATA[ ]]> 
       </RemoteFrameworkURL>
       <ConnectorParameters>
          <ConnectorParam>
             <Name>
               <![CDATA[ URL]]> 
             </Name>
             <Value>
                <![CDATA[ ]]> 
             </Value>
          </ConnectorParam>
       </ConnectorParameters>
      <ConnectorHeaders /> 
   </Connector>
  <AttachmentSection ResponseAsAttachment="N" /> 
</IBInfo>

--Integration_Server_MIME_Boundary
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: ContentSection0
Content-Disposition: inline

eJydll1P2zAUhu8n7T+g/gAKFdt6UYxOHCe1FH9gO1RwE1UMTUiMTRRN27+fk7SpvwItd/F57c
TvG+c5WVz9/fl08ufhZfP46/lycn56NrlCnz8trklTVLRcGlkBb4wCrguhGFoUjw9P382/3w8b
tJ+Ug4GT+6f1ZnM5UZNOAMxrlhF18mrnXk76wWTaaUzTRhOuxU7FS9hpopBxEbC5lSSuY6gqTU
seK/q6hlyJhIIFY+fp8iwuE8yCYk40VpXgZVCfeml0i1eSN1IRTYw+Ih1twFDBG569KUuhU/KK
gBQ8HVdR37VGeUHDzW9FIdtbx9oK1JJAnnDsWOxmcrihZbfBIxyv4FYKys2Y5YyAolHgVrDHsk
z4hMpQU+cJpYJRxb7REam1nnz8DakEpoYSHWs2iPakJCLbR7T1kIPaZnhEZv0yTSqCnXcWT2EiZ
alfLSQZ0TNQGkPiJHQLR2I3pYFU3V5yTqrWX/yq7iirzTIWpCoS2blh9esVA0b4Mcm9831BORIJ
TWy//9q0JDg8AlNnc2ghbZrMQ6TFalnbuBocflZQ59S0yAvjz0C3J3hsHdOlPQ/XFkLhUZVKYKJ
1Q7n1zjGJbMs6q6heNqquSEMTN+Y2Em69hCZ7X/bCbQts8yNfv67Rwrysnzfr+1fbWg5rFmj+bT
7ro9tV/H6B7C1UN8GpbdsGmp9eXHRaO9i3DVScz7f37IZue0Bfv1z0DxwqQ49AGXRKPxh6BMrwU
J7tegSyiRRduR3se8TAgrehiBKmXSh6GHTQ5+POR1yANQ9lIb48ZH0YUykXAaYCMKVg5AEohI4L
mhAuHlAGiHwQHCkvDjhcVAx4iJAwPfAv4KCHOX0/7PRRdw87utfFU53bp1X4K/MmvRDh5WLqFhy
CJajVz4+qLr4SyEJnFjZhLeSWzyqPTx6KpgOh9k6D/9z/1gQ1Ww==
--Integration_Server_MIME_Boundary--

IBRequest Header Section

The first part of a request message contains headers which describe the attributes of the whole message.

Message-ID: <-123.123.123.123@nowhere >
Mime-Version: 1.0
Content-Type: multipart/related; boundary="Integration_Server_MIME_Boundary"
Content-ID: PeopleSoft-Internal-Mime-Message
PeopleSoft-ToolsRelease: 8.51

--Integration_Server_MIME_Boundary
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: IBInfo
Content-Disposition: inline

IBRequest IBInfo Section

The following example shows an IBInfo section for a request message that was sent from the application server to the integration gateway (formatted for easier reading):

<?xml version="1.0" ?> 
  <IBInfo>
   <TransactionID>
     <![CDATA[ caa3a040-bde5-11da-914c-ecaede80d83b]]> 
  </TransactionID>
  <ExternalOperationName>
  <![CDATA[ QE_FLIGHTPLAN_TRANSFORM.VERSION_1]]> 
  </ExternalOperationName>
  <OperationType>async</OperationType> 
  <From>
    <RequestingNode>
       <![CDATA[ QE_LOCAL]]> 
    </RequestingNode>
    <RequestingNodeDescription>
       <![CDATA[ ]]> 
    </RequestingNodeDescription>
    <NodePassword>
       <![CDATA[ password]]> 
    </NodePassword>
    <ExternalUserName>
    <![CDATA[ ]]> 
    </ExternalUserName>
    <ExternalUserPassword>
    <![CDATA[ ]]> 
    </ExternalUserPassword>
    <AuthToken>
       <![CDATA[ owAAAAQDAgEBAAAAvAIAAAAAAAAsAAAABABTaGRyAk4AbQg4AC4AMQ
        AwABTFZOonLEjJaPtR6v02oadvRUoSq2MAAAAFAFNkYXRhV3icHYhNDkAwGERfEQ
        srFyFN0cZSaGz8xAmcwA0dzug3yZv53gMUeWaM+s1IV11EFnZOysjBSv2bm01mZl
        L3Dqt4GrETHSHtQCs6cWBM2ybr9fMBbP0LSQ==]]> 
    </AuthToken>
    <WSA-ReplyTo>
       <![CDATA[ ]]> 
    </WSA-ReplyTo>
    <NodeDN>
       <![CDATA[ ]]> 
    </NodeDN>
    <OrigUser>
       <![CDATA[ QEDMO]]> 
    </OrigUser>
    <OrigNode>
       <![CDATA[ QE_LOCAL]]> 
    </OrigNode>
    <OrigProcess>
       <![CDATA[ QE_FLIGHTDATA]]> 
    </OrigProcess>
    <OrigTimeStamp>2006-03-27T15:02:39.280000-0800</OrigTimeStamp> 
    <DirectGatewayRequest /> 
    <SyncServiceTimeout /> 
    <ExternalMessageID>
       <![CDATA[ ]]> 
    </ExternalMessageID>
    <SegmentsUnOrder>N
    </SegmentsUnOrder> 
    <ConversationID>
       <![CDATA[ ]]> 
    </ConversationID>
    <WSA-MessageID>
       <![CDATA[ ]]> 
    </WSA-MessageID>
    <InReplyToID>
       <![CDATA[ ]]> 
    </InReplyToID>
    <DataChunk>
       <![CDATA[ ]]> 
    </DataChunk>
    <DataChunkCount>
       <![CDATA[ ]]> 
    </DataChunkCount>
    </From>
    <WS-Security>
      <WSTokenType>
         <![CDATA[ ]]> 
      </WSTokenType>
    </WS-Security>
    <To>
      <DestinationNode>
          <![CDATA[ QE_IBTGT]]> 
      </DestinationNode>
      <FinalDestinationNode>
         <![CDATA[ ]]> 
      </FinalDestinationNode>
      <AppServerDomain>
         <![CDATA[ ]]> 
      </AppServerDomain>
    </To>
    <Cookies>
       <![CDATA[ ]]> 
    </Cookies>
    <PathInfo>
       <![CDATA[ ]]> 
    </PathInfo>
    <HttpSession>
      <SessionID>
         <![CDATA[ ]]> 
      </SessionID>
    </HttpSession>
    <QStrArgs /> 
    <ContentSections>
       <ContentSection>
          <ID>ContentSection0</ID> 
          <NonRepudiation>N</NonRepudiation> 
          <Headers>
            <version>
               <![CDATA[ VERSION_1]]> 
            </version>
            <encoding>
               <![CDATA[ base64(deflate)]]> 
            </encoding>
            <encodedlength>
               <![CDATA[ 948(709)]]> 
            </encodedlength>
            <length>
               <![CDATA[ 2840]]> 
            </length>
          </Headers>
       </ContentSection>
     </ContentSections>
    <PublishNode>
       <![CDATA[ QE_LOCAL]]> 
    </PublishNode>
    <Queue>
       <![CDATA[ QE_FLIGHTPLAN_CHNL]]> 
    </Queue>
    <SubQueue>
       <![CDATA[ c9de8110-bde5-11da-be79-846b4e717ebf]]> 
    </SubQueue>
    <VisitedNodes>
       <![CDATA[ QE_LOCAL|]]> 
    </VisitedNodes>
    <Connector>
       <ConnectorName>
          <![CDATA[ PSFTTARGET]]> 
       </ConnectorName>
       <ConnectorClassName>
          <![CDATA[ PeopleSoftTargetConnector]]> 
       </ConnectorClassName>
       <RemoteFrameworkURL>
          <![CDATA[ ]]> 
       </RemoteFrameworkURL>
       <ConnectorParameters>
          <ConnectorParam>
             <Name>
               <![CDATA[ URL]]> 
             </Name>
             <Value>
                <![CDATA[ ]]> 
             </Value>
          </ConnectorParam>
       </ConnectorParameters>
      <ConnectorHeaders /> 
   </Connector>
  <AttachmentSection ResponseAsAttachment="N" /> 
</IBInfo>

While the basic structure is the same for all requests, not all elements are always required. An example of this is the Connector section. The Connector XML is used to tell the integration gateway to route a message to the named target connector. It also lists configuration parameters for the outbound request. This XML would only be seen in requests sent from the application server to the integration gateway. For requests going in the other direction, the section would be empty.

Note. The only element that is always required is ExternalOperationName.

The following is a list of the most important elements that may appear in the IBInfo section:

IBRequest Content Section

The content section of a request message features the message body.

--Integration_Server_MIME_Boundary
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: ContentSection0
Content-Disposition: inline
eJydll1P2zAUhu8n7T+g/gAKFdt6UYxOHCe1FH9gO1RwE1UMTUiMTRRN27+fk7SpvwItd/F5
eJydll1P2zAUhu8n7T+7c TvG+c5WVz9/fl08ufhZfP46/lycn56NrlCnz8trklTVLRcGlkBb
4wCrguhGFoUjw9P382/3w TvG+8btJ+Ug4GT+6f1ZnM5UZNOAMxrlhF18mrnXk76wWTaaUzTRh
OuxU7FS9hpopBxEbC5lSSuY6gqtJ+Ug4GT+TUseK/q6hlyJhIIFY+fp8iwuE8yCYk40VpXgZVC
feml0i1eSN1IRTYw+Ih1twFDBG569KUuhU/KKgBQ8HVdR37VGeUHDzW9FIdtbx9oK1JJAnnDsWO
xmcrihZbfBIxyv4FYKys2Y5YyAolHgVrDHskz4hMpQU+cJpYJRxb7REam1nnz8DakEpoYSHWs2i
PakJCLbR7T1kIPaZnhEZv0yTSqCnXcWT2z4hMpQU+EiZalfLSQZ0TNQGkPiJHQLR2I3pYFU3V5y
TqrWX/yq7iirzTIWpCoS2blh9esVA0b4Mcm9831BORIJTWy//9q0JDg8AlNnc2ghbZrMQ6TFalnb
uBocflZQ59S0yAvjz0C3J3hsHdOlPQ/XFkLhUZVKYKJ1Q7n1zjGJbMs6q6heNqquSEMTN+Y2Em69
hCZ7X/bCbQts8yNfv67Rwrysnzfr+1fbWg5rFmj1Q7n1zjGJbMs6q6heNqquSEMTN++bT
7ro9tV/H6B7C1UN8GpbdsGmp9eXHRaO9i3DVScz7f37IZue0Bfv1z0DxwqQ49AGXRKPxh6BMrwU
J7tegSyiRRduR3se8TAgrehiBKmXSh6GHTQ5+POR1yANQ9lIb48ZH0YUykXAaYCMKVg5AEoh
J7tegSyiRRduR3se8TAgrehiBKmXSh6GHTQ5+I4LmhAuHlAGiHwQHCkvDjhcVAx4iJAwPfAv4KCHOX0
/7PRRdw87utfFU53bp1X4K/MmvRDh5WLqFhyCJajVz4+qLr4SyEJnFjZhLeSWzyqPTx6KpgOh9k6D
/9z/1gQ1Ww==

Internal Message Format for Response Messages

The internal format for response messages parallels that for request messages, and has the same basic MIME structure. These messages are frequently referred to as IBResponse messages.

There are three logical components to a MIME response message: the IBResponse header section, the IBInfo section, and the Content section.

The following code shows an example of a response message:

Message-ID: <32004392.1143500580241.JavaMail.KCOLLIN2@PLE-KCOLLIN2>
Date: Mon, 27 Mar 2006 15:03:00 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 
	boundary="----=_Part_4_9069393.1143500580221"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message
PeopleSoft-ToolsRelease: 8.51

------=_Part_4_9069393.1143500580221
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Content-ID: IBInfo

<?xml version="1.0"?><IBInfo><Status><StatusCode>0</StatusCode>
<MsgSet>158</MsgSet>

<MsgID>10000</MsgID><DefaultTitle>Integration Broker Response 
Message</DefaultTitle>

</Status><ContentSections><ContentSection><ID>ContentSection0</ID>
<NonRepudiation>N</NonRepudiation></ContentSection></ContentSections></IBInfo>
------=_Part_4_7210339.1008355101202

IBResponse Header

The first part of a response message contains headers which describe the attributes of the whole message.

Message-ID: <32004392.1143500580241.JavaMail.KCOLLIN2@PLE-KCOLLIN2>
Date: Mon, 27 Mar 2011 15:03:00 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 
	boundary="----=_Part_4_9069393.1143500580221"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message
PeopleSoft-ToolsRelease: 8.51

IBResponse IBInfo Section

The format for the XML for the IBInfo for a response message is different than that for the request message. The following is a sample (formatted for easier reading):

<?xml version="1.0"?>
<IBInfo>
   <Status>
      <StatusCode>0</StatusCode>
      <MsgSet>158</MsgSet>
      <MsgID>10000</MsgID>
      <DefaultMsg>OK</DefaultMsg>
      <DefaultTitle>Integration Broker Response Message</DefaultTitle>  
   </Status>  
   <ContentSections>
      <ContentSection>
      <ID>ContentSection0</ID>
      <NonRepudiation>N</NonRepudiation>
      </ContentSection>
   </ContentSections>
</IBInfo>

The following is the list of all the elements that may be present in the IBInfo for a response:

IBResponse Content Section

The content section of a response message features the message body only when working with SyncRequests

<?xml version="1.0"?>
<TestXml>This is a sample response message.</TestXml>

Error Codes and Message Catalog Entries

A response message may contain data relating to the processing of the request message, or it may contain error information if there were problems in fulfilling the request.

The status code describes the nature of the response message. The following table describes possible request message status codes and their meaning.

All PeopleSoft Integration Broker error messages are stored in the message catalog. A short and long description for every error can be found there. Catalog entries are given a number, and this number is used in the response messages.

Here is a sample error message:

Message-ID: <32004392.1143500580241.JavaMail.KCOLLIN2@PLE-KCOLLIN2>
Date: Mon, 27 Mar 2006 15:03:00 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 
	boundary="----=_Part_4_9069393.1143500580221"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message
PeopleSoft-ToolsRelease: 8.51

------=_Part_25_2235074.1008270392277
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Content-ID: IBInfo

<?xml version="1.0"?><IBInfo><Status><StatusCode>10</StatusCode><MsgSet>158</Msg⇒
Set>
​<MsgID>10721</MsgID><Parameters count="1"><Parm>404</Parm></Parameters>
<DefaultTitle>Integration Gateway Error</DefaultTitle></Status></IBInfo>
------=_Part_25_2235074.1008270392277--

All PeopleSoft Integration Broker errors use message set 158. The actual error seen here is 10721. Going to the message catalog, the description for message set 158, error 10721 is:

Message Text: Integration Gateway - External System Contact Error

Explanation: Integration Gateway was not able to contact the external system.  
The network location specified may be incorrect, or the site is permanently 
or temporarily down.

Therefore this error was created by the integration gateway when it tried to send a request message to an external system.

Local Compression

This section provides an overview of local compression and discusses how to:

• Set local compression for asynchronous messages.

• Set local compression for synchronous messages.

• Override local compression for synchronous messages.

Understanding Local Compression

The integration engine compresses and base64–encodes messages destined for the PeopleSoft listening connector on its local integration gateway.

Setting Local Compression for Asynchronous Messages

Asynchronous messages are always compressed and base64 encoded when sent to the integration gateway. There are no settings you need to make.

Setting Local Compression for Synchronous Messages

In PSAdmin you can set a threshold message size above which the system compresses synchronous messages. The setting is shown here:

Values for config section - Integration Broker
    Min Message Size For Compression=10000

Do you want to change any values (y/n)? [n]:

The value is the message size in bytes; the default value is 10000 (10 kilobytes). You can specify a setting of 0 to compress all messages.

To turn off compression, set the value to -1.

Warning! Turning compression off can negatively impact system performance when transporting synchronous messages greater than 1 MB. As a result, you should turn off compression only during integration development and testing.

Note. This setting does not affect the compression of messages that the integration gateway sends using its target connectors.

Overridding Local Compression for Synchronous Messages

You can override the PSAdmin message compression setting for synchronous messages at the transaction level. The following method on the IBInfo object in the Message class is provided for this purpose:

&MSG.IBInfo.CompressionOverride

The valid parameters for this method are: %IntBroker_Compress, %IntBroker_UnCompress, and %IntBroker_Compress_Reset.

See Message Classes.

See Also

Setting Application Server Domain Parameters

Accessing IBInfo Elements Using PeopleCode

You can use the PeopleCode Message object to access IBRequest and IBResponse IBInfo data.

The following example demonstrates reading target connector information on a notification method for a rowset-based asynchronous message.

method OnNotify
   /+ &_MSG as Message +/
   /+ Extends/implements PS_PT:Integration:INotificationHandler.OnNotify +/
   /* Variable Declaration */

   integer &i;
   string &strReturn; 
   rowset &RS;
   
   For &i = 1 To &MSG.IBInfo.IBConnectorInfo.GetNumberOfConnectorProperties()
   /* get Query arguments */ 
   
      &strReturn = &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgName(&i);
      &strReturn = &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgValue(&i);
      
   End-For;
   
   /* access the content data */

&RS = &MSG.GetRowset();
  
end-method;

The following example demonstrates reading target connector information on notification method for a nonrowset-based asynchronous message.

method OnNotify
   /+ &_MSG as Message +/
   /+ Extends/implements PS_PT:Integration:INotificationHandler.OnNotify +/
   /* Variable Declaration */

   integer &i;

   string &&strReturn;

   xmldoc &xmldoc;
   
   For &i = 1 To &MSG.IBInfo.IBConnectorInfo.GetNumberOfConnectorProperties()
      
      &strReturn = &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgName(&i);
      &strReturn = &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgValue(&i);
      
   End-For;
   
   /* access the content data */

&xmldoc = &MSG.GetXmlDoc();
  
end-method;

If an HTTP header is passed with a dollar sign ($), PeopleSoft Integration Broker converts the dollar sign to an underscore (_).

PeopleSoft Rowset-Based Message Format

This section discusses the PeopleSoft rowset-based message format and discusses:

• FieldTypes section of a rowset-based message.

• MsgData section of a rowset-based message.

• PeopleSoft rowset-based message example.

• PeopleSoft timestamp format.

• CDATA and special characters.

• Schema restrictions.

This section also provides an example of a rowset-based message.

See Also

Message Part Structures

Understanding the PeopleSoft Rowset-Based Message Format

To work with rowset-based messages—the PeopleSoft native format—you define a message in the PeopleSoft Pure Internet Architecture, insert records into the message definition in a hierarchical structure, and then populate the message and manipulate its contents by using the PeopleCode Rowset and Message classes. Externally, the message is transmitted as XML with a prescribed PeopleSoft schema.

The PeopleSoft message schema includes a PSCAMA record, which PeopleTools adds to every level of the message structure to convey basic information about the message and its data rows.

The Rowset and IntBroker classes are recommended for messaging between PeopleSoft applications. If a message is populated with data from a PeopleSoft application’s database or component buffer, the Message class is best for handling that data.

Record and Field Aliases

You can specify an alias for any record or field in a rowset-based message definition. Each node participating in a transaction maintains its own independent definition of the message and its versions, including record and field names and their aliases.

When you send a message with an alias defined and the message is converted to XML for sending, only the alias appears in the XML. If you don’t specify an alias, the original name is used. If the service operation is routed to multiple target nodes with different record or field naming schemes, you create for each target a separate service operation version with its own aliases and send each version separately.

The only requirement for a successful transaction is that the record and field names in the XML match either the original names or the aliases that are defined for that message and version at the node receiving the message. This behavior applies to both request and synchronous response messages, but typically only the source node applies aliases to accommodate the target node’s naming scheme in both directions.

In a synchronous transaction, the request and response messages can be completely different from each other. Upon receiving a synchronous request, the target node generates and sends a response message. Upon receiving the response, the source node uses its defined aliases to find and reapply its original record and field names. The resulting inbound message contains the original names that were defined at the source node, not the aliases. Therefore, both the sending and receiving PeopleCode at the source node should expect to work with the source node’s original record and field names.

See Also

PSCAMA

Understanding Integration PeopleCode

Applying Filtering, Transformation and Translation

Rowset-Based Message Template

The following template shows the overall structure of a message in the PeopleSoft rowset-based message format:

<?xml version="1.0"?>
   <psft_message_name>
      <FieldTypes>
         ...
      </FieldTypes>
      <MsgData>
         <Transaction>
            ...
         </Transaction>
      </MsgData>
   </psft_message_name>

Note. Psft_message_name is the name of the message definition in the PeopleSoft database. Integration Broker inserts this message content into a standard PeopleSoft XML message wrapper for transmission.

FieldTypes Section

Each PeopleSoft message includes field type information. Fieldtype information conveys the name of each data record and its constituent fields, along with each field’s data type. Your receiving application can use this information to validate data types. The field type information is contained in the FieldTypes section of the message.

There are two FieldTypes tags:

• Each record tag consists of the name of a record, followed by a class attribute with a single valid value: R. The record tag encloses that record’s field tags.

• Each field tag consists of the name of a field, followed by a type attribute with three valid values: CHAR for a character field, DATE for a date field, and NUMBER for a numeric field.

Following is a simple FieldTypes template.

<FieldTypes>
   <recordname1 class="R">
      <fieldname1 type="CHAR"/>
      <fieldname2 type="DATE"/>
      <fieldname3 type="NUMBER"/>
   </recordname1>
   <recordname2 class="R">
      <fieldname4 type="NUMBER"/>
   </recordname2>
<FieldTypes>

Note. Third-party sending applications must include a valid FieldTypes section in each message. The PeopleSoft system expects fieldtype information for each record and field in the message.

MsgData Section

In addition to field type information, each PeopleSoft message contains data content in the MsgData section of the message. Between the MsgData tags are one or more Transaction sections. Each transaction represents one row of data.

Between the Transaction tags is a rowset hierarchy of records and fields. The record tags at each level contain the fields for that record, followed by any records at the next lower level.

The last record within a transaction is a fully specified PeopleSoft Common Application Message Attributes (PSCAMA) record, which provides information about the entire transaction. Immediately following the closing tag of every record below level 0 is a PSCAMA record containing only the AUDIT_ACTN field that specifies the action for that record.

Simple MsgData Template

Following is a simple MsgData template.

Note. The PSCAMA PUBLISH_RULE_ID and MSGNODENAME fields (shown emphasized) are used internally by certain PeopleSoft utilities, but third-party systems can generally ignore them and don’t need to include them in messages.

<MsgData>
   <Transaction>
      <level0recname1 class="R">
         <fieldname1>value</fieldname1>
         <fieldname2>value</fieldname2>
         <level1recname1 class="R">
            <fieldname3>value</fieldname3>
            <fieldname4>value</fieldname4>
         </level1recname1>
         <PSCAMA class="R">
            <AUDIT_ACTN>value</AUDIT_ACTN>
         </PSCAMA>
         <level1recname2 class="R">
            <fieldname5>value</fieldname5>
         </level1recname2>
         <PSCAMA class="R">
            <AUDIT_ACTN>value</AUDIT_ACTN>
         </PSCAMA>
      </level0recname1>
      <level0recname2 class="R">
         <fieldname6>value</fieldname6>
      </level0recname2>
      <PSCAMA class="R">
         <LANGUAGE_CD>value</LANGUAGE_CD>
         <AUDIT_ACTN>value</AUDIT_ACTN>
         <BASE_LANGUAGE_CD>value</BASE_LANGUAGE_CD>
         <MSG_SEQ_FLG>value</MSG_SEQ_FLG>
         <PROCESS_INSTANCE>value</PROCESS_INSTANCE>
        ​<PUBLISH_RULE_ID>value</PUBLISH_RULE_ID>
        ​<MSGNODENAME>value</MSGNODENAME>
      </PSCAMA>
   <Transaction>
</MsgData>

See Also

PSCAMA

PSCAMA

PeopleTools adds the PSCAMA record to every level of the message structure during processing. It isn’t accessible in the message definition, but you can reference it as part of the Message object in the sending and receiving PeopleCode, and you can see it in the Integration Broker Monitor. PeopleCode processes this record the same way as any other record.

Note. PSCAMA records are automatically included in messages only if you insert database records to define the message structure. You can use the PeopleCode XmlDoc class to handle an inbound message containing PSCAMA records, but the PeopleCode Message class is much better suited for this.

PSCAMA contains fields that are common to all messages. The <PSCAMA> tag repeats for each row in each level of the transaction section of the message. The sender can set PSCAMA fields to provide basic information about the message; for example, to indicate the message language or the type of transaction a row represents. When receiving a message, your PeopleCode should inspect the PSCAMA records for this information and respond accordingly.

PSCAMA Record Definition

The PSCAMA record definition includes the following fields:

Language Codes

Each message can contain only one language code (the LANGUAGE_CD field) in the first PSCAMA record.

PeopleSoft language codes contain three characters and are mapped to corresponding International Organization for Standardization (ISO) locale codes in an external properties file. This mapping enables the PeopleSoft Pure Internet Architecture to derive certain defaults from the ISO locales that are stored in a user's browser settings. Your PeopleSoft application is delivered with a set of predefined language codes; you can define your own codes, as well.

Note. There can be only one language code for the entire message. To send messages in multiple languages, send multiple messages.

See Controlling International Preferences.

Audit Action Codes

A PSCAMA record appears following each row of the message. At a minimum, it contains an audit action code (the AUDIT_ACTN field), denoting the action to be applied to the data row. The audit action is required so that the receiving system knows how to process the incoming data.

The valid audit action codes match those that are used in the PeopleSoft audit trail processing: A, C, D, K, N, O, and blank.

The audit action values are set by the system or by the sending PeopleCode to specify that a record should be added, changed, or deleted:

Other PSCAMA Considerations

You can update values on the PSCAMA record just like any other record in the message definition before sending the message.

The receiving process can access the fields in this record just like any other fields in the message.

The size of the PSCAMA record varies. In particular, notice a difference between the first PSCAMA record and the ones that follow. The first record contains all of the fields, while the other PSCAMA records have only the AUDIT_ACTN field, which is the only field that can differ for each row of data.

Although the first PSCAMA record is always present, not all of the remaining PSCAMA records are sent in the message. If a <PSCAMA> tag is not included for a specific row, you can assume that the row hasn’t changed. In addition, if the <AUDIT_ACTN> tag is blank or null, you can also assume the row hasn’t changed.

If you’re receiving a message that has incremental changes, only the rows that have changed and their parent rows are present in the message.

You can view an example of an outbound message with the PSCAMA records inserted by testing your message definition using the Schema Tester.

See Using the Schema Tester Utility.

Identifying Changes to Field-Level Attributes

When sending and receiving messages, all blank data values get stripped. As a result, you cannot determine if a field value is blank by definition, or if its value was stripped in the messaging process.

The PeopleCode CopyRowset functions CopyRowset, CopyRowsetDelta and CopyRowsetDeltaOriginal, feature an IsChanged attribute that automatically gets set to identify fields that have been changed. Any field that has been changed displays the attribute IsChanged="Y".

Note. The IsChanged attribute applies only to rowset-based messages. For rowset-based message parts, use the Message Part Default Indicator field to distinguish blanks from zeros in part messages. The IsChanged attribute does not apply to nonrowset-based messages, including nonrowset-based container messages and nonrowset-based part messages.

For example:

<QE_ACNUMBER IsChanged="Y">2</QE_ACNUMBER>

Fields that had data and then were blanked contain the IsChanged attribute.

For example:

<DESCRLONG IsChanged="Y"/>

Fields that were always blank and thus were not changed do not feature this attribute. For example:

<QE_NAVDESC/>

If you are writing subscription PeopleCode you reference the IsChanged value of the field in the message rowset, as always. However, the blanks appear with the attribute IsChanged="Y".

See Also

Distinguishing Blank from Zero in Rowset-Based Part Messages

PeopleSoft Timestamp Format

The PeopleSoft format for all timestamps is ISO-8601. If any message fields are type timestamp, the following format is used:

CCYY-MM-DDTHH:MM:SS.ssssss+/-hhmm

Note. The ISO format specifies that the +/-hhmm parameter is optional, but PeopleSoft requires it. All date and time stamps in the header and the body of the message must include the Greenwich Mean Time (GMT) offset as +/-hhmm. This ensures that the timestamp is correctly understood by the receiving application.

CDATA and Special Characters

Consider the following points regarding rowset-based messages:

• You cannot use CDATA in message XML if you plan to use GetRowSet to parse the message.

• When using the ampersand character (&) in a string, it must be URL-encoded. For example: &amp. Passing only the ampersand character results in a PeopleCode error when you get the rowset values.

• Other special characters are best passed encoded as well, such as &gt for “<” and &lt ">."

Schema Restrictions

For stronger schema validation control, some PeopleSoft field types have certain implicit restrictions regarding the format of field data that is acceptable in a runtime message. These restrictions appear in message schema.

The restrictions apply to fields having the following formats.

• Mixed case.

• Name.

• Phone number.

• Social security number.

• Uppercase.

• Zip code.

Note. These restrictions apply to rowset-based messages and rowset-based message parts.

The restrictions for each are shown in the following example:

 <xsd:simpleType name="BASE_LANGUAGE_CD_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>BASE_LANGUAGE_CD is a character of length 3. 
        Allows Uppercase characters including numbers
      </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:maxLength value="3"/> 
      <xsd:whiteSpace value="preserve"/> 
      <xsd:pattern value="([A-Z]|[0-9]|\p{Z}|\p{P}|\p{Lu})*"/> 
    </xsd:restriction> 
  </xsd:simpleType>

Rowset-Based Message Example

The message data is enclosed in a tag with the name of the message, and consists of one FieldTypes section followed by one MsgData section. The FieldTypes section describes the records and fields that appear in the MsgData section, which contains the actual data.

Note. The PSCAMA record requires field type information just like any other record.

<SDK_BUS_EXP_APPR_MSG>
   <FieldTypes>
      <SDK_BUS_EXP_PER class="R">
         <SDK_EMPLID type="CHAR"/>
         <SDK_EXP_PER_DT type="DATE"/>
         <SDK_SUBMIT_FLG type="CHAR"/>
         <SDK_INTL_FLG type="CHAR"/>
         <SDK_APPR_STATUS type="CHAR"/>
         <SDK_APPR_INSTANCE type="NUMBER"/>
         <SDK_DESCR type="CHAR"/>
         <SDK_COMMENTS type="CHAR"/>
      </SDK_BUS_EXP_PER>
      <SDK_DERIVED class="R">
         <SDK_BUS_EXP_SUM type="NUMBER"/>
      </SDK_DERIVED>
      <SDK_BUS_EXP_DTL class="R">
         <SDK_CHARGE_DT type="DATE"/>
         <SDK_EXPENSE_CD type="CHAR"/>
         <SDK_EXPENSE_AMT type="NUMBER"/>
         <SDK_CURRENCY_CD type="CHAR"/>
         <SDK_BUS_PURPOSE type="CHAR"/>
         <SDK_DEPTID type="CHAR"/>
      </SDK_BUS_EXP_DTL>
      <PSCAMA class="R">
         <LANGUAGE_CD type="CHAR"/>
         <AUDIT_ACTN type="CHAR"/>
         <BASE_LANGUAGE_CD type="CHAR"/>
         <MSG_SEQ_FLG type="CHAR"/>
         <PROCESS_INSTANCE type="NUMBER"/>
      </PSCAMA>
   </FieldTypes>
   <MsgData>
      <Transaction>
         <SDK_BUS_EXP_PER class="R">
            <SDK_EMPLID>8001</SDK_EMPLID>
            <SDK_EXP_PER_DT>1998-08-22</SDK_EXP_PER_DT>
            <SDK_SUBMIT_FLG>N</SDK_SUBMIT_FLG>
            <SDK_INTL_FLG>N</SDK_INTL_FLG>
            <SDK_APPR_STATUS>P</SDK_APPR_STATUS>
            <SDK_APPR_INSTANCE>0</SDK_APPR_INSTANCE>
            <SDK_DESCR>Regional Users Group Meeting</SDK_DESCR>
            <SDK_COMMENTS>Attending Northeast Regional Users Group
            Meeting and presented new release functionality.
            </SDK_COMMENTS>
            <SDK_BUS_EXP_DTL class="R">
               <SDK_CHARGE_DT>1998-08-22</SDK_CHARGE_DT>
               <SDK_EXPENSE_CD>10</SDK_EXPENSE_CD>
               <SDK_EXPENSE_AMT>45.690</SDK_EXPENSE_AMT>
               <SDK_CURRENCY_CD>USD</SDK_CURRENCY_CD>
               <SDK_BUS_PURPOSE>Drive to Meeting</SDK_BUS_PURPOSE>
               <SDK_DEPTID>10100</SDK_DEPTID>
            </SDK_BUS_EXP_DTL>
            <PSCAMA class="R">
               <AUDIT_ACTN>A</AUDIT_ACTN>
            </PSCAMA>
            <SDK_BUS_EXP_DTL class="R">
               <SDK_CHARGE_DT>1998-08-22</SDK_CHARGE_DT>
               <SDK_EXPENSE_CD>09</SDK_EXPENSE_CD>
               <SDK_EXPENSE_AMT>12.440</SDK_EXPENSE_AMT>
               <SDK_CURRENCY_CD>USD</SDK_CURRENCY_CD>
               <SDK_BUS_PURPOSE>City Parking</SDK_BUS_PURPOSE>
               <SDK_DEPTID>10100</SDK_DEPTID>
            </SDK_BUS_EXP_DTL>
            <PSCAMA class="R">
               <AUDIT_ACTN>A</AUDIT_ACTN>
            </PSCAMA>
         </SDK_BUS_EXP_PER>
         <SDK_DERIVED class="R">
            <SDK_BUS_EXP_SUM>58.13</SDK_BUS_EXP_SUM>
         </SDK_DERIVED>
         <PSCAMA class="R">
            <LANGUAGE_CD>ENG</LANGUAGE_CD>
            <AUDIT_ACTN>A</AUDIT_ACTN>
            <BASE_LANGUAGE_CD>ENG</BASE_LANGUAGE_CD>
            <MSG_SEQ_FLG></MSG_SEQ_FLG>
            <PROCESS_INSTANCE>0</PROCESS_INSTANCE>
         </PSCAMA>
      </Transaction>
   </MsgData>
</SDK_BUS_EXP_APPR_MSG>

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.

XML Messages

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.

SOAP-Compliant Messages

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.

See Also

Generating and Sending Messages

Receiving and Processing Messages

Non-XML Files

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, you must write a transformation to physically remove the tags.

See Also

Message Classes

Applying Filtering, Transformation and Translation

Complying With Message Formatting and Transmission Requirements

Using Nonrowset-Based Messages in Service Operations Exposed as WSDL

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"/>

Message Part Structures

This section discusses:

• Rowset-based message parts.

• Nonrowset-based message parts.

Understanding Message Part Structures

Message parts are rowset-based messages or nonrowset-based messages that you designate as a part message on the message definition. Message parts are used in container messages

Message parts can be re-used in multiple containers.

All parts in a container must be of the same type (Rowset-based or Nonrowset-based).

You create messages using the Message Builder page in the PeopleSoft Pure Internet Architecture.

See Also

PeopleSoft Rowset-Based Message Format

Nonrowset-Based Message Structures

Managing Messages

Rowset-Based Message Parts

Rowset-based message parts provide all the ease of use of using rowsets, yet the generated XML message is industry standard and not PeopleSoft proprietary. Rowset-based message parts, like nonrowset-based parts, can only be part of a container type message.

These are the benefits of using Rowset-based parts:

• The XML schema generated is standard XML and not the PeopleSoft message format. Rowset-based message parts do not have a PSCAMA section, FieldTypes section, IsChanged attributes, and so forth.

• The message API for rowset-based parts is simple to use and understand.

• XML serialization and deserialization to and from part rowset is provided by Integration Broker framework.

• You can use a CopyRowSet type method to populate the rowset from another rowset (component rowset).

The following example shows a sample schema from a rowset-based message part:

<?xml version="1.0"?> 
<xsd:schema elementFormDefault="qualified" targetNamespace="http://xmlns.
oracle.com/Enterprise/Tools/schemas/Part_1.V1" xmlns="http://xmlns.oracle.
com/Enterprise/Tools/schemas/Part_1.V1" xmlns:xsd="http://www.w3.org/
2001/XMLSchema"> 
  <xsd:element name="Part_1" type="Part_1_TypeShape"/> 
  <xsd:complexType name="Part_1_TypeShape"> 
    <xsd:sequence> 
      <xsd:element name="First_Part" type="First_PartMsgDataRecord_TypeShape"/> 
    </xsd:sequence> 
  </xsd:complexType> 
  <xsd:complexType name="First_PartMsgDataRecord_TypeShape"> 
    <xsd:sequence> 
      <xsd:element name="QE_ACNUMBER" type="QE_ACNUMBER_TypeDef"/> 
      <xsd:element name="QE_WAYPOINT_NBR" type="QE_WAYPOINT_NBR_TypeDef"/> 
      <xsd:element minOccurs="0" name="QE_BEARING" type="QE_BEARING_TypeDef"/> 
      <xsd:element minOccurs="0" name="QE_RANGE" type="QE_RANGE_TypeDef"/> 
      <xsd:element minOccurs="0" name="QE_ALTITUDE" type="QE_ALTITUDE_TypeDef"/> 
      <xsd:element minOccurs="0" name="QE_LATITUDE" type="QE_LATITUDE_TypeDef"/> 
      <xsd:element minOccurs="0" name="QE_LONGITUDE" type="QE_LONGITUDE_TypeDef"/> 
      <xsd:element name="QE_HEADING" type="QE_HEADING_TypeDef"/> 
      <xsd:element name="QE_VELOCITIES" type="QE_VELOCITIES_TypeDef"/> 
      <xsd:element minOccurs="0" name="QE_NAVDESC" type="QE_NAVDESC_TypeDef"/> 
    </xsd:sequence> 
    <xsd:attribute fixed="R" name="class" type="xsd:string" use="required"/> 
  </xsd:complexType> 
  <xsd:simpleType name="QE_ACNUMBER_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_ACNUMBER is a number of length 10 with a decimal 
        position of 0</xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:integer"> 
      <xsd:totalDigits value="10"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_WAYPOINT_NBR_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_WAYPOINT_NBR is a number of length 3 with a decimal 
        position of 0</xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:integer"> 
      <xsd:totalDigits value="3"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_BEARING_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_BEARING is a character of length 10
      </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:maxLength value="10"/> 
      <xsd:whiteSpace value="preserve"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_RANGE_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_RANGE is a character of length 10</xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:maxLength value="10"/> 
      <xsd:whiteSpace value="preserve"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_ALTITUDE_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_ALTITUDE is a character of length 10
      </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:maxLength value="10"/> 
      <xsd:whiteSpace value="preserve"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_LATITUDE_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_LATITUDE is a character of length 15
      </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:maxLength value="15"/> 
      <xsd:whiteSpace value="preserve"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_LONGITUDE_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_LONGITUDE is a character of length 15
      </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:maxLength value="15"/> 
      <xsd:whiteSpace value="preserve"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_HEADING_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_HEADING is a character of length 4
     </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:enumeration value="MAG"/> 
      <xsd:enumeration value="TRUE"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_VELOCITIES_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_VELOCITIES is a character of length 4
      </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:enumeration value="ADC"/> 
      <xsd:enumeration value="GPS"/> 
      <xsd:enumeration value="INS"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
  <xsd:simpleType name="QE_NAVDESC_TypeDef"> 
    <xsd:annotation> 
      <xsd:documentation>QE_NAVDESC is a character of length 30
      </xsd:documentation> 
    </xsd:annotation> 
    <xsd:restriction base="xsd:string"> 
      <xsd:maxLength value="30"/> 
      <xsd:whiteSpace value="preserve"/> 
    </xsd:restriction> 
  </xsd:simpleType> 
</xsd:schema>

Nonrowset-Based Message Parts

A nonrowset-based message part schema is similar to a regular nonrowset-based message, however a nonrowset-based message part can be reused in multiple containers.

Message Container Structures

Message container structures hold rowset-based or nonrowset-based message part structures. All message parts assigned to a container must of the same type, rowset-based or nonrowset-based.

A message container is always a nonrowset-based message.

You create container messages using the Message Builder in the PeopleSoft Pure Internet Architecture.

See Also

Nonrowset-Based Message Structures

Managing Messages

Example 1: XML Schema of a Container Message with Rowset-Based Message Parts

The following example shows a sample schema of a container message with three rowset-based message parts:

<?xml version="1.0"?> 
<xsd:schema elementFormDefault="unqualified" targetNamespace="http://xmlns.
oracle.com/Enterprise/Tools/schemas/Part_Container.V1" 
xmlns="http://xmlns.oracle.com/Enterprise/Tools/schemas/Part_Container.V1" 
xmlns:Part_1.V1="http://xmlns.oracle.com/Enterprise/Tools/schemas/Part_1.V1" 
xmlns:Part_2.V1="http://xmlns.oracle.com/Enterprise/Tools/schemas/Part_2.V1" 
xmlns:Part_3.V1="http://xmlns.oracle.com/Enterprise/Tools/schemas/Part_3.V1" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
  <xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/
    Part_1.V1" schemaLocation="http://kcollin2042803:5000/PSIGW/PeopleSoft
     ServiceListeningConnector?Operation=GetSchema&amp;xsd=Part_1.V1"/> 
  <xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/
     Part_3.V1" schemaLocation="http://kcollin2042803:5000/PSIGW/PeopleSoft
     ServiceListeningConnector?Operation=GetSchema&amp;xsd=Part_3.V1"/> 
  <xsd:import namespace="http://xmlns.oracle.com/Enterprise/Tools/schemas/
     Part_2.V1" schemaLocation="http://kcollin2042803:5000/PSIGW/PeopleSoft
     ServiceListeningConnector?Operation=GetSchema&amp;xsd=Part_2.V1"/> 
  <xsd:element name="Part_Container" type="Part_ContainerType"/> 
  <xsd:complexType name="Part_ContainerType"> 
    <xsd:sequence> 
      <xsd:element maxOccurs="unbounded" minOccurs="0" name="Part_1" type="
         Part_1.V1:Part_1_TypeShape"/> 
      <xsd:element maxOccurs="10" minOccurs="0" name="Part_3" type="Part_3.V1:
         Part_3_TypeShape"/> 
      <xsd:element maxOccurs="unbounded" minOccurs="0" name="Part_2" type="
         Part_2.V1:Part_2_TypeShape"/> 
    </xsd:sequence> 
  </xsd:complexType> 
</xsd:schema>

Example 2: XML Schema of a Container Message with Nonrowset-Based Message Parts

The following example shows a sample schema from a container message that contains three nonrowset-based parts:

<?xml version="1.0"?> 
<xsd:schema elementFormDefault="unqualified" targetNamespace="http://xmlns.
 oracle.com/Enterprise/Tools/schemas/NonRowSetContainer.v1" 
xmlns="http://xmlns.oracle.com/Enterprise/Tools/schemas/NonRowSetContainer.v1" 
xmlns:Part_One_NonRowset.v1="http://xmlns.oracle.com/Enterprise/Tools/
   schemas/Part_One.v1" 
xmlns:Part_Three_NonRowset.v1="http://xmlns.oracle.com/Enterprise/Tools/
   schemas/Part_Two.v1" 
xmlns:Part_Two_NonRowset.v1="http://xmlns.oracle.com/Enterprise/Tools/
   schemas/Part_Three.v1" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
  <xsd:import schemaLocation="http://kcollin2042803:5000/PSIGW/PeopleSoft
    ServiceListeningConnector?Operation=GetSchema&amp;xsd=Part_One_NonRowset.v1"/> 
  <xsd:import schemaLocation="http://kcollin2042803:5000/PSIGW/PeopleSoft
    ServiceListeningConnector?Operation=GetSchema&amp;xsd=Part_Two_NonRowset.v1"/> 
  <xsd:import schemaLocation="http://kcollin2042803:5000/PSIGW/PeopleSoft
     ServiceListening Connector?Operation=GetSchema&amp;xsd=Part_Three_Non
Rowset.v1"/> 
  <xsd:element name="NonRowSetContainer" type="NonRowSetContainerType"/> 
  <xsd:complexType name="NonRowSetContainerType"> 
    <xsd:sequence> 
      <xsd:element maxOccurs="unbounded" minOccurs="0" name="Part_One_NonRowset" 
        type="Part_One_NonRowset.v1:Part_One_TypeShape"/> 
      <xsd:element maxOccurs="unbounded" minOccurs="0" name="Part_Two_NonRowset" 
        type="Part_Two_NonRowset.v1:Part_Two_TypeShape"/> 
      <xsd:element maxOccurs="unbounded" minOccurs="0" name="Part_Three_NonRowset" 
         type="Part_Three_NonRowset.v1:Part_Three_TypeShape"/> 
    </xsd:sequence> 
  </xsd:complexType> 
</xsd:schema>