How to update process variable type with the latest version of the CDT for the in-flight process instances?

how many instances you have? is your process too much complex? I would suggest you to add some "restartable" option to the process (or maybe a temporary process to migrate) in addition to some related action to make the migration and the user can add any information.

So the idea at the end is to kill the current process and start a new migration process ( or if possible the same) but using the new version of the process model.

Not sure if I were clear enough?

Jose

Hi ,

I am not sure I understood you proposal. Could you please elaborate? Btw I have 174 instances that needs to be upgraded and they are complex and long processes.

Unfortunately, the process upgrade tool doesn't work if the CDT has changed. I recommend Jose's approach of building a path in the model that allows a one time cancellation + restart of the affected instances.

Hi Josh ,

I am thinking, if we create a new process variable of type latest version of CDT and do the remapping in the nodes with the new process variable. Will that work?

You'd probably need to create a totally new cdt with the new fields Ex. APP_someCDTv2. Otherwise, the plugin will fail because the CDT had a new version.

Hello Arun,

I would suggest you to give us little more detail (or an idea of your process). maybe you cannot disclose it but you can redraw a high level.

I really prefer the option to find a way to kill the instances and restart them with a new version of the process.
community.appian.com/.../creating-flexible-processes
Take a look at the "Restartable Processes" and the "Asynchronous Process Linking". At the end the proposal is something between those two.

I have a question here, are those new fields needed during the process to take a decision? in the process model? Have you done something to the process models of the running process instances?

how is the old CDT affecting you? are the values cleared out? If you are just not able to display the values because you have the values saved in the process and mapping them to the interface instead of querying that, maybe can you handle that on the interfaces? (This becomes a bad option and bad idea if you have a lot of them having to display that).

Jose

Hi Jose,

The process model is a very long and complex one.

When the tasks from the in-flight process instances are submitted, values for the two newly created variables are getting cleared in the database. This is because the in-process instances would still refer to the old version of the CDT which wouldn’t have the newly added variables.

As a workaround, I am thinking to hide the section and set null for this CDT, based upon the deployment date on the task and rejecting null in the process which writes to the DB. In this way I can avoid writing data, when tasks from in-flight process instances are submitted.

Sounds like you can play easily with the interfaces. What about saving in another temporary table (on the related action) based on the date and display/query based on the deployment date.

I am not sure I understood that correct. Could you please clarify?

Well I was throwing ideas, after a second look FI you have the option just to hide that is a good approach since you don’t have to mess with all other stuff.

In my previous post I said something like affecting the process model of the related action and affect the interfaces to read from different sources, keep the information in two different places and when all the process models are done then you can copy the information from one table to another and rollback the precios mentioned changes. Trying to make the change seamless to the user. But I am not sure that is a worth solution if your user can agree just to hide the section based on the deployment date it might be a really good approach, because you do it and forget about it.

Sorry for throwing ideas without thinking it twice.

Jose

Don’t be sorry Jose. You help is very much appreciated. Thanks again.

Hi Arun,

You can try creating a stored procedure(which only gets called in the specific process model you mentioned) and in the script you can design to get the new field values from the required tables and give them as the values when you are updating the table with new record values.

You can call this stored procedure inside your process model(using execute stored procedure) and set conditions so that it only gets executed for your active instances, before the deployment.

After this you need to run Process upgrade so that these changes can be actually seen in the active instances.(need to create a new process for this).

PS: Never tried this, just a thought.

Thanks,
Sai Kiran

Hi Arun,

You can try creating a stored procedure(which only gets called in the specific process model you mentioned) and in the script you can design to get the new field values from the required tables and give them as the values when you are updating the table with new record values.

You can call this stored procedure inside your process model(using execute stored procedure) and set conditions so that it only gets executed for your active instances, before the deployment.

After this you need to run Process upgrade so that these changes can be actually seen in the active instances.(need to create a new process for this).

PS: Never tried this, just a thought.

Thanks,
Sai Kiran