Process Model is running every time when I re-start Appian services

Hi,

I have a Process Model and it should run as per the scheduled time. There were no issues with this.

But, as and when I am re-starting Appian services, the above defines process Model is triggering.

Can someone advise if I have to do any setting changes to avoid this issue.

Thanks in advance.

  Discussion posts and replies are publicly visible

Parents
  • Hi, i can suggest to add a constant as a condition on the timer
    Before imports or restarting, set the constant to false so that the trigger is deactivated and after the action set it to true so that when the times comes the trigger is active

  • 0
    Certified Lead Developer
    in reply to Gabriele Camilli

    An addition to the answer that whenever Appian services restart or a PM deploys to a next environment it triggers a new instance for all the scheduled process models. It is good to use an XOR gateway after the start node and check your constant value is true or not. It should only go to the main flow if it true else to the terminate node. Keep value of constant false when you restart the services or push to next environment and later change it to true.

  • Note that if you use your constant in the Timer Conditions under Advanced Options, you can avoid the extra XOR node and the process will not start at all if set to false:

  • 0
    Certified Lead Developer
    in reply to Chris

    Are changes to such a constant picked up live, or only after the process model is republished?  I know with a timer value stored in a constant, changes are only picked up after republishing, but not sure about the timer condition one.

  • Are changes to such a constant picked up live, or only after the process model is republished?  I know with a timer value stored in a constant, changes are only picked up after republishing, but not sure about the timer condition one.

    Yes, changes to the constant are picked up live in the Timer Conditions.  When I deploy a scheduled process to another environment, I'll deploy the constant (set as unique values on each server) along with it, set to false in the Import Customization File, then flip it back manually on the destination server after import (or you can re-deploy only the constant set to true).

    Additionally I built out an "Admin Console" in our COE which has a function to change constant values.  All (most) of my start condition constants are in here, and I can toggle them on and off via GUI and the processes will behave appropriately.  I also have constants in there that do things like, stop reads/writes to some external databases we manage.  When those are planned to have an outage, I flip the constant via the console, and all processes wait cleanly until I toggle it back after maintenance is complete.

    To note you are correct on storing the timer start dateTime in a constant, in this situation the change is not realized by the process until re-published (I'm positive I have an enhancement request logged for that somewhere a lonngg while ago..)

Reply
  • Are changes to such a constant picked up live, or only after the process model is republished?  I know with a timer value stored in a constant, changes are only picked up after republishing, but not sure about the timer condition one.

    Yes, changes to the constant are picked up live in the Timer Conditions.  When I deploy a scheduled process to another environment, I'll deploy the constant (set as unique values on each server) along with it, set to false in the Import Customization File, then flip it back manually on the destination server after import (or you can re-deploy only the constant set to true).

    Additionally I built out an "Admin Console" in our COE which has a function to change constant values.  All (most) of my start condition constants are in here, and I can toggle them on and off via GUI and the processes will behave appropriately.  I also have constants in there that do things like, stop reads/writes to some external databases we manage.  When those are planned to have an outage, I flip the constant via the console, and all processes wait cleanly until I toggle it back after maintenance is complete.

    To note you are correct on storing the timer start dateTime in a constant, in this situation the change is not realized by the process until re-published (I'm positive I have an enhancement request logged for that somewhere a lonngg while ago..)

Children
No Data