Integrating Cloud Applications on Software AG Hosted Environment : Integration Cloud : Applications : Creating SOAP Applications : SOAP Signature
SOAP Signature
All SOAP Application operations have an identical input and output signature with the exception of the variables used to represent the input and output messages. For information about how a SOAP Application operation represents the input and output messages in the signature, see How a SOAP Application Operation represents the Input and Output Messages.
How a SOAP Application Operation represents the Input and Output Messages
How a SOAP Application operation represents the contents of the input and output message in the signature depends on the style/use of the binder for the SOAP Application operation.
*For a SOAP Application operation that uses a style/use of Document/Literal:
*The input signature contains an optional document reference to a document type created to represent the operation input message. At run time, if you do not specify any input for the document reference variable or any of its child variables, Integration Cloud sends an empty SOAP body in the SOAP message.
*The output signature contains a document reference to a document type created to represent the operation output message. This document reference is conditional and is only returned by the SOAP Application operation if the SOAP Application operation executes successfully. If returned at run time, this document reference contains the response from a successful invocation of a SOAP Application operation. If the SOAP Application operation receives a SOAP fault, it is converted to an exception that can be caught with the try catch block in an Orchestrated Integration.
*For a SOAP Application operation that uses a style/use of RPC/Encoded or RPC/Literal:
*The input signature contains variables that represent the top-level elements in the operation input message. All of these variables are optional. At run-time, if you do not specify any input for the variable (or variables) that represent the input message, Integration Cloud sends an empty SOAP body in the SOAP message.
*The output signature contains variables that represent the top-level elements in the operation output message. All of these variables are conditional and are only returned by the SOAP Application operation if the SOAP Application operation executes successfully. If returned, these variables contain the response from a successful invocation of a SOAP Application operation.
Input Parameters
transportHeaders
Document Optional. Transport-specific header fields that you want to explicitly set in the request. Specify a key in transportHeaders for each header field that you want to set, where the key’s name represents the name of the header field and the key’s value represents the value of that header field.
The names and values supplied to transportHeaders must be of type String. For information about using transportHeaders with HTTP/S requests including a description of the default behavior, see Setting Transport Headers for HTTP/S.
Output Parameters
transportInfo
Document Conditional. Headers from response and request messages.
The contents of the transportInfo vary depending on the actual transport (HTTP or HTTPS) used.
transportInfo contains the following keys:
Key
Value
requestHeaders
Document Conditional. Header fields from the request message. The contents of the requestHeaders document are not identical to transportHeaders used as input. The transport can add, remove, or alter specific headers while processing the request.
Whether or not the SOAP Application operation returns the requestHeaders parameter depends on the success or failure of the operation. In the case of failure, the point at which the failure occurs determines the presence of the requestHeaders parameter. For more information, see Transport and Exceptions Returned by a SOAP Application Operation.
For the HTTP or HTTPS transports, the requestHeaders parameter will not contain any HTTP headers that the transport mechanism added or modified when sending the request.
responseHeaders
Document Conditional. Header fields from the response. Each key in responseHeaders represents a field (line) of the response header. Key names represent the names of header fields. The keys' values are Strings containing the values of the fields.
Whether or not the SOAP Application operation returns the responseHeaders parameter depends on the success or failure of the operation. In the case of failure, the point at which the failure occurs determines the presence of the responseHeaders parameter. For more information, see Transport and Exceptions Information Returned by a SOAP Application Operation.
For the HTTP or HTTPS transports, the responseHeaders parameter contains any HTTP/HTTPS headers present in the response.
status
String Conditional. Status code from the request, returned by the underlying transport.
For more information about status codes and status messages returned by a SOAP Application operation, see Transport and Exceptions Information Returned by a SOAP Application Operation.
statusMessage
String Conditional. Description of the status code returned by the transport.
For more information about status codes and status messages returned by a SOAP Application operation, see Transport and Exceptions Information Returned by a SOAP Application Operation.
Setting Transport Headers for HTTP/S
When creating a service that executes a SOAP Application operation, you can pass transport header information directly into the SOAP Application operation by passing name/value pairs in to the transportHeaders input parameter. When creating the SOAP request, Integration Cloud adds a transport header for each name/value pair.
Keep the following information in mind when setting transportHeaders for an HTTP/S request:
*Specify a key in transportHeaders for each header field that you want to set, where the key’s name represents the name of the header field and the key’s value represents the value of that header field.
*The names and values supplied to transportHeaders must be of type String. If a transport header has a name or value that is not of type String, the header will not be included in the message.
*For any header name/value pair supplied in transportHeaders for an HTTP/S request, Integration Cloud simply passes through the supplied headers and does not perform any validation for the headers beyond verifying that the name and value are of type String.
*If you do not set transportHeaders or do not specify the following header fields in transportHeaders, Integration Cloud adds and specifies values for the following standard header fields:
*Accept
*Authorization
*Connection
*Content-Type
*SOAPAction (Added when soapProtocol is SOAP 1.1 only)
*User-Agent
Note:  
Pass in the preceding headers to transportHeaders only if you are an experienced SOAP Application developer. Incorrect header values can result in failure of the request.
*For a SOAP Application operation, Integration Cloud sets the value of the Host header and overwrites any supplied value.
*If you specify Authorization in transportHeaders, the values specified for the auth/transport document and its children will not be used in the Authorization header.
*If you specify Content-Type in transportHeaders and the SOAP Protocol is SOAP 1.2, Integration Cloud ignores the value of soapAction obtained from the WSDL used to create the SOAP Application operation.
*If you specify the SOAPAction header in transportHeaders and the SOAP Protocol is SOAP 1.1, Integration Cloud ignores the value of SOAPAction obtained from the WSDL used to create the SOAP Application operation.
*Integration Cloud sets the value of Content-Length automatically and overwrites any value passed in to transportHeaders.
*Integration Cloud automatically adds the Cookie header to the HTTP header and supplies any cookies established between Integration Cloud and the HTTP server with which it is interacting. If you supply the Cookie header to transportHeaders, Integration Cloud prepends the values you supply to the already established Cookie header value.
*The following headers are considered to be standard and require the specified capitalization: Accept, Authorization, Connection, Content-Type, Cookie, Host, SOAPAction, User-Agent.
Important:  
Using capitalization other than that which is specified results in undefined behavior.
Important:  
Supplying duplicate entries for any standard header results in undefined behavior.
Transport and Exceptions Returned by a SOAP Application Operation
The transport information, such as headers, status codes, and status messages, returned by a SOAP Application operation varies depending on the following:
*The transport used to send and receive the SOAP message
*The success or failure of the SOAP Application operation
*The point at which failure occurs
*The message exchange pattern (MEP) for the operation
Note:  
Transport information is returned in the transportInfo output parameter.
If the SOAP Application operation receives a SOAP fault, it is converted to an exception that can be caught with the try catch block in an Orchestrated Integration.
SOAP Application Account Configuration Details
Applications
Copyright © 2015- 2017 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback