Processing assignments from a different application creating items with incorrect prefix
I'm having issues where work items are being created with the wrong prefix. They are being created with a default C- prefix. Everything works correctly when I create/update items where the work item is defined (let's call this Application A). I've created a common "support" monitoring application (let's call this application B) where we want to monitor several applications. From App B we would like to perform admin tasks to do things like retry a service call and continue the flow. From App B I can find work that we've routed to support work basket and use actions. However, when the flow reaches the next assignment shape the pxApplication property of the assignment is set to "Application B". Subsequently when the flow tries to create a child item the prefix is not correct.
When I do the same thing from Application A the assignment's pxApplication property is set to "Application A" and the child item is created with the correct prefix. This is expected since the parent and child item are defined in this application but I'm not sure how to explain why this does not work from Application B.
Application B has access to Application A's rules and I can action the items but I'd like some help explaining why the outcome is unexpected.
PEG
US
Unless you've customized something, the activity GenerateID is what gets the new ID. There are quite a few versions of this activity, include one in Work- and one in Work-Cover-.
There is a parameter param.IDPrefix that is used if it is not blank -- otherwise, certain defaults are used.
I suggest you run with the Tracer enabled and see who is calling this activity in the "unexpected" case, and if this parameter has a value when running in Application B.
Pega
US
Hi Ron,
We have not customized GenerateID or updated anything to override the prefix. We have set the prefix on the application record's cases & data tab in Application A. We have NOT defined the same in Application B's app record.
I'm under the assumption that one application can't perform work for another. Is that the correct assumption?
In this use case the flow in Application A may encounter an issue, trap the error and route the work to a support workbasket. For example a REST service fails and we want to put the work item on the system admin's work list so they can investigate and fix the issue. The system admin does not have access to application A so we created a separate application (Application B) where the admin can monitor the system looking for issues like this. After fixing the REST service the admin clicks a retry flow action on the work item (from Application B). The flow action ends on an assignment where Application A will eventually resume from. Since this assignment was created by Application B it seems to cause issues resulting in the prefix being the default "C-"
Should this sort of use case work correctly? Does Pega allow cross application work like this? Should I define this prefix in application B too?
Pega
US
By updating the Support application's Cases & data tab (App B) to include the prefixes used by App A we've addressed most of the issue. Work items are now created with the correct prefix. However, I have a secondary concern.
In the process of Retrying the failed task the Support application queues a request for one of the agents in App A. The queue record has pxApplication = "IVYSupport". Since the queue record references a different application the agent defined to Application A runs in a different context (IvySupport) and subsequently all additional tasks are queued with the wrong application.
Is there a way to force the agents that run in Application A to always use the right value for pxApplication? Can I problematically set the application. These agents belong to Application A and should never run under a different context. All I want to do is trigger some work for them from my support app.
Cognizant
IN
I believe we are trying to process assignments that are in the monitored applications (in our case Application-A) from an application that is monitoring other applications (called support application 'aka' Application-B).
In this case the support application is attempting to retry the assignment via agents that are present in Application A. This should not be our approach.
Support application should not attempt to queue a task for an agent that belongs to Application A however Support application can request Application A to do a task for it.
This is possible if we can achieve the following 2 things...
ONE # The support application should be alerted when a case reaches the support workbasket in Application A and this prompts the support application to react (OR) the support application could proactively monitor the support workbasket in Application A for detecting the arrival of any new assignments.
TWO # When the support application becomes aware of an assignment in the support workbasket in Application A; it should request Application A to retry it. This could be a REST request. The request should hold the necessary details for Application A to attempt a retry and send back the outcome to support application.