| Author |
Message
|
| mehedi |
 Posted: Thu Oct 16, 2003 1:00 pm Post subject: MQworkflow API - assigning workitems to users |
 |
|
Centurion
Joined: 11 Nov 2001
Posts: 102
Location: PSTech
|
This is the sequence of operations used by the application to assigns WorkItems between users.
1--------------------------
// getting the workitem decision
checkInOutput.setString ( Constants.WORKFLOW_WORKITEM_DECISION,
(String) htWorkItemDecision.get (
decision ) );
2-----------------------------------------
// If specific user is not null
// Set the ACTIVITY_INFO_PEOPLE in the WorkItem as the specific user.
checkInOutput.setString ( Constants.ACTIVITY_INFO_PEOPLE,
specificUser );
3-------------------------------
ReadWriteContainer checkInOutput = getOutputContainer ( eoeWorkItem,
decision,
specificUser,
SIDBean );
4-------------------------------------
// Check in the WorkItem
workItem.checkIn ( checkInOutput, 0 );
The activity_info_people is not being set.This was confirmed using the Container methods available.
Why doesn't it work and what will work.?
_________________
Thanks
Mehedi Hashir
mhashir@hotmail.com |
|
| Back to top |
|
 |
| jmac |
| Posted: Fri Oct 17, 2003 5:17 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
It is difficult to know exactly what you are doing, since it appears that you are wrapper code and not the actual API.
If I understand what you are saying the problem is that you are setting _Activity_Info.people to a valid userid and the activity is not being sent to that user.
How did you verify that the output container of the activity contained the data? I assume that somehow you have seen that the right data is in the appropriate field.
Now, the most likely issue: IS the data in the Input container of the activity you are attempting to start? If not you probably never mapped it there.
If the data is there, then check to see how you have the activity staffed, you should use "from Predefined" to get the staffing you wish.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| mehedi |
| Posted: Fri Oct 17, 2003 8:38 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2001
Posts: 102
Location: PSTech
|
Looks like we have the answer.Here is what we have figure out till now
If PERSON 'A' is transferring a workitem to PERSON 'B'
Then 'B' should be on the "authorized for workitems" list of 'A'.
If you use the workflow client and execute a transfer a workitem
you will find you can onky transfer the woritem to users of the dropdown list of the TO column.
The TO column is populated with users on the "authorized for workitems"
list.
_________________
Thanks
Mehedi Hashir
mhashir@hotmail.com |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Oct 17, 2003 10:10 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
A user can only transfer from/to users to whom they have Workitem authorization. This can be to specific users, or ALL users, but must be set in buildtime. The only user by default that has access to all is your System Administrator (ADMIN usually)
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| mehedi |
| Posted: Fri Oct 17, 2003 10:34 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2001
Posts: 102
Location: PSTech
|
oops i posted that incomplete - here is the post again
Looks like we have the answer.Here is what we have figured out till now
If PERSON 'A' is transferring a workitem to PERSON 'B'
Then 'B' should be on the "authorized for workitems" list of 'A'.
If you use the workflow client and execute a transfer a workitem
you will find you can only transfer the workitem to users of the dropdown list of the TO column.
The TO column is populated with users on the "authorized for workitems"
list.
John,
You correctly assesed what we were trying to accomplish.
To find out the values in the container elements we used the container object methods like (leaves() & toString()).
Here is what is really grey areas(which we think is related to the authorizations if it is then the API has deficiencies in reporting this back to the application).
The same code works for some users but not others.For some users (with the right authorizations the _ACTIVITY_INFO.People element is populated by the setString(see previous email) method, for some users without authorizations it is not. The setString method doesn't return completion values (ie succesfull or not etc). This means the application cannot handle this situation
The activity was staffed "from predefined". |
|
| Back to top |
|
|
| jmac |
| Posted: Sat Oct 18, 2003 5:50 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
EVERY mqwf api call returns a status.
I am not sure what you are saying... I think you are saying that setting container items requires authorization. This is definitely not true. If you can access the workitem, you can set its container items.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| mehedi |
| Posted: Fri Oct 24, 2003 11:39 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2001
Posts: 102
Location: PSTech
|
John,
This is how we figured it works
(a)if a user 'ABC' is not authorized for a workitem and the _ACTIVITY.INFO.People variable is set to 'ABC' the api call completes succesfully and the workitem will be assigned to the owner/starter of the process instance
(b) if a user 'ABC' is authorized for a workitem and the and the _ACTIVITY.INFO.People variable is set to 'abc' the api call completes succesfully and the workitem will be assigned to the owner/starter of the process instance - if you missed the intent of the above statement USERID's in workflow are case sensitive
The api call will throw an FMCException if the call is not succesfull.
In cases like above it complete succesfully but the application is not informed(via warnings etc) something different from what was requested was done.
Thanks for all the help
_________________
Thanks
Mehedi Hashir
mhashir@hotmail.com |
|
| Back to top |
|
|
| Ratan |
| Posted: Fri Oct 24, 2003 11:53 am Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
I am confused with what you are trying to do.
If you are setting The ActivityInputContainer __ACTIVITY.INFO.People to some value (UserID), it is at that point that Workitem authorization is given to that user. So I dont really understand when you say having authorization already and setting _Activity.INFO.People.
_________________
-Ratan |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Oct 24, 2003 12:08 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
| mehedi wrote: |
This is how we figured it works
(a)if a user 'ABC' is not authorized for a workitem and the _ACTIVITY.INFO.People variable is set to 'ABC' the api call completes succesfully and the workitem will be assigned to the owner/starter of the process instance |
What API call are you talking about. _ACTIVITY_INFO.People being set to "ABC" would assign the workitem to user ABC assuming that you have indicated that you wish to do your staffing "From Preddefined fields.
| mehedi wrote: |
(b) if a user 'ABC' is authorized for a workitem and the and the _ACTIVITY.INFO.People variable is set to 'abc' the api call completes succesfully and the workitem will be assigned to the owner/starter of the process instance - if you missed the intent of the above statement USERID's in workflow are case sensitive
The api call will throw an FMCException if the call is not succesfull.
In cases like above it complete succesfully but the application is not informed(via warnings etc) something different from what was requested was done. |
Maybe I am just confused as to what you are saying, but I really don't see the issue. What API call are you referring to?
It seems that you are getting the results that you expect, so I guess thats good.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
|
|
