| Author |
Message
|
| apdutta |
 Posted: Fri Feb 10, 2006 3:02 am Post subject: parallel branching with 'end if any 1 active incoming true' |
 |
|
Novice
Joined: 14 Dec 2004
Posts: 11
|
I have a process which has 3 Activities.
Activity 1 -> Activity 2 -> Activity 3
------------> Activity 2 ->------------
------------> Activity 2 ->------------
Activity 1 is a Create Activity. It is assigned to a particular person. That person creates a transaction.
Activity 2 is a Review Activity. It is assigned to a set of reviewers.
Activity 3 is a Finalize Activity. It is assigned to a new person.
We need parallel branching of Activity 2. So, after activity 1 is over, Activity 2 task Item is assigned to multiple persons. All persons work in parallel. These reviewers have two options. They can mark the work done during create as 'pass' or 'reject'.
Possible Scenarios:
1. If say all reviewers mark their work items as 'Success' then the process moves to activity 3.
2. Some reviewers marks their work items as 'success'. One reviewer marks his work item as 'reject'. As soon as the work item of the person who has marked his work item as 'reject' is checked in, the process must remove the activity 2 work items from remaining reviewers(who had not completed activity 2 work item). Also, a notification needs to be sent to all reviewers saying that a particular user has marked 'reject'. Then, the process should move to activity 3.
Please let me know if I can model a process wherein such a behavior (Scenario 2) would be possible. |
|
| Back to top |
|
 |
| elvis_gn |
| Posted: Fri Feb 10, 2006 3:37 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi apdutta,
You can create a Block activity and define the users of activity2 as the members of a role and then assign the role to the block activity itself.
I dont remember if you can check if all members of a role have accessed an activity, if it cant be done, then assign all the users to a variable in the workItem itself and delete one by one as and when they complete.
Put the exit condition of the Block as the variable being Null or something.
The notification can be based on the mail option in workflow.
Regards. |
|
| Back to top |
|
|
| supreeth |
| Posted: Fri Feb 10, 2006 4:12 am Post subject: |
|
|
Voyager
Joined: 17 May 2005
Posts: 90
Location: London
|
Hi,
I dont think having a block in between is a good idea. blocks incur an overhead of some BWUs.
I would suggest to have another intermediary activity node, which you can make it automatic. This automatic activity can check for what happened to the review nodes.
Diagramatically describing it,
Activity 1 -> Activity 2 ->
Activity 2 -> IntermediaryNode -------> Activity 3
Activity 2 ->
Thanks and Regards,
Supreeth
_________________
Supreeth Gururaj
IBM Certified WMQ Solution Expert |
|
| Back to top |
|
|
| Ratan |
| Posted: Fri Feb 10, 2006 12:39 pm Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
There is no need of a block just have an exit condition for Activity2 like elvis_gn explained (instead of having a block).
Activity2 should be assigned to each reviewer at a time. you cant have all the reviewers work on it in parallel. If a reviewer rejects exit out of the activity. I dont think you will have to notify all the reviewers of rejection because they wont have access to that workitem anyway.
elvis_gn's approach is what I would take except for the block, as there is no need for it (Blocks are needed if the activities inside the block have to start automatically when a exit condition fails).
Supreeth's approach will not work with out having a block.
_________________
-Ratan |
|
| Back to top |
|
|
| supreeth |
| Posted: Sun Feb 12, 2006 3:10 am Post subject: |
|
|
Voyager
Joined: 17 May 2005
Posts: 90
Location: London
|
Hi,
I was not actually able to get as to why the intermediary node approach doesnt work without a block. I could be wrong too but as far as my understanding goes, we can have transition conditions for the 3 connectors joining Activities2 from Activity 1. any or all of the activities can be spawned based on the transition condition.
I think we cant eliminate the parallel spawning of the activities if its a requirement and should be able to cater to it.
The only issue that could occur following the approach is that the activities could not be deleted until the control comes to the intermediary node. I dont see how can an activity node be deleted/terminated and stil pass on the control to the subsequent node.
The intermediary node checks the result as given by one or many activity 2s and evaluates a final result. The control goes on to the activity3 after the intermediate node finishes the result evaluation and intimation.
I tried pasting the flow i computed in mspaint but am unable to do so 
Thanks and Regards,
Supreeth
_________________
Supreeth Gururaj
IBM Certified WMQ Solution Expert |
|
| Back to top |
|
|
| jmac |
| Posted: Sun Feb 12, 2006 8:18 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
The issue you are referring to here, (I believe) is what was called a Bundle in the old FlowMark product. Generating two or three parallel activities as you do in the sample (based on my reading) is not an issue and can be done with tranisiton conditions in the process model. The bigger issue is when you have to generate "n" parallel activities, and "n" is not known until runtime.
There are ways to "simulate" the old Bundles from FlowMark in MQWorkflow, but they are all quite expensive in performance terms as they involve recursive subProcesses.
I am not sure I understand the initial requirement, so I may be off base here.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| apdutta |
| Posted: Mon Feb 13, 2006 12:59 am Post subject: |
|
|
Novice
Joined: 14 Dec 2004
Posts: 11
|
Let me rephrase my need.
I am pasting a simple FDL file to make my needs clear. I dont know how to upload a file.
A. I need parallel branching for Activity 2. I know already how many parallel branches I need. Its not variable at runtime.
B. In each of the branches, there is a leaf in the data structure(ECOData.ECOAction) which is used to determine whether user is marking that activity as 'pass' or 'reject'.
My need is that
a. in case all users checkin the activity 2 tasks with ECOData.ECOAction = 'pass', then the control should flow to next activity i.e. SinkNode and the process completes successfully.
b. in case any one user checksin the activity 2 task with ECOData.ECOAction = 'reject', all activity 2 tasks if remaining in task list of any other user should be deleted. Additionaly, we need that at that point all users must be sent a notification that one user has marked his activity 2 'reject'.
-----------------------------------------------------------------------------
This is my FDL File ::::
-----------------------------------------------------------------------------
/*
*
* FDL definitions generated by MQ Workflow at 2006-02-13, 2:18:51 PM.
*
*/
CODEPAGE 1252
FM_RELEASE V3R6 0
/*
* STRUCTUREs
*/
STRUCTURE 'ECOSupporter'
'ECOSupporterId': STRING
DESCRIPTION "";
END 'ECOSupporter'
STRUCTURE 'ECOOwner'
'ECOOwnerId': STRING;
END 'ECOOwner'
STRUCTURE 'ECOReviewer'
'ECOReviewerId': STRING;
END 'ECOReviewer'
STRUCTURE 'User'
'ID': STRING;
'Name': STRING;
END 'User'
STRUCTURE 'ECOData'
'ECOId': STRING;
'ECOStatus': STRING;
'ECOSupporter': 'ECOSupporter'(20);
'SMARAGDFlagSet': STRING;
'ECORecipientDefined': STRING;
'ECOAction': STRING;
'ECRId': STRING;
'ECRStatus': STRING;
'ECROwnerIdIdeal': STRING;
'ECOOwner': 'ECOOwner'(20);
'CreateECOAcceptorId': STRING;
'CreateECORejectorId': STRING;
'OptionalAttManaged': STRING;
'ImplementECORejectorId': STRING;
'ImplementECOAcceptorId': STRING;
'ECOReviewer': 'ECOReviewer'(20);
'User': 'User';
'AssignedSupporterID': STRING
DESCRIPTION ""
DOCUMENTATION "ID of the Supporter to whom the task has been assigned.";
END 'ECOData'
/*
* PROCESS_CATEGORYs
*/
PROCESS_CATEGORY 'Test'
END 'Test'
/*
* PROGRAMs
*/
UPDATE PROGRAM 'Show'
DESCRIPTION ""
STRUCTURES_FROM_ACTIVITY
NOT UNATTENDED
WINNT EXE PATH_AND_FILENAME "C:\IBM\WMQWorkflow\BIN\fmcnshow.exe"
INHERIT ENVIRONMENT
STYLE VISIBLE
START FOREGROUND
END 'Show'
/*
* PERSONs
*/
PERSON 'FTLSUPPORTER1'
DESCRIPTION ""
RELATED_ROLE 'ECOSUPPORTER'
PASSWORD %7C46EC8A807BA993AC9F614EE551AA27
IS_NOT_ABSENT
DO NOT RESET_ABSENT
GROUP 'IPDCGRP'
SYSTEM 'IPDCSYS'
END 'FTLSUPPORTER1'
PERSON 'FTLSUPPORTER2'
DESCRIPTION ""
RELATED_ROLE 'ECOSUPPORTER'
PASSWORD %334EA5C49B92E38DD328913F03DC1F91
IS_NOT_ABSENT
DO NOT RESET_ABSENT
GROUP 'IPDCGRP'
SYSTEM 'IPDCSYS'
END 'FTLSUPPORTER2'
PERSON 'FTLSUPPORTER3'
DESCRIPTION ""
RELATED_ROLE 'ECOSUPPORTER'
PASSWORD %7F965A258ABB0484E994C001BC8A2F52
IS_NOT_ABSENT
DO NOT RESET_ABSENT
GROUP 'IPDCGRP'
SYSTEM 'IPDCSYS'
END 'FTLSUPPORTER3'
/*
* PROCESSes
*/
/*
* PROCESS BranchTest
*/
PROCESS 'BranchTest' ( 'ECOData', 'ECOData' )
CATEGORY 'Test'
DO NOT PROMPT_AT_PROCESS_START
WINDOW VIEW_REFERENCE_POINT XPOS 0 YPOS 58
WINDOW SHOW ALL CONNECTORS
WINDOW SHOW TRANSITION_CONDITIONS
SOURCE 1 XPOS -700 YPOS 500
SINK 1 XPOS 800 YPOS 0
PROGRAM_ACTIVITY 'Branch1' ( 'ECOData', 'ECOData' )
START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS -100 YPOS 400
NAME_POSITION XPOS -100 YPOS 325
PRIORITY DEFINED_IN INPUT_CONTAINER
DONE_BY PERSON TAKEN_FROM 'ECOSupporter[0].ECOSupporterId'
PROGRAM 'Show'
SYNCHRONIZATION NESTED
END 'Branch1'
PROGRAM_ACTIVITY 'Branch2' ( 'ECOData', 'ECOData' )
START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS -100 YPOS 0
NAME_POSITION XPOS -100 YPOS -75
PRIORITY DEFINED_IN INPUT_CONTAINER
DONE_BY PERSON TAKEN_FROM 'ECOSupporter[1].ECOSupporterId'
PROGRAM 'Show'
SYNCHRONIZATION NESTED
END 'Branch2'
PROGRAM_ACTIVITY 'Branch3' ( 'ECOData', 'ECOData' )
START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS -100 YPOS -400
NAME_POSITION XPOS -100 YPOS -475
PRIORITY DEFINED_IN INPUT_CONTAINER
DONE_BY PERSON TAKEN_FROM 'ECOSupporter[2].ECOSupporterId'
PROGRAM 'Show'
SYNCHRONIZATION NESTED
END 'Branch3'
PROGRAM_ACTIVITY 'SinkNode' ( 'ECOData', 'ECOData' )
START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS 500 YPOS 0
NAME_POSITION XPOS 500 YPOS -75
PRIORITY DEFINED_IN INPUT_CONTAINER
DONE_BY PROCESS_ADMINISTRATOR
PROGRAM 'Show'
SYNCHRONIZATION NESTED
END 'SinkNode'
PROGRAM_ACTIVITY 'SourceNode' ( 'ECOData', 'ECOData' )
START MANUAL WHEN AT_LEAST_ONE CONNECTOR TRUE
EXIT AUTOMATIC
LAYOUT XPOS -700 YPOS 0
NAME_POSITION XPOS -700 YPOS -75
PRIORITY DEFINED_IN INPUT_CONTAINER
DONE_BY PROCESS_ADMINISTRATOR
PROGRAM 'Show'
SYNCHRONIZATION NESTED
END 'SourceNode'
CONTROL
FROM 'Branch1' TO 'SinkNode'
LAYOUT
XPOS 300 YPOS 300
XPOS 400 YPOS 300
CONTROL
FROM 'Branch2' TO 'SinkNode'
LAYOUT
XPOS 100 YPOS -100
XPOS 200 YPOS -100
CONTROL
FROM 'Branch3' TO 'SinkNode'
LAYOUT
XPOS 400 YPOS -400
CONTROL
FROM 'SourceNode' TO 'Branch1'
LAYOUT
XPOS -500 YPOS 300
CONTROL
FROM 'SourceNode' TO 'Branch2'
LAYOUT
XPOS -300 YPOS 100
CONTROL
FROM 'SourceNode' TO 'Branch3'
LAYOUT
XPOS -400 YPOS -400
DATA
FROM SOURCE 1 TO 'SourceNode'
MAP '_STRUCT' TO '_STRUCT'
DATA
FROM 'SourceNode' TO 'Branch3'
MAP '_STRUCT' TO '_STRUCT'
DATA
FROM 'Branch3' TO 'SinkNode'
MAP '_STRUCT' TO '_STRUCT'
DATA
FROM 'SinkNode' TO SINK 1
MAP '_STRUCT' TO '_STRUCT'
DATA
FROM 'SourceNode' TO 'Branch1'
MAP '_STRUCT' TO '_STRUCT'
DATA
FROM 'Branch1' TO 'SinkNode'
MAP '_STRUCT' TO '_STRUCT'
DATA
FROM 'Branch2' TO 'SinkNode'
MAP '_STRUCT' TO '_STRUCT'
DATA
FROM 'SourceNode' TO 'Branch2'
MAP '_STRUCT' TO '_STRUCT'
END 'BranchTest'
----------------------------------------------------------------------------- |
|
| Back to top |
|
|
| jmac |
| Posted: Mon Feb 13, 2006 6:33 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
The verbage you write does not match the FDL you posted, so I am still not sure what it is you want to do.
You have 5 activities, none of which is labeled Activity 2. I see 3 activities in parallel, Branch1, Branch2, Branch3. There are NO Transition conditions in your FDL.
My guess is that you need to do some research into basic MQWorkflow terminology and how it works. Read some doc, look at the samples supplied by IBM...
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| apdutta |
| Posted: Wed Feb 15, 2006 12:05 am Post subject: |
|
|
Novice
Joined: 14 Dec 2004
Posts: 11
|
Sorry If you had trouble reading it.
This was a test/experimental FDL I was working on.
In the FDL
Activity 1 = "SourceNode". Yes, I know I should have named it something else !!!
Activity 2 has the 3 parallel branches Branch1, Branch2 and Branch3
Activity 3 = "SinkNode"
Branch1, Branch2 and Branch3 are parallel branches of the same business activity.
I had initially put some transition condition and later removed it.
Please note that Branch1 is getting assigned to a user id coming in ECOSupporter[0].ECOSupporterID
Please note that Branch2 is getting assigned to a user id coming in ECOSupporter[1].ECOSupporterID
Please note that Branch3 is getting assigned to a user id coming in ECOSupporter[2].ECOSupporterID
Please let me know if this clarifies some of the issues you faced. |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Feb 15, 2006 6:35 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
I am still not sure I understand what you want to do.... this is what I am hearing now:
The 3 activities "Branch1" "Branch2" and "Branch3" are to run in parallel, and if any one of the three sets a memeber to reject you wish to kill the other 2 activities. (Note that originally I mistakenly said instances instead of activities and just noticed it....I have now edited my response sorry for any confusion) The only way to do this is programatically. I.E. you need to add code to each of the activities to kill the other 2 if rejected.
_________________
John McDonald
RETIRED
Last edited by jmac on Thu Feb 16, 2006 6:30 am; edited 2 times in total |
|
| Back to top |
|
|
| supreeth |
| Posted: Thu Feb 16, 2006 12:35 am Post subject: |
|
|
Voyager
Joined: 17 May 2005
Posts: 90
Location: London
|
Hi,
I wouldnt vote for a requirement which would allow me killing activity instances assigned to other people. You may not even know what status the activity procesing would be in since it is spawned paralelly.
I would stil go with the intermediary node design, which has a single point of control over the activities.
I dont think this is any client requirement. For academic purposes, you can, i think proceed ahead with the solution suggested by john.
Thanks and Regards,
Supreeth
_________________
Supreeth Gururaj
IBM Certified WMQ Solution Expert |
|
| Back to top |
|
|
| Ratan |
| Posted: Fri Feb 17, 2006 11:21 am Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
Supreet,
Looking at what apdutta wants, John's solution is the only way I can think of doing it. I dont see how you can address it with a intermidiary node.
_________________
-Ratan |
|
| Back to top |
|
|
|
|
