Understanding Supported Message Structures

This chapter discusses the internal format PeopleSoft uses to exchange request and response messages between the integration gateway and the application server. 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.

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: <5722340.1008266844175.JavaMail.MNowosel@MNOWOSEL071900>
Date: Thu, 13 Dec 2001 10:07:24 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 	
		boundary="----=_Part_5_7190308.1008266838787"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message

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

<?xml version="1.0"?><IBInfo><MessageName><![CDATA[EXAMPLE_REQUEST_MESSAGE]]>
</MessageName><MessageType>sync</MessageType><From><RequestingNode>
<![CDATA[SOURCENODE]]></RequestingNode><OrigTimeStamp>2001-11-13T10:07:18.817-0800
</OrigTimeStamp></From><PathInfo><![CDATA[/PSIGW/PeopleSoftListeningConnector]]>
</PathInfo><ContentSections><ContentSection> <ID>ContentSection0</ID>
<NonRepudiation>N</NonRepudiation></ContentSection></ContentSections></IBInfo>
------=_Part_5_7190308.1008266838787
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Content-ID: ContentSection0

<?xml version="1.0"?>
<TestXml>This is a sample request message.</TestXml>
------=_Part_5_7190308.1008266838787"

IBRequest Header Section

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

Message-ID: <5722340.1008266844175.JavaMail.MNowosel@MNOWOSEL071900>
Date: Thu, 13 Dec 2001 10:07:24 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 	
   boundary="----=_Part_5_7190308.1008266838787"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message

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>
   <MessageName><![CDATA[EXAMPLE_REQUEST_MESSAGE]]></MessageName>
   <MessageType>sync</MessageType>
   <TransactionID><![CDATA[]]></TransactionID>
   <From>
      <RequestingNode><![CDATA[QE_LOCAL]]></RequestingNode>
      <Password><![CDATA[]]></Password>
      <DN><![CDATA[]]></DN>
      <OrigUser><![CDATA[]]></OrigUser>
      <OrigNode><![CDATA[]]></OrigNode>
      <OrigProcess><![CDATA[]]></OrigProcess>
      <OrigTimeStamp>2001-11-13T11:06:22.142-0800</OrigTimeStamp>
   </From>
   <To>
      <DestinationNode><![CDATA[TARGETNODE]]></DestinationNode>
      <FinalDestinationNode><![CDATA[]]></FinalDestinationNode>
   </To>
   <QStrArgs/>
   <Cookies><![CDATA[]]></Cookies>
   <PathInfo><![CDATA[/PSIGW/PeopleSoftListeningConnector]]></PathInfo>
   <ContentSections>
     <ContentSection>
        <ID>ContentSection0</ID>
        <NonRepudiation>N</NonRepudiation>
        <Headers>
        <version><![CDATA[VERSION_1]]></version>
        </Headers>
     </ContentSection>
   </ContentSections>
   <InternalInfo>
     <AppMsg>
        <PublishingNode><![CDATA[]]></PublishingNode>
        <Channel><![CDATA[]]></Channel>
        <SubChannel><![CDATA[]]></SubChannel>
        <DefaultDataVersion>VERSION_1</DefaultDataVersion>
        <VisitedNodes><![CDATA[|QE_LOCAL|]]></VisitedNodes>
        <PublicationID></PublicationID>
     </AppMsg>
   </InternalInfo>
   <Connector>
        <ConnectorName><![CDATA[HTTPTARGET]]></ConnectorName>
        <ConnectorClassName><![CDATA[HttpTargetConnector]]></ConnectorClassName>
        <RemoteFrameworkURL><![CDATA[]]></RemoteFrameworkURL>
        <ConnectorParameters>
           <ConnectorParam>
              <Name><![CDATA[Method]]></Name>
              <Value><![CDATA[POST]]></Value>
           </ConnectorParam>
           <ConnectorParam>
              <Name><![CDATA[URL]]></Name>
              <Value><![CDATA[http://www.externalsystem.com/serlvet]]></Value>
           </ConnectorParam>
        </ConnectorParameters>
        <ConnectorHeaders>
           <Header>
              <Name><![CDATA[sendUncompressed]]></Name>
              <Value><![CDATA[Y]]></Value>
          </Header>
        </ConnectorHeaders>
   </Connector>
</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.

The only elements that are always required are MessageName and RequestingNode.

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.

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

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: <2351889.1008355101212.JavaMail.MNowosel@MNOWOSEL071900>
Date: Fri, 14 Dec 2001 10:38:21 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 	
   boundary="----=_Part_4_7210339.1008355101202"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message

------=_Part_4_7210339.1008355101202
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
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Content-ID: ContentSection0

<?xml version="1.0"?>
<TestXml>This is a sample response message.</TestXml>
------=_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: <2351889.1008355101212.JavaMail.MNowosel@MNOWOSEL071900>
Date: Fri, 14 Dec 2001 10:38:21 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 	
			boundary="----=_Part_4_7210339.1008355101202"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message

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.

<?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: <4328049.1008270392287.JavaMail.MNowosel@MNOWOSEL071900>
Date: Thu, 13 Dec 2001 11:06:32 -0800 (PST)
Mime-Version: 1.0
Content-Type: multipart/related; 	
   boundary="----=_Part_25_2235074.1008270392277"
Content-ID: PeopleSoft-Integration-Broker-Internal-Mime-Message

------=_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</MsgSet>
<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

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

Asynchronous messages are always compressed and base64 encoded when sent to the integration gateway.

For synchronous messages, in PSADMIN you can set a threshold message size above which messages are compressed. 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.

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 Subscription event for a rowset-based asynchronous message.

Local MESSAGE &MSG;
String &strReturn;

&MSG = GetMessage();

For &i = 1 To &MSG.IBInfo.IBConnectorInfo.GetNumberOfConnectorProperties()
   
   &strReturn= &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgName(&i);
   &strReturn= &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgValue(&i);
   
End-For;

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

Local MESSAGE &MSG;
Local XmlDoc &xmldoc;
String &strReturn;

&MSG = GetMessage();

For &i = 1 To &MSG.IBInfo.IBConnectorInfo.GetNumberOfConnectorProperties()
   
   &strReturn= &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgName(&i);
   &strReturn= &MSG.IBInfo.IBConnectorInfo.GetQueryStringArgValue(&i);
   
End-For;

// To access the content data 

&xmldoc = &MSG.GetXmlDoc();

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.

Understanding the PeopleSoft Rowset-Based Message Format

To work with rowset-based messages—the PeopleSoft native format—you define a message in PeopleSoft Application Designer, 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.

Note. Rowset-based messages are also referred to as structured messages.

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 Message 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 message has multiple target nodes with different record or field naming schemes, you create for each target a separate message 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 fieldtype 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 fieldtype 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 fieldtype 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 in PeopleSoft Application Designer.

See Generating Test Messages.

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

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

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.

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 fieldtype 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 an use with PeopleSoft Integration Broker. This section discusses:

• XML DOC-compliant messages.

• SOAP-compliant messages.

• Non-XML files.

Note. Nonrowset-based messages are sometimes referred to as nonrowset-based messages.

XML DOC-Compliant Messages

The World Wide Web Consortium (W3C) has established a DOM for accessing and manipulating structured data. A DOM specifies how data should be presented for access by programming languages, regardless of the data’s actual internal representation. The DOM specifies a standardized application programming interface (API) that provides a consistent, familiar way to work with almost any data. This API—the XML DOM—enables you to create, retrieve, navigate, and modify messages.

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 XmlDoc class and built-in functions, which comply with the XML DOM. The XmlDoc class is well-suited for handling messages that are populated with XML data from an external file or uniform resources locator (URL).

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. Both SOAP and 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.

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 for transport through PeopleSoft Integration Broker.

<?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
900000100000100000002001234578900000000100000000000100099999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999
99999999999999999999999999999999999999999999999999999999999999999999999
]]>
  </data>
</AsyncRequest>

See Also

Complying With Message Formatting and Transmission Requirements