Open ESB: The Solution for the Open Minded The Crooked Stick

« Java CAPS Tip :... | Main | Java CAPS Tip :... »

Wednesday Aug 13, 2008

Java CAPS Tip : Implementing a Vendor Relationship Management Portal (Part 2)

This blog entry takes the process implemented in Part 1 of this trail, eInsight Implementation, and extends it to integrated it into a new BPEL 2.0 style process. Because we are extending what has already been implemented I will not be discussing those sections in detail and assume that you have read the previous part.

The overall workflow to be implemented is shown below.

VRMP Trail

Resources

BPEL 2.0Workflow Implementation

Because the Worklist Manager UA API does not exist within BPEL 2.0 we will not be able to call the User Activities Directly. Instead we will leverage the JBI Bridge functionality available with the Java CAPS 6 product to link to the previously built Sub Processes (hence the reason the previous article created them as Sub Processes). Again we will implement the Workflow as two distinct BPEL processes, for the reasons described previously, one for the POWorkflow and one for the ASNWorkflow. These two new processes will again be made persistent and I will assume that the appropriate Database tables have been created.

Exposing the User Activities Sub Processes

Before we can commence building the Workflow implementations we must expose the appropriate Sub Processes using the JBI Bridge technology. This is achieved by creating new Connectivity Maps (CM) within the Java CAPS Repository Project that will link the Sub Processes to a JBI Bridge external rather than a Web Service External.

Create Connectivity Map cmPOWorkflowBridge

Add bpAcceptPOUA
Add bpCreateASNUA
Manually map the inputs to a JBI Bridge

Create Connectivity Map cmASNWorkflowBridge

Add bpAuthoriseASNUA
Add bpAuthoriseASNFLSLUA
Manually map the inputs to a JBI Bridge

Create Deployment Profile dpUABridge

Once created select the properties (Right Click) for the Deployment profile and change the EAR name to dpUABridge. This will allow you to recreate the DP without worrying that the name will change.

Create a Composite Application (WLMPOCompositeApp)

Add CAPS Module dpUABridge

Create a new BPEL Module WLMPOBpelModule

Purchase Order Workflow

Within the WLMPOBpelModule Project create a new BPEL Process "poWorkflow" and import the previously create WLMPO.wsdl and its associated xsd and then create WSDL files associated with the PO and ASN JMS inputs.

Create new BPEL Process poWorkflow
Drag poMessage.wsdl onto the Canvas and name the Partner Link plPOMsg

Attached to the Receive

Drag an Invoke on the the Canvas
From the WLMPOCompositeApp Drag the bpAcceptPOUA.wsdl (created when the CAPS Module was associated with the CA) onto the right of the Canvas and name the Partner Link plAcceptPOUA.

Configure as below

Link the Invoke to the newly created Partner Link, their should be only one Operation WLMAcceptPO and create the variables.
Drag and If onto the Canvas and modify the test so that it checks the Accept attribute in the output from the previous Invoke. If it is true then continue otherwise exit.
Within the If add an Invoke.
We now need to add a call to the second Sub Process but because they are all defined within the same WSDL, i.e. WLMPO.wsdl, importing it will cause the BPEL 2 processes to flag an error because the same definitions are imported twice. We can work around this as follows.

Create a second BPEL Process (name does not matter because we will delete it.
From the WLMPOCompositeApp drag the bpCreateASNUA.wsdl onto the Right of the Canvas and configure as below
This will Create a Partners Directory bpCreateASNUA.

Copy the bpCreateASNUAWrapper.wsdl to the bpAcceptPOUA Partners Directory and edit to match the following:

<?xml version="1.0" encoding="UTF-8"?>

<definitions
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 xmlnssd="http://www.w3.org/2001/XMLSchema" name="bpCreateASNUAWrapper" targetNamespace="http://enterprise.netbeans.org/bpel/bpCreateASNUAWrapper" xmlns:tns="http://enterprise.netbeans.org/bpel/bpCreateASNUAWrapper" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype" xmlns:ns="urn:wsdl.wlm.po.processing">
 <import location="bpAcceptPOUA.wsdl" namespace="urn:wsdl.wlm.po.processing"/>
 <plnk:partnerLinkType name="WLMCreateASNLinkType">
 <plnk:role name="WLMCreateASNRole" portType="ns:WLMCreateASNPortType"/>
 </plnk:partnerLinkType>
</definitions>

Drag the newly modified bpCreateASNUAWrapper.wsdl onto the Right of the Canvas.

Link the invoke to the new Partner Link
Add Assigns, as below, and Map appropriately.

ASN Workflow

Within the WLMPOBpelModule Project create a new BPEL Process "asnWorkflow" and import the previously create WLMPO.wsdl and its associated xsd and then create WSDL files associated with the PO and ASN JMS inputs.

Create a new BPEL Process asnWorkflow
Drag asnMessage.wsdl onto the Left of the Canvas and name it plASNMsgIn

Attach to the Receive

Drag and Assign and Invoke onto the Canvas
From the WLMPOCompositeApp Drag the bpAuthoriseASNUA.wsdl onto the right of the Canvas and configure as follows:
Link the Invoke to the newly created Partner Link and create the variables
Drag and If, Assign and Invoke onto the Canvas as with the poWorkflow.
We need to add the second AuthoriseASNFLSLUA. To do this repeat the process described above (using the AuthoriseASNUA directory) configuring the Partner Link as below:

Modify the AuthoriseASNFLSLWrapper.wsdl as below:

<?xml version="1.0" encoding="UTF-8"?>

<definitions
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 xmlnssd="http://www.w3.org/2001/XMLSchema" name="bpAuthoriseASNFLSLUAWrapper" targetNamespace="http://enterprise.netbeans.org/bpel/bpAuthoriseASNFLSLUAWrapper" xmlns:tns="http://enterprise.netbeans.org/bpel/bpAuthoriseASNFLSLUAWrapper" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype" xmlns:ns="urn:wsdl.wlm.po.processing">
 <import location="bpAuthoriseASNUA.wsdl" namespace="urn:wsdl.wlm.po.processing"/>
 <plnk:partnerLinkType name="WLMAuthoriseASNFLSLLinkType">
 <plnk:role name="WLMAuthoriseASNFLSLRole" portType="ns:WLMAuthoriseASNFLSLPortType"/>
 </plnk:partnerLinkType>
</definitions>

Import the new AuthoriseASNFLSLWrapper.wsdl
Link the Invoke to the new Partner Link
Add a second If, Assign, Invoke
Drag the asnMessage.wsdl to the right side of the canvas and name the Partner Link plASNMsgOut. This will provide the process termination functionality as define with Part 1.
Map Assigns and you should have a BPEL Process below:

Build Composite Application

To allow us to build and deploy the linked application we will need to extend the provious create WLMPOCompositeApp and add the newly created WLMPOBpelModule.

Within the WLMPOCompositeApp add the JBI Module WLMPOBpelModule.
Execute a clean and build
Edit Service Assembly and Configure as below:
Following the first clean and build the JMS Ports will not be created. You will need to add them and then configure to be associated with the Sun SeeBeyond Queue Manager

stcms://localhost:18007
admin
adminadmin

Modify to match the appropriate Queue Name and message part name.
Build
If the dpPOWorkflow & dpASNWorkflow are still deployed then these must be Undeployed.
Deploy WLMPOCompositeApp.

To test this we will be using the same simple load jcd built and deployed in Part 1 of this trail. Therefore copy the po00001.xml file into the appropriate directory and it will be read. This will initiate the BPEL 2.0 processes. We can use the same Visual Web Pack application to move the PO and ASN through the appropriate steps executing a mix of BPEL 2.0 and eInsight processes.

Because of the changes made to BPEL 2.0 Persistence the process will be passivated out of memory when stalled awaiting the User Activity to return and hence the overall memory usage is likely to be lower.

Trail