Open ESB Tip : Implementing a Vendor Relationship Management Portal (Part 3)

In the final part of my "Vendor Relationship Management Portal" (VRMP) implementation trail I will implement the Vendor Workflow using just the functionality available in the Open ESB (GlassFish ESB) product. This uses the Open ESB BPEL 2.0 JBI Based functionality and the Worklist Manager Service Engine (WLM SE). Previously I have blogged about Java CAPS 6 WLM functionality and how to link BPEL with this traditional Java CAPS functionality; see:
Within those entries I discussed the Part 3 entry that would be the same project implemented using pure Open ESB and the WLM SE. Therefore this blog entry is the first in the Sub-Thread associated with building the VRMP using only Open ESB.

VRMP Trail


WLM SE Trail
  1. Configuring WLM SE to use Open DS.
  2. Implementing a Vendor Relationship Management Portal (Part 3) (VRMP Build Video).
  3. Developing the Worklist Interface using Visual Web Pack.
  4. Developing the Worklist Interface with ICEfaces.
  5. Adding Security Using OpenSSO.


Resources

I have upload a Flash Video (VRMP Build Video) of the build process below to the WLM SE Wiki (or at the end of this entry) and this will take you through the whole process in about 30 minutes.

Process Overview


The following "Java CAPS 6 eInsight" process flow, seen in the previous blogs, shows the logical representation of the overall VRMP process and exists in this blog pure to show what we will implement.

eInsight


Open ESB Workflow Implementation (WLM SE)


In the previous blogs I split the logical workflow into two parts because the GUI user was allowed to raise multiple ASN for each PO. For this blog entry I will not do that, for no other reason than I wanted to implement a single long running BPEL 2.0 process. Hence the net result of this is that the GUI user will only be able to Accept a PO and raise a single ASN for the PO. You can change this by having a PO Workflow and an ASN workflow initiated by a queue. I will leave this to the reader to do a an intellectual exercise.

The implementation of the VRMP Process is essentially split into 3 projects (4 if you include the default Web Application) WorkFlow Project, BPEL Module and a Composite Application. I will describe each of these below and then briefly cover the default Web Application.

Following on from this I intend to cover building a Custom Web Application using Visual Web Pack and then its replacement ICEfaces.

I will assume that you have configured you WLM SE Engine to use Open DS and MySQL as described in the blog entry "Configuring WLM SE to use Open DS".

WLMPOWorkflowApp


The WLMPOWorkflowApp Module will provide the 4 Workflow Tasks to be used in the main BPEL module. These tasks will be based on the Operations defined in the WLMPO.wsdl (below) and the types are defined in the WLMPOComplexTypes.xsd.

WLMPOComplexTypes.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:xsd.wlm.po.processing"
xmlns="urn:xsd.wlm.po.processing"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:xsd.wlm.po.processing"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="PurchaseOrderComplexType">
<xs:sequence>
<xs:element name="PONumber" type="xs:string"/>
<xs:element name="SupplierName" type="xs:string"/>
<xs:element name="PODescription" type="xs:string"/>
<xs:element name="ApprovalResult" type="tns:ApprovalResult" minOccurs="0"></xs:element>
</xs:sequence>
<xs:attribute name="Accept" type="xs:boolean"/>
</xs:complexType>
<xs:complexType name="ASNComplexType">
<xs:sequence>
<xs:element name="PONumber" type="xs:string"/>
<xs:element name="SupplierName" type="xs:string"/>
<xs:element name="PODescription" type="xs:string"/>
<xs:element name="ASNNumber" type="xs:string"/>
<xs:element name="ApprovalResult" type="tns:ApprovalResult" minOccurs="0"></xs:element>
</xs:sequence>
<xs:attribute name="Accept" type="xs:string"/>
</xs:complexType>
<xs:element name="PurchaseOrder" type="PurchaseOrderComplexType"/>
<xs:element name="ASN" type="ASNComplexType"/>
<xs:simpleType name="ApprovalResult">
<xs:restriction base="xs:string">
<xs:enumeration value="Approved"/>
<xs:enumeration value="Rejected"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

WLMPO.wsdl.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="urn:wsdl.wlm.po.processing"
targetNamespace="urn:wsdl.wlm.po.processing"
xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype">
<wsdl:types>
<xs:schema targetNamespace="urn:wsdl.wlm.po.processing" elementFormDefault="qualified" xmlns:types="urn:xsd.wlm.po.processing">
<xs:import namespace="urn:xsd.wlm.po.processing" schemaLocation="WLMPOComplexTypes.xsd"/>
<xs:element name="PurchaseOrder" type="types:PurchaseOrderComplexType"/>
<xs:element name="ASN" type="types:ASNComplexType"/>
</xs:schema>
</wsdl:types>
<wsdl:message name="WLMPOAcceptPORequest">
<wsdl:part name="parameter" element="tns:PurchaseOrder"/>
</wsdl:message>
<wsdl:message name="WLMPOAcceptPOResponse">
<wsdl:part name="result" element="tns:PurchaseOrder"/>
</wsdl:message>
<wsdl:message name="WLMPOCreateASNRequest">
<wsdl:part name="parameter" element="tns:PurchaseOrder"/>
</wsdl:message>
<wsdl:message name="WLMPOCreateASNResponse">
<wsdl:part name="result" element="tns:PurchaseOrder"/>
</wsdl:message>
<wsdl:message name="WLMPOAuthoriseASNRequest">
<wsdl:part name="parameter" element="tns:ASN"/>
</wsdl:message>
<wsdl:message name="WLMPOAuthoriseASNResponse">
<wsdl:part name="result" element="tns:ASN"/>
</wsdl:message>
<wsdl:message name="WLMPOAuthoriseASNFLSLRequest">
<wsdl:part name="parameter" element="tns:ASN"/>
</wsdl:message>
<wsdl:message name="WLMPOAuthoriseASNFLSLResponse">
<wsdl:part name="result" element="tns:ASN"/>
</wsdl:message>
<wsdl:portType name="WLMAcceptPOPortType">
<wsdl:operation name="WLMAcceptPO">
<wsdl:input message="tns:WLMPOAcceptPORequest"/>
<wsdl:output message="tns:WLMPOAcceptPOResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="WLMCreateASNPortType">
<wsdl:operation name="WLMCreateASN">
<wsdl:input message="tns:WLMPOCreateASNRequest"/>
<wsdl:output message="tns:WLMPOCreateASNResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="WLMAuthoriseASNPortType">
<wsdl:operation name="WLMAuthoriseASN">
<wsdl:input message="tns:WLMPOAuthoriseASNRequest"/>
<wsdl:output message="tns:WLMPOAuthoriseASNResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="WLMAuthoriseASNFLSLPortType">
<wsdl:operation name="WLMAuthoriseASNFLSL">
<wsdl:input message="tns:WLMPOAuthoriseASNFLSLRequest"/>
<wsdl:output message="tns:WLMPOAuthoriseASNFLSLResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="WLMAcceptPOBinding" type="tns:WLMAcceptPOPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="WLMAcceptPO">
<soap:operation soapAction="http://localhost:${HttpDefaultPort}/WLM/WLMAcceptPO"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="WLMCreateASNBinding" type="tns:WLMCreateASNPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="WLMCreateASN">
<soap:operation soapAction="http://localhost:${HttpDefaultPort}/WLM/WLMCreateASN"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="WLMAuthoriseASNBinding" type="tns:WLMAuthoriseASNPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="WLMAuthoriseASN">
<soap:operation soapAction="http://localhost:${HttpDefaultPort}/WLM/WLMAuthoriseASN"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="WLMAuthoriseASNFLSLBinding" type="tns:WLMAuthoriseASNFLSLPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="WLMAuthoriseASNFLSL">
<soap:operation soapAction="http://localhost:${HttpDefaultPort}/WLM/WLMAuthoriseASNFLSL"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="WLMService">
<wsdl:port name="WLMAcceptPOPort" binding="tns:WLMAcceptPOBinding">
<soap:address location="http://localhost:${HttpDefaultPort}/WLM/AcceptPOUA"/>
</wsdl:port>
<wsdl:port name="WLMCreateASNPort" binding="tns:WLMCreateASNBinding">
<soap:address location="http://localhost:${HttpDefaultPort}/WLM/CreateASNUA"/>
</wsdl:port>
<wsdl:port name="WLMAuthoriseASNPort" binding="tns:WLMAuthoriseASNBinding">
<soap:address location="http://localhost:${HttpDefaultPort}/WLM/AuthoriseASNUA"/>
</wsdl:port>
<wsdl:port name="WLMAuthoriseASNFLSLPort" binding="tns:WLMAuthoriseASNFLSLBinding">
<soap:address location="http://localhost:${HttpDefaultPort}/WLM/AuthoriseASNFLSLUA"/>
</wsdl:port>
</wsdl:service>
<plnk:partnerLinkType name="WLMAcceptPOPLT">
<plnk:role name="AcceptPORole" portType="tns:WLMAcceptPOPortType"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="WLMCreateASNPLT">
<plnk:role name="CreateASNRole" portType="tns:WLMCreateASNPortType"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="WLMAuthoriseASNPLT">
<plnk:role name="AuthoriseASNRole" portType="tns:WLMAuthoriseASNPortType"/>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="WLMAuthoriseASNFLSLPLT">
<plnk:role name="AuthoriseASNFLSLRole" portType="tns:WLMAuthoriseASNFLSLPortType"/>
</plnk:partnerLinkType>
</wsdl:definitions>

At the time of this blog entry publication their is currently an issues with type inheritance. Hence you will notice that the ASNComplexType is no longer inherited from POComplexType. Also I have added the ApprovalResult Element because mapping to an Attribute seems to fail.

To create the Worklist Application execute the following:
  1. File->New Project->SOA->Worklist Module



  2. Next
  3. Name : WLMPOWorklistApp



  4. Finish

Copy the WLMPOComplexTypes.xsd and the WLMPO.wsdl files into the Project src directory and these will appear within your projects "Worklist Files". We can now create the Worklist Tasks associated with the 4 operations within the WSDL:
  • AcceptPOTask - WLMAcceptPO Operation
  • CreateASNTask - WLMCreateASN Operation
  • AuthoriseASN - WLMAuthoriseASN Operation
  • AuthoriseASNFLSL - WLMAuthoriseASNFLSL Operation
To create the Tasks you will need to execute the following (note that this is essentially the same for all tasks). I will document it in detail for AcceptPOTask and then simply describe the specifics differences for the other Task.

AcceptPOTask

  1. Right Click "Worklist Files"->New->Worklist Task Definition.



    At present the New option is only available from WorkList Files.

  2. In the Name and Location Wizard Panel set
    1. File Name : AcceptPO
    2. Task Name (Auto Generated) : AcceptPOTask
    3. Select Operation (Press ...) to WLMAcceptPO



  3. Next
  4. Add User Andrew



  5. Finish
  6. In the newly opened AcceptPO.wf add:
    1. Title : Accept PO
    2. Priority : 5



      At the time of writing you are required to put single quotes around the text string. That is Accept PO above must be written as 'Accept PO'.

  7. Switch to the Actions Tab and add the following Actions:
    1. Accept PO : Type Completed
    2. Reject PO : Type Aborted
    3. Complete : Type Completed (For the Worklist Web Application)



  8. Switch to the Mapper and add the mappings:
    1. TaskInput.PONumber -> TaskOutput.PONumber
    2. TaskInput.SupplierName -> TaskOutput.SupplierName
    3. TaskInput.PODescription -> TaskOutput.PODescription



  9. Switch to the Source View and we will add the Action specific mappings below.

    <action name="Complete" type="Completed">
    <changeVariables>
    <copy>
    <from>$TaskInput.parameter/ns:ApprovalResult</from>
    <to>$TaskOutput.result/ns:ApprovalResult</to>
    </copy>
    </changeVariables>
    </action>
    <action name="Accept" type="Completed">
    <changeVariables>
    <copy>
    <from>'Approved'</from>
    <to>$TaskOutput.result/ns:ApprovalResult</to>
    </copy>
    </changeVariables>
    </action>
    <action name="Reject" type="Aborted">
    <changeVariables>
    <copy>
    <from>'Rejected'</from>
    <to>$TaskOutput.result/ns:ApprovalResult</to>
    </copy>
    </changeVariables>
    </action>

    At the time of writting the mappings will need to be modified to remove the part components. Hence the mapping should be modified to match the following:
    <variable-init>
    <copy>
    <from>$TaskInput/ns:PONumber</from>
    <to>$TaskOutput/ns:PONumber</to>
    </copy>
    <copy>
    <from>$TaskInput/ns:SupplierName</from>
    <to>$TaskOutput/ns:SupplierName</to>
    </copy>
    <copy>
    <from>$TaskInput/ns:PODescription</from>
    <to>$TaskOutput/ns:PODescription</to>
    </copy>
    </variable-init>

  10. Save
Now we have out first Worklist Task but before we can build the process you will need to create tasks for the remaining 3 Operations following the example above:
  1. WLMCreateASN
    1. Name : CreateASN
    2. Assigned to user : aknight
  2. WLMAuthoriseASN
    1. Name : AuthoriseASN
    2. Assigned to group : FAST
  3. WLMAuthoriseASNFLSL
    1. Name : AuthoriseASNFLSL
    2. Assigned to group : Managers
Save all and then Clean & Build the Project.

Once the build has been completed a number of files will be generated. These are the xhtml files used to display the Task Information within the GUI and will be used later.

WLMPOBpelModule


The WLMPOBpelModule will provide the overall workflow, in a single BPEL 2.0 Process, and use the Worklist Tasks previously created. Because the interface to the Worklist Tasks is defined by the WSDL WLMPO.wsdl we will need to either link to the existing version or create a new copy of the wsdl file and its associated xsd (defined above).

To create the BPEL Module we will need to execute the following:
  1. File->New Project->SOA->BPEL Module



  2. Next.
  3. Name : WLMPOBpelModule



  4. Finish

Copy the WLMPOComplexTypes.xsd and the WLMPO.wsdl files into the Project src directory and these will appear within your projects "Process Files".

I have chosen to copy the files for simplicities sake and it does reduce reference issues because the wsdl imports the xsd.

In addition to the Task Definition WSDL will will need to create two more WSDL documents that define the Input and Output messages for the BPEL Process. We can create these within the BPEL Module as abstract WSDL or import the previously create ones:


poMessage.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="poMessage" targetNamespace="http://j2ee.netbeans.org/wsdl/poMessage"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://j2ee.netbeans.org/wsdl/poMessage" xmlns:ns="urn:xsd.wlm.po.processing" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype">
<types>
<xsd:schema targetNamespace="http://j2ee.netbeans.org/wsdl/poMessage">
<xsd:import namespace="urn:xsd.wlm.po.processing" schemaLocation="WLMPOComplexTypes.xsd"/>
</xsd:schema>
</types>
<message name="poMessageOperationRequest">
<part name="message" element="ns:PurchaseOrder"/>
</message>
<portType name="poMessagePortType">
<operation name="poMessageOperation">
<input name="input1" message="tns:poMessageOperationRequest"/>
</operation>
</portType>
<plnk:partnerLinkType name="poMessage">
<!-- A partner link type is automatically generated when a new port type is added. Partner link types are used by BPEL processes.
In a BPEL process, a partner link represents the interaction between the BPEL process and a partner service. Each partner link is associated with a partner link type.
A partner link type characterizes the conversational relationship between two services. The partner link type can have one or two roles.-->
<plnk:role name="poMessagePortTypeRole" portType="tns:poMessagePortType"/>
</plnk:partnerLinkType>
</definitions>

asnMessage.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="asnMessage" targetNamespace="http://j2ee.netbeans.org/wsdl/asnMessage"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://j2ee.netbeans.org/wsdl/asnMessage" xmlns:ns="urn:xsd.wlm.po.processing" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype">
<types>
<xsd:schema targetNamespace="http://j2ee.netbeans.org/wsdl/asnMessage">
<xsd:import namespace="urn:xsd.wlm.po.processing" schemaLocation="WLMPOComplexTypes.xsd"/>
</xsd:schema>
</types>
<message name="asnMessageOperationRequest">
<part name="message" element="ns:ASN"/>
</message>
<portType name="asnMessagePortType">
<operation name="asnMessageOperation">
<input name="input1" message="tns:asnMessageOperationRequest"/>
</operation>
</portType>
<plnk:partnerLinkType name="asnMessage">
<!-- A partner link type is automatically generated when a new port type is added. Partner link types are used by BPEL processes.
In a BPEL process, a partner link represents the interaction between the BPEL process and a partner service. Each partner link is associated with a partner link type.
A partner link type characterizes the conversational relationship between two services. The partner link type can have one or two roles.-->
<plnk:role name="asnMessagePortTypeRole" portType="tns:asnMessagePortType"/>
</plnk:partnerLinkType>
</definitions>

Now that we have all the WSDL and hence interface definitions imported we can define the BPEL Process and hence the Workflow. At this point we will not be specifying that this is a Workflow application rather it is the logical / abstract (although their are physical mappings) implementation of the process and it will only be converted to a concrete physical implementation in the next step "WLMPOCompositeApp".

To create the BPEL Process we must execute the following:
  1. Right Click "Process Files"->New->BPEL Process



  2. In the Wizard set the Name to POWorkflow.



  3. Open the POWorkflow.bpel (if not open).
  4. Drag the poMessage.wsdl onto the left swim-lane of the canvas and name the Partner Link "plPOMsgIn".
  5. Drag the  asnMessage.wsdl onto the right swim-lane of the canvas and name the Partner Link "plASNMsgOut".
  6. Drag the WLMPO.wsdl onto the right swim-lane and name set the following:
    1. Name : plAcceptPO
    2. Partner Link Type : WLMAcceptPOPL



  7. Drag the WLMPO.wsdl onto the right swim-lane and name set the following:
    1. Name : plCreateASN
    2. Partner Link Type : WLMCreateASNPL



  8. Drag the WLMPO.wsdl onto the right swim-lane and name set the following:
    1. Name : plAuthoriseASN
    2. Partner Link Type : WLMAuthoriseASNPL



  9. Drag the WLMPO.wsdl onto the right swim-lane and name set the following:
    1. Name : plAuthoriseASNFLSL
    2. Partner Link Type : WLMAuthoriseASNFLSLPL



  10. This will now create a fairly empty BPEL Process that contain 1 inbound Partner Link and 5 Outbound Partner Link.

    I can be seen that at this point we have not associated any of the output processes with WLM Tasks.



  11. We can now build the process and connect it as follows:
    1. Drag a receive onto the canvas and connect it to the plPOMsgIn (Double Click) Partner Link.



    2. Drag an Assign onto the canvas (Assign1)
    3. Drag an Invoke onto the canvas and connect it to the plAcceptPO (Double Click) Partner Link.



    4. Drag an If onto the Canvas (IfAcceptPO)
    5. Optional : Drag an Exit to the Else portion of (IfAcceptPO)
    6. Drag an Assign onto the If part of IfAcceptPO (Assign2)
    7. Drag an Invoke onto the IfAcceptPO below Assign2 and connect it to plCreateASN (Double Click) Partner Link.



    8. Drag an If below the Invoke (IfCreateASN)
    9. Optional : Drag an Exit onto the Else portion of (IfCreateASN)
    10. Drag an Assign onto the If portion of IfCreateASN (Assign3)
    11. Drag an Invoke onto IfCreateASN below Assign3 and connect to plAuthoriseASN (Double Click) Partner Link.



    12. Drag an If below the Invoke (IfAuthoriseASN)
    13. Optional : Drag an Exit onto the Else portion of IfAuthoriseASN.
    14. Drag an Assign onto the If part of IfAuthoriseASN (Assign4)
    15. Drag an Invoke below Assign4 and connect to plAuthoriseASNFLSL (Double Click) Partner Link.



    16. Drag an If below th Invoke (IfAuthoriseASNFLSL)
    17. Optional : Drag and Exit onto the Else portion of the IfAuthoriseASNFLSL
    18. Drag an Assign onto the If fortion of the IfAuthoriseASNFLSL (Assign5)
    19. Drag an Invoke below Assign5 and connect to plASNMsgOut (Double Click) Partner Link.



    20. Save and we will now have a BPEL that look like:



We now need to add the mappings to the Assigns and the conditions to the If statements. Essentially these are the same (this is after all a simple Process) and hence I will document only 2 Assigns and 1 If leaving you to do the rest.

Assign1



Assign3



IfAcceptPO



Because of the issue at the time of writing concerning the Attributes I have added the Element ApprovalResult and hence the mapping should be:




Once the Mapping has been completed we can Clean and Build the project then move onto the next part "WLMPOCompositeApp".

WLMPOCompositeApp


The WLMPOCompositeApp is used to link the Abstract BPEL Module to a number of physical concrete end points. To create the Composite Application we will need to do the following:
  1. File->New Project->SOA->Composite Application.



  2. Next
  3. Name : WLMPOCompositeApp



  4. Finish
This will create a new Composite Application and open the WLMPOCompositeApp.casa. Close the WLMPOCompositeApp.casa file. Add the WLMPOBpelModule and WLMPOWorklistApp to the JBI Module. This is done by Right Clicking the "JBI Modules" and selecting add. Once this has been done Clean & Build the project.

Open the Service Assembly and you will notice that a number of default connections have been created as follows:



Delete these connections and map as follows:



You will notice that the plPOMsgIn Partner Link has two inputs; a JMS and SOAP Input. The reason for this is so that I can quickly add a Web Service based test call.

You will now need to configure the casaPort Parameter to match your JMS Server (or what ever input / output you choose). For my example see the attached project.

We can now Clean, Build and Deploy the project, I assume that the wlm engine has been configured correct (see previous blog entry) Configuring WLM SE to use Open DS.

Worklist Web Application


The Worklist Application can be downloaded from the Resources and configured as described in Configuring WLM SE to use Open DS. Once deployed it can be accessed through the following URL http://localhost:8080/WorklistWebApplication/wlm-jsp/wlmEntry.jsp.

Executing a Test call of the SOAP Input will initiate the following process:

  1. Initial "Accept PO" WLM Activity will be assigned to the user ahopkinson.



  2. Once completed the POWorkflow.bpel will continue and an Activity will be created for aknight.



  3. When this Activity have been completed the POWrokflow will continue and an Activity will be raised for the Group FAST. This will be accessible by all member of the FAST Group.



  4. On completion of this Activity the POWorkflow will continue to its last WLM Task and raise an Activity that is Assigned to the Managers Group.



  5. Once completed the POWorkflow will write a record to the qASNOut Queue and terminate.

You will notice that you have the option to modify the "Approval Action" to Rejected. Doing this will terminated the process.

The Complex type for PO and ASN contains a Attribute called Accept. This was initially meant to perform the same actions as the ApprovalResult Element but because of a bug at the time of writing this blog entry we are unable to assign a value to this and hence check it in the bpel process.


Build Video





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