Question
American Express
US
Last activity: 15 Dec 2015 5:05 EST
Change class group and work type classes
Hi , I recently started working on an application which dint have the most optimized design. In current design , the class names do not reflect the organizational hierarchy , so we have to change the class name of the worktypes.
Also all worktypes seem to be defined as class groups. Hence we want to club them at work level class group and define all work type classes as belongs to the class group,
This application is currently in Production and hence these changes might impact the work objects and the linked tables like assignments , history , attachments etc.
Has anyone experienced this scenario and are there any best practices to handle this ? Can we update the pzinskeys in assignment objects to reflect the new class group etc.
Regards,
Prasad
Pegasystems Inc.
IN
Hi Prasad, Good Morning!
- learning's from the use case
- app is in production
- now want to restructure classes (class groups/instances) for an optimal design...
- would it make sense to leave old classes as-is & create a new application with desired optimal class structure?
- on consumption of new version - the old school of case creation (application/work flow/classes) will be disabled (deprecated).
- in flight cases will be processed to its resolution & new cases will be created in the model of latest app version
Please share your thoughts/comments, Thank you!
psahukaru
Pegasystems Inc.
US
Hi Prasad,
I agree with Phani. I would caution against changing the underlying class structure of your production items. There are just too many opportunities for something to go wrong with your production data. Certainly, if you refactor your class structure, you can close off all avenues from the portals for making new items in the old class structure and let the existing ones run their course. Having this parallel data structure will make reporting challenging, but otherwise, I can't think of any obvious problems you'll run into.
If you change the class of in flight items, you don't just need to update the pzInsKey, you'll need to update all the class references on the work objects, on the assignments, on queue items, on SLA items, on link-attach items, on history items. I'm sure I'm forgetting several others and of course if you get any wrong, that will result in problems of varying degrees of difficulty to debug.
Thanks,
Mike
American Express
US
Hi Phani,
Currently we have 2 implementation layers , one for US and one for other regions. We want to remove those layers and put all of them as subclasses under one implementation layer inheriting from one framework layer,
With this a single user can access different regions based on his skillsets and access roles. Also the WOs are currently being saved in different tables and we want them to go into the same table based on class group for efficient search.
If we dont touch inflght cases , how will users be able to search for them especially when they are in a different implementation layer? Let me know your thoughts.
Regards,
Prasad
Pegasystems Inc.
IN
Hi Prasad, Good Morning!
I could be missing part of the use case, but could you please help me learn...
>>> If we dont touch inflght cases , how will users be able to search for them especially when they are in a different implementation layer?
- until the workobject is resolved-* it will be in its own table. later the workobjects can be dumped to the current worktable (if there is no change in schema/constraint violations) or
- saved into reports table for future reference/search.
>>> put all implementations/layers as sub classes under one implementation layer inheriting from one framework layer...
- if customer is looking only for US region specific assets/application - how would it be?
search and maintenance of region specific implementation layers are the reasons to refactor the production deployed application?
Sorry if questions/answer donesn't make sense, but interested to learn the use case. Thank you!
psahukaru