Dynamic Services

Dynamic services enable an application to consume Web services as it does other services—as part of a business process. Services are created based on the WSDL that you check in to the application.

These services can then communicate with a specified Web service using SOAP messages as part of a business process, enabling you to extend your business to use external Web functionality.

The following table provides an overview of Dynamic services.

System Name	Determined by the information in the WSDL
Graphical Process Modeler (GPM) categories	Dynamic Services
Description	Enables the application to consume a Web service as a normal service. User can check in the WSDL of the consumed Web service into the application. Once checked in, the application creates a service definition and service instances corresponding to operations within the WSDL and adds those service instances in the GPM Palette. The user can then use these services as a normal service and build a BPML out of it. Once this BPML is executed these services are called, which in turn makes a SOAP call to the service endpoint and returns the response back to the BPML. The main objective of the Dynamic service is to generate the SOAP message from the checked-in WSDL file. While the Default Transport configuration determines the transport to use to send the SOAP message (HTTP), a newer configuration option (“Other Transport”) is transport-independent.
Business usage	Include Web service functionality in a business process.
Usage example	You need to do currency conversions in a business process, and are aware of a Web service that performs conversions on the fly. You can include a Dynamic service in a business process. The service sends an amount and currency code to the Web service, along with the code of the currency to convert to, and receives the converted value back from the Web service.
Preconfigured?	No. A Dynamic service is created by checking in a WSDL file.
Requires third party files?	WSDL, and if required for signing SOAP messages, certificates and security tokens
Platform availability	All supported platforms for the application
Related services	Related services: SOA Inbound Message service SOA Outbound Message service Services and adapters used for transport, such as the HTTP Client Begin Session service, HTTP Client POST service, and the HTTP Client End Session service Note: These are configured automatically for the default (legacy) HTTP transport option SOA Inbound Security service (optional) SOA Outbound Security service (optional)
Application requirements	Application Web services
Initiates business processes?	No. Dynamic services are used within a business process.
Invocation	As part of a business process
Business process context considerations	Requires that values for parameters are passed through workflow context to the service; once the Web service returns a result, the result becomes the primary document.
Returned status values	Returned status values: Success Error
Restrictions	None
Persistence level	System default
Testing considerations	To test a Dynamic service, include it in a business process and run the process. For an overview of the procedure, see Implementing a Dynamic Service.

How Dynamic Services Are Created

The application creates Dynamic services based on information provided in a WSDL file that you check in.

In the WSDL, you specify each Web service and port combination that is required. The application creates a GPM stencil category for each unique Web service and port combination.

The name of the stencil category is always in upper case to avoid any conflicts with operating system restrictions. Therefore, you cannot specify two categories with the same name but with different capitalization.

In the WSDL, you also specify any operations needed for each Web service and port. The application creates a service definition and configuration of the service definition for each operation on the Web service and port.

Once created, the services are displayed in the GPM and can be used in business processes. If the Other option is used for HTTP or HTTPS transport, configuration of additional services (SOAInboundMessageProcessing, SOAOutboundMessageProcessing, and optionally SOAInboundSecurity and SOAOutboundSecurity) is required.

Note: Only SOAP bindings are considered for Dynamic services. Other types of bindings are ignored and Dynamic services are not created for them.

Once the Dynamic Service creation process is done, you can begin using the services in your business processes. The dynamically created services can only be used as part of a business process.

What Happens During a Business Process

When a business process is invoked, the Dynamic service loads the WSDL (which has been stored in a cache by the check in process), creates a SOAP request for the specified operation, and posts it to the endpoint specified in the WSDL. The Dynamic service then waits for the response from the service endpoint. Once the endpoint returns a response, the Dynamic service loads the response as the primary document, and into the work flow context, so that next service in the business process can take appropriate action on the returned response.

Example

Your corporation has a Web service that performs currency conversions. You create a business process that receives values in U.S. dollars, but that needs to have the amounts converted to Euros for a later step in the process.

You define WSDL for the Web service, specifying the information necessary to dynamically create a service, and check in the WSDL.

The application validates the WSDL and creates the new service and a stencil and category for it in the GPM. It adds the service definition to the list of services available in the application for creation, editing, and copying. It creates as many configurations of the service as needed for the functions you specify in the WSDL. So, if you specified “Convert” as the Web service to go to in the WSDL and “US_to_Euro” and “Euro_to_Yen” as the actions needed, a service category called Convert would be created on the Dynamic Services stencil. Within that new category, one service definition and one service configuration would be created for each action – US_to_Euro and Euro_to_Yen.

You include the US_to_Euro service in your business process. The US_to_Euro service sends a SOAP message containing the value (the U.S. dollar amount, say $50) to the Convert Web service. The Web service does the conversion to Euros, and sends back the converted amount to the US_to_Euro service, which passes the new Euro amount to the primary document. The next step in the business process uses the Euro amount for its operation.

You must have Web services for your application to use this functionality. You create a WSDL file that provides information about the service (or services), and the application creates the services and makes them available in the GPM for you to configure.

Implementing a Dynamic Service

To implement a Dynamic service, complete the following tasks:

Obtain the WSDL for the Web service you want to access during a business process.
Verify that the WSDL contains the necessary content to describe the Dynamic service to the application. If it does not, you must edit the WSDL to include the required information. See About WSDL.
Check in the WSDL.
In the GPM, create your business process and select the desired service from the newly created stencil, then select a configuration of the service.
Specify the parameter settings for the service configuration.
Check in, test, and use the business process.

Configuring a Dynamic Service

You must specify field settings in the application, using the GPM.

Setting Up the Service in the GPM

When the WSDL is checked in using the Default Transport as the transport binding, the four security-related parameters (Certificate, InsertSecurityHeader, SecurityToken, and X509CertificateOption) are displayed in the GPM Stencil for the particular Dynamic Service that is created. For Other Transport (HTTP/HTTPS) the four security-related parameters are not created. They are only required for the transport implementation.

Additionally, a Dynamic service can have parameters based on the partType element in the WSDL. If the partType element is from the XML Schema namespace (simple type), then these parameters will also be displayed in GPM. This normally happens for the RPC/Literal style WSDL. However, if the partType of these parameters refers to another namespace, then these parameters are not displayed in the GPM service editor. This normally happens for the Document/Literal style WSDL.

Field	Description
Config	Select the name of the service configuration from the list.
Certificate	Enter the name of the digital certificate to use for signing the SOAP request. This certificate must have already been imported to the Web service endpoint system. (Displayed only for Default Transport.)
InsertSecurityHeader	Whether to insert the security header. Valid values are true and false. (Displayed only for Default Transport.)
SecurityToken	Name of the security token. This token must have already been imported to the Web service endpoint system. (Displayed only for Default Transport.)
X509CertificateOption	Used when inserting a digital certificate into the SOAP request. (Displayed only for Default Transport.)Valid values are: Binary Token IssuerSerial (default) X509KeyIdentifier

Business Process Example – RPC/Literal

The following example illustrates how a Dynamic service could be used in a business process:

You need to access a Web service that does simple mathematical calculations during a business process step. The Web service is called Calculator.

The WSDL for Calculator is shown in the following example.

Check in the WSDL to the application.
Create a business process and include one or more configurations of the new service in it.
Check in the business process.
Test the Dynamic service by running the business process. If there is a problem accessing the Web service, error messages are displayed in the BP Monitor.

The following example shows a WSDL file with the name Calculator.

The following example shows creating a Dynamic service creation against a WSDL with one port type and with two operations:

<?xml version="1.0" encoding="UTF-8"?> 
<wsdl:definitions name="CalculatorWSDL" targetNamespace="http://00.00.00.00:1234/axis/Calculator.jws"
xmlns:intf="http://00.00.00.00:1234/axis/Calculator.jws"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
 <wsdl:message name="subtractResponse"> 
 		<wsdl:part name="subtractReturn" type="xsd:int"/> 
 	</wsdl:message> 
 	<wsdl:message name="addResponse"> 
 		<wsdl:part name="addReturn" type="xsd:int"/> 
 	</wsdl:message> 
 	<wsdl:message name="addRequest"> 
 		<wsdl:part name="i1" type="xsd:int"/> 
 		<wsdl:part name="i2" type="xsd:int"/> 
 	</wsdl:message> 
 	<wsdl:message name="subtractRequest"> 
 		<wsdl:part name="i1" type="xsd:int"/> 
 		<wsdl:part name="i2" type="xsd:int"/> 
 	</wsdl:message> 
  <wsdl:portType name="Calculator"> 
    <wsdl:operation name="add" parameterOrder="i1 i2"> 
      <wsdl:input message="intf:addRequest" name="addRequest"/>	
	<wsdl:output message="intf:addResponse" name="addResponse"/> 
   </wsdl:operation> 
   <wsdl:operation name="subtract" parameterOrder="i1 i2"> 
     <wsdl:input message="intf:subtractRequest" name="subtractRequest"/> 
     <wsdl:output message="intf:subtractResponse" name="subtractResponse"/> 
   </wsdl:operation> 
 </wsdl:portType> 
 <wsdl:binding name="CalculatorSoapBinding" type="intf:Calculator"> 
     <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> 
 		<wsdl:operation name="add"> 
 			<soap:operation soapAction=""/> 
 			<wsdl:input name="addRequest"> 
 				<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
           namespace="http://DefaultNamespace" use="encoded"/> 
 			</wsdl:input> 
 			<wsdl:output name="addResponse"> 
 				<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
           namespace="http://00.00.00.00:1234/axis/Calculator.jws" use="encoded"/> 
 			</wsdl:output> 
 		</wsdl:operation> 
		<wsdl:operation name="subtract"> 
 			<soap:operation soapAction="foo"/> 
 			<wsdl:input name="subtractRequest"> 
 				<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
           namespace="http://DefaultNamespace" use="encoded"/> 
 			</wsdl:input> 
 			<wsdl:output name="subtractResponse"> 
 				<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
          namespace="http://00.00.00.00:1234/axis/Calculator.jws" use="encoded"/> 
 			</wsdl:output> 
 		</wsdl:operation> 
 	</wsdl:binding> 
 <wsdl:service name="CalculatorService"> 
     <wsdl:port binding="CalculatorSoapBinding" name="IQuizService"> 
     <soap:address location="http://00.00.00.00:1234/axis/Calculator.jws"/> 
     </wsdl:port> 
 </wsdl:service> 
 </wsdl:definitions>

When the file is checked in, the application attempts to validate this WSDL file. On successful validation, it creates services in the GPM stencil:

Dynamic Services > CALCULATOR (name of the WSDL file)
Dynamic Services > CALCULATOR > IQUIZSERVICE (Port Name)

For each operation listed under a particular port, a service definition file is created in the application. For example, for the two operations (add and subtract) in the WSDL shown in the previous example, the following two service definition files are created:

CALCULATOR_add
CALCULATOR_subtract

A new stencil opens that displays all the operations this port type will have as a service for the application.

The add and subtract operations are displayed as services for the IQUIZSERVICE stencil in the GPM, as shown in the following example:

Using a Dynamic Service in a Business Process

Once a Dynamic service is created, you can include it in a business process, as shown in the following example. Note that the add service icon is selected. In the service editor, the default service instance (DS_CALCULATOR_PORT1_OPE2_Instance) has been selected, and its parameters are displayed in the editor in the lower half of the screen. Values have been assigned for the i1 and i2 part name parameters

The Certificate, InsertSecurityHeader, SecurityToken and X509CertificateOption parameters appear in every Dynamic service configuration, but are only used when signing the SOAP request. The remaining two parameters, i1 and i2, are specific to this service. These are the part names of the input message of the add operation of the Calculator WSDL. Values have been entered for them. (Normally, these values would be passed to the service by an earlier step in the business process.)

Note: The parameters for a Dynamic service are displayed in the GPM only when the partType is from the XML schema namespace (simple type). If the partType refers to another namespace, the parameters do not display in the GPM and it must be passed in to the service as a document.

Validate, save, and check in the business process to the application. When the business process runs, the add service is invoked, reads the WSDL (which has been stored in a cache by the check in process), generates a SOAP message, sends it to the Web service, and waits for a response. The Web service returns the response, it becomes the primary document (and therefore available to subsequent steps in the business process), and the business process continues.

Request by Dynamic Service to Web Service

The following example shows a request:

<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
       
           xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  
           xmlns:tns0="http://DefaultNamespace"   
           xmlns:xs="http://www.w3.org/2001/XMLSchema"  
           xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
   <soapenv:Body   
              soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/
encoding/"> 
        <tns0:add> 
             <i1 xsi:type="xs:int">20</i1> 
             <i2 xsi:type="xs:int">30</i2> 
        </tns0:add> 
   </soapenv:Body> 
 </soapenv:Envelope>

Response from the Web Service

The following is the response received by the add service from the Web service:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  
                   xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
     <soapenv:Body> 
         <ns1:addResponse              
              soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/
encoding/"  
              xmlns:ns1="http://DefaultNamespace"> 
            <addReturn xsi:type="xsd:int">50</addReturn> 
         </ns1:addResponse> 
     </soapenv:Body> 
 </soapenv:Envelope>

Errors Generated

If any input was invalid, or if there is an internal processing error at the Web service endpoint, a SOAP_FAULT will be returned. The following is an example of a SOAP fault response for invalid input obtained from the Web service endpoint:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  
                   xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
       <soapenv:Body> 
      <soapenv:Fault> 
            <faultcode>soapenv:Server.userException</faultcode> 
            <faultstring>java.lang.NumberFormatException: z20</faultstring> 
            <detail> 
            <ns1:hostname   
                 xmlns:ns1="http://xml.apache.org/axis/">ADT</ns1:hostname> 
            </detail> 
            </soapenv:Fault> 
        </soapenv:Body> 
 </soapenv:Envelope>

If the endpoint specified in the WSDL is not running, then after the waiting time specified in the HTTP Client adapter, the business process at the client end will return the error NO RESPONSE FROM ENDPOINT.

Dynamic Service for Document/Literal style WSDL

The following is an example of a Document/Literal style WSDL with one portType and one operation:

<?xml version="1.0" encoding="UTF-8"?> 
 <wsdl:definitions name="BeadInquiryWS" 
     targetNamespace="http://www.sterlingcommerce.com/mesa" 
     xmlns:mesa="http://www.sterlingcommerce.com/mesa" 
     xmlns:mesa_xsd="http://www.sterlingcommerce.com/mesa/schema" 
     xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
     xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
     xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
     <wsdl:types> 
         <xs:schema attributeFormDefault="unqualified" 
             elementFormDefault="qualified" 
             targetNamespace="http://www.sterlingcommerce.com/mesa/schema" 
             xmlns="http://www.sterlingcommerce.com/mesa/schema" 
             xmlns:tns="http://www.sterlingcommerce.com/mesa/schema" 
             xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
        <xs:complexType name="Binary"> 
                 <xs:simpleContent> 
                     <xs:extension base="xs:base64Binary"> 
                         <xs:attribute name="href" type="xs:anyURI"/> 
                     </xs:extension> 
                 </xs:simpleContent> 
        </xs:complexType> 
             <xs:element name="attachment" type="tns:Binary"/> 
             <xs:element name="inlineAttachment" type="xs:base64Binary"/> 
        <xs:complexType name="ProcessData"> 
                 <xs:sequence> 
                     <xs:any/> 
                 </xs:sequence> 
        </xs:complexType> 
        <xs:element name="mesaFault" type="tns:MESAFault"/> 
        <xs:complexType name="MESAFault"> 
        <xs:sequence> 
                     <xs:element name="code"/> 
                     <xs:element name="message"/> 
                     <xs:element name="statusReport"/> 
         </xs:sequence> 
         </xs:complexType> 
         <xs:element name="processData" type="tns:ProcessData"/> 
           <xs:element name="documents"> 
               <xs:complexType> 
                 <xs:sequence> 
                      <xs:element maxOccurs="unbounded" 
                                  ref="tns:attachment"/> 
                 </xs:sequence> 
               </xs:complexType> 
           </xs:element> 
         <xs:simpleType name="HashType"> 
<xs:restriction base="xs:string"> 
                <xs:enumeration value="MD5"/> 
                     <xs:enumeration value="NONE"/> 
                 </xs:restriction> 
             </xs:simpleType> 
             <xs:complexType name="MESAAuth"> 
                 <xs:sequence> 
                     <xs:element name="principal"/> 
                     <xs:element name="auth"> 
                         <xs:complexType> 
                             <xs:simpleContent> 
                                 <xs:extension base="xs:string"> 
                            <xs:attribute name="hashType" 
                                          type="tns:HashType"/> 
                                 </xs:extension> 
                             </xs:simpleContent> 
                         </xs:complexType> 
                     </xs:element> 
                 </xs:sequence> 
             </xs:complexType> 
             <xs:element name="mesaAuth" type="tns:MESAAuth"/> 
         <xs:element name="Bead_Inquiry" type="tns:ProcessData" 
             xmlns:xs="http://www.w3.org/2001/XMLSchema"/> 
         </xs:schema> 
     </wsdl:types> 
     <wsdl:message name="MESAResponse"> 
         <wsdl:documentation xmlns:wsi="http://ws-i.org/schemas/
conformanceClaim/"> 
             <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.1"/> 
         </wsdl:documentation> 
         <wsdl:part element="mesa_xsd:processData" name="parameters"/> 
         <wsdl:part element="mesa_xsd:attachment" name="attachment"/> 
     </wsdl:message> 
     <wsdl:message name="Bead_Inquiry"> 
         <wsdl:documentation xmlns:wsi="http://ws-i.org/schemas/
conformanceClaim/"> 
             <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.1"/> 
         </wsdl:documentation> 
         <wsdl:part element="mesa_xsd:mesaAuth" name="header"/> 
         <wsdl:part element="mesa_xsd:Bead_Inquiry" name="parameters"/> 
     </wsdl:message> 
     <wsdl:message name="MESAFault"> 
         <wsdl:documentation xmlns:wsi="http://ws-i.org/schemas/
conformanceClaim/"> 
             <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.1"/> 
         </wsdl:documentation> 
         <wsdl:part element="mesa_xsd:mesaFault" name="parameters"/> 
     </wsdl:message> 
<wsdl:message name="GISGeneric"> 
         <wsdl:documentation xmlns:wsi="http://ws-i.org/schemas/
conformanceClaim/"> 
             <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.1"/> 
         </wsdl:documentation> 
         <wsdl:part element="mesa_xsd:mesaAuth" name="header"/> 
         <wsdl:part element="mesa_xsd:processData" name="parameters"/> 
     </wsdl:message> 
   <wsdl:portType name="GISPortType"> 
         <wsdl:documentation xmlns:wsi="http://ws-i.org/schemas/
conformanceClaim/"> 
             <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.1"/> 
         </wsdl:documentation> 
         <wsdl:operation name="executeBead_Inquiry"> 
             <wsdl:documentation xmlns:wsi="http://ws-i.org/schemas/
conformanceClaim/"> 
                 <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/
1.1"/> 
             </wsdl:documentation> 
             <wsdl:input message="mesa:Bead_Inquiry"/> 
             <wsdl:output message="mesa:MESAResponse"/> 
         </wsdl:operation> 
     </wsdl:portType> 
     <wsdl:binding name="GISBinding" type="mesa:GISPortType"> 
         <wsdl:documentation xmlns:wsi="http://ws-i.org/schemas/
conformanceClaim/"> 
             <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.1"/> 
         </wsdl:documentation> 
         <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> 
         <wsdl:operation name="executeBead_Inquiry"> 
             <soap:operation soapAction="sii:Bead_Inquiry"/> 
             <wsdl:input> 
                 <soap:body parts="parameters header" use="literal"/> 
             </wsdl:input> 
             <wsdl:output> 
                 <mime:multipartRelated> 
                     <mime:part> 
                       <soap:body parts="parameters" use="literal"/> 
                     </mime:part> 
                     <mime:part> 
                       <mime:content part="attachment" 
                              type="application/octetstream"/> 
                     </mime:part> 
                 </mime:multipartRelated> 
             </wsdl:output> 
         </wsdl:operation> 
     </wsdl:binding> 
     <wsdl:service name="BeadInquiryWS"> 
         <wsdl:port binding="mesa:GISBinding" name="GISPort"> 
           <soap:address location="http://10.11.20.98:5040/soap?service=BeadInquiryWS"/> 
</wsdl:port> 
     </wsdl:service> 
 </wsdl:definitions>

Once the file is checked in and validated, the services are created in the GPM stencil. This WSDL file, beadInquiry, would have the following entries in the GPM :

Dynamic Services > BEADINQUIRY (name of the WSDL file)
Dynamic Services > BEADINQUIRY > GISPORT (Port Name)

The application creates a new service definition called BEADINQUIRY_executeBead_Inquiry and a default service instance called DS_BEADINQUIRY_PORT1_OPE1_Instance .

The main difference between execution of an RPC/Literal-based Dynamic service and a Document/Literal-based Dynamic service is that the Document/Literal requires many documents to be present in the workflow context of the executed business process. For example, to execute the executeBead_Inquiry service, the workflow context of the executed business process should contain the following two documents, one each for the mesaAuth and Bead_Inquiry element:

MesaAuth.txt:

<mesa:mesaAuth xmlns:mesa="http://www.sterlingcommerce.com/mesa">
<principal>admin</principal> 
<auth hashType="NONE">password</auth> 
</mesa:mesaAuth>

BeadInquiry.txt :

<mesa:Bead_Inquiry xmlns:mesa="http://www.sterlingcommerce.com/mesa"/>

Both elements are part of the input message of the executeBead_Inquiry operation of the checked-in WSDL file – the number and type of these required documents depends on the input message of the operation.

Before execution of any document/literal based Dynamic service, all documents mentioned in the input message of the operation should be present in the workflow context.

How these documents will be available in the workflow context depends on how you write the business process. You can write some business specific services or adapters, or can use some system level services or adapters to put these prerequisite documents into the workflow context. For example, to execute the executeBead_Inquiry service, this example uses the File System adapter to populate the two documents in the workflow context .

The first File System adapter collects the BeadInquiry.txt file from the file system and the second collects the mesaAuth.txt file from the file system. Once these two documents are in the workflow context, you can extract the two documents from the primary document and assign them to Bead_Inquiry and mesaAuth elements using the two Assign services, as shown in the following example.

The following BPML example shows how the business process might look:

<process name="default"> 
   <sequence> 
     <operation name="File System Adapter"> 
       <participant name="AS2Extract"/> 
       <output message="FileSystemInputMessage"> 
         <assign to="attachFile">/server1/share/joeuser/20060307/BeadInquiry.txt
            </assign> 
         <assign to="." from="*"></assign> 
       </output> 
       <input message="inmsg"> 
         <assign to="." from="*"></assign> 
       </input> 
     </operation> 
     <assign to="Bead_Inquiry" from="//PrimaryDocument/@SCIObjectID"></assign> 
     <operation name="File System Adapter"> 
       <participant name="AS2Extract"/> 
       <output message="FileSystemInputMessage"> 
         <assign to="attachFile">/server1/joeuser/20060307/MesaAuth.txt</assign> 
         <assign to="." from="*"></assign> 
       </output> 
       <input message="inmsg"> 
         <assign to="." from="*"></assign> 
       </input> 
     </operation> 
     <assign to="mesaAuth" from="//PrimaryDocument/@SCIObjectID"></assign> 
<operation name="executeBead_Inquiry"> 
       <participant name="DS_BEADINQUIRY_PORT1_OPE1_Instance"/> 
       <output message="DS_BEADINQUIRY_PORT1_OPE1InputMessage"> 
         <assign to="." from="*"></assign> 
       </output> 
       <input message="inmsg"> 
         <assign to="." from="*"></assign> 
       </input> 
     </operation> 
   </sequence> 
 </process>

Because we are not generating a signed SOAP request, leave the four parameters blank.

Validate, save, check in, and execute the business process. When executed, the following happens:

The executeBead_Inquiry service reads the WSDL file, identifying the operation and the input message that need to be executed.
For each part of the input message, the service tries to obtain the corresponding document from the workflow context. For this example, the executeBead_Inquiry service will try to obtain the documents named mesaAuth and Bead_Inquiry. If the service fails to obtain these two documents, the service throws an exception that it cannot find the specified document in the process data. If it succeeds, the service generates the SOAP message, sends it to the endpoint, and waits for the response.

Request Sent to Web Service

The following example shows the SOAP message generated by the executeBead_Inquiry service:

<soapenv:Envelope  
            xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
 <soapenv:Body> 
 <mesa:Bead_Inquiry     
                xmlns:mesa="http://www.sterlingcommerce.com/mesa"> 
 </mesa:Bead_Inquiry> 
 <mesa:mesaAuth xmlns:mesa="http://www.sterlingcommerce.com/mesa"> 
     <principal>admin</principal> 
     <auth hashType="NONE">password</auth> 
 </mesa:mesaAuth> 
 </soapenv:Body> 
 </soapenv:Envelope>

Response from Web Service

The following example shows the response the executeBead_Inquiry service received from the Web service endpoint :

<soapenv:Envelope
       xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"    
       xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
       xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/"> 
 <soapenv:Body> 
 <mesa:processData  
             xmlns:mesa="http://www.sterlingcommerce.com/mesa"> 
 <ProcessData> 
     <service>BeadInquiryWS</service> 
     <b2b-protocol>http</b2b-protocol> 
     <transport-instance-id>MESAHttpServerAdapter_HttpServerAdapter_node1 
 </transport-instance-id> 
     <http-request-uri>/soap</http-request-uri> 
     <transport-session-id>Mon Mar 13 11:33:49 IST 2006:26</transport-session-id> 
     <messageMode>1</messageMode> 
     <wsConfig name="BeadInquiryWS"> 
         <certID></certID> 
         <verificationCertID></verificationCertID> 
     </wsConfig> 
     <SOARequiredSignature>false</SOARequiredSignature> 
     <EXPECT_SECURITY_HEADER>false</EXPECT_SECURITY_HEADER> 
     <SOAP_URI>/soap</SOAP_URI> 
     <SOAPEnvNSPrefix>soapenv</SOAPEnvNSPrefix> 
  <SOAPEnvNSURI> 
http://schemas.xmlsoap.org/soap/envelope/ 
 </SOAPEnvNSURI> 
 <mesa xmlns="uri:sci"> 
  <Bead_Inquiry  
         xmlns="http://www.sterlingcommerce.com/mesa"></Bead_Inquiry> 
  </mesa> 
     <serviceMode>0</serviceMode> 
     <typeName>Bead_Inquiry</typeName> 
     <PrimaryDocument SCIObjectID="blrgislin01:3399d4b3:109f23357e5:-4260"> 
     </PrimaryDocument> 
     <ADD_SOAP_ENVELOPING>false</ADD_SOAP_ENVELOPING> 
     <SOAPOutboundAttachments> 
         <SOAPAttachment1  
               Content-ID="cid:attachment= 
                   1015796913_1142248458099@sterlingcommerce.com"  
                SCIObjectID="blrgislin01:3399d4b3:109f23357e5:-4245"> 
        </SOAPAttachment1> 
     </SOAPOutboundAttachments> 
     <attachmentCID> 
           cid:attachment=1015796913_1142248458099@sterlingcommerce.com 
      </attachmentCID> 
     <INSERT_SECURITY_HEADER>false</INSERT_SECURITY_HEADER> 
 </ProcessData> 
 </mesa:processData> 
 <mesa:attachment  
        xmlns:mesa="http://www.sterlingcommerce.com/mesa"  
href="cid:attachment=1015796913_1142248458099@sterlingcommerce.com"> 
 </mesa:attachment> 
 </soapenv:Body> 
 </soapenv:Envelope> 
 --_=29258051243737204Sterling29258051243737204MOKO 
 content-type: application/octet-stream 
 content-id: <attachment=1015796913_1142248458099@sterlingcommerce.com> 
 <?xml version='1.0' encoding='UTF-8'?> 
   <result><row><OBJECT_ID>B2B_WF_OBJECT_ID_2</OBJECT_ID> 
   <OBJECT_VERSION>1.0</OBJECT_VERSION> 
   <OBJECT_NAME>HTTP_SEND_ENVELOPE_OFF</OBJECT_NAME> 
   <TRANSPORT_DESC>HTTP</TRANSPORT_DESC> 
   <ENVELOPE_DESC>NO- ENVELOPE 
 </ENVELOPE_DESC> 
 <MESSAGE_MODE>send</MESSAGE_MODE> 
 <WORKFLOW_VERSION>1.0</WORKFLOW_VERSION> 
 <OBJECT_CLASS>B2B_WORKFLOW</OBJECT_CLASS> 
 <LAST_MODIFICATION></LAST_MODIFICATION> 
 <LAST_MODIFIER></LAST_MODIFIER><OBJECT_STATE></OBJECT_STATE></row> 
 --_=29258051243737204Sterling29258051243737204MOKO--

About WSDL

For creation of a Dynamic service to succeed, the following elements need to be included in the WSDL:

Note: See WSDL Validation for more information about specific rules used the validation process.

Element	Description
Service	At least one service with a name associated with it.
Ports	For each service, there should be one or more ports, each with a unique name.
SOAP port	At least one port must have a SOAP address location specified for it.
Endpoint	Each SOAP address must include a location attribute that specifies the endpoint where the Web service runs. The location must be a proper URI and the protocol must be HTTP or HTTPS.
Binding	Each port must refer to a binding element, using the binding attribute. For Dynamic services, only SOAP binding over HTTP or HTTPS is supported. If the WSDL contains both SOAP and non-SOAP bindings, Dynamic services are created for only the SOAP addresses – non-SOAP bindings are ignored. The binding element describes how the service is bound to a messaging protocol, particularly the SOAP messaging protocol. You can use either Remote Procedure Call (RPC) or Document style bindings. If the attribute is not present, then the system assumes the style is Document. The SOAP binding can also have an encoded use or a literal use.
Operations	The number of operations in the binding section and the port type section must be the same. The names must be the same.
Input/Output Messages in Operations	Each operation must have input and output operations associated with it. Dynamic Service Creation supports only Request-Response transmission and does not support solicit-response or one-way transmission types.
Parts	Each message can include zero or more parts. Each part must have a unique name.
Part Element	If the WSDL uses Document/Literal style binding, each part must have a part element that refers to a root element of the schema defined in the WSDL.
Duplicate Operations	WSDL files that use RPC binding can have two duplicate operations, but not more than that. WSDL that uses Document/Literal binding can never have any duplicate operations.

Checking In a New WSDL

If you check in a new version of a WSDL file, the following occurs:

Old Dynamic services based on the old WSDL are deleted.
New Dynamic services are created based on the new WSDL file
Note: When a WSDL has multiple versions, the Dynamic service is created for the default version only.

Deleting Dynamic Services

To delete a Dynamic service, delete the WSDL. When you delete a checked-in WSDL file, the application deletes the following items, in this sequence:

All service configurations associated with the WSDL
All service definitions associated with the WSDL
The XML file created for the service definition
GPM stencil categories and items associated with the WSDL