If you change class to a more specialized class that pattern-inherits or directly extends the existing case type class you would be fine. 

If you want to convert to a completely different case type class it would be best to close the case and create a new one salvaging what information you can from the original case such as a Link-Attachments.

In your example you would not only have to modify properties within pxFlow() such pxFlowInsKey and pxAssignmentKey you would also have to update the pxRefObjectKey and pxRefObjectClass properties within the assignment instance referenced by pxAssignmentKey.

Nice explanation Pedel, just adding to that, case type modification is not possible, it s better to have a new case type.  "Page-Change-Class" can be used to switch work class at runtime for the same case type.  For the same case type work instances we can set pattern inherited class or direct inherited class at runtime.

But completely changing casetype rule manually is not possible.

Direct inheritance is fine also as long as the class group does not change to where a different database table is used. 

When using the App Explorer's tree view, you can directly navigate between classes in the inheritance hierarchy when pattern inheritance is used unlike direct inheritance.

Modifying the pxObjClass to a case type outside the original case type's inheritance hierarchy would not work.  In that situation you would need to create a new case type instance

Persisting the bulk of the original case's data as Data- instances outside the case would simplify the transition plus avoid redundancy. You would only need to propagate lookup key values such as ClaimID.

Hi OnKar,

Can you help here on 2 things :

1. What is the intent/objective of changing the case-type by user ?

2. How the case-types are related with each other ?

Actual idea is to change a case type at runtime will lead to the corruption of the current case as the stages/process of the current case might conflict with a new case (if there is a way) but can you please let us understand the actual requirement?

I think it is required to change case type (with pattern inheritance) dynamically in order to achieve polymorphism. 

For an example, You have a Contest class and you have many sub classes like Cricket, Golf..etc.

As a first step in the Contest case you select contest type, based on that, pxObjClass needs to be changed dynamically.

Is this correct way to implement ? Any other idea?

Regarding:  "the class name will be more stretched". There is no restriction on the length on the applies-to property, pyClassName, other than database column size, for example 2000 characters. 

A pzInsKey is restricted to 256 characters. The maximum length for a work pool class is 256 - 1 - pyID.length(), the "1" representing the space between the work pool class and pyID.

From a readability perspective you want to avoid overly lengthy pyClassName values . Pattern inheritance makes it possible to view inheritance as a tree within the App Explorer.  The left panel may need to be expanded to the right.

On another note, if changing to a new class after case creation. how would you deal with pyDefault plus avoid calling it twice?

One approach to the post-construction, dynamic-class-change initialization problem is to use an @baseclass-defined Boolean “WasPageInitialized” ValueGroup property.  Every pyDefault Data Transform within an inheritance hierarchy could be altered as follows.

1. Set param.Class = @replaceAll(.pxObjClass,"-","_")
2. When .WasPageInitialized(param.Class) Exit Data Transform
3. <if this transform called from application level as opposed to enterprise level, apply pattern-inherited Default transform(s) left to right>
4. <steps to initialize the defaults for this class go here>
5. Set .WasPageInitialized(param.Class) = true

pyDefault Data Transform would be called from the bottom up, each higher DT adding initialization or overriding inherited initialization.

What gets tricky is changing the class dynamically more than once. Should the instance be completely reinitialized?  Might that overwrite information that was manually set/overridden after the first dynamic class change and before the second dynamic class change?

Perhaps best either not to allow this or force a do-over. What is the possibility that someone would go from Org-Data-Vehicle to Org-Data-Vehicle-Car, and then decide to change to Org-Data-Vehicle-Truck instead?

You are trying to change pxObjClass within a pyDefault (??) Data Transform while trying to propagate data from a parent class to "some" class, that propagation effected by a different Data Transform defined in the child case's class (which)?

You have a lot going on at the same time. Suggest simplifying for the sake of maintainability.

The Application rule defines the default class for each case type.

The parent class that is creating the child case does have the ability to dictate the pxObjClass of the child case (DCR). But....

According to Separation of Concerns, it is not necessarily the parent case's responsibility to micro-manage the pxObjClass of a child case.  Liskov Substitution Principle also applies. The parent case should not care as long the methods and properties defined in child case's base class are used by any derived class.

This discussion thread is about changing pxObjClass post construction, for example. using a downstream Data Transform.

"SetRules" is not a very descriptive name. You should not hard-code the pxObjClass, instead ask a Data Page what the pxObjClass should be. The Data Page can take a parameter, for example, Param.Sport.

Hi, I find the algorithm proposed by Pedel really interesting, although I can't understand the replacement used in step 1:

Set param.Class = @replaceAll(.pxObjClass,"-","_")

Our problem is similar to the one discussed here, we have a case type similar to Org-App-Work-Onboarding, and in one of the first assignments we ask for the Country (we have previously created available classes like -USA, or -MEX) so if the user selects one of the available countries we try to change the class to Org-App-Work-Onboarding-USA. If the user selects a country that is not available, the class would stay as it is.

How I tried to resolve this problem in my project, was to do something like this in pyDefault:

Set .pxObjClass = DataPage[Country:Param.Country].CountryClass

Where param is the one chosen by the user in the Country drop-down.

This approach works, however, it generates a severe warning for trying to change the class of the containing page.

Let me know if this approach looks good or if you see any problems with it.

Thank you,

-Jose