10/22/2021 Exception: Cannot route task.
The group contains no users - Cases - IBM Support
TS006661256 - Exception: Cannot route task. The group contains no users
Case history
23 Sep 2021
09:35 AM CDT JOESTEW1 (IBM) changed Status from IBM is working to Closed by IBM.
09:34 AM CDT JOESTEW1 (IBM)
Thank you for working with us. I hope you were satisfied with the handling of this case.
If you have any further questions, you can reopen this case any time in the next 30 days.
If you need assistance on another issue, please open a new case with IBM.
If you receive a survey from IBM after this case closes, please take a few minutes to
respond. Your candid feedback is extremely valuable as we strive to deliver the best
technical support possible and exceed your expectations.
Thank you for using IBM
15 Sep 2021
06:30 AM CDT JOESTEW1 (IBM)
Hi Abdullah; the group is generated by the action in point 3.
10 Sep 2021
02:59 AM CDT JOESTEW1 (IBM) changed Status from Waiting for IBM to IBM is working.
12:47 AM CDT Abdullah Khan (Customer) changed Status from Awaiting your feedback to Waiting
for IBM.
12:47 AM CDT Abdullah Khan (Customer)
Hi Joe,
Can you explain point 4-"If you use one of the APIs you can add / remove members
from the generated group(s)."
How can we find this generated group, add the user there directly to add membership
and using what api?
Regards,
Abdullah
8 Sep 2021
07:42 AM CDT JOESTEW1 (IBM)
Hi Abdullah;
Joe here; looking for an update or clarification on the below?
Thanks for confirmation Abdullah, I would like to make the below observations and
suggested fix attempt:
1. The first time a team filter service is called and returns a specific set of users, a new
user group is created in the DB and returned as the one to use.
2. A subsequent call to the filter service that returns the same users will re-used that
initial group. I have reason to believe this matching is done based on a hash of the
returned users.
3. A subsequent call to the filter service that returns a different set of users will make a
new group (assuming that answer wasn't previously given) and return that new group.
4. If you use one of the APIs you can add / remove members from the generated
group(s).
5. If you then call the filter service and it still returns the list that it initially returned
(e.g. in 1 above) that group is returned even though its current membership doesn't
match the value the filter service is returning.
At i t th i t th TFS ll d d t d th t d l
https://www.ibm.com/mysupport/s/case-history-print?caseId=5003p00002YqxgSAAR&sortOrder=DESC 1/4
10/22/2021 Exception: Cannot route task. The group contains no users - Cases - IBM Support
At some point on the environment the TFS was called and returned the expected value -
[user1] that you want. Later through some mechanism, this user was removed from the
group. This could have been via the APIs or a direct DB manipulation. So now when
you respond with [user1] the TFS is pulling the group whose hash matches that output,
but whose membership does not.
You can prove this out via one of the following mechanisms -
In Dev - Create a simple solution with a BPD, a Task, a TFS, and the API calls needed
to remove a person from the generated group. Issue the task that uses the TFS. This will
create the group. Find the group, delete the 1 person in it, and then run the BPD again.
You should see the same behavior you describe above.
In the bad environment - make the API calls to add user1 to the targeted group, then run
the BPD. It is likely this will fix the problem.
We'd love to hear back if this helps.
Kind Regards,
Joe
2 Sep 2021
08:47 AM CDT JOESTEW1 (IBM)
Thanks for confirmation Abdullah, I would like to make the below observations and
suggested fix attempt:
1. The first time a team filter service is called and returns a specific set of users, a new
user group is created in the DB and returned as the one to use.
2. A subsequent call to the filter service that returns the same users will re-used that
initial group. I have reason to believe this matching is done based on a hash of the
returned users.
3. A subsequent call to the filter service that returns a different set of users will make a
new group (assuming that answer wasn't previously given) and return that new group.
4. If you use one of the APIs you can add / remove members from the generated
group(s).
5. If you then call the filter service and it still returns the list that it initially returned
(e.g. in 1 above) that group is returned even though its current membership doesn't
match the value the filter service is returning.
At some point on the environment the TFS was called and returned the expected value -
[user1] that you want. Later through some mechanism, this user was removed from the
group. This could have been via the APIs or a direct DB manipulation. So now when
you respond with [user1] the TFS is pulling the group whose hash matches that output,
but whose membership does not.
You can prove this out via one of the following mechanisms -
In Dev - Create a simple solution with a BPD, a Task, a TFS, and the API calls needed
to remove a person from the generated group. Issue the task that uses the TFS. This will
create the group. Find the group, delete the 1 person in it, and then run the BPD again.
You should see the same behavior you describe above.
In the bad environment - make the API calls to add user1 to the targeted group, then run
the BPD. It is likely this will fix the problem.
We'd love to hear back if this helps.
Kind Regards,
Joe
08:47 AM CDT JOESTEW1 (IBM) changed Status from IBM is working to Awaiting your feedback.
07:59 AM CDT JOESTEW1 (IBM) changed Status from Waiting for IBM to IBM is working.
06:14 AM CDT Abdullah Khan (Customer)
Hi Joe,
We are getting this error whenever a task is assigned to the specific users. The instance
works fine until the task is assigned to them. Please note that these are the LDAP users
and are not created through BPM.
Task is being assigned to the user via the "team filter service" attached to the task.
Below is script:
var newTeamSize = 0;
tw.local.filteredTeam = new tw.object.Team();
https://www.ibm.com/mysupport/s/case-history-print?caseId=5003p00002YqxgSAAR&sortOrder=DESC 2/4
10/22/2021 Exception: Cannot route task. The group contains no users - Cases - IBM Support
f j ()
tw.local.filteredTeam.members = new tw.object.listOf.String();
var user = tw.system.org.findUserByName(tw.local.forwardUser);
tw.local.filteredTeam.members.insertIntoList( newTeamSize++ , user.name
(https://user.name));
We didn't specify any group in the team filter service so please confirm why it is
throwing "group contains no user" error and if its lookup the user from group then from
where it is fetching. Kindly check the attached Team_Filter_Service.docx file.
Regards,
Abdullah
06:10 AM CDT ECUREP (IBM) changed Status from Awaiting your feedback to Waiting for IBM.
1 Sep 2021
03:49 AM CDT JOESTEW1 (IBM)
HI Abdullah,
Following up on this:
I notice from your group membership screenshot - there is a red icon - That is to indicate
that those groups are BPM groups .. created in BPM PAC or by BPM Javascript API).
Sometimes there can be some confusion in that REST API view when you have not
selected the "Include Internal Memberships" checkbox.
Without that checkbox selected you will get the "friendly name" (actually known as the
"display name") of Teams, instead of their full names that include Snapshot context.
I will also ask - when you are doing your UserDetails REST API after removing or
adding a user from the Dynamic Group - are you checking the "Refresh User"
checkbox? I would consider that necessary to force BAW to simulate a login of the user-
of-interest, since a login of a user causes that user's group membership to get refreshed.
Regards,
Joe Stewart
IBM BPM/BAW/Workflow Support
30 Aug 2021
08:49 AM CDT JOESTEW1 (IBM)
HI Abdullah,
I notice from your group membership screenshot - there is a red icon - That is to indicate
that those groups are BPM groups .. created in BPM PAC or by BPM Javascript API).
Sometimes there can be some confusion in that REST API view when you have not
selected the "Include Internal Memberships" checkbox.
Without that checkbox selected you will get the "friendly name" (actually known as the
"display name") of Teams, instead of their full names that include Snapshot context.
I will also ask - when you are doing your UserDetails REST API after removing or
adding a user from the Dynamic Group - are you checking the "Refresh User"
checkbox? I would consider that necessary to force BAW to simulate a login of the user-
of-interest, since a login of a user causes that user's group membership to get refreshed.
Regards,
Joe Stewart
IBM BPM/BAW/Workflow Support
08:49 AM CDT JOESTEW1 (IBM) changed Status from IBM is working to Awaiting your feedback.
07:38 AM CDT JOESTEW1 (IBM)
Hi Abdullah;
My name is Joe and will be taking ownership of this case. Allow some time for review
and will update accordingly.
Kind Regards,
Joe
07:38 AM CDT JOESTEW1 (IBM) changed Status from New Case to IBM is working.
07:10 AM CDT Abdullah Khan (Customer) created this case
https://www.ibm.com/mysupport/s/case-history-print?caseId=5003p00002YqxgSAAR&sortOrder=DESC 3/4
10/22/2021 Exception: Cannot route task. The group contains no users - Cases - IBM Support
https://www.ibm.com/mysupport/s/case-history-print?caseId=5003p00002YqxgSAAR&sortOrder=DESC 4/4
