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.

Workflow



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.
  1. Create Connectivity Map cmPOWorkflowBridge
    1. Add bpAcceptPOUA
    2. Add bpCreateASNUA
    3. Manually map the inputs to a JBI Bridge
      CM
  2. Create Connectivity Map cmASNWorkflowBridge
    1. Add bpAuthoriseASNUA
    2. Add bpAuthoriseASNFLSLUA
    3. Manually map the inputs to a JBI Bridge
      CM
  3. Create Deployment Profile dpUABridge
    1. 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.
      EAR Name
  4. Create a Composite Application (WLMPOCompositeApp)
    1. Add CAPS Module dpUABridge
  5. 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.
  1. Create new BPEL Process poWorkflow
  2. Drag poMessage.wsdl onto the Canvas and name the Partner Link plPOMsg
    1. Attached to the Receive
  3. Drag an Invoke on the the Canvas
  4. 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.
    1. Configure as below

      plAcceptPOUA

  5. Link the Invoke to the newly created Partner Link, their should be only one Operation WLMAcceptPO and create the variables.
  6. 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.
  7. Within the If add an Invoke.
  8. 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.
    1. Create a second BPEL Process (name does not matter because we will delete it.
    2. From the WLMPOCompositeApp drag the bpCreateASNUA.wsdl onto the Right of the Canvas and configure as below

      plCreateASNUA

    3. This will Create a Partners Directory bpCreateASNUA.
    4. 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/"
      xmlns:xsd="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>

    5. Drag the newly modified bpCreateASNUAWrapper.wsdl onto the Right of the Canvas.
  9. Link the invoke to the new Partner Link
  10. Add Assigns, as below, and Map appropriately.

    poWorkflow



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.
  1. Create a new BPEL Process asnWorkflow
  2. Drag asnMessage.wsdl onto the Left of the Canvas and name it plASNMsgIn
    1. Attach to the Receive
  3. Drag and Assign and Invoke onto the Canvas
  4. From the WLMPOCompositeApp Drag the bpAuthoriseASNUA.wsdl onto the right of the Canvas and configure as follows:

    plAuthoriseASNUA

  5. Link the Invoke to the newly created Partner Link and create the variables
  6. Drag and If, Assign and Invoke onto the Canvas as with the poWorkflow.
  7. 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:

    Authorise

  8. 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/"
    xmlns:xsd="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>

  9. Import the new AuthoriseASNFLSLWrapper.wsdl
  10. Link the Invoke to the new Partner Link
  11. Add a second If, Assign, Invoke
  12. 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.
  13. Map Assigns and you should have a BPEL Process below:

    asnWorkflow

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.
  1. Within the WLMPOCompositeApp add the JBI Module WLMPOBpelModule.
  2. Execute a clean and build
  3. Edit Service Assembly and Configure as below:

    CASA

  4. 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
    1. stcms://localhost:18007
    2. admin
    3. adminadmin
  5. Modify to match the appropriate Queue Name and message part name.
  6. Build
  7. If the dpPOWorkflow & dpASNWorkflow are still deployed then these must be Undeployed.
  8. 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
Resources

 

Comments:

Post a Comment:
Comments are closed for this entry.
About

As a member of the Oracle A-Team we specialise in enabling and supporting the Oracle Fusion Middleware communities.

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today