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

We had to add two new columns for an existing CDT. New process instances post deployment are fine as they refer to the latest version of the CDT. But in-flight process instances refer to the previous version of the CDT. However there is a related action available where the end user can capture the data for the newly added fields. But the business is more aligned with the option of the data entry on the tasks from the in-flight process instances.

Hence, hiding the section based upon the deployment date is ruled out. Please let me know other possible options to handle this scenario. Thanks in advance.

  Discussion posts and replies are publicly visible

Parents Reply
  • 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
Children
  • 0
    Certified Lead Developer
    in reply to josep
    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.
  • 0
    Certified Lead Developer
    in reply to josep
    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
  • 0
    Certified Lead Developer
    in reply to josep
    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