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:

Click to jump to parent topicIntegration Broker Message Structures

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

Click to jump to top of pageClick to jump to parent topicInternal 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:

Headers

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

IBInfo
(Integration Broker Information)

The IBInfo (Integration Broker Information) section contains the credentials of the request as well as all other information required by the PeopleSoft Integration Broker to process the message. The IBInfo for a request has a specific XML structure which is used for all request messages in the system, regardless if the message is being sent to the application server or to the integration gateway.

Content section

The final section contains the message body of the original request. This is the payload and is what is ultimately delivered to the final destination.

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.50 --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.50 --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:

Element

Description

IBInfo / ExternalOperationName

The name of the requested service operation.

IBInfo / Operation Type

(Optional.) This is the type of service operation. The valid values are: asynchronous, synchronous and ping.

IBInfo / TransactionID

(Optional.) The transaction ID is used to uniquely identify a request.

IBInfo / From / RequestingNode

(Optional.) The requesting node is the node that sent the request to the current system.

IBInfo / From / Password

(Optional.) This is the password for the requesting node.

IBInfo / From / DN

(Optional.) For incoming requests, the DN gives the Distinguished Name extracted from the certificate authentication process.

IBInfo / From / OrigNode

(Optional.) For requests that cross multiple nodes, OrigNode is used to identify the node that initiated the request.

IBInfo / From / OrigTimeStamp

(Optional.) This timestamp corresponds to the time that the request was created. For requests that cross nodes, this is the time that the first request was created.

IBInfo / To / DestinationNode

(Optional.) This is the node to which the request will be delivered.

IBInfo / To / FinalDestinationNode

(Optional.) In cases where the message will be passed across several nodes, this value specifies the ultimate target of the message.

IBInfo / QStrArgs

(Optional.) Specific to incoming HTTP requests. These are the query string parameters found when the request was received by the HTTP listening connector.

IBInfo / Cookies

(Optional.) Specific to incoming HTTP requests. This is cookie string found when the request was received by the HTTP listening connector.

IBInfo / PathInfo

(Optional.) Specific to incoming HTTP requests. This is the path information extracted from the request.

IBInfo / ContentSections / ContentSection

(Optional.) This node provides metadata about the text present in the ContentSection.

IBInfo / ContentSections / ContentSection / ID

(Optional.) The index number of the content section.

IBInfo / ContentSections / ContentSection / NonRepudiation

(Optional.) Indicates as to whether nonrepudiation should be performed.

IBInfo / ContentSections / ContentSection / Headers

(Optional.) Provides additional information about the data.

IBInfo / PublishingNode

(Optional.) The node that published the message.

IBInfo / Queue

(Optional.) The queue to which the service operation was published.

IBInfo / InternalInfo / AppMsg / SubQueue

(Optional.) The subqueue to which the service operation was published.

IBInfo / InternalInfo / AppMsg / VisitedNodes

(Optional.) The list of nodes that have already received this message. This is useful when a message is being propagated across multiple nodes.

IBInfo / InternalInfo / AppMsg / PublicationID

(Optional.) The publication ID for this message.

IBInfo / Connector

(Optional.) Connector information instructs the gateway as to how to process the request.

IBInfo / Connector / ConnectorName

(Optional.) This is the proper name of the target connector to invoke to send the message.

IBInfo / Connector / ConnectorClassName

(Optional.) This is the class name of the target connector to invoke.

IBInfo / Connector / ConnectorParameters

(Optional.) Connector parameters are processing instructions for the target connector to be invoked.

IBInfo / Connector / ConnectorHeaders

(Optional.) Connector headers provide further metadata about the contents of the message to be sent.

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==

Click to jump to top of pageClick to jump to parent topicInternal 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.50 ------=_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 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.50

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:

Element

Description

IBInfo / Status / StatusCode

Describes the result of the request. The possible values are:

  • 0 (zero). Request successfully processed.

  • 10. Temporary error occurred. Request can be resent.

  • 20. Fatal error occurred. Do not resend request.

  • 30. Request message is a duplicate of a message previously received.

IBInfo / Status / MsgSet

The MessageSetNumber for this message in the Message Catalog. Message set number 158 is assigned to the PeopleSoft Integration Broker.

IBInfo / Status / MsgID

The Message Number for this message in the Message Catalog. If no errors occurred during the processing of the request, the MsgID will be set to the value ‘10000’.

IBInfo / Status / DefaultTitle

Used if the message catalog is unavailable. This value corresponds to the “Message Text” for a given entry in the message catalog.

IBInfo / Status / DefaultMsg

Used if the message catalog is unavailable. This value corresponds to the “Explanation” for a given entry in the message catalog.

IBInfo / Status / Parameters

Parameters may be used to provide additional information for error responses.

IBInfo / ContentSection

A description of the content section returned with the response.

Note. Not all response messages will have a content section. The structure of the content section and all child elements is the same as was seen in the request IBInfo.

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.

Value

Meaning

Description

0

Success

The message transport and processing were successful.

10

Retry

The transport was not successful. PeopleSoft Integration Broker will perform its retry logic and send the message again.

20

Error

An error occurred.

30

Duplicate message

The transaction ID for the message has already been received.

40

Acknowledgement error

This status is used for SOAP messages and indicates that the contents of the data is not proper, but the transport was successful.

50

Acknowledgement hold

Used for asynchronous chunking of messages from PeopleSoft to PeopleSoft nodes when sending multiple message segments.

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.50 ------=_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.

Click to jump to top of pageClick to jump to parent topicLocal Compression

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

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

Click to jump to top of pageClick to jump to parent topicAccessing 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 (_).

Click to jump to parent topic PeopleSoft Rowset-Based Message Format

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

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

See Also

Message Part Structures

Click to jump to top of pageClick to jump to parent topicUnderstanding 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

Click to jump to top of pageClick to jump to parent topicRowset-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.

Click to jump to top of pageClick to jump to parent topicFieldTypes 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:

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.

Click to jump to top of pageClick to jump to parent topicMsgData 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

Click to jump to top of pageClick to jump to parent topicPSCAMA

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_CD

Indicates the language in which the message is generated, so the receiving application can take that information into account when processing the message. When sending a message with component PeopleCode, the system sets this field to the user’s default language code.

AUDIT_ACTN

Identifies each row of data as an Add, Change, or Delete action.

BASE_LANGUAGE
_CD

(Optional.) Indicates the base language of the sending database. This is used by generic, full-table subscription PeopleCode to help determine which tables to update.

MSG_SEQ_FLG

(Optional.) Supports the transmission of large transactions that may span multiple messages. Indicates whether the message is a header (H) or trailer (T) or contains data (blank). The header and trailer messages don’t contain message data. The receiving system can use this information to determine the start and end of the set of messages and initiate processes accordingly. For example, the header message might cause staging tables to be cleared, while the trailer might indicate that all of the data has been received and an update job should be initiated.

PROCESS_INSTANCE

(Optional.) Process instance of the batch job that created the message. Along with the sending node and publication ID, the receiving node can use this to identify a group of messages from the sending node.

PUBLISH_RULE_ID

(Optional.) Indicates the publish rule that is invoked to create the message. This is used by routing PeopleCode to locate the appropriate chunking rule, which then determines to which nodes the message should be sent. Third-party applications can ignore this field.

MSGNODENAME

(Optional.) The node to which the message should be sent. This field is passed to the Publish utility by the Application Engine program. Routing PeopleCode must look for a value in this field and return that value to the application server. Third-party applications can ignore this field.

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:

Audit Action Code

Description

A

Add a noneffective or effective-dated row.

To add an effective-dated row, the value is A.

If you populate the row data by using the CopyRowsetDeltaOriginal method in the PeopleCode Message class, an additional record is created with an audit action value of O, containing the original values of the current effective-dated row.

C

Change non-key values in a row.

D

Delete a row.

K

If you change at least one key value in a row (in addition to any non-key values) and then populate the row data by using the CopyRowsetDeltaOriginal or CopyRowsetDelta methods in the Message class, an additional record is created with an audit action value of K, containing the original values of the current effective-dated row.

N

Change at least one key value in a row (in addition to any non-key values).

O

If you change non-key values in a row and populate the row data by using the CopyRowsetDeltaOriginal method in the Message class, an additional record is created with an audit action value of O, containing the original values of the current effective-dated row.

Blank

Default value.

If a row’s content hasn’t changed, the value is blank.

This audit action code is also used to tag the parents of rows that have changed.

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.

Click to jump to top of pageClick to jump to parent topicIdentifying 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

Click to jump to top of pageClick to jump to parent topicPeopleSoft 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.

Click to jump to top of pageClick to jump to parent topicCDATA and Special Characters

Consider the following points regarding rowset-based messages:

Click to jump to top of pageClick to jump to parent topicSchema 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.

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>

Click to jump to top of pageClick to jump to parent topicRowset-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>

Click to jump to parent topicNonrowset-Based Message Structures

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

Click to jump to top of pageClick to jump to parent topicXML 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:

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.

Click to jump to top of pageClick to jump to parent topicSOAP-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:

See Also

Generating and Sending Messages

Receiving and Processing Messages

Click to jump to top of pageClick to jump to parent topicNon-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.

If you are using the Publish or SyncRequest methods to send data, you can use the built-in function SetXMLDoc to remove the tags upon exiting the integration gateway or write a transformation to do so. If you choose neither of these options, 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>

See Also

Complying With Message Formatting and Transmission Requirements

Click to jump to top of pageClick to jump to parent topicUsing 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"/>

Click to jump to parent topicMessage Part Structures

This section discusses:

Click to jump to top of pageClick to jump to parent topicUnderstanding 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

Click to jump to top of pageClick to jump to parent topicRowset-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 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>

Click to jump to top of pageClick to jump to parent topicNonrowset-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.

Click to jump to parent topicMessage 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

Click to jump to top of pageClick to jump to parent topicExample 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>

Click to jump to top of pageClick to jump to parent topicExample 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>