Author |
Message
|
arnab.ganguly |
Posted: Thu May 22, 2008 9:56 pm Post subject: Caputure Item Locked notification in front end |
|
|
Newbie
Joined: 22 May 2008 Posts: 5
|
I am pretty new to Workflow tool . I am using a C# front end to interact with IBM MQ Workflow . THe requirement is to disable the workitems in the frontend which are presently being edited by some other person . For this I am trying to get the workitem locked notification from MQ Workflow but have not been able to achieve this . I am receiving no notification in the listening thread when the item is opened by another person. |
|
Back to top |
|
|
arnab.ganguly |
Posted: Fri May 23, 2008 2:32 am Post subject: |
|
|
Newbie
Joined: 22 May 2008 Posts: 5
|
I forgot to add - the version I am working on is Version 3.6 |
|
Back to top |
|
|
jmac |
Posted: Fri May 23, 2008 5:11 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
I do not understand what it is you are trying to do. You use the term notification in your question, but I doubt that this is an MQWF notification. You need to explain in more detail what it is you are attempting to do. _________________ John McDonald
RETIRED |
|
Back to top |
|
|
arnab.ganguly |
Posted: Fri May 23, 2008 5:50 am Post subject: |
|
|
Newbie
Joined: 22 May 2008 Posts: 5
|
I need to get notified when the State of the Item is changed in my worklist. Say i have a Process Instance P1 which creates 2 workitems W1 for person P1 and W2 for Person P2 with the State of the workitems READY. If the Person P1 opens the workitem W1 from his worklist the state of the Workitems changes to RUNNING. I should notify the Person P2 that the state of your workitem W2 is running. As W1 and W2 are workitems created under the same ProcessInstance P1.
Iam using the C++ to interface with the IBM workflow library. |
|
Back to top |
|
|
jmac |
Posted: Fri May 23, 2008 6:50 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
Are you suggesting:
User A sees WI1 in a ready state on their worklist
User B sees WI1 in a ready state on their worklist
User A now checks out WI1 so WI1 is now in a checked out state
You want User B's worklist to immediately reflect the WI in a checked out state
If this is the case, I don't think you can do what you are trying to do very easily. It might have been possible with a fat client, but at this point the best way to deal with MQWF is using the Java api. _________________ John McDonald
RETIRED |
|
Back to top |
|
|
arnab.ganguly |
Posted: Fri May 23, 2008 10:53 pm Post subject: |
|
|
Newbie
Joined: 22 May 2008 Posts: 5
|
Yes you have got it perfectly right . I am using a fat client and that is why I would like some kind of notification from MQWF which will help me show it as checkout to the second user . I am using C++ API form MQWF. I am running a seperate thread for listening to any notifications from MQWF . I am able to get notifications like change of a workitem from one approver to the next one . But no notifications are coming in case only the state of that items changes like in this case , the workitem changes from a ready to running state or vice versa. |
|
Back to top |
|
|
jmac |
Posted: Sat May 24, 2008 5:31 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
I have not played with this for about 6 or 8 years. IIRC, you use the Receive() method and then use an ExecutionData object.
I would seriously recommend that you think through any solution like this, as it will have no path forward to WPS. You really need to stick to the Java api. _________________ John McDonald
RETIRED |
|
Back to top |
|
|
Kumarakuru |
Posted: Sun May 25, 2008 7:52 pm Post subject: Caputure Item Locked notification in front end |
|
|
Novice
Joined: 21 Jan 2008 Posts: 17
|
Hi ,
what arnab referring to is the FMCJRecieveNotification which waits on blocked call, which will evntually informs any change in the work item change (i.e., a delete or create in work list), this works fine, except that it doesnt work for Locked STATE
In short, it works for any work ITEM CHANGE, but not for the STATE CHANGE.
Is anything else needs to be addressed?
Thanks for your time |
|
Back to top |
|
|
hos |
Posted: Tue May 27, 2008 11:15 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002 Posts: 470
|
Hi,
I assume that you have read chapter 5 of the Programming Guide.
There you can find the restrictions that apply to the push data access model:
you do not get a notification of an item state change if you are the caller of the action or if the item is in state 'Disabled'.
Quote: |
P1 opens the workitem W1 from his worklist the state of the Workitems changes to RUNNING. I should notify the Person P2 that the state of your workitem W2 is running. |
This scenario should work. P2 should get a notification that W2 has changed its state from 'Ready' to 'Disabled' - if P2 is logged on as 'Present'.
Having said this, I must also mention that the usage of the Push API is discouraged. As you can only have all-or-nothing, it usually creates too much traffic and therefore hits your system performance.
MQWF users usually use other smarter solutions to avoid user clashes on the same workitem (getNext() implementations, virtual user concept, sorting and filtering, etc.). |
|
Back to top |
|
|
|