Exporting business objects

Business processes and human tasks have well-defined interfaces that allow them to be accessed externally as Web services. If these interfaces reference business objects, you need to export the interface definitions and business objects to your client programming environment.

Why and when to perform this task

This procedure must be repeated for each business object that your client application needs to interact with.

In WebSphere® Process Server, business objects define the format of request, response and fault messages that interact with business processes or human tasks. These messages can also contain definitions of complex data types.

For example, to create and start a human task, the following items of information must be passed to the task interface:

These items are encapsulated within a single business object. All operations of the Web service interface are modeled as a "document/literal wrapped" operation. Input and output parameters for these operations are encapsulated in wrapper documents. Other business objects define the corresponding response and fault message formats.

In order to create and start the business process or human task through a Web service, these wrapper objects must be made available to the client application on the client side.

This is achieved by exporting the business objects from the WebSphere environment as Web Service Definition Language (WSDL) and XML Schema Definition (XSD) files, importing the data type definitions into your client programming environment, then converting them to helper classes for use by the client application.

Steps for this task

  1. Launch the WebSphere Integration Developer (WID) Workspace if it is not already running.
  2. Select the Library module containing the business objects to be exported. A Library module is a compressed file that contains the necessary business objects.
  3. Export the Library module.
  4. Copy the exported files to your client application development environment.

Example

Example

Assume a business process exposes the following Web service operation:

<wsdl:operation name="updateCustomer">
    <wsdl:input message="tns:updateCustomerRequestMsg" 
                name="updateCustomerRequest"/>
    <wsdl:output message="tns:updateCustomerResponseMsg" 
                 name="updateCustomerResponse"/>
    <wsdl:fault message="tns:updateCustomerFaultMsg" 
                name="updateCustomerFault"/>
  </wsdl:operation>

with the WSDL messages defined as:

<wsdl:message name="updateCustomerRequestMsg">  
    <wsdl:part element="types:updateCustomer" 
               name="updateCustomerParameters"/> 
  </wsdl:message>
  <wsdl:message name="updateCustomerResponseMsg">
    <wsdl:part element="types:updateCustomerResponse" 
               name="updateCustomerResult"/> 
  </wsdl:message>
  <wsdl:message name="updateCustomerFaultMsg">
    <wsdl:part element="types:updateCustomerFault" 
               name="updateCustomerFault"/> 
  </wsdl:message>

The concrete customer-defined elements "types:updateCustomer", "types:updateCustomerResponse" and "types:updateCustomerFault" must be passed to and received from the Web services APIs using <xsd:any> parameters in all generic operations (call, sendMessage, and so on) performed by the client application. These customer-defined elements are created, serialized and deserialized on the client application side using helper classes that are generated using the exported XSD files.

Related tasks
Creating helper classes for BPEL processes (.NET)
Creating helper classes for BPEL processes (Java Web services)
Creating helper classes for BPEL processes (.NET)

(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)