Session Variables and "Forced" Process Deployment

[Jason_Acton]

Our Business Process has a restriction wherein it must not be allowed to run during payroll processing periods for our company (Mon-Wed every other week). As the process has been setup with the scheduler to deploy on an hourly basis Monday-Friday (and the option of using the Calendar to enforce this restriction seemed limited as it appeared that a calendar would need to be granularly created), I've opted to insert logic at the beginning of the process where it will loop through a collection populated with the dates on which the process must not be allowed to run. If "Today" matches a provided collection date, the process immediately goes to "End". If not, it continues. The business would like to have the option to manually deploy the process (essentially overriding the aforementioned date evaluation logic), and I believe we can use Session Variables to our advantage, but am not quite certain how (or if there may be a better way to design a solution to this distinct business need that doesn't require this logic or Session Variables). Is there a recommended methodology that would allow for a process to be manually deployed in this manner, overriding the evaluation of the current date, using Session Variables or some other design-related solution? Thank you kindly for your time and consideration!

[Denis__Dennehy]

Hi Jason, A session variable sounds like a good way to adjust the running of your process - called something like 'Ignore Calander'. It could also be an input parameter to your process so that it can be set when the process starts (either manually or via schedular"". Off the top of my head I can't think of a better way than yours to handle your payroll days than your solution. Den

[Jason_Acton]

Hey there, Denis! So the only thing I'm seeing as an issue with the Session Variable method is that Session Variables can be edited and are passed to the Process in ""real-time"". The difficulty with this and the way I've designed the process is that the logic which evaluates the date happens immediately at process launch, and takes 1-2 seconds to process. This doesn't allow a manual deployment agent to edit the session variable (say, a flag data item). Alternatively, if we make the flag choice an input parameter of the Start action of the process which is set upon launch, this solves the issue of a manual deployment to override the date restriction, but how will this affect the ability of the automatic scheduler to essentially ""disregard"" this input request? I can try testing it out and see what results I get. I'd thought about essentially building a ""dumb wait"" period of 30 seconds at the launch of the process to satisfy automatic scheduler deployment and also allow for a manual deployment agent to have sufficient time to edit the Session Variable. Any thoughts on that method? Thanks a lot for your time and feedback - it's greatly appreciated!

[DamianGomes1]

Have you considered externalizing this parameter to the process? Use an external file with a key / value pair. Upon start of the process, read the file, check for the value and proceed or stop. The file could be stored on a network drive that the process owner has access to and can update as the schedule changes.

[Jason_Acton]

In typical fashion, I should have tested things out before coming to the forum - I've confirmed that the scheduler effectively ignores the Session Variable value (or recognizes it is set to ""False"" by default), and that it can be set to ""True"" upon manual deployment. Thanks again for your time and assistance!