Introduction

This article continues with the mediated exchange example and shows you how to develop a business process for the travel scenario using the WebSphere Process Choreographer (Process Choreographer) workflow tool. The Process Choreographer -- a component of the current release of WebSphere Studio Application Developer Integration Edition -- is based on the Business Process Execution Language (BPEL) specification, which is an industry-accepted standard for process orchestration.

Using WebSphere Studio Application Developer (Application Developer), we'll go through the required steps to create a business flow that will accept and dispatch user travel requests. In this article, you discover the basic elements of the Process Choreographer development cycle. The details and concepts you learn will help prepare you to evaluate and assess BPEL technology, and determine how you can use Process Choreographer in your enterprise systems.

Back to top

Revisit the business scenario

"Integrate business processes among service consumers, brokers, and providers" described our mediated travel scenario, which simulates a company that provides travel reservation services to business customers. The mediator has travel industry expertise that allows it to serve as a mediator between customers with travel needs and airlines that provide travel services. You learned how the mediator could set up a travel policy template and use WebSphere business rule beans (BRBeans) to customize the template for individual customers (for example, to set up price limits that require approval).

In this article, you'll create a business process, also called a business flow, that will accept a travel request and orchestrate calls to the necessary interfaces to determine whether the request should result in a booked flight or whether it should be rejected. As part of this example, you'll see how the rule-driven travel policy we implemented in "Develop business rules with WebSphere business rule beans, Part 2" is integrated into the business flow.

Because of length constraints, we'll keep the example simple and limit our BPEL integration to only use the previously developed getPreferredAirProviders and isApprovalRequired interfaces. The travel process will use getPreferredAirProviders to ensure that the carrier selected by the customer is in their preferred list. The isApprovalRequired method will be used to determine whether the incoming request requires a special approval step based on the travel cost. These integration examples will be enough to provide a realistic demonstration of how to develop a process flow to use external services.

Back to top

Know the product requirements

Resource requirements for the Process Choreographer development and continuation of the travel policy example are unchanged from the previous article. The development environment needs the following components:

Back to top

Get started

If you've been following the series, you've already created the travel policy interface and integrated it with BRBeans. Now we can concentrate on the development of our travel process flow. For the BPEL development aspects of the scenario, little preparatory work is required. Other than generating some Web Service Description Language (WSDL) files, the BPEL editor provides everything required to get started.

This article describes our development activities, using the following steps:

1. Create service project and empty BPEL process within it.
2. Create a WSDL file to define the input and output messages for our travel process.
3. Create a WSDL file for travel policy methods (getPreferredAirProviders and isApprovalRequired).
4. Create partner links to define interactions between clients and the BPEL process, and interactions between the BPEL process and external services.
5. Create invoke activities in the BPEL process to invoke the travel policy methods.
6. Add Java™ snippets to provide required processing logic.
7. Generate deploy code.
8. Test BPEL process using the WebSphere BPEL Web client.

System enhancements

Our planned system enhancements are to allow all trip requests using approved air carriers to be processed and booked with the designated air provider. Trip requests using a nonpreferred air carrier will be rejected as an interim solution. Requests that exceed cost limits and require cost approval will only force the generation of a warning message in the console log. Because this microsecond processing delay -- occurring from the generation of a log message -- probably would not discourage employees from booking first-class airfares, we'll remedy this vulnerability in the next article.

Back to top

Create a service project and BPEL process

First, you need to start Application Developer and specify the workspace directory where the TravelPolicy BRBeans interfaces were set up earlier. Once Application Developer is fully initialized, you should see the TravelPolicyEAR and TravelPolicyEJB projects in the Java 2 Platform, Enterprise Edition (J2EE) Project Navigator view. Follow these steps to create a service project and a BPEL process.

1. Open the Business Integration perspective, as shown in Figure 1.
   Figure 1. Existing travel policy projects
   
   
2. Select File > New > Service Project, and enter TravelSVC as the project name for the Service project. Click Finish.
3. Create a package to contain our business process. Highlight the TravelSVC project, right-click, and select New > Package. Enter com.friendlydestinations.bp.travel.
4. To create the business process, highlight the newly created package. Right-click and select New > Business Process, as shown in Figure 2.
   Figure 2. Business Process wizard
   
   
5. Enter TravelBP for the File name field in the Business Process dialog. Click Next.
6. Accept the Flow-based BPEL Process selection on the Choose Process Type message. Click Finish.

   The flow-based BPEL process lets you organize a set of activities that can be performed concurrently. As an alternative, you could opt to create a sequence-based BPEL process, which forces activities to be performed in a sequential order. We chose the flow-based process because it's the default type, it's intuitive, and it provides a lot of processing flexibility. You'll now see a basic business process displayed in the BPEL editor.

7. Immediately remove the default object under the Variables section (labeled InputVariable) and the default object under the Partner Links section (labeled PartnerLink).To remove these, highlight the object and click on the minus sign (-) above the object, as shown in Figure 3. These default objects are currently not associated with any service or message that we want to use, so we'll delete them and create our required objects later. Their deletion will result in some errors in the Task view during this interim period, but just ignore them.
   Figure 3. Deleting default Variable and Partner Link
   
   
8. Highlight the TravelSVC project, right-click and select Properties. In the Properties for TravelSVC dialog, highlight the Java Build Path property on the left and select the Projects tab in the center of the dialog. Click the TravelPolicyEJB checkbox, as shown in Figure 4. Click OK to save this change, which will allow classes in our travel policy project to be available for reference in our business process service project.
   Figure 4. Project Properties dialog
   
   

Back to top

Define input message for travel process

One of the first tasks of our BPEL development is to define the input and output messages for our process. We'll use the WSDL editor to define the message our client will send when invoking the business process and the response message it will receive.

1. Highlight the com.friendlydestinations.bp.travel package, right-click, and select New > Service Interface.
2. Type TravelRequest for the File name field in the Service Interface dialog. Click Finish.
3. The WSDL editor will open with the partial definition, containing a Port Type called TravelRequest, as shown in Figure 5.
   Figure 5. New service interface file
   
   
4. Right-click on the TravelRequest port type and select Add Child > operation. Type in processTravel in the New Operation dialog.

   Next you need to define the input and output messages for this operation. For this business process, you only need to define an input message. For now, you can develop this business flow as an asynchronous process that only accepts an input message from the client and provides no response back.

5. Right-click on processTravel operation and select Add Child > Input.
6. Right-click on the Input message and select Set Message. Click Finish in the Specify Message window to accept the defaults for the new input message you'll create. (See Figure 6 for an example.)
   Figure 6. Creating a new service message
   
   
7. Under the Messages category, highlight the processTravelRequest message, right-click, and select Add Child > part. Type AirCarrierName in the New Part dialog. Click OK.
8. Right-click on processTravelRequest and again select Add Child > part. Type AirPrice in the New Part dialog and click OK.
9. Repeat this message-part creation process for two new fields called FlightNo and TravelDate.
10. Right-click on AirPrice. Select Set Type. Choose the Select an existing type radio button in the Specify Type dialog. Scroll down the type list, highlight xsd:double, as shown in Figure 7, and click Finish.
    Figure 7. Type selection dialog
    
    
11. Do the same to change the TravelDate field to an xsd:date type.
12. At the end of this activity, our TravelRequest.wsdl file should resemble Figure 8. Save and close the WSDL file.
    Figure 8. Completed TravelRequest.wsdl File
    
    

Back to top

Create service call interface for TravelPolicy

Since you're creating WSDL files, you'll also create a WSDL file to describe the getPreferredAirProviders and isApprovalRequired methods. Because these are session EJB methods, the creation of a WSDL file with EJB bindings (rather than SOAP/HTTP) lets you define access to these methods as Web services using the RMI-IIOP protocol.

1. While still in the Business Integration perspective, expand the TravelPolicyEJB project and drill down to the com.friendlydestinations.policy package. Highlight the TravelPolicyEJBBean.java file.
2. Right-click and select New > Service built from.
3. In the Create Service dialog, highlight the EJB icon under the Choose the Service column and click Next.
4. Drill down on the TravelPolicyEAR and highlight the TravelPolicyEJB bean, as shown in Figure 9. Click the checkboxes for getPreferredAirProviders and isApprovalRequired methods under the EJB Methods section, as shown in Figure 9. Click Finish.
   Figure 9. Method selection for new EJB service
   
   
5. With the WSDL editor, close the TravelPolicyEJBBinding.wsdl file that should now be open in the workbench.
6. Highlight the three new WSDL files (TravelPolicyEJB.wsdl, TravelPolicyEJBBinding.wsdl, TravelPolicyEJBService.wsdl), right-click and select Copy. Click on the com.friendlydestinations.bp.travel directory back under the TravelSVC project. Right-click and select Paste to copy the WSDL files in the directory with our business process.

Back to top

Create partner links in the BPEL process

The next step is to create partner links in our BPEL process for all components with which we'll interact. Partner links, a fundamental aspect of the BPEL standard, are used to describe the services used in the business process and the port types associated with those services. Without partner links, our process is isolated and contributes little. As a result, each service provided by the business process and each service consumed by the business process must have a partner link defined for it to help identify the communication and interactions. The business process itself requires a partner link defining how the client will talk to the process. So first, you'll need to create this process partner link representing the communication between the travel customer and the business process.

1. Highlight the TravelRequest.wsdl file in the TravelSVC project and drag it onto the BPEL editor canvas for the TravelBP.bpel file.
2. In the Select Service dialog, accept the default TravelRequest service and click OK. You'll see a new partner link under the Partner Links section called TravelRequest.
3. Highlight the Receive object in the BPEL editor, right-click and select Set Partner Link. An arrow will immediately appear. Connect the arrow to the TravelRequest partner link in the upper-right corner of the BPEL editor, as shown in Figure 10. Click on TravelRequest to connect the Receive activity.
   Figure 10. Setting partner link for Receive Activity
   
   
4. Highlight the TravelRequest partner link. You'll see the TravelRequest port type displayed under the Partner's Role Name on the left. Since this TravelRequest partner link is actually associated with the acceptance of input for the business process, we want to switch the role for this link to indicate that it represents the process. Do this by simply clicking the < -- > symbol (as shown in Figure 11), to shift the port type to fall under the Process Role Name section. This now indicates the business process provides this service, also shown in Figure 11.
   Figure 11. Switching Partner Link role to Process Role
   
   
5. Highlight the Receive activity again, and click Implementation under the Properties section for the activity (just below the BPEL canvas). Notice that the Port Type is set to TravelRequest and no Operation or Request variable is defined. We will remedy this by first selecting processTravel from the Operation drop-down list. Click New, enter TravelRequestRqst as the name for the new variable in the New Request Variable dialog, and click OK. The Receive implementation should resemble Figure 12.
   Figure 12. Receive implementation properties
   
   
6. Click the new TravelRequestRqst variable that should now display in the BPEL editor. Verify that this variable has all of the correct message fields by selecting the Message tab. As shown in Figure 13, you should see the four fields we defined earlier in the TravelRequest.wsdl file.
   Figure 13. TravelRequestRqst message
   
   
7. As explained earlier, we won't be sending a reply to any client calling this business process, so we need to delete the Reply activity that was added by default when we created the BPEL process. Highlight the Reply activity, right-click, and select Delete. The Reply activity should be gone.

   Now we need to create a partner link defining interaction with our travel policy services.

8. Highlight the TravelPolicyEJBEJBService.wsdl file under the com.friendlydestinations.bp.travel directory. Drag this file onto the BPEL canvas. Click OK on the Select Service dialog, as shown in Figure 14. You should now see a new TravelPolicyEJB partner link in the BPEL editor.
9. Save the BPEL file and verify that all errors have disappeared from the Tasks view.
   Figure 14. Select Service dialog
   
   

Back to top

Add invoke activities

At this point, you have a business process that simply receives input from a client and does nothing with it. And although your local cable provider may use a similar system to handle customer service calls, this probably won't help our mediator company win or retain many customers. Ultimately, the processing goal is to receive trip requests from our customer's employees, check input and restrictions associated with the requests, and either reject requests or book flights. To accomplish this goal, you need to add business logic and set up interaction between this process and some required services. In this section, we'll establish interactions with external services. Inclusion of the supporting business logic is covered in the next section.

The first external service that we'll call is the getPreferredAirProviders method. Although you might expect the client application calling the business process would also call this method to get a valid list of air carriers to choose from, this business process will ensure that the policies are enforced. It will also ensure that the selected air carrier passed into the business process matches one in the travel policy rules. The following steps describe how you can set up the service call.

1. Click on the Invoke activity button, shown in Figure 15, in the upper left section of the BPEL palette. Immediately move the cursor into the flow boundaries just under the Receive activity and left-click your mouse. This action inserts a new Invoke activity into the business process, as shown in Figure 16. Notice that none of the fields in the Implementation section are filled in yet.
   Figure 15. Invoke icon
   
   
2. Click on the Description tab in the Invoke properties section and change the name of this activity from Invoke to VerifyCarrier. In general, double-clicking on any type of activity provides an avenue for changing the name of that activity.
3. Click on the Implementation tab. Select TravelPolicyEJB for the Partner Link field and make sure getPreferredAirProviders is chosen for the Operation field. Select New for both the Request and Response fields to create two new variables called AirProviderRqst and AirProviderRsp, as shown in Figure 16. There is no actual input required for the getPreferredAirProviders method, so the AirProviderRqst variable will not be populated with any values.
   Figure 16. Implementation properties for VerifyCarrier activity
   
   
4. Right-click on the Receive activity, select Set Link between Flow activities, and click on the VerifyCarrier activity to connect the link between Receive and VerifyCarrier.
5. Save the BPEL file, but do not close it. There should be no errors in the Task view at this point.

   The isApprovalRequired travel policy method is the next service that needs to be set up in the business process. This method is also an operation defined in our TravelPolicyEJB partner link, so you need to create an Invoke activity pointing to that partner link.

6. Click on the Invoke button in the upper left section of the BPEL palette. Immediately move the cursor into the flow boundaries just under the GetCarriers activity, and left-click your mouse button. This inserts a new Invoke activity into the business process.
7. Click Description in the Invoke properties section, and change the name of this activity from Invoke to IsApprovalRequired.
8. Click on Implementation. Select TravelPolicyEJB for the Partner Link field and make sure IsApprovalRequired is chosen for the Operation field. Select the New button for both the Request and Response fields to create two new variables called ApprovalRqst and ApprovalRsp, as shown in Figure 17.
   Figure 17. Implementation properties for IsApprovalRequired activity
   
   
9. Right-click on GetCarriers activity, select Set Link between Flow activities, and click on the IsApprovalRequired activity to connect the link between GetCarriers and IsApprovalRequired.
10. Click on Terminate in the BPEL palette, as shown in Figure 18. Move the cursor to the right of the IsApprovalRequired activity and left-click your mouse. Create a second link between the Receive activity and this new Terminate activity. (We discuss this second link in more detail below.)
11. Save the BPEL file. Again, there should be no errors in the Task view.
    Figure 18. Terminate icon
    
    

Back to top

Add Java snippets and conditional links

We currently have a business process that receives input from a client and invokes two external services. Although we're making progress, this process still lacks key elements to make it useful. We have a flow that invokes two external services, but there is no mechanism to populate the input message for the IsApprovalRequired call. There is also no action taken, or processing performed, on the resulting response messages returned from the service calls. Java snippets and conditional links will help us fill in these voids.

The Java snippets feature, a WebSphere Studio Application Developer extension to the BPEL standard, was added to help optimize the usability of BPEL and provide more flexibility. The conditional links feature is part of the BPEL standard. Both features let you add supporting Java code to the processes.

First, we'll add a link condition following the Receive activity that validates the input message and, based on the results, routes to a Terminate activity or to the first service call. It starts off by printing a confirmation message indicating that the client message was received. Follow the steps below to add this snippet.

1. Click the link between the Receive and GetCarriers activities. In the properties area, you'll see the Condition tab with a Value field set to True, indicating that this link will always be traversed from the Receive activity. We want to change it so this path will be traversed only if certain conditions are met.
2. Select Expression for the Value field and enter the code in Listing 1 to the code input field (shown in Figure 19). To keep this example straightforward, we're simply making sure a value is provided for the AirCarrier field and that the price is greater than zero. If this condition is met, this link will be traversed, since a link with a transition condition is only followed if the condition results in true.
3. Create another link between the Receive and Terminate activity. Click on the link and select Condition in the properties area. Select Otherwise for the Value field. This sets up the link to be traversed only if the first link from the Receive activity is not true. In this example, if a valid carrier or price is not provided by the client, a message is printed and the process instance is terminated. In a more realistic implementation, we'd probably update the status of a requisition record in a database before terminating, but this gives you an example of how the flow can be controlled. And, as you might have observed, we could have also set this second link condition to true, allowing concurrent paths to be traversed within the process flow.

   Listing 1. Link expression code

   System.out.println("DEMO-In Receive Link Condition Check"); // Check for valid input boolean retCode = false; try { ProcessTravelRequestMessage travelMsg = getTravelRequestRqst(); if ( travelMsg.getAirCarrierName() == null || travelMsg.getAirPrice() == 0 ) { System.out.println("DEMO-Invalid Client Input - Route To Terminate"); retCode = false; } else { System.out.println("DEMO-Valid TravelRequest Received."); retCode=true; } } catch (Exception e) { System.out.println("DEMO ERROR-Error Trying To Access Client Input"); } return retCode;

   
   
   
   Figure 19. BPEL link expression
   
   

The next step to our process is to add a Java snippet, which allows you to add Java logic at required stages of the process. Because Java snippets can access process variables, they provide much programmatic flexibility to our process and are commonly used to move data between variables. (Assign activities provide an alternative method for data transfer, but don't provide for additional logic that can be included in Java snippets.) So now you need to place a Java snippet after the VerifyCarrier Invoke activity, which will be used to verify that the AirCarrier passed in by the client is a preferred air carrier passed back from the preferredAirProviders service call.

1. Click on Java Snippet on the BPEL palette, as shown in Figure 20. Move the cursor to an area under the GetCarriers Invoke activity and left-click your mouse.
2. Rename the Java snippet to ValidateCarrier.
3. Click on the Implementation tab under the properties area. You'll see a blank form where we'll type in our Java code. Add the code shown in Listing 2 to this Java snippet. Right-click anywhere in the snippet code area and select Source > Organize Imports to import necessary packages and resolve unknown class issues.
4. Click on the link between the two Invoke activities (GetCarriers and IsApprovalRequired). Right-click and select Delete to remove this link.
5. Add a new link between GetCarriers and ValidateCarrier. Add another link between ValidateCarrier and IsApprovalRequired.
   Figure 20. Java snippet icon
   
   

   Listing 2. ValidateCarrier Java snippet code

   System.out.println("DEMO-In ValidateCarrier"); // Start by setting price in the ApprovalRqst variable to zero to // indicate that there is not a valid trip request to check approval // on. // Notice that we must set the "true" parameter in the // getApprovalRqst() method in order to access a variable for updating. IsApprovalRequiredRequestMessage apprRqst = getApprovalRqst(true); TripSelection tripRequest = new TripSelection(); tripRequest.setAirCarrierPrice(new Double(0)); // Get array of AirCarriers returned back from GetCarriers String[] carriers = getAirProviderRsp().getResult(); for (int i=0; carriers[i] != null; i++) { if ( 0 == carriers[i].compareToIgnoreCase(getTravelRequestRqst(). getAirCarrierName()) ) { System.out.println("DEMO-Match Found For Carrier: ["+carriers[i]+"]"); // Since we have valid client input, setup the ApprovalRqst // variable with data to pass to the next service call. tripRequest.setAirCarrierName(getTravelRequestRqst(). getAirCarrierName()); tripRequest.setAirCarrierPrice(new Double(getTravelRequestRqst(). getAirPrice())); break; } } // Update the ApprovalRqst variable apprRqst.setTripSelection(tripRequest); setApprovalRqst(apprRqst); if ( 0 == apprRqst.getTripSelection().getAirCarrierPrice(). doubleValue() ) { // In real implementation, we would probably route to some activity to handle properly System.out.println("DEMO-ERROR: Invalid Air Carrier Submitted - Reject Trip Request."); } apprRqst = getApprovalRqst(true); setApprovalRqst(apprRqst);

   
   

   The code in Listing 2 shows an array of AirCarriers (strings) obtained and iterated through the list to make sure the carrier passed in by the client matches one in the list. If there is a match, you'll need to populate the ApprovalRqst variable with data needed for the IsApprovalRequired service call. If there is not a match, you can assume the client has somehow circumvented the system and submitted an invalid request. In this case, you can print a reject message and set the ApprovalRqst message to indicate this request should be rejected. To direct this process appropriately, you should alter the link between this ValidateCarrier activity and the IsApprovalRequired activity. And you also need to add an alternative route to the Terminate activity.

6. Click on the Link between the ValidateCarrier and IsApprovalRequired activities. Select Condition in the properties section and change the Value field to Expression. Enter the code shown in Listing 3 into the code input field.
7. Create another link between the ValidateCarrier and Terminate activity. Click on the link and select Condition in the properties area. Select Otherwise for the Value field, which sets up this link to be traversed only if the first link from the ValidateCarrier activity is not true.

   Listing 3. Link expression for ValidateCarrier link

   // If the ApprovalRqst price field is zero, we // should not traverse this link. if ( 0 == getApprovalRqst().getTripSelection().getAirCarrierPrice(). doubleValue() ) { System.out.println("DEMO-Terminte Process Instance After ValidateCarrier"); return false; } System.out.println("DEMO-Move To IsApprovalRequiredActivity"); return true;

   
   

If our client's carrier is validated, the process flow moves on to invoke the IsApprovalRequired activity. You've already populated the ApprovalRqst input variable in the ValidateCarrier Java snippet, so everything is set up for this service call. You now must add a Java snippet to handle the response message returned by the IsApprovalRequired activity. This snippet will be used to check the returned Boolean value indicating whether approval is required for this trip request. (In the previous article, this is determined within a BRBeans rule that evaluates the trip cost and the employee's management role). If approval is not required, you can print a message indicating the trip request has been approved.

In a more realistic implementation, you'd probably move on to invoke another external service to book the flight with the air carrier. If approval is required, you'll simply print a message indicating this condition, but take no other action.

To create our final Java snippet for this article:

1. Follow the normal process to add a Java snippet and place it below the IsApprovalRequired activity. Rename this snippet ApprovalRqmtCheck.
2. Add the code shown in Listing 4 to this Java snippet.
3. Until the next article, this concludes the processing for this business flow, so no other links are required. The process instance will automatically end after this activity. The process in the BPEL editor should now resemble Figure 21.

   Listing 4. ApprovalRqmtCheck Java snippet
   

   if ( getApprovalRsp().getResult() ) { // Approval is required - need to route to approval process // (just print message for now) System.out.println("DEMO-Approval IS Required"); } else { System.out.println("DEMO-Approval NOT Required"); } // Print out info about this customer trip request System.out.println("DEMO-BOOK THE FOLLOWING FLIGHT:"); System.out.println(" Flight No:["+getTravelRequestRqst(). getFlightNo()+"]"); Calendar tripDate = getTravelRequestRqst().getTravelDate(); System.out.println(" Flight Date:["+(tripDate.get(Calendar.MONTH)+1)+ "-"+tripDate.get(Calendar.DAY_OF_MONTH)+"]"); System.out.println(" Carrier:["+getTravelRequestRqst(). getAirCarrierName()+"]"); System.out.println(" Price:["+getTravelRequestRqst().getAirPrice()+ "]");

   
   
   
   Figure 21. Finished process flow
   
   

Back to top

Generate deploy code

Before running the business process, you must generate the code that results in an EJB and EAR project that can be deployed to the test server, as follows.

1. Save all changes made in the BPEL editor and ensure there are no errors displayed in the Task view.
2. Within the TravelSVC project, highlight the TravelBP.bpel file under the com.friendlydestinations.bp.travel directory.
3. Right-click and select Enterprise Services > Generate Deploy Code.
4. A Generate BPEL Deploy Code dialog appears, as shown in Figure 22. From here, you can observe one externally referenced partner, which is -- as you would expect -- the TravelPolicyEJB. If you click this partner icon, you'll see details related to the port type, WSDL file name, service, and port. If you click the TravelRequest icon (just above the EJB binding icon), you can see that an EJB binding is the default binding for the interface to call our business process. You also have the option of generating JMS, SOAP/HTTP, and SOAP/JMS bindings.

   (For this article, we use the BPEL Web client application, a packaged WebSphere Business Integration Server Foundation component that comes with the other business process components and communicates with business processes using the EJB bindings. As a result, we don't need to generate any other category of bindings to test the process.)

5. Click Finish to proceed with the deploy code generation. It may take 30 to 60 seconds to complete this generation phase.
6. Verify that a TravelSVCEAR, TravelSVCEJB, and TravelSVCWeb project now exist in your work space. Also verify that no errors exist in the Task view.

Back to top

Test BPEL process

You can now run and test the BPEL process. WebSphere Business Integration Server Foundation packages a handy BPEL Web client application that can be used for client interaction in a Universal Test Environment (UTE) server or normal run-time server environment. This client makes it easy to quickly test BPEL processes without having to create a client application with the necessary BPEL APIs. The BPEL Web client is automatically installed in our integrated test environment server we configured in Develop business rules with WebSphere business rule beans, Part 1.

The tests are very basic, with the primary objectives of verifying the functions of our current process and ensuring we can interact with the Travel Policy services. This positions us for additional enhancements in the next article. Follow the steps below to test the process.

1. Highlight the server1 entry in the Servers tab in the lower section of the Applcication Developer workbench. Right-click and select Add and remove projects.
2. In the Add and Remove Projects dialog, highlight the TravelSVCEAR project in the left panel and click Add.
3. Click Finish.
4. Start the UTE server and verify that no errors are present in the Console view.
5. Bring up a Web browser and type http://localhost:9080/bpe/webclient for the URL address. (This is the address for the BPEL Web client we'll use to test our process flow.)
6. Click the My Templates link on the left panel of the Web client. A template displays in the main section of the window called TravelBP, as shown in Figure 23.
   Figure 23. TravelBP template in BPEL Web client
   
   
7. Click on the checkbox for the TravelBP template, and click Start Instance. You see a display that lets you enter input values required by the Receive activity in the business process.
8. Enter EconomyAirlineB, 801.0, EA111, and 08/11/04 15:30 PM for the AirCarrierName, AirPrice, FlightNo, and TravelDate fields, as shown in Figure 24.
   Figure 24. TravelBP input fields
   
   
9. Click Start Instance to submit the input data and start an instance of the business process EJB.
10. Change window focus back to Application Developer. You should see the output in Listing 5 in the Console output view.

Listing 5. Business process output

[8/29/04 9:20:11:467 EDT] 4319a353 SystemOut     O DEMO-In Receive Link 
   Condition Check
[8/29/04 9:20:11:477 EDT] 4319a353 SystemOut     O DEMO-Valid 
   TravelRequest Received.
[8/29/04 9:20:15:523 EDT] 4319a353 SystemOut     O DEMO-New TriggerPoint 
   Object Created
[8/29/04 9:20:15:633 EDT] 4319a353 SystemOut     O DEMO-In ValidateCarrier
[8/29/04 9:20:15:633 EDT] 4319a353 SystemOut     O DEMO-Match Found For 
   Carrier: [EconomyAirlineB]
[8/29/04 9:20:15:633 EDT] 4319a353 SystemOut     O DEMO-Move To 
   IsApprovalRequiredActivity
[8/29/04 9:20:16:154 EDT] 4319a353 SystemOut     O DEMO-trigger method 
   called
[8/29/04 9:20:16:154 EDT] 4319a353 SystemOut     O DEMO-Approval IS 
   Required
[8/29/04 9:20:16:154 EDT] 4319a353 SystemOut     O DEMO-BOOK THE FOLLOWING 
   FLIGHT:
[8/29/04 9:20:16:154 EDT] 4319a353 SystemOut     O   Flight No:[EA111]
[8/29/04 9:20:16:204 EDT] 4319a353 SystemOut     O   Flight Date:[8-12]
[8/29/04 9:20:16:204 EDT] 4319a353 SystemOut     O   Carrier:
   [EconomyAirlineB]
[8/29/04 9:20:16:204 EDT] 4319a353 SystemOut     O   Price:[801.0]

Notice that the AirCarrierName matches a valid carrier defined in our business rule, and the approval rule check results in true for the $801 purchase request. (See Develop business rules with WebSphere business rule beans, Part 2 for details related to these rules.) In this early version of our business process, the trip was booked regardless of cost.

Rerun another test with the Web client using a price under $800. No approval should be required for this request.

Run another test with an invalid AirCarrierName. In the Console output view, you should see the message:

DEMO-ERROR: Invalid Air Carrier Submitted - Reject Trip Request

Back to top

Go with the interruptible flow

The scenario flow example deploys as a noninterruptible process, also called a microflow. This means the process runs without interruption, and all its activities are encapsulated in a single transaction. In the next article, we'll switch our process to an interruptible, or long-running, process to support human intervention for trip approval. (When you introduce an activity into the flow that requires human interaction, you can't predict how long the process will remain in an interrupted state, so an immediate reply from the process does not make sense. Because we created a one-way interface for the travel business process (where the client does not receive a reply), we're set up to easily convert to a long-running process, which was the primary reason for making this design decision earlier in the article. A more sophisticated approach, using an asynchronous reply, could also be employed as an alternative design, but that's beyond the scope of this article.

Back to top

Summary

By completing the development, deployment, and testing of a basic business process, you learned the mechanics involved in developing a BPEL process. The Process Choreographer development environment supported in WebSphere Studio Application Developer Integration Edition V5.1 lets you quickly get up to speed and become proficient in developing process flows. As shown in this article, the Process Choreographer also makes it easy to integrate heterogeneous services into a controlled logical process. This was a good match for the travel mediator, where trip requests require interaction with multiple external services.

In the next article, you'll learn additional aspects of BPEL development that the mediated exchange company can use, including allowing human interaction for approval, starting process flows from custom client applications, and debugging processes. This flexibility allows your enterprise to become anOn Demand Business.

Back to top

Upcoming articles in this series

Our introductory article, "Integrate business processes among service consumers, brokers, and providers," describes a 5-stage roadmap for enabling the mediated exchange solution. Stay tuned to this series, which discusses each stage in detail and includes a set of articles describing how the capabilities required in each of these stages are designed, implemented, and deployed.

Resources

• Read the Specification for Business Process Execution Language for Web Services Version 1.1.
  
  
• Download a WebSphere Studio Application Developer Integration Edition trial program.
  
  
• Visit the WebSphere Studio zone on developerWorks WebSphere for information about WebSphere Studio Application Developer Integration Edition.
  
  
• Download trial code for DB2 Universal Database.
  
  
• Visit the DB2 Universal Database zone on developerWorks DB2 for information about DB2 Universal Database.
  
  
• Take this tutorial to learn how to configure WebSphere Process Choreographer to use an LDAP-based staff repository.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Revisit the business scenario
• Know the product requirements
• Get started
• Create a service project and BPEL process
• Define input message for travel process
• Create service call interface for TravelPolicy
• Create partner links in the BPEL process
• Add invoke activities
• Add Java snippets and conditional links
• Generate deploy code
• Test BPEL process
• Go with the interruptible flow
• Summary
• Upcoming articles in this series
• 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