Introduction

This article series is based on a real on demand transformation project, Oneida-2. This paper uses a specific Order to Manufacturing Processing System (OTMPS) scenario, which was presented in the first paper in this series (see Resources), to describe how to implement an executable on demand application.

In Part 4 of this series (see Resources), we described how to import into IBM® WebSphere® Studio Application Developer Integration Edition (Application Developer) artifacts that are exported from WebSphere Business Integration Modeler and Rational® XDE. Now we add some specific extensions to these artifacts, including the following:

• Fault handlers to capture system level exceptions
• Java snippets to execute data transformation/event generation
• Externalization of business rules using rule engines
• Generation of bindings to service endpoints.

Back to top

Application Developer workflow development process

We describe a method of developing, testing, and deploying an on demand business process application by following these steps:

1. Implement workflow activities as services.
2. Create wrappers for remote partners.
3. Add rule services to workflow.
4. Add fault handlers.
5. Enable event generation.
6. Generate deployment code.
7. Deploy for development testing.
8. Deploy for production.

Back to top

Step 1: Implement workflow activities as services

Processes invoke workflow activities to perform specific functions. For example, OrderProcessSystem invokes the Data Format Conversion activity for data format conversion (For details about the activities in OrderProcessSystem, please refer to Part 4 of this series). Each of the activities in this model has a corresponding portType which is included in the process Web Services Description Language (WSDL) interface file. The Business Process Execution Language (BPEL) process connects to these activities through the operations that the portTypes expose using the invoke activity and partner links. For example, the process WSDL interface OrderProcessSystemInterface.wsdl that WebSphere Business Integration Modeler exports contains the activity portTypes, as shown in Listing 1.

				
<?xml version="1.0" encoding="UTF-8"?> 
<definitions
    targetNamespace="http://Processes/OrderProcessSystem/interface"
	......................
    <portType name="OrderProcessSystemPT"> 
        <operation name="sendOrderProcessSystem_InputCriteria"> 
	.................................
        </operation> 
    </portType> 
    <portType name="DataFormatConversionPT"> 
        <operation name="sendDataFormatConversion_InputCriteria"> 
            <input message="tns:InputCriteriaMessage" name=
            "InputCriteriaMessage3"/> 
            <output message="tns:OutputCriteriaMessage3" name=
            "OutputCriteriaMessage3"/> 
        </operation> 
    </portType> 
    <portType name="DataFormatConversion2PT"> 
                   ………………….
    </portType> 
    <portType name="ManufacturingLoopApplyManufacturingPlantSelectionPolicyPT "> 
                   ………………….
    </portType>
    <portType name="ManufacturingLoopDecrementOrderCountPT"> 
                   ………………….
    </portType>
                    ..............
</definitions>

			

These portTypes need to be implemented as services. First, use Application Developer tooling to generate the service, the binding, and the Java service skeleton class based on the portType in the process definition file OrderProcessSystem.wsdl. Then you need to supply a concrete implementation of the service in the generated Java service skeleton class.

To generate the Java service skeletons, complete the following steps:

1. In Application Developer's Services navigator, select the service interface WSDL file (OrderProcessSystemInterface.wsdl), as shown in Figure 1.
2. Create a new Build from Service with the choices Java Service Skeleton and Creating new port and binding.
   Figure 1. Create a Build from Service
   
   
3. Pick the right Port type name from the drop-down list, as shown in Figure 2.
   Figure 2. Create a service skeleton
   
   
4. Specify the name and location for the generated Java class, as shown in Figure 3.

Repeat the above 4 steps for all of the portTypes (activities) listed in the WSDL file. In this example, there are 5 activities (see also Listing 1):

• OrderProcessSubsystemPT
• DataFormatConversionPT
• DataFormatConversion2PT
• ManufacturingLoopApplyManufacturingPlantSelectionPolicyPT
• ManufacturingLoopDecrementOrderCountPT

In addition to the Java classes, binding and service WSDL files are also generated. The binding files are generated based on the selection made when creating a new Build from Service. In this case we selected the Java service option (the other available option is an Enterprise JavaBean (EJB) service) and hence the binding WSDL contains Java binding information related to the generated Java class. The service WSDL contains concrete endpoint information on how to invoke the service. For example, Listing 2 shows the service file for the Data Format Conversion service with the service endpoint using java:address element.

				
	<service name="DataFormatConversion2PTJavaService">
		<port binding="binding1:DataFormatConversion2PTJavaBinding" name=
"DataFormatConversion2PTJavaPort">
			<java:address className=
			"Processes.OrderProcessSystem.DataFormatConversion2PT"/>
		</port>
	</service>
			

Figure 4 shows the directory structure after the Java classes and binding and service WSDL files are generated.

Because only skeleton code is generated, you must next provide concrete implementation code for each class. Insert your code between user code begin and user code end to add the business logic for the specific activity, as shown in Listing 3.

				
Package Process.OrderProcessSystem;
/**
 * DataFormatConversion2PT
* Generated code. Only edit user code sections.
* @generated
*/
public class DataFormatConversion2PT {
	/**
	  * @generated
	  */
	public DataFormatConversion2PT() {
		// user code begin {constructor_content}
		// user code end
	}
	/**
 	  * sendDataFormatConversion2_InputCriteria
	  * @generated
	  */
	public Services.ManufactureIn sendDataFormatConversion2_InputCriteria(
		Services.ServiceOutput argInputPart4,
		Manufacturing.Orders argInput2Part2) {
		// user code begin {method_content}
		return null;
		// user code end
	}
}
			

Back to top

Step 2: Create wrappers for remote partners

Processes interact with remote partner services to perform certain operations. If the binding for the remote service is available, we bind the service at deployment time (details in Step 7: Generate deploy code). We would do this, for example, if the service is already deployed and its binding is available in a WSDL file.

However, if the remote partner service or its binding are unavailable, then you need to create a service wrapper for the remote partner. This wrapper provides the actual service implementation or acts as a proxy to the remote service. In order to connect to the legacy application using this wrapper, you need to add the specific transport and data transformation mechanisms. In our OTMPS example, we had to access a remote legacy partner that provided an order validation function. In this case, the validation function is accessed through WebSphere MQ protocol. We created a service wrapper which uses the WebSphere MQ protocol to connect to that legacy application.

We use partner services for accessing Validation and Manufacturing services. Each of these services has a corresponding WSDL file with a portType and an operation. They are integrated to the business process using the BPEL invoke activity using the partner links; for example, the ManufacturingPlant service interface WSDL file (ManufacturePlant1Interface.wsdl), as shown in Listing 4.

				
<?xml version="1.0" encoding="UTF-8"?>
<definitions
    targetNamespace="http://Services/ManufacturePlant1/interface"
    .............
    <portType name="ManufacturePlant1PT">
        <operation name="sendManufacturePlant1_InputCriteria">
            <input message="tns:InputCriteriaMessage" name="InputCriteriaMessage"/>
            <output message="tns:OutputCriteriaMessage" name="OutputCriteriaMessage"/>
        </operation>
    </portType>
    ............
</definitions>
			

In the OTMPS scenario, FTP and MQ are used to access the Validation and Manufacturing services respectively. In this case, you need to generate wrappers for each of the services. The steps to generate such external wrappers are similar to those described in Step 3 for the internal services. In the Java class implementation of these wrappers, you need to write the implementation to access the remote services, using the appropriate protocols.

Back to top

Step 3: Add rule services to workflow

There are several ways to add rules to a business process. One way is to add Java snippets in your process and write Java code in the snippets using the BRBeans API (see Resources) to access business rules that are implemented using the Business Rule Beans (BRBeans) framework in WebSphere Business Integration Server Foundation. Another way is to wrap-up business rules as services and use partner links in the process to access the services. All rules are wrapped in a service façade interface, with each rule exposed as a method. The second choice keeps the rules' implementation details from the process programmer. The programmers can invoke business rules as a service.

Back to top

Step 4: Add fault handlers

When a fault occurs within a process and regular execution is no longer possible, you use a fault handler to attempt to find another way to complete the process. In the Process editor, the process and each activity within it can have a fault handler associated with it. First, in this example, you need to add a fault handler on the selected BPEL activity to catch the exceptions it throws. You can either catch the specific faults as defined in the BPEL specification (for example, invalidReply, runtimeFailure, selectionFailure) or catch all of the faults. In this example (see also Figure 5), we added a fault handler on the Validate and Generate Topology activities to capture all of the faults generated in that activity.

Next you need to add the necessary activities in the fault handler such as the following:

• Create java snippets to handle errors.
• Use the Terminate activity to end the process immediately.
• Send the errors to another macro process for further handling.
• Include staff for problem resolution.

We created a long running process (ExceptionHandler process), which includes staff activity and send the faults to that process for further evaluation and resolution. In order to use an ExceptionHandler process to effectively handle an exception, you need to add a partner link to point to that process and then add an invoke activity in the fault handler, which links to the partner link, as shown in Figure 5.

Back to top

Step 5: Enable event generation

Events are required to collect on demand business process measurements that are later used to compute metrics and monitor Key Performance Indicators (KPI). The State Observer Plugin (SOP) that Application Developer provides automatically emits the appropriate events (as Common Base Events) corresponding to the processes, activities, variables, and so on, that are marked as BusinessRelevant in BPEL extensions. In order to create events you select the appropriate BPEL element (such as processes, activities, variables) and check the business relevant flag in the server tab. For example, if you have selected the OrderProcessSystem process and checked the business relevant flag, then SOP generates two process instance events -- one for process start and another for process stop.

Back to top

Step 6: Generate deployment code

In addition to the ordering of activities, the BPEL description of a process includes service port types, operations, and message types which are referenced through partner links. This process deployment step creates the bindings for actual services used through the partner links and the binding for the process itself.

This service run-time binding could be instantiated using any of the following mechanisms:

• Static binding generation at run-time (through the WSDL service binding information)
• Dynamic binding through endpoint referencing (for example, use WS-Addressing -- see Resources)
• Dynamic binding through UDDI referencing

Since we had all of the service binding information during deployment, we used static binding for the OTMPS example. In order to calculate the endpoint references at run-time, you must set the value of the resolutionScope flag in the server tab to computed. Then you should compute the endpoint reference at runtime and assign that with the partner link reference during run-time (The next paper in this series will include more details on this).

Process deployment includes assigning WSDL port and service to the port types of the partners in the process. The process connects to its partners using the binding created during run-time.

To generate deployment code for a process, right-click on the process BPEL file and choose Enterprise Services and Generate Deploy Code from the menu. As shown in Figure 6, you decide what kind of bindings you want for your process (EJB (the default), SOAP, or JMS). For testing purposes, the deploy code you choose doesn't matter since you use the Business Process Web Client to initiate the process.

Now you need to assign an endpoint for each referenced partner service. Highlight the partner, click Browse, and find the WSDL service file for the partner. Make sure to choose the correct port for the partner service, since there could be more than one port for a service in a WSDL service file. Figure 7 shows the partner binding selection screen.

At deployment time, the artifacts necessary for execution are created and packaged together into an enterprise application archive (EAR) file. With generated deployment code, the processes are accessible with different protocols and bindings, like Simple Object Access Protocol (SOAP), EJB components, or Java Message Service (JMS). When the process is deployed, a J2EE application project, including an EJB project and a Web project, are created.

Back to top

Step 7: Deploy for development testing

The run-time environment for workflow applications is WebSphere Business Iintegration Server Foundation. Installing a J2EE application with a process is no different than installing any other J2EE application on a WebSphere server. Figure 8 shows how the J2EE application is deployed with the BPEL process.

To test your process, complete the following steps:

1. Create a test server. In the server perspective, create a new WebSphere version 5.1 and Integration Test Environment type server and a new server configuration.
2. Install the J2EE application on the server. In the Add and Remove Projects window, add your project into the server. Now, expand your server and you will see the projects on the server, as shown in Figure 9.
   Figure 9. Installed applications on the server
   
   
3. Create tables and data sources. Right-click on the server and choose Create tables and data sources. This step is required if any one of the deployed processes is long-running.
4. Start the server. Launch the process Web client and test the process. Right-click on the test server and select Launch Business Process Web Client to bring up the Web client browser window (Figure 10).
5. In the Process Template Lists section, select My Templates. Check the box next to the template name and select Start the instance. Initialize the Process Input Message by filling in all of the fields. Click Start instance again. Figure 10 shows the Web client screen.

You do not have to use the Process Web Client to administer a process. There is a set of process engine APIs which you can use to control the process life cycle (for example, start, stop), and to handle work items for staff activity.

A workflow process is deployed as a service. During deployment code generation time (Step 7), you selected one or more inbound binding types for enabling clients to access the process. In order to access the workflow process, the clients need proxies and other helper artifacts conforming to the process binding type. For example, for a process deployed with IBM Web Services binding, you might use the process WSDL file to generate a JAX-RPC-type service proxy. Alternatively, you might use IIOP to access the process deployed with EJB bindings.

Back to top

Step 8: Deploy for production

After testing is completed, you can export the generated J2EE application project as an EAR file into a directory for production deployment. This EAR file includes all of the files needed for run-time execution. The installation of an EAR file with workflow processes is identical to the installation of any other J2EE application. But before a workflow process can be deployed in a production environment, it is important to correctly install and configure WebSphere Business Integration Server Foundation. For running a workflow process, the process container needs to be set up. For details on how to install and configure WebSphere Business Integration Server Foundation, please refer to WebSphere Application Server Information Center in the Resources section.

Back to top

Conclusion

The development of an executable workflow is a key step in the on demand business process life cycle method. The authors described how to implement workflow activities as services and how to generate a service wrapper for a remote partner, how to generate deployment code, and the different choices for bindings and deployment. Finally, they described process testing using the process Web client and how to access the process through a service proxy. Coming up in this series, the authors will discuss business process monitoring, customization, staff activities, performance, and compensation.

Acknowledgements

The authors would like to thank Martin Keen, Naveen Sachdeva, and Catherine Rivi for their contributions, suggestions, and assistance with this content.

Resources

• Read all parts of the On demand business process life cycle, and keep track as we add new installments.
  
  
• Learn more about Dynamic Service Binding with WebSphere Process Choreographer from this developerWorks paper (June 2004).
  
  
• Read the IBM Redbook BPEL4WS Business Processes with WebSphere Business Integration: Understanding, Modeling, Migrating (December 2004).
  
  
• Find out more about BPELJ in the whitepaper BPEL for Java technology (developerWorks, March 2004).
  
  
• Get the Business Process Execution Language for Web Services Version 1.1 Specification from developerWorks.
  
  
• Access the BRBeans API.
  
  
• Learn more by reading Business process choreographer in WebSphere: Combining the power of BPEL and J2EE.
  
  
• Find more resources at the WebSphere Application Server Information Center.
  
  
• Download the Web Services Addressing Specification from developerWorks.
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
  
  

About the authors

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Application Developer workflow development process
• Step 1: Implement workflow activities as services
• Step 2: Create wrappers for remote partners
• Step 3: Add rule services to workflow
• Step 4: Add fault handlers
• Step 5: Enable event generation
• Step 6: Generate deployment code
• Step 7: Deploy for development testing
• Step 8: Deploy for production
• Conclusion
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers