In one of my published process model, I have to change number of parameters/real

In one of my published process model, I have to change number of parameters/real inputs in a form (same applies to expression rules). Since the process model is in production now, many of its instances have already been initiated by the users. If I change the number of parameters on a form and save it with the same name, it will trigger exception for all active process using this form. I was wondering how other guys handle this type of situation?

Thank you!

OriginalPostID-163125

OriginalPostID-163125

  Discussion posts and replies are publicly visible

Parents
  • @zeeshanp Hi, here we do need to consider two scenarios:
    1. Live instances: The instances of process model which has been triggered already in the Production environment. The only issue that could arise is the form and it can break depending on the way it is invoked. So there could be two scenarios here as follows:
    a. If you pass arguments to the interface/ expression rule that has SAIL form by keyword. Example: rule!XYZ(a:1,b:2,c:3). In this case you could create a constant that contains release date and time and surface the new components only if the process start time is greater than the value in release date and time constant. This way the new components will be surfaced only for new processes and also will be hidden in the processes that were triggered prior to release. I wouldn't confirm that this is an elegant way, but it drastically brings down the time required to develop, as in-flight modifications would involve many implications depending on the various scenarios. This method best fits to the changed SAIL interface as long as you invoke the expression or interface by passing arguments via keyword.
    b. If you pass arguments to the interface/ expression rule that has SAIL form by position. Example: rule!XYZ(1,2,3). In this case the SAIL form breaks immediately after the release because of the change in number of parameters. So here there isn't an alternate way apart from going with the in-flight modifications as suggested by @mohanp.

    2. Future Instances: The instances of process model that are about to trigger in the Production environment. As known already, there shouldn't be any issue with this.

    Please do let me know if you have any followup questions.
Reply
  • @zeeshanp Hi, here we do need to consider two scenarios:
    1. Live instances: The instances of process model which has been triggered already in the Production environment. The only issue that could arise is the form and it can break depending on the way it is invoked. So there could be two scenarios here as follows:
    a. If you pass arguments to the interface/ expression rule that has SAIL form by keyword. Example: rule!XYZ(a:1,b:2,c:3). In this case you could create a constant that contains release date and time and surface the new components only if the process start time is greater than the value in release date and time constant. This way the new components will be surfaced only for new processes and also will be hidden in the processes that were triggered prior to release. I wouldn't confirm that this is an elegant way, but it drastically brings down the time required to develop, as in-flight modifications would involve many implications depending on the various scenarios. This method best fits to the changed SAIL interface as long as you invoke the expression or interface by passing arguments via keyword.
    b. If you pass arguments to the interface/ expression rule that has SAIL form by position. Example: rule!XYZ(1,2,3). In this case the SAIL form breaks immediately after the release because of the change in number of parameters. So here there isn't an alternate way apart from going with the in-flight modifications as suggested by @mohanp.

    2. Future Instances: The instances of process model that are about to trigger in the Production environment. As known already, there shouldn't be any issue with this.

    Please do let me know if you have any followup questions.
Children
No Data