I need some help in mind storming the best method to achieve what I need. Your t

I need some help in mind storming the best method to achieve what I need. Your thoughts and comments will be highly valuable.

I want to start a process, automatically once its date and time matches that of a predefined constant. Every year, this constant will be updated to prepare for the next year. And I want the process to auto start every year based on that constant.

Using a start even at the beginning of a process [followed by a controller rule] only works for 1 time after I publish the process. But when the constant is updated the process does not run again after 1 year, unless the original process was republished sometime after it auto ran the 1st time. Any thoughts?

I have this idea of using a message sending/receiving somehow, but have not wrapped my mind around it yet.

Thanks for your thoughts.

OriginalPostID-208672

OriginalPostID-208672

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer
    You could create a process that runs every day and reads a database table for a date, which then decides whether or not it should do anything. You could then maintain that database table with a simple process and interface?
  • @adela - You can use recurrence of timer for each year if your date and time for each year is fixed. Also if you are changing the time so that you can delay the process at the specific time, its also useful to start the process only at that time. If the date and time will change multiple times and can be sometime within the year then you will need some events like rule or receive message to be configured in your process to update the timer. You can update timer by terminating the running process and restarting the timer subprocess. Timer subprocess will have events configured in it.
  • My solution would be similar to sagarl511's above, if you are not going the DB route as phil suggests. I would do this with 2 processes, since date/time should be exact it is not feasible to have a process that starts regularly, terminating if not current time >= cons!runTime.

    One process would be used to update the constant. This would send a kill message to any annual process waiting (to allow for date/time changes), update the constant, then call the annual process asynchronously. The annual process will start and wait until the date/time selected. Once completed, the annual instance terminates. The Update mechanism will then start a new instance of the annual process which waits until the next date/time to continue.

    My example is attached.

  • Would it be possible for you to have an instance start every day and run a check to see if its the date to run. If its not the date then have the process terminate. You could set the process to archive or delete a couple days after it finishes so it doesn't take up space.
  • Thanks guys, i decided on both using a DB for the dates, as i will be handling a different date set for each year managed by an interface and process.

    And to manage the auto start of my processes, i will create an orchestrator process which takes the year as a parameter, the very 1st time this orchestrator will be run by the admin and from there onwards, that orchestrator manages calling the other processes for this current year, and at some point, it calls the next orchestrator processes for the next year.

    Thanks a lot for all of your comments.
  • 0
    Certified Senior Developer
    Adela: Take care of the instances of the sub process (orchestrator) your main process creates. We had to create a scheduler for 2 mins and to do so i was calling the same process within bt that ended up in creating maximum instance of sub processes.
  • Thanks for the heads up Raghunandanc, but i was planning on using send and receive messages to call the new instances of the processes with control flows to keep things under control.
  • 0
    Certified Senior Developer
    But usage of Send and Receive messagesa re not recommended strongly by Appian as well as they tend to use lot of memory and cause slowness and other performance related issues. We had used the message events initially but eventually took it out and now sticking to a 5 mins standard OOTB scheduler to do the job with a boolean constant to control the process.