What is a business process?

Within the context of WebSphere, a business process is a choreographed set of activities that, collectively, represent a real-world business operation. Internally, the individual activities are defined using the Web Services Description Language (WSDL), and the interactions between activities are defined using the Business Process Execution Language for Web Services (BPEL4WS). These standards, and the tools within WebSphere Studio Application Developer Integration Edition (hereafter called Application Developer Integration Edition) that exploit them, let you develop business processes at a very high level. You can also integrate services, whose implementation is hidden, to construct ever more complex services.

Application Developer Integration Edition provides a graphical editor for assembling business processes, and a unit test environment in which processes can be executed and debugged. These tools provide everything a developer needs to build business processes that can be deployed on the WebSphere Application Server Enterprise.

Back to top

Our scenario

In this article I construct a simple business process that shows some of the interactions and operations supported by the business process choreography. I'll also show how the resulting process can be deployed and debugged in the unit test environment.

There are many business scenarios where information that resides in one form inside the enterprise must be analyzed and processed in different ways before being published externally in another form. One such scenario is that of a supplier who makes product information available in a global repository so that buyers can acquire it. Typically, suppliers store their product data in their own systems. These Enterprise Information Systems have a prescribed format for the data (as well as their own access mechanisms for obtaining the data). Transformations and routing within the enterprise are often required to get this data into a format that is supported by the global repository before the data is published.

A messaging infrastructure is often used inside the enterprise for transporting information among systems because of the qualities of service it provides: reliability, security, and integrity. The business process described in this article provides some of the required function. For example, it could be invoked when data is extracted from the Enterprise Information System and used to distribute the data to different systems within the enterprise using reliable messaging. The information could then be handled by these different systems before being published to the global repository.

In this article, I show you how to design a business process that would fit such a scenario. A related article showed how to design a JCA-compliant resource adapter that, given an item number, returns the item's price from an Enterprise Information System (EIS). For this scenario, product part information that comes from a (hypothetical) manufacturing EIS needs to be aggregated with pricing information from this pricing EIS. To achive this, the business process will:

1. Receive a list of product part descriptions in an XML document. Each part description has a number of attributes, including itemNumber, supplier, name,category, and so on.
2. Determine the price of each part in the list by querying the pricing Enterprise Information System (EIS).
3. If the part's price is found in the pricing EIS, then place a message containing the part's information (including price) on the Java Messaging Service (JMS) queue jms/Q1.
4. If the part's price is not found in the pricing EIS, then place a message containing the part's information on the JMS queue jms/Q2.
5. Return a string that indicates the process completed successfully, including the number of parts that were processed.

The development of business processes easily lends itself to a top-down design approach. Using the WebSphere User Roles terminology, this approach means that the interfaces and bindings between solution components are provided to the application developer by a solution architect in the form of WSDL files. This example will generally follow this design approach. In contrast, bottom-up design means that application developers start by creating components that satisfy the business logic requirements, and defer the creation of interfaces and bindings until the components are integrated with each other. The bottom-up approach can be appropriate when an application's requirements are not yet fully defined, or when they change over time. The tooling in Application Developer Integration Edition that supports bottom-up development of business processes will be discessed in a future article in this series.

In accordance with top-down design, you begin by using the WSDL files to define both the interface to your business process and the binding that determines how the process is exposed to the world.

Road map

• Getting started lists the prerequisites and prepares the Application Developer Integration Edition workspace by importing the necessary WSDL files which were supplied by the solution architect.
• Creating the business process examines the process interface WSDL files and proceeds to create the process based on this interface. I take a look at the results produced by the process creation wizard, and discuss invoking-type activities and some of their important properties. This section also discusses helper classes and process variables, and shows how a Java snippet activity can be added to the process to move data between variables.
• Deploying and testing the process reviews the process binding and service WSDL files, which describe how the process is to be exposed to the outside world. You'll generate the wrapper (deployment code) based on this binding, create a unit test server, deploy your process to the server, and test the process using the business process Web client.

Back to top

Getting started

To implement and test the business process, you will need:

• WebSphere Studio Application Developer Integration Edition installed (Version 5.0 or later).
• WebSphere Embedded Messaging installed (Version 5.3).
• IBM Agent Controller installed (Version 5.0.1). This is used for process debugging.
• A basic understanding of the following concepts:
  • Java and J2EE technology
  • Web services
  • XML
  • Java Messaging Service (JMS)

Workspace setup

To begin, start Application Developer Integration Edition with a new workspace, or using the same workspace you used when creating the JCA adapter described in the related article. You will use that JCA adapter to complete the business process.

1. Using the Business Integration Perspective, create a new service project called testService.
2. In the testService project, create a new package called com.test.
3. Download the source code zip file for this article and import the following files into the com.test package in the testService project:
   • partInformation.xsd, which contains the XML schema for describing a list of product parts. This schema defines the format of the messages that will be received by the business process.
   • process.wsdl, which describes the process' input and output interfaces, and is described in detail in Creating the business process.
   • processEJBBinding.wsdl and processEJBService.wsdl, which describe how the process is exposed to the world as a session EJB, and are desribed in detail in Deploying and testing the process.

Back to top

Creating the business process

For this example, I'll use the top-down design approach, assuming that the process input and output interfaces have been created by a solution architect and provided to you in the form of a WSDL file (process.wsdl). I'll describe what the business process editor created, and why. Finally, I'll show how a Java snippet activity is used to move data between process variables.

The process interface WSDL file

The process interface WSDL file, process.wsdl, contains the following:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="process" targetNamespace="http://test.com/process"
	xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd1="http://www.pe.com"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:interface="http://schemas.xmlsoap.org/wsdl/wsadie/messages/"
	xmlns:tns="http://test.com/process">
	<import namespace="http://www.pe.com" location="partInformation.xsd"></import>
	<import namespace="http://schemas.xmlsoap.org/wsdl/wsadie/messages/"
	   location="/org/xmlsoap/schemas/wsdl/wsadie/messages/BuiltinMessages.wsdl">
	   </import>
	<message name="inputMsg">
	   <part name="partInformation" type="xsd1:PartListType"></part>
	</message>
	<message name="outputMsg">
	   <part name="result" type="xsd:string"></part>
	</message>
	<portType name="processPortType">
	   <operation name="doProcess">
	      <input name="doProcessRequest" message="tns:inputMsg"></input>
	      <output name="doProcessResponse" message="tns:outputMsg"></output>
	   </operation>
	</portType>
</definitions>
			

This WSDL file defines:

• The message inputMsg, which has one part: partInformation. The type of this message part is defined by the XML schema described in partInformation.xsd.
• The message outputMsg, which has one part: result (string).
• An operation called doProcess, which takes an inputMsg as input and returns an outputMsg as output.

Using the top-down design approach

Next, you'll use the business process creation wizard to create a process that implements this interface definition.

1. From the File menu, select New > Business Process.
2. Fill out the first panel of the New Business Process dialog as shown in Figure 1, then click Next.
   Figure 1. New Business Process dialog
   
   
3. Since you already have a WSDL file (process.wsdl) that describes the process interface, you can specify it on the second panel of the New Business Process dialog, as shown in Figure 2 below. I'll discuss this WSDL file in detail soon, but for now simply select Use existing WSDL file for business process interface, then click Browse... and select process.wsdl. There is only one operation to choose from, called doProcess. Click Finish when you're done.
   Figure 2. New Business Process dialog (Interface Specification)
   
   
4. The business process editor will be started on the new process, as shown in Figure 3.
   Figure 3. Initial process layout
   
   

Examining results

At this point, it's worthwhile to understand how the process' interface definition WSDL file maps to its input and output activities and variables. Let's examine what Application Developer Integration Edition has done for you so far.

Because you selected the doProcess operation as its interface definition, the process created for you is initialized so that it implements the doProcess operation. This is done by setting up the process' input and output activities appropriately.

Activities are the building blocks that make up a business process. The tooling supports several different types of activities, including:

• Input activities
• Output activities
• Java snippet activities
• Service activities
• Java activities
• Enterprise JavaBeans (EJB) activities
• Nested process activities
• Block activities
• Loop activities

and others. Activities have terminals that are connected to the terminals of other activities by control links. In this scenario, the initial process layout includes an input and an output activity that are connected by a control link.

Each type of activity has various properties, although the properties associated with a given activity will vary depending on the activity type. In particular, the properties of input, output, service, Java (not Java snippet), EJB, and nested process activities include an implementation and the variables associated with the activity's input and output terminals. These types of processes are also known as invoking activities, and they are usually employed to perform the real work done by a process. Process design is basically a matter of ensuring that the invoking activities are executed in the correct order and under the correct circumstances.

An invoking activity's implementation describes the interface between the activity itself and the object it invokes (such as Web service, EJB, nested process, and so on). For example, a service activity's implementation is described by a WSDL file and a service, port type, and operation.

Process variables are global variables which, when associated with the input or output terminal of an invoking activity, become the inputs and outputs of the invoked object (such as service, EJB, nested process, and so on). So, a process variable associated with a service activity's input terminal becomes the input message to the underlying Web service. Naturally, this requires that the variable types associated with input and output terminals of invoking activities match the variable types expected by the activity's implementation.

All business processes have an input and an output activity. Both of these have an implementation consisting of an associated operation and variable. To represent the interface defined in the process.wsdl, Application Developer Integration Edition did the following for you:

1. Created a process variable called input of type inputMsg.
2. Created a process variable called output of type outputMsg.
3. Created the com.test.process_msg Java package in the service project containing the helper classes for each of the above variable types.
4. Assigned the doProcess operation to the input activity's implementation.
5. Assigned the doProcess operation to the output activity's implementation.
6. Assigned the input variable to the input activity's implementation.
7. Assigned the output variable to the output activity's implementation.

Remember that process.wsdl specified that the doProcess operation has an input message of type inputMsg and an output message of type outputMsg. Notice how the input and output process variables were created with types that match those expected by the doProcess operation.

The input activity's implementation can be viewed by right-clicking on the input activity, selecting Properties, and clicking on Implementation in the properties dialog.

Manipulating process data using Java snippet activities

All process variables are effectively global, and can be read or updated by any process activity. Because the input and output data types expected by invoking activities will generally be different for each invoking activity in a process, a variable assigned to the output terminal of one invoking activity is unlikely to be usable as an input variable to another invoking activity. Therefore, it is usually necessary to move data between process variables of differing types. Java snippet activities are often used for this purpose. As an example, add a Java snippet activity that prepares the output message indicating the number of messages sent by the process. You're looking for the number in the countpart of the input variable.

When a new variable of a complex type is added to a process (either manually or automatically, as in the case of the process creation wizard), Application Developer creates a helper class for that variable type. Helper classes contain the getter and setter methods needed to manipulate these complex variables. So, in the case of your process, which already has two complex variables (input and output), the wizard created the helper classes com.test.process_msg.inputMsgMessage and com.test.process_msg.outputMsgMessage. The following steps show how the helper classes let you move the count value from the input variable to the output variable.

1. In the process editor's Process panel, select the (Java Snippet) icon from the left menu and click anywhere on the right-hand side. Or, right-click on the connector between the input and output activities and select Insert Activity > Java Snippet.
2. In the new Java snippet editor window, between the //user code begin and //user code end comments, right-click and select Update Variable > output. Two lines of code should have been added in the editor. On the empty line between the two new lines, add the following:

   int total = 0; if(getInput().getPartInformation().getPart() != null) total = getInput().getPartInformation().getPart().length; output.setResult("sent " + total + " messages");

   
   

   By examining the helper classes, you can see that getCount() is a method within com.test.process_msg.inputMsgMessage and setResult() is a method within com.test.process_msg.outputMsgMessage.

3. The resulting snippet should look like Figure 4.
   Figure 4. Java snippet setting output variable
   
   

Within the Java snippet editor window, the context menu (accessed by right-clicking in the editor itself) has three options: Update Variable, Get Variable, and Set Variable. These are very useful, because they ensure that the Java code associated with the process contains the necessary import statements. To see these import statements, click on any white space in the process activity editor window. You should see something similar to Figure 5 below. The import input.input_msg.OutputMsgMessage; statement was created for you because you used the Update Variable > output menu option.

Back to top

Deploying and testing the process

At this point, you have a process that returns an output message based on the number of parts specified in its input message. Next you'll test it using the unit test server.

Generating deployment code for the process

To deploy your process on a test server, you first need to generate the deployment code. To the outside world, business processes are often exposed as Web services. Generating deployment code for a process is a matter of choosing a Web service binding (which can be SOAP, EJB, or JMS) and letting the tooling create the underlying servlet, session bean, or receiver bean that will handle calls to the Web service and, in turn, invoke your process. Session EJBs used to wrap processes or other Web services are often called facade EJBs. Similarly, receiver EJBs that wrap processes or other Web services are often called facade MDBs.

In keeping with the top-down design, your process binding was previously determined and provided to you in the processEJBBinding.wsdl and processEJBService.wsdl files. As their names imply, these WSDL files describe an EJB binding for your process. You'll use these files to automatically generate the appropriate deployment code.

1. First save the process editor and ensure there are no outstanding tasks.
2. Right-click on the testProcess.process file in the Services window and select Enterprise Services > Generate Deploy Code....
3. The tooling supports three types of deployment wrappers for business processes: SOAP, EJB, and JMS. As shown in Figure 6, under Specify whether to generate a new or use an exiting port:, select Use an existing port. Even though our existing binding type is EJB, it does not matter that the binding type beside Inbound binding type is SOAP. Leave the EAR and EJB project names at their defaults and click Next.
   Figure 6. Generate process deploy code
   
   
4. Next to Service file name: click Browse... and select the processEJBService.wsdl located in the com.test package in the testService project. Then click Finish.
   Figure 7. Generate process deploy code (specifying service WSDL file)
   
   

Based on the binding information specified in the processEJBBinding.wsdl (referenced by processEJBService.wsdl), the testServiceEJB project is automatically generated and populated with the session EJB called processService. This EJB contains a doProcess() method that invokes your process using the Web Service Invocation Framework (WSIF).

The new testServiceEAR project contains the testServiceEJB, a JAR containing the testService project, and the process module (FAR file) containing the FDML that represents your process.

Creating the unit test server

Application Developer Integrated Edition contains a complete installation of WebSphere Application Server Enterprise, which is integrated into the development tooling to make it very easy to unit test applications. For example, applications can be deployed to the unit test server automatically, at the click of the mouse; no EAR file needs to be exported; and there are no WebSphere Admin Console application deployment panels to worry about. Administration of the unit test server is conveniently performed within the Application Developer Integrated Edition environment, and (perhaps most useful of all) every message that appears in the server's standard output log file (SystemOut.log) can be seen in the Console panel of the business integration perspective.

The built-in unit test server is particularly useful when developing business processes because the server is automatically configured with a fully-functional business process container, complete with the (Cloudscape) datasource and (Embedded MQ) JMS resources needed by the business process container applications. Anyone who has installed the business process container on a real WebSphere Application Server Enterprise will appreciate that this installation is done automatically on the built-in unit test server! The process container application components themselves appear as projects in the workspace when the unit test server is created. These projects are:

• BPEContainer
• bpecontainer_ejb
• BPERemoteDeploy
• bperemotedeploy_ejb
• bpesoapclient
• bpewebclient
• compensate_ejb

The projects make up the business process container application needed to support business processes, but can be otherwise ignored.

Now, create a test server:

1. On the File menu, click New > Other.
2. Click Server on the left side of the New dialog, and select Server and Server Configuration on the right side. Click Next.
3. As shown in Figure 8, for the Server name enter testServer. For the server type, select EE Test Environment. The rest of the options can be left to their defaults. Click Finish.
   Figure 8. New server and server configuration
   
   A new server project will be created for the unit test server, and the business process container application components will appear in your workspace, as described above.
4. Add the testServiceEAR, which contains your process and its deployment wrapper to the test server: Click on the Server Configuration view in the lower right corner, right-click on testServer, and select Add > testServiceEAR.
5. Now you need to instruct the test server to add data representing your process to the database used by the process choreographer to manage the process. Right-click on the server in the Server view, and select Deploy Process. This step must be done every time a change is made to a business process. On a real WebSphere Application Server Enterprise, this step is performed automatically when an EAR containing a business process is deployed. Since a process can be deployed on the unit test server and then subsequently altered, this step is necessary to reinitialize the process container's database.

Testing the process

Now it's time to start the server and test the process using the Universal test client.

1. Start the server by right-clicking on your server in the Servers view, and selecting Start. Once the console view contains the message indicating that the server is "open for ebusiness," go back to the Servers view, right-click on the server again and select Run Universal test client.
2. You will use the Universal test client to create an instance of the EJB that wraps your business process, and then to invoke its doProcess() method. On the Universal test client Homepage, click the JNDI Explorer link.
3. On the JNDI Explorer page, navigate to the com/test/processPortTypeServiceHome bean, and click on it to access the Bean page. The JNDI name com/test/processPortTypeServiceHome was specified in the processEJBService.wsdl file, and therefore that is the JNDI name that was associated with the process' EJB wrapper when you ran the Generate Deploy Code wizard.
4. On the Bean page, navigate to, and invoke the ProcessService.create() method, then click Work with Object.
5. In the References frame, you should now have a bean instance named ProcessService_1. Navigate to the doProcess(PartListType) method of this bean instance. Because the PartListType parameter is a complex type, you must use a constructor to create this input. In the right-hand frame, ensure that the two value pull-down menus specify Objects and Constructors, and click Invoke, then Work with Object.
6. In the References frame, under Object References, you should now see an instance of a PartListType object. Navigate to the void setPart(PartType[]) method.
7. In the right-hand frame, click the Expand button, then click Add to add a PartType element to the array. Then click the Expand button on the PartType element to see the various PartType fields.
8. Enter some arbitrary values for the product part, then click Add again to add another element to the list. Click this new element's Expand button and enter some values for the second product part. Create as many parts as you want, then click Invoke. An example is shown in figure 9.
   Figure 9. Constructing a complex object type
   
   
9. Now go back to the doProcess(PartListType) method of the ProcessService_1 bean. The Objects drop-down list will now contain a reference to the PartListType object we just constructed. Select that object, then click Invoke. The Result message should be something like Sent 2 messages, assuming you created a PartListType object containing 2 parts. If so, congratulations! Otherwise, check the Console view for exceptions, and retrace your steps to make sure you didn't leave anything out.
   Figure 10. Viewing the result message
   
   

Back to top

Coming soon...

Stay tuned! In the next installment of this series I'll extend the process with the addition of loop and service activities, as well as conditional control links. In the third installment, I add the necessary JMS resources to the unit test server and will deploy, test, and debug the finished process. In the fourth installment, I explore the options available to developers following a bottom-up design approach by demonstrating how a new (JMS) deployment code wrapper for the process can be generated and tested.

Acknowledgements

I would like to thank the following for their generous help in reviewing this article and for offering excellent suggestions that have improved it greatly: Mike Starkey, Mark Wainwright, Larry Yusuf, Luc Chamberland, Heidi Von Ludewig, Mike Leandertz, and Dwayne James.

Back to top

Download

Information about download methods

Resources

• Download the source code used in this article.
  
  
• "WebSphere Application Server Process Choreographer Series" contains several articles that discuss various aspects of business process development and runtime.
  
  

About the author

David Leigh is an Advisory Software Engineer in IBM Software Group's WebSphere Platform System House organization, located in Research Triangle Park, North Carolina. His areas of expertise include the process choreographer, application and server security, high-availability, monitoring, IBM AIX, and Linux.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• What is a business process?
• Our scenario
• Getting started
• Creating the business process
• Deploying and testing the process
• Coming soon...
• Download
• Resources
• About the author
• 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