SOAP (Simple Object Access Protocol) is a lightweight, XML-based protocol specification for exchanging structured information in the implementation of Web services in computer networks. For example, Web service provider receives SOAP requests from Web service clients to invoke Web services and also sends the corresponding SOAP responses out to the clients.
SOAP Message Structure
SOAP messages are contained in one of the SOAP components called Envelope. The SOAP envelop defines an overall framework for describing what is in a message, who should deal with it, and whether it is optional or mandatory. It consists of the following elements:
Header (Optional)
An envelope element can optionally have a Header element. If an envelope contains a Header element, it must contain no more than one, and it must appear as the first child of the envelope. The first level child elements of the Header element are called Header Blocks.
Header blocks can be used in the following mechanisms:
It can be used to attach security related information targeted at a specific recipient.
For more information, see SOAP Security Header.
It can be used to set applications context values required for services.
For more information, see SOAP Header for Applications Context.
It can be used to populate mandatory header variables for XML Gateway inbound transactions to be completed successfully.
For more information, see SOA Header for XML Gateway Messages.
Body
Every envelope element must contain exactly one Body element that holds the message. Immediate child elements of the Body element are called Body Blocks or Parts.
Attachment (Optional)
A SOAP message can carry multiple attachments and these attachments can be of any type including text, binary, image, and so on.
The following diagram depicts the structure of a SOAP message.
SOAP Message Structure
A skeleton of a SOAP message can be like:
<xml version="1.0">
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
When a SOAP request message is received through Oracle SOA Suite for the deployed SOA Composites in an Oracle WebLogic managed server, the SOAP message is authenticated by a JAAS (Java Authentication and Authorization Service) based login module for Oracle E-Business Suite.
A SOAP message is authenticated using either UsernameToken or SAML Token security model which has been identified earlier for a service before being deployed. The selected authentication information is embedded in the wsse:security Web Security header.
A UsernameToken-based SOAP header should include the following wsse:security section:
<soapenv:Header> <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1"> <wsse:UsernameToken> <wsse:Username>Username</wsse:Username> <wsse:Password>Password</wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header>
Note: When a <wsse:security> header includes a mustUnderstand="1" attribute, then the receiver must generate a fault if it is unable to interpret or process security tokens contained the <wsse:security> header block according to the corresponding WS SOAP message security token profiles.
A typical WS-Security header in a SOAP Request can be like:
<soapenv:Header> <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1"> <wsse:UsernameToken> <wsse:Username>myUser</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header>
The UsernameToken based security includes UsernameToken profile which provides username and password information in the Web service security header. Username is a clear text; password is the most sensitive part of the UsernameToken profile. In this security model, the supported password type is plain text password (or PasswordText).
Note: The PasswordText password type is the password written in clear text. SOAP requests invoking the Web services should include security header consisting of Username and plain text password. The password received as part of the SOAP request at run time will be validated against the encrypted password stored in Oracle E-Business Suite. After validation, the plain text password from the SOAP request will be discarded.
The username/password in SOAP Header of a SOAP message will be passed to authenticate Web services. The username/password discussed here in wsse:security is the Oracle E-Business Suite username/password (or the username/password created through the Users window in defining an application user).
Passing security header elements along with the SOAP request is essential to the success of invoking Oracle E-Business Suite Web services.
If these security header values are not passed, the Web service will not be authenticated and the execution of the service will be failed.
Detailed instructions on how to pass the security header when invoking an Oracle E-Business Suite Web service, see Configuring Web Service Policies.
Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider.
When a Web application invokes a service that uses SAML as its authentication mechanism, this SOAP request message containing or referencing SAML assertions is received through Oracle SOA Suite and passed on to a JAAS based login module for Oracle E-Business Suite for authentication based on the wsse:security Web Security headers. As part of the validation and processing of the assertions, the receiver or login module for Oracle E-Business Suite must establish the relationship among the subject, claims of the referenced SAML assertions, and the entity providing the evidence to satisfy the confirmation method defined for the statements.
A trusted entity uses the sender-vouches confirmation method to ensure that it is acting on behalf of the subject of SAML statements attributed with a sender-vouches SubjectConfirmation element.
The following SOAP example describes a trusted entity that uses the sender-vouches subject confirmation method with an associated <ds:Signature> element to establish its identity and to assert that it has sent the message body on behalf of the subject(s):
<soapenv:Envelope
xmlns:fnd="http://xmlns.oracle.com/apps/fnd/soaprovider/plsql/fnd_user_pkg/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<ds:Signature Id="Signature-26598842" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-31755621">
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>hbb/y+b3whhaFakWGO+bnkNm5/Q=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
jiXB+bsTfqd0uYxnaPAJcooCGb9UrKfzqSlGu/lE0nbL+sPkQQzmaB+ZKMFxUAc5pJStyeBu3DIg
6bEXSknB3JeJaHy6UFeGKZz3ROf4WKqRvDLXsa10Ei6Id66go3goqYzYtoUA4J43MjLJbKUw5KG/
LGBImRKABFPRP4qlAlQ=
</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-1042529">
<wsse:SecurityTokenReference wsu:Id="STRId-6382436" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">ADoNKKuduSTKTwi7jqEzCxwD7JU=</wsse:KeyIdentifier></wsse:SecurityTokenReference>
</ds:KeyInfo></ds:Signature>
<Assertion AssertionID="be7d9814c36381c27fefa89d8f27e126" IssueInstant="2010-02-27T17:26:21.241Z" Issuer="www.oracle.com" MajorVersion="1" MinorVersion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Conditions NotBefore="2010-02-27T17:26:21.241Z" NotOnOrAfter="2011-02-27T17:26:21.241Z"/>
<AuthenticationStatement AuthenticationInstant="2010-02-27T17:26:21.241Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<Subject>
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="notRelevant">SYSADMIN</NameQualifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
</AuthenticationStatement>
</Assertion>
</wsse:Security>
<fnd:SOAHeader>
<!--Optional:-->
<fnd:Responsibility>UMX</fnd:Responsibility>
<!--Optional:-->
<fnd:RespApplication>FND</fnd:RespApplication>
</fnd:SOAHeader>
</soapenv:Header>
<soapenv:Body wsu:Id="id-31755621" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<tes:InputParameters xmlns:tes="http://xmlns.oracle.com/apps/fnd/soaprovider/plsql/fnd_user_pkg/testusername/">
<!--Optional:-->
<tes:X_USER_NAME>AMILLER</tes:X_USER_NAME>
</tes:InputParameters>
</soapenv:Body>
</soapenv:Envelope>
Note: SAML Token based security can be used to authenticate users in both Single Sign-On (SSO) and non-SSO enabled environments. The format of the NameIdentifier in the SAML assertion indicates if the user has been authenticated against LDAP (for SSO users) or Oracle E-Business Suite FND_USER table (for non-SSO users).
The SAML assertion in the above SOAP message is for non-SSO enabled environment. If the username in the NameIdentifier tag is of the form of LDAP DN as shown below, then the username is verified in the registered OID for SSO users.
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="notRelevant">orclApplicationCommonName=PROD1,cn=EBusiness,cn=Products,cn=OracleContext,dc=us,dc=oracle,dc=com</NameIdentifier>
For more information about SAML Token sender-vouches based security, see SAML Sender-Vouches Token Based Security.
Applications context contains many crucial elements that are used in passing values that may be required in Oracle E-Business Suite. For example, the context header information is required for an API transaction or a concurrent program in order for an Oracle E-Business Suite user that has sufficient privileges to run the program.
Applications Context in SOAHeader Part of a SOAP Request
These context header elements defined in SOAHeader part of a SOAP request for PL/SQL and Concurrent Program services are:
Responsibility
It is the Oracle E-Business Suite application responsibility information. It accepts responsibility_key (such as SYSTEM_ADMINISTRATOR) as its value.
RespApplication
It is the responsibility application short name information. It accepts Application Short Name (such as FND) as its value.
SecurityGroup
It accepts Security Group Key (such as STANDARD) as its value.
NLSLanguage (optional)
It is an optional parameter to be passed in SOAHeader part of a SOAP request for PL/SQL and Concurrent Program services.
If the NLS Language element is specified, SOAP requests can be consumed in the language passed. All corresponding SOAP responses and error messages can also be returned in the same language. If no language is identified, then the default language of the user will be used.
Org_Id (optional for PL/SQL and Concurrent Program services)
It is an optional parameter to be passed in SOAHeader part of a SOAP request for PL/SQL and Concurrent Program services. If a service execution is dependent on any particular organization, then you must pass the Org_Id element of that SOAP request.
The following SOAP message shows the SOAHeader part printed in bold:
<soapenv:Header> <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1"> <wsse:UsernameToken> <wsse:Username>sysadmin</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password> </wsse:UsernameToken> </wsse:Security> <ozf:SOAHeader> <ozf:Responsibility>OZF_USER</ozf:Responsibility> <ozf:RespApplication>OZF</ozf:RespApplication> <ozf:SecurityGroup>STANDARD</ozf:SecurityGroup> <ozf:NLSLanguage>AMERICAN</ozf:NLSLanguage> <ozf:Org_Id>204</ozf:Org_Id> </ozf:SOAHeader> </soapenv:Header>
Applications Context in ServiceBean_Header Part of a SOAP Request
These context header elements defined in ServiceBean_Header part of a SOAP request for a Business Service Object service are:
RESPONSIBILITY_NAME
It is the Oracle E-Business Suite application responsibility information. It can accept both the name (Responsibility_Name, such as System Administrator) and the key (in the format of {key}responsibility_key, such as {key}SYSTEM_ADMINISTRATOR) as its values.
RESPONSIBILITY_APPL_NAME
It is the responsibility application short name information. It accepts Application Short Name (such as FND) as its value.
SECURITY_GROUP_NAME
It accepts Security Group Key (such as STANDARD) as its value.
NLSLanguage (optional)
It is an optional parameter to be passed in ServiceBean_Header part of a SOAP request for a Business Service Object service.
If the NLS Language element is specified (such as AMERICAN), SOAP requests can be consumed in the language passed. All corresponding SOAP responses and error messages can also be returned in the same language. If no language is identified, then the default language of the user will be used.
Org_Id (optional)
It is an optional parameter to be passed in ServiceBean_Header part of a SOAP request for a Business Service Object service.
If a service execution is dependent on any particular organization, then you must pass the Org_Id element of that SOAP request.
The following SOAP request example includes the ServiceBean_Header part printed in bold for a business service object service:
<soapenv:Envelope xmlns:ser="http://xmlns.oracle.com/apps/fnd/ServiceBean"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://xmlns.oracle.com/apps/fnd/rep/ws">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-22948433" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>sysadmin</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
<ser:ServiceBean_Header>
<ser:RESPONSIBILITY_NAME>System Administrator</ser:RESPONSIBILITY_NAME>
<ser:RESPONSIBILITY_APPL_NAME>sysadmin</ser:RESPONSIBILITY_APPL_NAME>
<ser:SECURITY_GROUP_NAME>standard</ser:SECURITY_GROUP_NAME>
<ser:NLS_LANGUAGE>american</ser:NLS_LANGUAGE>
<ser:ORG_ID>202</ser:ORG_ID>
</ser:ServiceBean_Header>
</soapenv:Header>
<soapenv:Body>
<ws:IntegrationRepositoryService_GetInterfaceByType>
<interfaceType>XMLGATEWAY</interfaceType>
</ws:IntegrationRepositoryService_GetInterfaceByType>
</soapenv:Body>
</soapenv:Envelope>
In Oracle XML Gateway, each trading partner is configured with Oracle E-Business Suite users. Only these authorized users defined in the Trading Partner Setup form are allowed to perform XML transactions. External clients can pass such usernames in the <USERNAME> and <PASSWORD> elements defined within the <ECX:SOAHeader> element (or <XMLGateway_Header> element for generic XML Gateway services) in the SOAP body. These username parameters are validated by Oracle XML Gateway against the username defined in the trading partner setup before initiating a transaction.
Therefore, for XML Gateway interface type, the authorization check is performed at both the trading partner level, as well as on the username passed in the wsse:security header in the SOAP request. For information on trading partner setup and how to associate users with trading partners, see Oracle XML Gateway User's Guide.
The following code snippet shows the SOAHeader element within a SOAP request for an XML Gateway inbound message:
<soapenv: Envelope xmlns:ecx="http://xmlns.oracle.com/apps/ecx/soaprovider/xmlgateway/ecx__cbodi/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:sys="http://xmlns.oracle.com/xdb/SYSTEM">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-10586449"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>SYSADMIN</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
<ecx:SOAHeader>
<sys:ECXMSG>
<MESSAGE_TYPE></MESSAGE_TYPE>
<MESSAGE_STANDARD></MESSAGE_STANDARD>
<TRANSACTION_TYPE></TRANSACTION_TYPE>
<TRANSACTION_SUBTYPE></TRANSACTION_SUBTYPE>
<DOCUMENT_NUMBER></DOCUMENT_NUMBER>
<PARTYID></PARTYID>
<PARTY_SITE_ID></PARTY_SITE_ID>
<PARTY_TYPE></PARTY_TYPE>
<PROTOCOL_TYPE></PROTOCOL_TYPE>
<PROTOCOL_ADDRESS></PROTOCOL_ADDRESS>
<USERNAME></USERNAME>
<PASSWORD></PASSWORD>
<ATTRIBUTE1></ATTRIBUTE1>
<ATTRIBUTE2></ATTRIBUTE2>
<ATTRIBUTE3></ATTRIBUTE3>
<ATTRIBUTE4></ATTRIBUTE4>
<ATTRIBUTE5></ATTRIBUTE5>
</sys:ECXMSG>
</ecx:SOAHeader>
</soapenv:Header>
XML Gateway header parameters defined in the SOAHeader element (or XMLGateway_Header element for generic XML Gateway services) within a SOAP request are described in the following table:
XMLGateway Header Information in SOAHeader Element within a SOAP Request
| Attribute | Description |
|---|---|
| MESSAGE_TYPE | Payload message format. This defaults to XML. Oracle XML Gateway currently supports only XML. |
| MESSAGE_STANDARD | Message format standard as displayed in the Define Transactions form and entered in the Define XML Standards form. This defaults to OAG. The message standard entered for an inbound XML document must be the same as the message standard in the trading partner setup. |
| TRANSACTION_TYPE | External Transaction Type for the business document from the Trading Partner table. The transaction type for an inbound XML document must be the same as the transaction type defined in the Trading Partner form. |
| TRANSACTION_SUBTYPE | External Transaction Subtype for the business document from the Trading Partner table. The transaction subtype for an inbound XML document must be the same as the transaction subtype defined in the Trading Partner form. |
| DOCUMENT_NUMBER | The document identifier used to identify the transaction, such as a purchase order or invoice number. This field is not used by the XML Gateway, but it may be passed on inbound messages. |
| PROTOCOL_TYPE | Transmission Protocol is defined in the Trading Partner table. |
| PROTOCOL_ADDRESS | Transmission address is defined in the Trading Partner table. |
| USERNAME | USERNAME is defined in the Trading Partner table. |
| PASSWORD | The password associated with the USERNAME is defined in the Trading Partner table. |
| PARTY_SITE_ID | The party site identifier for an inbound XML document must be the same as the Source Trading Partner location defined in the Trading Partner form. |
| ATTRIBUTE1 | This parameter may be defined by the base application. |
| ATTRIBUTE2 | This parameter may be defined by the base application. |
| ATTRIBUTE3 | For outbound messages, this field has the value from the Destination Trading Partner Location Code in the Trading Partner table. For inbound messages, the presence of this value generates another XML message that is sent to the trading partner identified in the Destination Trading Partner Location Code in the Trading Partner table. This value must be recognized by the hub to forward the XML message to the final recipient of the XML Message.
Note: For more information, see Destination Trading Partner Location Code in the Oracle XML Gateway User's Guide. |
| ATTRIBUTE4 | This parameter may be defined by the base application. |
| ATTRIBUTE5 | This parameter may be defined by the base application. |
Note: The PARTYID and PARTY_TYPE parameters are not used.
The following code snippet shows the XMLGateway_Header element within a SOAP request for a generic XML Gateway service:
<soap:Envelope>
<soap:Header>
...
<ns1:XMLGateway_Header
xmlns:ns1="http://xmlns.oracle.com/apps/fnd/XMLGateway
soapenv:mustUnderstand="0">
<ns1:MESSAGE_TYPE>XML</ns1:MESSAGE_TYPE>
<ns1:MESSAGE_STANDARD>OAG</ns1:MESSAGE_STANDARD>
<ns1:TRANSACTION_TYPE>PO</ns1:TRANSACTION_TYPE>
<ns1:TRANSACTION_SUBTYPE>PROCESS</ns1:TRANSACTION_SUBTYPE>
<ns1:DOCUMENT_NUMBER>123</ns1:DOCUMENT_NUMBER>
<ns1:PARTY_SITE_ID>4444</ns1:PARTY_SITE_ID>
</ns1:XMLGateway_Header>
</soap:Header>
...
</soap:Envelope>
The following table describes the XML Gateway header information in XMLGateway_Header part of a SOAP request:
XMLGateway_Header Part of a SOAP Request
| Parameter Name | Description |
|---|---|
| MESSAGE_TYPE | Payload message format. This defaults to XML. Oracle XML Gateway currently supports only XML. |
| MESSAGE_STANDARD | Message format standard as displayed in the Define Transactions form and entered in the Define XML Standards form. This defaults to OAG. The message standard entered for an inbound XML document must be the same as the message standard in the trading partner setup. |
| TRANSACTION_TYPE | External Transaction Type for the business document from the Trading Partner table. The transaction type for an inbound XML document must be the same as the transaction type defined in the Trading Partner form. |
| TRANSACTION_SUBTYPE | External Transaction Subtype for the business document from the Trading Partner table. The transaction subtype for an inbound XML document must be the same as the transaction subtype defined in the Trading Partner form. |
| DOCUMENT_NUMBER | The document identifier used to identify the transaction, such as a purchase order or invoice number. This parameter is not used by the XML Gateway, but it may be passed on inbound messages. |
| PARTY_SITE_ID | The party site identifier for an inbound XML document must be the same as the Source Trading Partner location defined in the Trading Partner form. |
To better understand SOAP request and response messages received through Oracle SOA Suite, the following sample SOAP messages are described in this section:
For information about synchronous SOAP messages, see:
For information about asynchronous SOAP messages, see:
The following example shows a synchronous SOAP request for a PL/SQL service:
<soapenv:Envelope xmlns:ser="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:ozf="http://xmlns.oracle.com/apps/ozf/soaprovider/plsql/ozf_sd_request_pub/"
xmlns:cre="http://xmlns.oracle.com/apps/ozf/soaprovider/plsql/ozf_sd_request_pub/create_sd_request/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1">
<wsse:UsernameToken>
<wsse:Username>trademgr</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
<ozf:SOAHeader>
<ozf:Responsibility>OZF_USER</ozf:Responsibility>
<ozf:RespApplication>OZF</ozf:RespApplication>
<ozf:SecurityGroupE>STANDARD</ozf:SecurityGroup>
<ozf:NLSLanguage>AMERICAN</ozf:NLSLanguage>
<ozf:Org_Id>204</ozf:Org_Id>
</ozf:SOAHeader>
</soapenv:Header>
<soapenv:Body>
<cre:InputParameters>
<cre:P_API_VERSION_NUMBER>1.0</cre:P_API_VERSION_NUMBER>
<cre:P_INIT_MSG_LIST>T</cre:P_INIT_MSG_LIST>
<cre:P_COMMIT>F</cre:P_COMMIT>
<cre:P_VALIDATION_LEVEL>100</cre:P_VALIDATION_LEVEL>
<cre:P_SDR_HDR_REC>
<cre:REQUEST_NUMBER>SDR-CREATE-A1</cre:REQUEST_NUMBER>
<cre:REQUEST_START_DATE>2008-08-18T12:00:00</cre:REQUEST_START_DATE>
<cre:REQUEST_END_DATE>2008-10-18T12:00:00</cre:REQUEST_END_DATE>>
<cre:USER_STATUS_ID>1701</cre:USER_STATUS_ID>
<cre:REQUEST_OUTCOME>IN_PROGRESS</cre:REQUEST_OUTCOME>
<cre:REQUEST_CURRENCY_CODE>USD</cre:REQUEST_CURRENCY_CODE>
<cre:SUPPLIER_ID>601</cre:SUPPLIER_ID>
<cre:SUPPLIER_SITE_ID>1415</cre:SUPPLIER_SITE_ID>
<cre:REQUESTOR_ID>100001499</cre:REQUESTOR_ID>
<cre:ASSIGNEE_RESOURCE_ID>100001499</cre:ASSIGNEE_RESOURCE_ID>
<cre:ORG_ID>204</cre:ORG_ID>
<cre:ACCRUAL_TYPE>SUPPLIER</cre:ACCRUAL_TYPE>
<cre:REQUEST_DESCRIPTION>Create</cre:REQUEST_DESCRIPTION>
<cre:SUPPLIER_CONTACT_EMAIL_ADDRESS>sdr.supplier@testing.com</cre:SUPPLIER_CONTACT_EMAIL_ADDRESS>
<cre:SUPPLIER_CONTACT_PHONE_NUMBER>2255</cre:SUPPLIER_CONTACT_PHONE_NUMBER>
<cre:REQUEST_TYPE_SETUP_ID>400</cre:REQUEST_TYPE_SETUP_ID>
<cre:REQUEST_BASIS>Y</cre:REQUEST_BASIS>
<cre:USER_ID>1002795</cre:USER_ID>
</cre:P_SDR_HDR_REC>
<cre:P_SDR_LINES_TBL>
<cre:P_SDR_LINES_TBL_ITEM>
<cre:PRODUCT_CONTEXT>PRODUCT</cre:PRODUCT_CONTEXT>
...
</cre:P_SDR_LINES_TBL_ITEM>
</cre:P_SDR_LINES_TBL>
<cre:P_SDR_CUST_TBL>
...
</cre:P_SDR_CUST_TBL>
</cre:InputParameters>>
</soapenv:Body>
</soapenv:Envelope>
The following example shows a synchronous SOAP response for a PL/SQL service:
<env:Envelope xmlns:env=""http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<OutputParameters xmlns="http://xmlns.oracle.com/apps/ozf/soaprovider/plsql/ozf_sd_request_pub/create_sd_request/">
<X_RETURN_STATUS>S</X_RETURN_STATUS>
<X_MSG_COUNT>23</X_MSG_COUNT>
<X_MSG_DATA xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<X_REQUEST_HEADER_ID>162</X_REQUEST_HEADER_ID>
</OutputParameters>
</env:Body>
</env:Envelope>
The SOAP Fault element is used to carry error and status information within a SOAP message.
For example, the following fault synchronous response message indicates that the service is not deployed:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<Fault xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode xmlns="">SOAP-ENV:Server</faultcode>
<faultstring xmlns="">Service is not deployed.</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
The following example shows an asynchronous SOAP request for CREATE_SD_REQUEST_ASYNCH operation contained in a PL/SQL service OZF_SD_REQUEST_PUB:
<soapenv:Envelope "http://xmlns.oracle.com/isg/ozf_sd_request_pub/CREATE_SD_REQUEST_ASYNCH" xmlns:cre1="http://xmlns.oracle.com/apps/ozf/soaprovider/plsql/ozf_sd_request_pub/create_sd_request/" xmlns:ozf="http://xmlns.oracle.com/apps/ozf/soaprovider/plsql/ozf_sd_request_pub/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-3" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>trademgr</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">JtcpwUGEcUyy09YgwaPzSA==</wsse:Nonce>
<wsu:Created>2011-09-21T08:17:10.656Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
<ozf:SOAHeader>
<!--Optional:-->
<ozf:Responsibility>OZF_USER</ozf:Responsibility>
<!--Optional:-->
<ozf:RespApplication>OZF</ozf:RespApplication>
<!--Optional:-->
<ozf:SecurityGroupE>STANDARD</ozf:SecurityGroup>
<!--Optional:-->
<ozf:NLSLanguage>AMERICAN</ozf:NLSLanguage>
<!--Optional:-->
<ozf:Org_Id>204</ozf:Org_Id>
</ozf:SOAHeader>
</soapenv:Header>
<soapenv:Body>
<cre:InputParameters>
<cre:P_API_VERSION_NUMBER>1.0</cre:P_API_VERSION_NUMBER>
<cre:P_INIT_MSG_LIST>T</cre:P_INIT_MSG_LIST>
<cre:P_COMMIT>F</cre:P_COMMIT>
<cre:P_VALIDATION_LEVEL>100</cre:P_VALIDATION_LEVEL>
<cre:P_SDR_HDR_REC>
<cre1:REQUEST_NUMBER>SDR-CREATE-BPEL001</cre1:REQUEST_NUMBER>
<cre1:REQUEST_START_DATE>2011-08-18T12:00:00</cre1:REQUEST_START_DATE>
<cre1:REQUEST_END_DATE>2012-10-18T12:00:00</cre1:REQUEST_END_DATE>>
<cre1:USER_STATUS_ID>1712</cre1:USER_STATUS_ID>
<cre1:REQUEST_OUTCOME>IN_PROGRESS</cre1:REQUEST_OUTCOME>
<cre1:REQUEST_CURRENCY_CODE>USD</cre1:REQUEST_CURRENCY_CODE>
<cre1:SUPPLIER_ID>1718</cre1:SUPPLIER_ID>
<cre1:SUPPLIER_SITE_ID>2854</cre1:SUPPLIER_SITE_ID>
<cre1:REQUESTOR_ID>100001499</cre1:REQUESTOR_ID>
<cre1:ASSIGNEE_RESOURCE_ID>100001499</cre1:ASSIGNEE_RESOURCE_ID>
<cre1:ORG_ID>204</cre1:ORG_ID>
<cre1:ACCRUAL_TYPE>SUPPLIER</cre1:ACCRUAL_TYPE>
<cre1:REQUEST_DESCRIPTION>Create</cre1:REQUEST_DESCRIPTION>
<cre1:SUPPLIER_CONTACT_EMAIL_ADDRESS>sdr.supplier@testing.com</cre1:SUPPLIER_CONTACT_EMAIL_ADDRESS>
<cre1:SUPPLIER_CONTACT_PHONE_NUMBER>2255</cre1:SUPPLIER_CONTACT_PHONE_NUMBER>
<cre1:REQUEST_TYPE_SETUP_ID>400</cre1:REQUEST_TYPE_SETUP_ID>
<cre1:REQUEST_BASIS>Y</cre1:REQUEST_BASIS>
<cre1:USER_ID>1002795</cre1:USER_ID>
</cre:P_SDR_HDR_REC>
<cre:P_SDR_LINES_TBL>
<cre1:P_SDR_LINES_TBL_ITEM>
<cre1:PRODUCT_CONTEXT>PRODUCT</cre:PRODUCT_CONTEXT>
<cre1:INVENTORY_ITEM_ID>149</cre1:INVENTORY_ITEM_ID>
<cre1:ITEM_UOM>Ea</cre1:ITEM_UOM>
<cre1:REQUESTED_DISCOUNT_TYPE>%</cre1:REQUESTED_DISCOUNT_TYPE>
<cre1:REQUESTED_DISCOUNT_VALUE>15.5</cre1:REQUESTED_DISCOUNT_VALUE>
<!--<cre1:COST_BASIS>200</cre1:COST_BASIS>-->
<cre1:MAX_QTY>200<cre1:MAX_QTY>
<cre1:DESIGN_WIN>200</cre1:DESIGN_WIN>
<cre1:APPROVED_DISCOUNT_TYPE>%</cre1:APPROVED_DISCOUNT_TYPE>
<cre1:APPROVED_DISCOUNT_VALUE>15.5</cre1:APPROVED_DISCOUNT_VALUE>
<cre1:APPROVED_MAX_QTY>200</cre1:APPROVED_MAX_QTY>
<cre1:VENDOR_APPROVED_FLAG>Y</cre1:VENDOR_APPROVED_FLAG>
<cre1:PRODUCT_COST_CURRENCY>USD</cre1:PRODUCT_COST_CURRENCY>
<cre1:END_CUSTOMER_CURRENCY>USD</cre1:END_CUSTOMER_CURRENCY>
</cre1:P_SDR_LINES_TBL_ITEM>
</cre:P_SDR_LINES_TBL>
<cre:P_SDR_CUST_TBL>
<cre1:P_SDR_CUST_TBL_ITEM>
<cre1:CUST_ACCOUNT_ID>1290</cre1:CUST_ACCOUNT_ID>
<cre1:PARTY_ID>1290</cre1:PARTY_ID>
<cre1:SITE_USE_ID>10479</cre1:SITE_USE_ID>
<cre1:CUST_USAGE_CODE>BILL_TO</cre1:CUST_USAGE_CODE>
<cre1:END_CUSTOMER_FLAG>N</cre1:END_CUSTOMER_FLAG>
</cre1:P_SDR_CUST_TBL_ITEM>
<cre1:P_SDR_CUST_TBL_ITEM>
<cre1:CUST_ACCOUNT_ID>1287</cre1:CUST_ACCOUNT_ID>
<cre1:PARTY_ID>1287</cre1:PARTY_ID>
<cre1:SITE_USE_ID>1418</cre1:SITE_USE_ID>
<cre1:CUST_USAGE_CODE>CUSTOMER</cre1:CUST_USAGE_CODE>
<cre1:END_CUSTOMER_FLAG>Y</cre1:END_CUSTOMER_FLAG>
</cre1:P_SDR_CUST_TBL_ITEM>
</cre:P_SDR_CUST_TBL>
</cre:InputParameters>>
</soapenv:Body>
</soapenv:Envelope>
The following example shows asynchronous response for CREATE_SD_REQUEST_ASYNCH operation contained in a PL/SQL service OZF_SD_REQUEST_PUB:
<?xml version="1.0" encoding="UTF-8" ?>
<outputParameters
xmlns:client="http://xmlns.oracle.com/isg/ozf_sd_request_pub/CREATE_SD_REQUEST_ASYNCH"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns="http://xmlns.oracle.com/isg/ozf_sd_request_pub/CREATE_SD_REQUEST_ASYNCH">
<OutputParameters
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/apps/ozf/soaprovider/plsql/ozf_sd_request_pub/create_sd_request/">
<X_RETURN_STATUS>S</X_RETURN_STATUS>
<X_MSG_COUNT>23</X_MSG_COUNT>
<X_MSG_DATA xsi:nil="true"/>
<X_REQUEST_HEADER_ID>31</X_REQUEST_HEADER_ID>
</OutputParameters>
</outputParameters>
For example, the following sample shows the asynchronous response message for incorrect header from soapUI:
<?xml version="1.0" encoding="UTF-8" ?>
<outputParameters
xmlns:client="http://xmlns.oracle.com/isg/ozf_sd_request_pub/CREATE_SD_REQUEST_ASYNCH"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns="http://xmlns.oracle.com/isg/ozf_sd_request_pub/CREATE_SD_REQUEST_ASYNCH">
<OutputParameters
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/apps/ozf/soaprovider/plsql/ozf_sd_request_pub/create_sd_request/">
<X_RETURN_STATUS>E</X_RETURN_STATUS>
<X_MSG_COUNT>1</X_MSG_COUNT>
<X_MSG_DATA>The Organization Id provided is invalid, please provide a valid Organization Id.</X_MSG_DATA>
<X_REQUEST_HEADER_ID xsi:nil="true"/>
</OutputParameters>
</outputParameters>