Performance impact of Open Cases
Hi,
We have a business requirement where we need to have a large number of cases (approx 1.5 Million) created and will be open for certain period of time. These cases would be updated through agent processing and a %age of those can be routed to user worklist. Rest all would be in a default work-basket and can be manually routed to users on need basis. There is a stringent SLA for agent processing which needs to be completed in 3-4 hours.
I would like to know what would be performance impact of these number of open cases and what steps can be taken to minimize the impact.
Larsen & Toubro Ltd
IN
Hey, this reminds of the large scale migration we did recently from SF into Pega. On a nutshell, we had migrated half a million customer records, and created around 1million work object and 1.2 million assignments in Pega. All the migration and case creation was done in less than 4 hrs time.
One thing you need to keep in mind, as we create assignments, it gets into shared tables(assignment table). This would straight away impact the GetNextWork, SLA processing (as it tries to query against the million records) and work indexing.
We can simplify by divide and conquer model, or extend the assignments to be stored into custom tables, and customise the assignment & SLA processing. Lots of alert threshold needs to be reviewed post processing of the cases
BUPA
AU
Hi Imthiyaz,
Which model is more preferred comparing time and best practices. If we need to follow model 1, what should be the primary criteria to divide the current data sets? If we follow model 2, there will be lot of customization involved. Will this be a Pega recommended approach? If you pls elaborate little then it will help a lot.
Larsen & Toubro Ltd
IN
This is a open ended question, mostly driven by the Client architecture in place. We have chosen to re-use the OOTB WL/WB tables, relaxed on the getnextwork functionality. However the partitions were done on the DB for the less urgent or the aged SLA's so that the highest urgent ones is readily accessible.
One of the Pega recommendations is to extend the assign classes, avoid common tables and store in specific tables, as we do for Work and history and de-rail the risk for other applications as well
BUPA
AU
Hi Imthiyaz,
Thanks for your reply. Did you mean by the partitions that you have used different tables to store the cases in DB based on SLA or other factors? In that case how the less urgent cases could be moved to actual table when user would like to open the case or work on it? Or did you over write the Case Search feature as well?