A common use case for IBM Case Manager solutions is to have a manager assign a user from a role to handle a specific work item. Moving the item into the user's personal inbox is often undesirable due to the loss of easy access to the item once it goes there. By adding a "handler" property to the work item and displaying it in the In-basket allows both assignment and visibility. The trick then becomes "How do I easily display just the current user's assigned items from a shared In-basket queue?".
The IBM Case Manager In-basket widget can be configured to include user settable filter values where the user can enter a value for a column that will cause only work items with that value to be displayed. By default, the user must manually enter the filter value every time.
Dynamic in-basket filtering events to the rescue!
The IBM Case Manager 5.1 in-basket added a new inbound event that allows the user filter values to be set pro grammatically. Let's explore how that works.
Here's what the event payload looks like to set a couple filter values:
{"queueName":"WID_ClaimUnderwriter","inbasketName":"Admin Tasks","hideFilterUI":false,"filters":[{"name":"Filter1","value":"p8admin"},{"name":"Filter2","value":"high"}]}
One really important thing to note in the event above is that the filter name is specified by its internal name, not its display label.
You can't see what internal name is created for you in the Case Builder UI, but there are two ways to find out what they are - look at the in-basket in Process Designer/PCC or send the In-basket selected event to the Script Adapter and look at its payload. The In-basket selected event is fired when the in-basket fire loads and also when the user clicks to another in-basket tab. Here's a snippet of what that event look like.
{"inbasketCount":2,"currentInbasket":"Admin Tasks","queueName":"WID_ClaimUnderwriter","appSpaceName":"Claims Processing","currentRoleName":"Admin","filters":[{"operator":0,"attributes":"queues/WID_ClaimUnderwriter/workbaskets/Claims/filters/Filter1/attributes","customAttributes":{},"type":2,"name":"Filter1","description":"","_key":"Filter1","displayName":"Assign To User"},...
You can see in the payload above that the internal name for the filter is actually Filter1. Passing an incorrect value will cause the event to simply be ignored.
Add a Script Adapter to the hidden widgets area of your page and wire it as shown below.
Configure the Script Adapter widget with code like the following. It uses the Get Current User tip we showed you previously to only show the items assigned to the currently logged on user.
var PEConnectionPt = ecmwdgt.getBean("spaceConfig").getPEConnectionPoint(); var serverBase = window.location.protocol + "\/\/" + window.location.host; var getUserURL =serverBase + "/CaseManager/P8BPMREST/p8/bpm/v1/currentuser?cp=" + PEConnectionPt; var xmlhttp= null; xmlhttp= new XMLHttpRequest(); xmlhttp.open('GET' , getUserURL , false); xmlhttp.send(); myResObj = eval('(' + xmlhttp.responseText + ')'); var myUser = myResObj.name; var filter= { "queueName":payload.queueName, "inbasketName":payload.currentInbasket, "hideFilterUI":true, "filters":[ { "name": "Filter1", "value":myUser } ] }; return filter;
Comentários (5)
This works great and I added a document in the file section that gives the complete step by step of how to make this work.
For a full documentation on how to implement this feature, go to this link in the file section of this community. <div> </div> Dynamic Filters Documentation - Assign To User Filter.docx <div> </div> https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/communityview?communityUuid=e8206aad-10e2-4c49-b00c-fee572815374#fullpageWidgetId=Wf2c4e43b120c_4ac7_80ae_2695b8e6d46d&file=65f06ef6-ac14-4625-a0b9-3e8253fb3025
Dave, <div> </div> great post and you can do so many more stuff going from this! I was ust wondering what is the best practice from a performance viewpoint. Should you use the script adapter and the ability to transform payloads or create your own widgets to do this? <div> </div> Cheers, <div> </div> Patrick
Hi Dave, <div> </div> great post. Just wondering from a performance perspective what is best practies. Would you recommend the Script adapter's ability to execute some custom Javascript or create your own Widget. Keeping in mind the best practie of not having more than 6-8 widgets on one page, which is stated in IBM's documentation (somewhere). <div> </div> Thanks, <div> </div> Patrick
Thanks Dave, very handy... it has some shortfalls though that may cause issues in a production environment where you don't want users to be able to change the userid in the filter themselves, or remove it entirely, and see other people's work. There is a hideFilter parameter that can be passed in with the filter object, but that doesn't allow you to filter on just the parameter you are setting.... it hides the entire dynamic filtering mechanism(!) which means users can no longer use any other valid filters they might need. As far as I could tell there was no good way to just hide that one particular filter, which would be a very handy feature indeed in this case.