Last activity: 9 Aug 2016 2:27 EDT
pc_assign_workbasket & worklist tables for implementation layers
We are using Pega 7.2. Can we have separate pc_assign_workbasket & worklist tables for implementation layers
***Updated by Moderator: Vidyaranjan. Removed user added Ask the Expert and #helpme tags. Apologies for confusion, shouldn't have been an end-user option***
All layers should share the same tables for assignments.
It is causing performance impact with regards to Get Next Work. Also some of our LOB's do not want to share same tables and DB. Is there an option to seperate the assignment tables based on implementation layer?
So how you are planning to improve the performance by using a different table for those 2 classes? Is your DB is shared by multiple applications?
If I am not wrong Pega uses List view to get the list of assignment, You can use RDB list, that will save some time. You can even customize the get next work activity and comment out the unrelated steps. Like if your Get next always used for work basket then you can comment the step to check the work list.
We are having different work DB for the implementations of different LOB's. Performance is one of the concern. The main concern is, we have a requirement to not mix up commercial business data with Govenrment business data and hence we are looking for an option to have work list and work basket tables per implementation layer. Is it possible?
You can map the workbasket or worklist to a different table but that will not help. Changing the table name will not change anything. If you create one child class of worklist and workbasket and map it to a different table then the number of rows will be decreased and performance should be improved. But doing so you need to customize all logic related to transfer, get next, assignment pulling. I dont think its feasible.
What you can do is have a table where you store the data you need for get next and then custmize the get next only.
Experts - please confirm the feasibility of having seperate WL/WB tables per implementation layer
I'm not aware of anyone ever doing that, so I can't say what trouble you might run into. Theoretically, you can definitely map classes to specific tables, but I believe assignment objects live in the OOTB assign-worklist or assign-workbasket classes, directly. Changing them to be in a differnt class would probably require changes to the process engine itself. That would definitely be an enhancement request.
What is the concern coming from the LOBs? Is it performance? Security? If your concern is performance, as was suggested, you could create views or indecies in your database that would represent specific subsets of the contents of the assignment tables and then cusotmize get next work to use those instead. For security, you can use things like access-deny rules to keep users away from data they shouldn't have access to without needing to rearchitect the system internals.
Overall, without some clear understanding of what it would get you that can't be accomplished through other mechanisms, I would say it's probably not a good idea since it is outside the guardrails and likely to break a number things.
Thank you mike for your response. The concerns were security and performance. We will try the options you suggested for them.