Skip Headers

Oracle E-Business Suite Integrated SOA Gateway Developer's Guide
Release 12.1
Part Number E12065-08
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Discovering and Viewing Integration Interfaces

Overview

Similar to regular users or system integration analysts, system integration developers can view integration interfaces and their details from Oracle Integration Repository, as well as review generated or deployed Web service WSDL files in the appropriate Web Service region. The developers cannot perform administrative tasks, such as generating or deploying Web services, which are done by the integration repository administrators.

However, the developers have more privileges than the analysts in viewing all types of integration interfaces including public, private, and internal interface types from Oracle Integration Repository. These privileges allow developers to have sufficient integration interface information which could be useful to better understand each integration interface from different perspectives.

Note: System integration analysts can view Public integration interfaces only, and they do not have the access privileges to view Private to Application and Internal to Oracle interfaces from the Oracle Integration Repository.

This section covers the following topics:

Searching and Viewing Integration Interfaces

To better understand each integration interface and the integration between different applications, Oracle E-Business Suite Integrated SOA Gateway allows system integration developers and integration repository administrators to have more interface access privileges in viewing all integration interface types regardless of public, private, or internal interface types.

Browsing the Integration Interfaces

When viewing integration interfaces, you can browse by product family, by interface type, or by standard based on your selection in the View By drop-down list. Expand the navigation tree in one of these views to see a list of the available interfaces.

For more information on how to browse the interfaces, see Browsing the Integration Interfaces, Oracle E-Business Suite Integrated SOA Gateway User's Guide.

Searching the Integration Interfaces

To search for an integration interface, click Search to access the main Search page. After clicking the Show More Search Options link in the Search page, you can find Private to Application and Internal to Oracle interface types along with Public and All displayed from the Scope drop-down menu. If 'All' is selected from the Scope field, then all integration interfaces including public, private to application, and internal to Oracle interfaces can be listed in the results region.

Note: System integration analysts can view Public integration interfaces only, and they do not have the access privileges to view Private to Application and Internal to Oracle interfaces from the Oracle Integration Repository.

In addition, they can only find 'All' (default) and 'Public' list of values available from the Scope drop-down list. And only Public integration interfaces will be retrieved and listed in the search result even if they do not change the default value 'All' in the Scope field.

For detailed information on Public, Private to Application, and Internal to Oracle, see Scope, Oracle E-Business Suite Integrated SOA Gateway User's Guide.

By using the search feature, you can easily locate a deployed Web service for a particular product or product family if you want to use the deployed service for a partner link creation while orchestrating the BPEL process.

For example, to locate all deployed Web services for concurrent program, first select 'Concurrent Program' from the Interface drop-down list and then click Show More Search Options to select 'Deployed' for the Web Service Status field. After executing the search, you should find all deployed Web services for the concurrent program interface type.

Searching for Deployed Web Services

the picture is described in the document text

Searching for Java Bean Services, Application Module Services, and Security Services

Java Bean Services, Application Module Services, and Security Services are all specialized Java classes and are categorized as a subtype of Java interfaces and displayed in the Integration Repository under the Java interface type.

To easily locate these interfaces or services through the Search page, click the Show More Search Options link to display more search fields. Enter the following key search values along with any product family or scope if needed as the search criteria:

Note: Although you can search and locate the 'Java APIs for Forms' interfaces from the search, these Forms-based Web services are desupported in Oracle E-Business Suite Release 12.2. If you are planning to use this type of interfaces as Web services, you are advised to use alternate serviceable interfaces, such as PL/SQL and Business Service Objects interfaces, which can be deployed as Web services. Refer to My Oracle Support Knowledge Document 966982.1 for the suggested alternatives to the existing Java APIs for Forms services.

To view the interface or service details, click the interface or service name link that you want to view from the search result region. The interface details page is displayed. For more information on interface details, see Reviewing Interface Details.

Searching for Custom Integration Interfaces

Annotated custom interface definitions, once they are uploaded successfully, are merged into the interface types they belong to and displayed together with Oracle interfaces from the Integration Repository browser window. To easily distinguish annotated custom interface definitions from Oracle interfaces, the Interface Source "Custom" is used to categorize those custom integration interfaces in contrast to Interface Source "Oracle" for Oracle interfaces.

Therefore, you can search for custom integration interfaces by clicking Show More Search Options to display more search fields.

Searching for Custom Integration Interfaces

the picture is described in the document text

Enter the following information along with any interface type, product family, or scope if needed as the search criteria:

For information on how to view custom integration interfaces, see Viewing Custom Integration Interfaces, Oracle E-Business Suite Integrated SOA Gateway User's Guide.

For more information on each search field in the Search page, see Searching for an Integration Interface, Oracle E-Business Suite Integrated SOA Gateway User's Guide.

To search for all integration interface types:

  1. Log in to Oracle Integration Repository as a user who has the System Integration Developer role.

    Select the Integrated SOA Gateway responsibility from the navigation menu. Select the Integration Repository link to open the repository browser.

  2. Click Search to open the main Search page.

  3. Enter appropriate search information such as product family, product, interface type, or business entity.

  4. Click Show More Search Options to open more search options.

  5. To view deployed integration interfaces, select 'Deployed' from the Web Service Status field drop-down list.

  6. To view all integration interfaces, select All from the Scope field. This allows all integration interfaces including Public, Internal to Oracle, and Private to Application displayed in the results region.

  7. To view integration interfaces of Public, Internal to Oracle, or Private to Application type, select 'Public', 'Internal to Oracle', or 'Private to Application' from the Scope drop-down list respectively.

  8. Click Go to execute the search. All interfaces that match your search criteria are displayed.

  9. Select an interface type from the search result to view the interface details.

Reviewing Interface Details

After searching for an integration interface, a system integration developer can review a selected interface details by clicking on an interface name from the search result page. This opens the interface details page where the developer can view the interface general information, a description region, a source region, and an interface methods or procedure and functions region.

Based on the selected interface, the developer can view the associated Web service information including the SOAP-based and REST-based services if it's available in the interface details page.

Note: Only PL/SQL APIs and Concurrent Programs can be exposed as both SOAP and REST services. Java Bean Services and Application Module Services can be exposed as REST services only.

For more information on SOAP-based services, see Common Information on SOAP Web Services, Oracle E-Business Suite Integrated SOA Gateway User's Guide.

For more information on REST-based services, see Common Information on REST Web Services, Oracle E-Business Suite Integrated SOA Gateway User's Guide.

Once a Web service is generated, a system integration developer can then use the associated WSDL or WADL definition in invoking the Oracle E-Business Suite service. For information on how to invoke Oracle E-Business Suite services, see each individual chapter described in this book.

Reviewing WSDL Element Details

If an interface can be exposed as a Web service, the corresponding WSDL file is created and can be accessed through the interface details page.

By clicking the View WSDL link, a new window containing the WSDL document appears. This XML-based document describes a selected Web service as a set of endpoints operating on messages containing document-oriented information.

Locating the Interface Exposed as a Web Service

the picture is described in the document text

For example, click the deployed View WSDL link for the PL/SQL: Invoice Creation from the interface details page, the WSDL document appears.

the picture is described in the document text

Note: The http:// address in the new window has the exact WSDL URL information that appeared in the interface details page. This address can be copied and used directly in any of the Web service clients for invoking Web services.

For example, it can be used while creating a partner link for the invocation of the interface that is exposed as Web service in a BPEL process.

WSDL Document Structure

A WSDL document is simply a set of definitions. There is a definitions element at the root, and definitions inside. The definitions element defines the set of services that the Web service offers.

It often contains an optional TargetNamespace property, a convention of XML schema that enables the WSDL document to refer to itself.

The structure of this definitions element can be like:

<definitions name="nmtoken"
  <targetNamespace="uri">
   <import namespace="uri" location="uri"/> *
</definitions>

For example, a corresponding WSDL document for the Invoice Creation API (AR_INVOICE_API_PUB) that is exposed as a Web service appears in a new window.

<definitions name="AR_INVOICE_API_PUB"  
targetNamespace="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/ar_invoice_api_pub/"
xmlns:tns="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/ar_invoice_api_pub/
xmlns="http://schemas.xmlsoap.org/wsdl/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:tns1="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/ar_invoice_api_pub/create_invoice/" 
xmlns:tns2="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/ar_invoice_api_pub/create_single_invoice/>

For example, the definitions element specifies that this WSDL document is the called 'AR_INVOICE_API_PUB'. It also specifies numerous namespaces that will be used throughout the remainder of the document. It also specifies a default namespace: xmlns=http://schemas.xmlsoap.org/wsdl/.

In addition to the definitions element, Web services are defined using the following six major elements:

The following diagram shows the relationship of the basic parts of WSDL:

the picture is described in the document text

Types

The types element contains all data types used in all method calls described in the WSDL. It can be used to specify the XML Schema (xsd:schema) that is used to describe the structure of a WSDL Part.

The structure of this Types element can be like:

<definitions...>
	<types>
  		<xsd:schema.../>*
   </types>
</definitions>

For example, the Invoice Creation Web service contains the following two functions:

Each function is described in the data type definition. WSDL prefers the use of XSD as the type of system mechanism to define the types in a message schema. As a result, the message schema location of the CREATE_INVOICE function is defined in the APPS_XX_BPEL_CREATE_INVOICE_AR_INVOICE_API_PUB-24CREATE_INV.xsd. The message schema location of the CREATE_SINGLE_INVOICE function is defined in the APPS_XX_BPEL_CREATE_SINGLE_INVOICE_AR_INVOICE_API_PUB-24CREATE_SIN.xsd.

<types>
  	<schema xmlns="http://www.w3.org/2001/XMLSchema" 
			elementFormDefault="qualified" 
			targetNamespace="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/ar_invoice_api_pub/create_invoice/">
			<include 
			schemaLocation="https://<hostname>:<port>/webservices/SOAProvider/plsql/ar_invoice_api_pub/APPS_XX_BPEL_CREATE_INVOICE_AR_INVOICE_API_PUB-24CREATE_INV.xsd"/> 
   </schema>
		<schema xmlns="http://www.w3.org/2001/XMLSchema" 
			elementFormDefault="qualified" 
			targetNamespace="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/ar_invoice_api_pub/create_single_invoice/">
			<include 
			schemaLocation="https:///<hostname>:<port>/webservices/SOAProvider/plsql/ar_invoice_api_pub/APPS_XX_BPEL_CREATE_SINGLE_INVOICE_AR_INVOICE_API_PUB-24CREATE_SIN.xsd"/> 
   </schema>
...		

In addition to message schema locations and schema elements that help to define Web messages, the Types element can also take a complex data type as input.

For example, the Responsibility, Responsibility Application, Security Group, NLS Language, and Organization ID complex types listed under the "SOAHeader" as shown below are used in passing values that would be used to set applications context during service execution.

...
<schema xmlns="http://www.w3.org/2001/XMLSchema" 
			elementFormDefault="qualified" 
			targetNamespace="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/ar_invoice_api_pub/">
			<element name="SOAHeader">
			 	<complexType>
					<sequence> 
						<element name="Responsibility" minOccurs="0" type="string"/>
      				<element name="RespApplication" minOccurs="0" type="string"/>
      				<element name="SecurityGroup" minOccurs="0" type="string"/>
      				<element name="NLSLanguage" minOccurs="0" type="string"/>
                 <element name="Org_Id" minOccurs="0" type="string" />
 					</sequence>
				</complexType>
  		</element>
 	</schema>
</types>

Message

The Message element defines the name of the message. It consists of one or more Part elements, which describe the content of a message using Element or Type attributes.

Parts are a flexible mechanism for describing the logical abstract content of a message. A binding may reference the name of a part in order to specify binding-specific information about the part.

The structure of this element can be like:

<definitions...>
	<message name="nmtoken"> *
 		<part name="nmtoken" element="qname"? type="qname"? />   
	</message>
</definitions>

A typical document-style Web service could have a header and body part in the input message and output message as well. For example, the Message element for the Invoice Creation Web service appears:

<message name="CREATE_INVOICE_Input_Msg">
  	<part name="header" element="tns:SOAHeader"/> 
   <part name="body" element="tns1:InputParameters"/> 
</message>
<message name="CREATE_INVOICE_Output_Msg">
   <part name="body" element="tns1:OutputParameters"/> 
</message>
<message name="CREATE_SINGLE_INVOICE_Input_Msg">
  	<part name="header" element="tns:SOAHeader"/> 
   <part name="body" element="tns2:InputParameters"/> 
</message>
<message name="CREATE_SINGLE_INVOICE_Output_Msg">
  	<part name="body" element="tns2:InputParameters"/> 
</message>

Each message defined by the associated schema includes input message and output message parts. For example, the Invoice Creation Web service has two functions:

The value of body part of each message will be set as SOAP body; the value of header part will be set in the SOAP header which is required for Web service authorization.

For more information, see Understanding Web Service Input Message Parts.

PortType

The portType element combines multiple message elements to form a complete one-way or round-trip operation supported by a Web service.

For example, a portType can combine one request (input message element) and one response (output message element) message into a single request/ response operation for the synchronous request - response operation, most commonly used in SOAP services.

If it is for one-way operation, then the operation would contain an Input element only.

The structure of this element can be like:

<wsdl:definitions...>
	<wsdl:portType name="nmtoken">*
   		<operation name="nmtoken"/> 
    			<wsdl:input name="nmtoken"? message="qname">?  
				</wsdl:input>
				<wsdl:output name="nmtoken"? message="qname">?  
				</wsdl:output>
				<wsdl:fault name="nmtoken"? message="qname">? 
				</wsdl:fault>
			</wsdl:operation> 
	</wsdl:portype>
</wsdl:definitions>

Note: An optional Fault element can be used for error handling in both request-response and solicit response Operation models. This feature is not supported in this release.

In this Invoice Creation Web service example, corresponding to above two functions, AR_INVOICE_API_PUB_PortType has the following two operations:

<portType name="AR_INVOICE_API_PUB_PortType">
   		<operation name="CREATE_INVOICE"> 
    			<input name="tns:CREATE_INVOICE_Input_Msg" /> 
				<output name="tns:CREATE_INVOICE_Output_Msg" />   
			</operation> 
			<operation name="CREATE_SINGLE_INVOICE"> 
    			<input name="tns:CREATE_SINGLE_INVOICE_Input_Msg" /> 
				<output name="tns:CREATE_SINGLE_INVOICE_Output_Msg" />   
			</operation>
</portype>

Binding

A binding defines message format and protocol details for operations and messages defined by a particular portType. It provides specific details on how a portType operation will actually be transmitted over the Web. Bindings can be made available through multiple transports, including HTTP GET, HTTP POST, or SOAP.

A port defines an individual endpoint by specifying a single address for a binding.

The structure of this element can be like:

<wsdl:definitions...>
	<wsdl:binding name="nmtoken" type="qname">*
   	<wsdl:operation name="nmtoken"/> 
    		<wsdl:input> ?
      	</wsdl:input>
			<wsdl:output>?  
			</wsdl:output>
			<wsdl:fault name="nmtoken"? message="qname">? 
			</wsdl:fault>
		</wsdl:operation> 
	</wsdl:binding>
</wsdl:definitions>

In the same example, the binding element as shown below describes the SOAP binding for PortType AR_INVOICE_API_PUB_PortType.

<binding name="AR_INVOICE_API_PUB_Binding" type="tns:AR_INVOICE_API_PUB_PortType">
	<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> 
     		<operation name="CREATE_INVOICE"> 
				<soap:operation
				 soapAction="https:///<hostname>:<port>/webservices/SOAProvider/plsql/ar_invoice_api_pub/"/> 
				<input>
					<soap:header message="tns:CREATE_INVOICE_Input_Msg" part="header" use="literal" />
					<soap:body parts="body" use="literal" /> 
 			</input>
				<output>
					<soap:body use="literal" /> 
	 			</output>    		  
			</operation> 
			<operation name="CREATE_SINGLE_INVOICE"> 
    		<soap:operation
				 soapAction="https:///<hostname>:<port>/webservices/SOAProvider/plsql/ar_invoice_api_pub/"/> 
				<input>
					<soap:header message="tns:CREATE_SINGLE_INVOICE_Input_Msg" part="header" use="literal" />
					<soap:body parts="body" use="literal" /> 
 			</input>
				<output>
					<soap:body use="literal" /> 
	 			</output>    		  
			</operation> 
	</binding

The binding used is always document style, SOAP over http binding. It also defines the content of SOAP header and SOAP body.

Note: Because it is a document-style service (style="document"), the request and response messages will consist of simply XML documents, instead of using the wrapper elements required for the remote procedure call (RPC-style) Web service. The transport attribute indicates the transport of the SOAP messages is through SOAP HTTP.

Within each operation, the soap:operation element indicates the binding of a specific operation (such as CREATE_INVOICE) to a specific SOAP implementation. The soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the service.

The soap:header element allows header to be defined that is transmitted inside the Header element of the SOAP Envelope. The SOAHeader comprises of Responsibility, RespApplication, SecurityGroup, NLSLanguage, and Org_Id complex types within the Types element.

The soap:body element enables you to specify the details of the input and output messages for a specific operation.

Service

The service element defines the Web service, and typically consists of one or more Port elements. A port defines an individual endpoint by specifying a single address for a binding.

The service binding is commonly created using SOAP.

The structure of this element can be like:

<wsdl:definitions...>
	<wsdl:service name="nmtoken">*
   		<wsdl:port name="nmtoken" binding="qname"> *
      	</wsdl:port>	
	</wsdl:service>
</wsdl:definitions>

In this example, the Service element AR_INVOICE_API_PUB_Service defines physical location of service endpoint where the service is hosted for the portType AR_INVOICE_API_PUB_PortType.

<service name="AR_INVOICE_API_PUB_Service">
		<port name="AR_INVOICE_API_PUB_Port" binding="tns:AR_INVOICE_API_PUB_Binding">
			<soap:address 
			location="https:///<hostname>:<port>/webservices/SOAProvider/plsql/ar_invoice_api_pub/"/>
		</port>
	</service>

Reviewing WADL Element Details

If an interface is exposed as a REST service, you can view the corresponding WADL description in a separate window.

Take the same interface example PL/SQL API Invoice Creation (AR_INVOICE_API_PUB) explained earlier for WSDL description. This interface can also be exposed as a REST service. To view the associated WADL information, click View WADL link in the REST Web Service tab of the interface details page. The WADL document appears.

WADL Document Structure

WADL (Web Application Description Language) is designed to provide a machine processable description of HTTP-based Web applications.

The application element forms the root of a WADL description. It may contain the following elements:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 
<application xmlns:tns="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/rest/ar_invoice_api_pub/" xmlns="http://wadl.dev.java.net/2009/02"
xmlns:tns1="http://xmlns.oracle.com/apps/ar/rest/ar/create_invoice/" name="AR_INVOICE_API_PUB" 
targetNamespace="http://xmlns.oracle.com/apps/ar/soaprovider/plsql/rest/ar_invoice_api_pub/">
  	<grammars>
...
  	</grammars>
   <resources base="http://<hostname>:<port>/webservices/rest/Invoice/">
		...
	</resources
</application>

Grammars

This element acts as a container for definitions of data exchanged during execution of the protocol described by the WADL document. Include element is often referenced to allow the definitions of one or more data format descriptions to be included.

  	<grammars>
  		<include xmlns="http://www.w3.org/2001/XMLSchema" href="https://<hostname>:<port>/webservices/rest/Invoice/?XSD=CREATE_INVOICE.xsd" /> 
		   <include xmlns="http://www.w3.org/2001/XMLSchema" href="https://<hostname>:<port>/webservices/rest/Invoice/?XSD=CREATE_SINGLE_INVOICE.xsd" /> 
   	</grammars>

Invoice highlighted here is the service alias name entered earlier prior to the service deployment. Once the service has been successfully deployed, the specified alias name (Invoice) becomes part of the service endpoint in the WADL and namespaces in the XSDs.

Resources

The resources element represents the resource information provided by the Web application. It includes a base attribute that provides the base URI for each included child resource identifier.

For example, each child resource element represents a specific service operation (such as create_invoice and create_single_invoice) contained in the selected interface.

	<resources base="http://<hostname>:<port>/webservices/rest/Invoice/">
		<resource path="/create_invoice/">
			...
		</resource>
		<resource path="/create_single_invoice/">
			...
  	</resource>
	</resources>

Resource

A resources element may contain a set of resource elements; each resource element represents a REST service operation. In this example, create_invoice and create_single_invoice are included child resource element.

Each resource element can include the following child elements:

	<resources base="http://<hostname>:<port>/webservices/rest/Invoice/">
		<resource path="/create_invoice/">
			<method id="CREATE_INVOICE" name="POST">
				<request>
					<representation mediaType="application/xml" type="tns1:InputParameters" /> 
					<representation mediaType="application/json" type="tns1:InputParameters" /> 
				</request>
				<response>
					<representation mediaType="application/xml" type="tns1:OutputParameters" /> 
					<representation mediaType="application/json" type="tns1:OutputParameters" /> 
				</response>
			</method>
		</resource>
		<resource path="/create_single_invoice/">
			<method id="CREATE_SINGLE_INVOICE" name="POST">
				<request>
					<representation mediaType="application/xml" type="tns2:InputParameters" /> 
					<representation mediaType="application/json" type="tns2:InputParameters" /> 
				</request>
				<response>
					<representation mediaType="application/xml" type="tns2:OutputParameters" /> 
					<representation mediaType="application/json" type="tns2:OutputParameters" /> 
				</response>
			</method>
		</resource>
	</resources>

In this example, input request and output response messages are all supported with XML and JSON formats when applying the HTTP method POST for each resource element 'create_invoice' and 'create_single_invoice'.

If the deployed REST service is an interface type of Java Bean Services or Application Module Services, then both GET and POST can be shown as the supported methods in the REST service operation. For example, the following WADL description shows two of many methods contained in the Rest Service Locator interface. addGrant is implemented with POST HTTP method, and getOperations is assisted with GET HTTP method.

 	<resources base="http://<hostname>:<port>/webservices/rest/locator/">
		<resource path="/addGrant/">
			<method id="addGrant" name="POST">
				<request>
					<representation mediaType="application/xml" type="tns1:addGrant_InputParameters" /> 
					<representation mediaType="application/json" type="tns1:addGrant_InputParameters" /> 
				</request>
			<response>
					<representation mediaType="application/xml" type="tns1:addGrant_OutputParameters" /> 
					<representation mediaType="application/json" type="tns1:addGrant_OutputParameters" /> 
				</response>
			</method>
		</resource>
...
		<resource path="/getOperations/{irepClassName}/">
		  <param name="irepClassName" style="template" required="true" type="xsd:string"/>
			<method id="getOperations" name="GET">
				<request>
					<param name="ctx_responsibility" type="xsd:string" style="query" required="false" />
              <param name="ctx_respapplication" type="xsd:string" style="query" required="false" />
					<param name="ctx_securitygroup" type="xsd:string" style="query" required="false" />
					<param name="ctx_nlslanguage" type="xsd:string" style="query" required="false" />
					<param name="ctx_orgid" type="xsd:int" style="query" required="false" />
				</request>
		   	<response>
					<representation mediaType="application/xml" type="tns3:getOperations_OutputParameters" /> 
					<representation mediaType="application/json" type="tns3:getOperations_OutputParameters" /> 
				</response>
			</method>
		</resource>
</resources>

The GET method of the above example contains the path variable and application context information if required for the service execution:

Note: Path variables and context parameters are applicable only for HTTP GET method.

Control parameters are predefined query parameters that may be used for a resource or collection resource. For example, use offset and limit parameters to limit the number of records returned and for pagination.

offset=<number>&limit=<number>

Understanding SOAP Messages

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.

To support all integration interface types and services in Oracle E-Business Suite Integrated SOA Gateway, all SOAP messages are authenticated, authorized, and service enabled through SOA Provider except for Business Service Object services and generic XML Gateway messages that are enabled through Web Service Provider.

SOAP Message Structure

SOAP is an XML-based protocol and acts as a building block for Web service communication. 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:

The following diagram depicts the structure of a SOAP message.

SOAP Message Structure

the picture is described in the document text

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>

SOAP Security Header

When a SOAP request message is received through SOA Provider, the SOAP message is passed on to OC4J Web Service Framework for authentication. The framework authenticates the SOAP message based on the specified authentication type(s) during the service deployment. The identified authentication information is embedded in the wsse:security Web Security headers.

UsernameToken-based SOAP 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.

See A Sample Fault SOAP Response for Business Service Object.

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">myPasswd</wsse:Password>
	</wsse:UsernameToken>
</wsse:Security>

</soapenv:Header>

The UsernameToken based security mechanism 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).

The username/password in SOAP Header of a SOAP message will be passed for Web service authentication. 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 through SOA Provider or Web Service Provider.

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 along with the SOAP request when invoking an Oracle E-Business Suite Web service from a BPEL process, see Passing Values to Security Headers.

SAML Token-based SOAP Security Header

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 SOA Provider and passed on to OC4J Web Service Framework for authentication. The framework authenticates the SOAP message based on the wsse:security Web Security headers. As part of the validation and processing of the assertions, the receiver or authentication framework must establish the relationship between 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 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 (SSO user) or Oracle E-Business Suite FND_USER table (for non-SSO user).

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

<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, Oracle E-Business Suite Integrated SOA Gateway Implementation Guide.

SOAP Header for Applications Context

Applications context contains many crucial elements that are used in passing values that may be required in proper functioning of Oracle E-Business Suite Web services. 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:

The following SOAP message shows the SOAHeader part highlighted in bold text:

<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">myPasswd</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 Business Service Object services are:

The following SOAP request example includes the ServiceBean_Header part highlighted in bold text for business service object:

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

SOAP Header for XML Gateway Messages

The SOAP header part can also be used to populate header variables for XML Gateway inbound transactions to be completed successfully. These XML Gateway header parameters defined in the SOAHeader (through SOA Provider) or XMLGateway_Header (through Web Service Provider) part of a SOAP Request are described in the following table:

The following code snippet shows the SOAHeader part of a SOAP request for an XML Gateway inbound message through SOA Provider:

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

The following table describes the XML Gateway header information in SOAHeader part of a SOAP request:

XMLGateway Header Information in SOAHeader Part of 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.

The following code snippet shows the XMLGateway_Header part of a SOAP request through Web Service Provider:

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

Examples of SOAP Messages Through SOA Provider

To better understand SOAP request and response messages received through SOA Provider, the following sample SOAP messages are described in this section:

A Sample SOAP Request

The following example shows a 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">welcome</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@example.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>

A Sample SOAP Response

The following example shows a 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>

A Sample Fault SOAP Response

The SOAP Fault element is used to carry error and status information within a SOAP message.

For example, the following fault 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>

Examples of SOAP Messages Through Web Service Provider

To better understand SOAP request and response messages for business service object exposed to Web services through Web Service Provider, the following sample SOAP messages are described in this section:

A Sample SOAP Request for Business Service Object

The following example shows a valid SOAP request for business service object:

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

A Sample SOAP Response for Business Service Object

The following example shows a valid SOAP response for business service object:

<soapenv:Envelope xmlns:env=http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header/>
  <env:Body>
  <oans:IntegrationRepositoryService_GetInterfaceByType_Response 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
   xmlns:oans="http://xmlns.oracle.com/apps/fnd/rep/ws">
      <interfaceClass>
       	<ClassId>906</ClassId>
			<ClassName>XMLGATEWAY:CLN:SHIP_ORDER_CONFIRM_OUT</ClassName>
  			<IrepName>CLN:SHIP_ORDER_CONFIRM_OUT</IrepName>
			<SecurityGroupId xsi:nil="true"/>    
			<ClassType>XMLGATEWAY</ClassType>
        	<ProductCode>cln</ProductCode>
			<ImplementationName xsi:nil="true"/>
			<DeployedFlag>N</DeployedFlag>
			<GeneratedFlag>N</GeneratedFlag>
			<CompatibilityFlag>N</CompatibilityFlag>
   		<AssocClassId xsi:nil="true"/>
			<ScopeType>PUBLIC</ScopeType>
			<LifecycleMode>ACTIVE</LifecycleMode>
			<SourceFileProduct>CLN</SourceFileProduct>
         ...
        
      <InterfaceFunction>
       ...
      </InterfaceFunction>
    </InterfaceClass>
  </oans:IntegrationRepositoryService_GetInterfaceByType_Response>
 </env:Body>
</env:Envelope>

A Sample Fault SOAP Response for Business Service Object

The SOAP Fault element is used to carry error and status information within a SOAP message.

For example, if a SOAP request message contains invalid header information or the header is missing from the request, then Fault element appears as a body entry in the response message as shown below for business service object:

<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>SOAP-ENV:Client</faultcode>
      <faultstring>InvalidHeader: Invalid or missing header in request.</faultstring>
   </env:Fault>
 </env:Body>
</env:Envelope>

Understanding REST Messages

Based on REST architecture, the REST message uses HTTP header and method POST to create or update Oracle E-Business Suite data through a service provider.

Supporting XML and JSON Message Formats

Unlike SOAP message completely based on XML format, REST messages can process both XML and non-XML formats such as JSON.

Note: Only Jackson JSON format is supported in this release. Other JSON formats, like Google GSON are not supported.

REST Message Structure

A REST request is a simple HTTP request which includes the following elements:

The following diagram depicts the structure of a REST message:

the picture is described in the document text

REST Security Header

User credentials must be authenticated based on either one of the following methods:

REST Header for Applications Context

Some Oracle E-Business Suite APIs require applications context values to be passed before they can be invoked. These context values including Responsibility, RespApplication. SecurityGroup, NLSLanguage, and Org_Id may be included in the RESTHeader element as part of the HTTP body.

Optional Context Values in Token Based Security

Context header values are optional. If the context values are not passed while using token based security, the previously passed values will be used. If context values are passed, newly passed values will override the ones set previously for the given token.

The following REST message in XML format shows the RESTHeader element printed in bold:

<?xml version = '1.0' encoding = 'UTF-8'?>
<TESTUSERNAME_Input xmlns="http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/testusername/">
	   <RESTHeader xmlns="http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/header">
			<Responsibility>SYSTEM_ADMINISTRATOR</Responsibility>
    	<RespApplication></RespApplication>
    	<SecurityGroup></SecurityGroup>
    	<NLSLanguage>AMERICAN</NLSLanguage>
    	<Org_Id>/Org_Id>
    </RESTHeader>
    <InputParameters>
			<X_USER_NAME>sysadmin</X_USER_NAME>
    </InputParameters>
</TESTUSERNAME_Input>

Constructing Payload from WADL Description

Based on the resources information in a WADL description, you can compile an input payload before invoking a REST service.

Use the following steps to compile an input payload:

  1. In the Integration Repository, search and locate the deployed REST service that you want to use.

  2. Click the View WADL link in the REST Web Service tab. The following WADL description appears:

    <xml version="1.0" encoding="UTF-8" standalone="no" ?> 
    <application xmlns:tns="http://xmlns.oracle.com/apps/fnd/soaprovider/plsql/rest/fnd_user_pkg/" xmlns="http://wadl.dev.java.net/2009/02" xmlns:tns1="http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/testusername/" name="FND_USER_PKG"
    targetNamespace="http://xmlns.oracle.com/apps/fnd/soaprovider/plsql/rest/fnd_user_pkg/">
    <grammars>
      		<include xmlns="http://www.w3.org/2001/XMLSchema" href="https://<hostname>:<port>/webservices/rest/FndUserSvc/?XSD=TESTUSERNAME_SYNCH_TYPEDEF.xsd" /> 
    </grammars>
    	<resources base="http://<hostname>:<port>/webservices/rest/FndUserSvc/">
    		<resource path="/testusername/">
    			<method id="GET" name="POST">
    				<request>
    					<representation mediaType="application/xml" type="tns1:InputParameters" /> 
    					<representation mediaType="application/json" type="tns1:InputParameters" /> 
    				</request>
    				<response>
    					<representation mediaType="application/xml" type="tns1:OutputParameters" /> 
    					<representation mediaType="application/json" type="tns1:OutputParameters" /> 
    				</response>
    			</method>
    		</resource>
    	</resources>
    </application>
    
  3. Locate the schema information (.XSD) for the Test User Name (TESTUSERNAME) service operation from the WADL description. The XSD for the operation TESTUSERNAME in the WADL would be:

    http://<hostname>:<port>/webservices/rest/FndUserSvc/?XSD=TESTUSERNAME_SYNCH_TYPEDEF.xsd

    Note: The schema information for the service operation can also be constructed by concatenating the values of the following elements from the WADL description:

  4. Construct the payload of the service by using any XSD to XML conversion tools to get the payload information.

Once the payload is compiled, it can be used to invoke the TESTUSERNAME REST service operation. The request, response, and fault messages with both XML and JSON formats are listed in the following table:

  REST Messages with XML and JSON Formats
Input Payload (Request Message) XML-based REST Message
<?xml version="1.0" encoding="UTF-8" ?>
<TESTUSERNAME_Input xmlns="http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/testusername/">
	<RESTHeader xmlns="http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/header">
    	<Responsibility>SYSTEM_ADMINISTRATOR</Responsibility>
    	<RespApplication></RespApplication>
    	<SecurityGroupE></SecurityGroup>
    	<NLSLanguage></NLSLanguage>
    	<Org_Id></Org_Id>
  	</RESTHeader>
  <InputParameters>
		<X_USER_NAME>sysadmin</X_USER_NAME>
	</InputParameters>
</TESTUSERNAME_Input>	

JSON-based REST Message
{"TESTUSERNAME_Input":{
"@xmlns":"http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/testusername/",
"RESTHeader":{
"@xmlns":"http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/header",
"Responsibility":"SYSTEM_ADMINISTRATOR",
"RespApplication":"SYSADMIN",
"SecurityGroup":"STANDARD",
"NLSLanguage":"AMERICAN",
"Org_Id":"202"
},
"InputParameters":{
"X_USER_NAME":"operations"
}
}} 
Response XML-based REST Message
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<OutputParameters xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://xmlns.oracle.com/apps/fnd/rest/FndUserSvc/testusername/">
<X_USER_NAME>2</X_USER_NAME>
</OutputParameters>

JSON-based REST Message
{
  "OutputParameters" : {
    "@xmlns:xsi" : "http://www.w3.org/2001/XMLSchema-instance",
    "@xmlns" : "http://xmlns.oracle.com/apps/fnd/rest/fndGlobalSvc/user_id/",
    "TESTUSERNAME" : "2"
  }
}
  
Error Response XML-based REST Message
<ISGServiceFault>
	<Code>IRepAccessError</Code>
	<Message>This is a sample Fault Message. Message will vary depending on fault condition</Message>
	<Resolution>Check the server logs for details</Resolution>
	<ServiceDetails>
		<ServiceName>FndUserSvc</ServiceName>
		<OperationName>testusername</OperationName>
		<InstanceId>0</InstanceId>
	</ServiceDetails>	
</ISGServiceFault>

JSON-based REST Message
{
  "ISGServiceFault": {
    "Code": "IRepAccessError",
    "Message": "Sample Fault Message. Will vary depending on fault condition",
    "Resolution": "Check the server logs for details",
    "ServiceDetails": {
      "ServiceName": "FndUserSvc",
      "OperationName": "testusername",
      "InstanceId": "0"
    }
  }
}

For more examples of REST messages used in OZF_SD_REQUEST_PUB service invocation, see Examples of REST Messages.

Examples of REST Messages

To better understand REST request and response messages received through Oracle E-Business Suite, the following sample REST messages are described in this section:

A Sample XML-based REST Request

The following example shows a synchronous XML-based REST request for a PL/SQL service (OZF_SD_REQUEST_PUB API):

<?xml version="1.0" encoding="UTF-8" ?>
<CREATE_SD_REQUEST_Input xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://xmlns.oracle.com/apps/ozf/rest/ozfsdrequestpubsvc/create_sd_request/xsd/OZF_SD_REQUEST_PUB_CREATEREQUEST.xsd"
      xmlns="http://xmlns.oracle.com/apps/ozf/rest/ozfsdrequestpubsvc/create_sd_request/">
	<RESTHeader xmlns="http://xmlns.oracle.com/apps/fnd/rest/ozfsdrequestpubsvc/header">
    	<Responsibility>SYSTEM_ADMINISTRATOR</Responsibility>
    	<RespApplication></RespApplication>
    	<SecurityGroupE></SecurityGroup>
    	<NLSLanguage></NLSLanguage>
    	<Org_Id></Org_Id>
  	</RESTHeader>
  <InputParameters>
		<P_API_VERSION_NUMBER>1.0</P_API_VERSION_NUMBER>
		<P_INIT_MSG_LIST>T</P_INIT_MSG_LIST>
 	   <P_COMMIT>F</P_COMMIT>
		<P_VALIDATION_LEVEL>100</P_VALIDATION_LEVEL>
      <P_SDR_HDR_REC>
        <REQUEST_NUMBER>SDR-CREATE-BPEL1</REQUEST_NUMBER>
        <REQUEST_START_DATE>2008-08-18T12:00:00</REQUEST_START_DATE>
  		  <REQUEST_END_DATE>2008-10-18T12:00:00</REQUEST_END_DATE>>
        <USER_STATUS_ID>1701</USER_STATUS_ID>
        <REQUEST_OUTCOME>IN_PROGRESS</REQUEST_OUTCOME>
        <REQUEST_CURRENCY_CODE>USD</EQUEST_CURRENCY_CODE>
        		<SUPPLIER_ID>601</SUPPLIER_ID>
        		<SUPPLIER_SITE_ID>1415</SUPPLIER_SITE_ID>
       		<REQUESTOR_ID>100001499</REQUESTOR_ID>
		 	 	<ASSIGNEE_RESOURCE_ID>100001499</ASSIGNEE_RESOURCE_ID>
		  		<ORG_ID>204</ORG_ID>
		  		<ACCRUAL_TYPE>SUPPLIER</ACCRUAL_TYPE>
		  		<REQUEST_DESCRIPTION>Create</REQUEST_DESCRIPTION>
				<SUPPLIER_CONTACT_EMAIL_ADDRESS>sdr.supplier@example.com</SUPPLIER_CONTACT_EMAIL_ADDRESS>
       		<SUPPLIER_CONTACT_PHONE_NUMBER>2255</SUPPLIER_CONTACT_PHONE_NUMBER>
   	 		<REQUEST_TYPE_SETUP_ID>400</REQUEST_TYPE_SETUP_ID>
       		<REQUEST_BASIS>Y</REQUEST_BASIS>
       		<USER_ID>1002795</USER_ID>
   </P_SDR_HDR_REC>
   <P_SDR_LINES_TBL>
     <P_SDR_LINES_TBL_ITEM>
       	<PRODUCT_CONTEXT>PRODUCT</PRODUCT_CONTEXT>
				<INVENTORY_ITEM_ID>2155</INVENTORY_ITEM_ID>
				<ITEM_UOM>Ea</ITEM_UOM>
				<REQUESTED_DISCOUNT_TYPE>%</REQUESTED_DISCOUNT_TYPE>
				<REQUESTED_DISCOUNT_VALUE>20</REQUESTED_DISCOUNT_VALUE>
				<COST_BASIS>200</COST_BASIS>
				<MAX_QTY>200</MAX_QTY>
				<DESIGN_WIN>200</DESIGN_WIN>
				<APPROVED_DISCOUNT_TYPE>%</APPROVED_DISCOUNT_TYPE>
				<APPROVED_DISCOUNT_VALUE>20</APPROVED_DISCOUNT_VALUE>
				<APPROVED_MAX_QTY>200</APPROVED_MAX_QTY>
				<VENDOR_APPROVED_FLAG>Y</VENDOR_APPROVED_FLAG>
				<PRODUCT_COST_CURRENCY>USD</PRODUCT_COST_CURRENCY>
				<END_CUSTOMER_CURRENCY>USD</END_CUSTOMER_CURRENCY>
     </P_SDR_LINES_TBL_ITEM>
   </P_SDR_LINES_TBL>
   <P_SDR_CUST_TBL>
		<P_SDR_CUST_TBL_ITEM>
			<CUST_ACCOUNT_ID>1290</CUST_ACCOUNT_ID>
			<PARTY_ID>1290</PARTY_ID>
			<SITE_USE_ID>10479</SITE_USE_ID>
			<CUST_USAGE_CODE>BILL_TO</CUST_USAGE_CODE>
			<END_CUSTOMER_FLAG>N</END_CUSTOMER_FLAG>
		</P_SDR_CUST_TBL_ITEM>	
		<P_SDR_CUST_TBL_ITEM>
			<CUST_ACCOUNT_ID>1287</CUST_ACCOUNT_ID>
			<PARTY_ID>1287</PARTY_ID>
			<SITE_USE_ID>1418</SITE_USE_ID>
			<CUST_USAGE_CODE>CUSTOMER</CUST_USAGE_CODE>
			<END_CUSTOMER_FLAG>Y</END_CUSTOMER_FLAG>
		</P_SDR_CUST_TBL_ITEM>
   </P_SDR_CUST_TBL>
  </InputParameters>
</CREATE_SD_REQUEST_Input>

A Sample JSON-based REST Request

The following example shows a synchronous JSON-based POST request for the same PL/SQL service (OZF_SD_REQUEST_PUB API):

Note: Only Jackson JSON format is supported in this release. Other JSON formats, like Google GSON are not supported.

{
  "CREATE_SD_REQUEST_Input": {
    "@xmlns": "http://xmlns.oracle.com/apps/ozf/rest/ozfsdrequestpubsvc/create_sd_request/",
    "RESTHeader": {
      "@xmlns": "http://xmlns.oracle.com/apps/fnd/rest/ozfsdrequestpubsvc/header",
      "Responsibility": "SYSTEM_ADMINISTRATOR"
    },
    "InputParameters": {
      "P_API_VERSION_NUMBER": "1.0",
      "P_INIT_MSG_LIST": "T",
      "P_COMMIT": "F",
      "P_VALIDATION_LEVEL": "100",
      "P_SDR_HDR_REC": {
        "REQUEST_NUMBER": "SDR-CREATE-BPEL1",
        "REQUEST_START_DATE": "2008-08-18T12:00:00",
        "REQUEST_END_DATE": "2008-10-18T12:00:00",
        "USER_STATUS_ID": "1701",
        "REQUEST_OUTCOME": "IN_PROGRESS",
        "REQUEST_CURRENCY_CODE": "USD",
        "SUPPLIER_ID": "601",
        "SUPPLIER_SITE_ID": "1415",
        "REQUESTOR_ID": "100001499",
        "ASSIGNEE_RESOURCE_ID": "100001499",
        "ORG_ID": "204",
        "ACCRUAL_TYPE": "SUPPLIER",
        "REQUEST_DESCRIPTION": "Create",
        "SUPPLIER_CONTACT_EMAIL_ADDRESS": "sdr.supplier@example.com",
        "SUPPLIER_CONTACT_PHONE_NUMBER": "2255",
        "REQUEST_TYPE_SETUP_ID": "400",
        "REQUEST_BASIS": "Y",
        "USER_ID": "1002795"
      },
      "P_SDR_LINES_TBL": {
        "P_SDR_LINES_TBL_ITEM": {
          "PRODUCT_CONTEXT": "PRODUCT",
          "INVENTORY_ITEM_ID": "2155",
          "ITEM_UOM": "Ea",
          "REQUESTED_DISCOUNT_TYPE": "%",
          "REQUESTED_DISCOUNT_VALUE": "20",
          "COST_BASIS": "200",
          "MAX_QTY": "200",
          "DESIGN_WIN": "200",
          "APPROVED_DISCOUNT_TYPE": "%",
          "APPROVED_DISCOUNT_VALUE": "20",
          "APPROVED_MAX_QTY": "200",
          "VENDOR_APPROVED_FLAG": "Y",
          "PRODUCT_COST_CURRENCY": "USD",
          "END_CUSTOMER_CURRENCY": "USD"
        }
      },
      "P_SDR_CUST_TBL": {
        "P_SDR_CUST_TBL_ITEM": [
          {
            "CUST_ACCOUNT_ID": "1290",
            "PARTY_ID": "1290",
            "SITE_USE_ID": "10479",
            "CUST_USAGE_CODE": "BILL_TO",
            "END_CUSTOMER_FLAG": "N"
          },
          {
            "CUST_ACCOUNT_ID": "1287",
            "PARTY_ID": "1287",
            "SITE_USE_ID": "1418",
            "CUST_USAGE_CODE": "CUSTOMER",
            "END_CUSTOMER_FLAG": "Y"
          }
        ]
      }
    }
  }
}

The following example shows a JSON-based GET request for a Java Bean Service called REST Service Locator:

 Request Headers
            Authorization: Basic c3lzYWRtaW46c3lzYWRtaW4=
            Accept: application/json
            Content-Language: en-US

Note: For GET requests, JSON is the default output response format. Use Accept header application/xml to receive response in XML format. If Content-Type header is sent in GET HTTP request, it will be ignored.

A Sample XML-based REST Response

The following example shows an XML-based REST response for the OZF_SD_REQUEST_PUB API service:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<OutputParameters 
xmlns:xsl=""http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/apps/ozf/rest/ozfsdrequestpubsvc/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_IDxsi:nil="true"/>
</OutputParameters>

A Sample JSON-based REST Response

The following example shows a JSON-based REST response for the OZF_SD_REQUEST_PUB API service with POST method:

{
  "OutputParameters" : {
    "@xmlns:xsi" : "http://www.w3.org/2001/XMLSchema-instance",
    "@xmlns" : "http://xmlns.oracle.com/apps/ozf/rest/ozfsdrequestpubsvc/create_sd_request/",
    "X_RETURN_STATUS" : "E",
    "X_MSG_COUNT" : "1",
    "X_MSG_DATA" : "The Organization Id provided is invalid, please provide a valid Organization Id.",
    "X_REQUEST_HEADER_ID" : {
      "@xsi:nil" : "true"
    }
  }

The following example shows a JSON-based REST response for the REST Service Locator (getRestInterface service operation) service with GET method:

   {
                  "OutputParameters" : {
                    "EbsRestServiceBean" : [ {
                   "alternateAlias" : "plsql/PLSQL:FND_PROFILE",
                   "serviceAlias" : "NotAnything",
                   "serviceName" : "PLSQL:FND_PROFILE",
                   "wadlUrl" : "http://<hostname>:<port>/webservices/rest/profile?WADL"
                    } ],
                "ControlBean" : [ {
                      "fields" : "",
                      "filter" : "",
                      "limit" : "",
                      "offset" : ""
                } ]
          }
        }

Samples of XML-based Fault Responses

The following sample shows the XML-based REST response message when XML is not well formed:

<ISGServiceFault>
	<Code>RequestParsingError</Code>
	<Message>SAXException in XmlRequestObject, while parsing XML request The request could not be parsed correctly</Message>
	<Resolution>This may be due to malformed construction of the payload or incorrectContent-Type header. Please check the wellformed-ness of payload, matching Content-Type header of the http request and retry.</Resolution>
	<ServiceDetails>
		<ServiceName>ozfsdrequestpubsvc</ServiceName>
		<OperationName>create_sd_request</OperationName>
		<InstanceId>0</InstanceId>
	</ServiceDetails>	
</ISGServiceFault>

The following sample shows the XML-based REST response message when RespApplication (Responsibility Application short name) is invalid:

<ISGServiceFault>
	<Code>InvalidResponsibilityApplicationShortCode</Code>
	<Message>Responsibility short code is invalid System error while processing the request</Message>
	<Resolution>Check the server logs for details</Resolution>
	<ServiceDetails>
		<ServiceName>ozfsdrequestpubsvc</ServiceName>
		<OperationName>get_text_number</OperationName>
		<InstanceId>0</InstanceId>
	</ServiceDetails>	
</ISGServiceFault>