Control Room Scheduler: Pause Function/Option

[stepher]

Use Case:  We have automations against the Epic EHR application.  They claim to NEVER have any downtimes, but they often had "silent pauses", or somesuch, which seem to be just as disruptive to our processes.

Idea: Have a 'Pause' option, alongside the 'Request Stop' option.  The 'Pause' option would have a start and stop DateTime parameter.  When executed, the Process, upon reaching the Stop/Stop Time check would hold until the Pause parameters expired.  The exact mechanics in the Process could be addressed in a couple of different ways.

So, rather than a full Stop/Restart, the Process is able to pick back up where it left off.

[Mukeshh_k]

Pausing would definitely be helpful in many of business case scenarios, along with pausing it should make sure the resource is free if at paused stage and should be able to reconnect to last memory block when plugged.

[chris.strong]

Hello @ Robert Stephens and @Mukesh Kumar 

If I’ve understood your idea request correctly, you already have this capability with a Wait Stage.  A Wait stage allows you to pause the execution of a business object until a certain condition has been met in the target application, and you can then branch the flow of your business object depending on the outcome. 

Is this what you were looking for?

Kind regards

Chris Strong

SS&C Blue Prism Product Manager

[stepher]

@Chris Strong,

Wait Stages within objects work well for a) determining that the requirements for an action are present, or b) that the results of the action were as expected. For the purposes of this discussion, I think of Wait Stages as being internal to the Process (really the Object). For the use case that I am presenting, I would think of the Pause as external to the Process.  Specifically, when Epic performs its “Silent Pause”, the target system simply freezes. Wait Stages will time out, and appropriate Exception Handling will bring the process to a termination.  Which is what I would be hoping to avoid.  Some of our processes do not lend themselves to being restarted, and others would take a significant amount of time (rework) to catch up to the point where the pause occurred.  In either of these cases, it would be better (at least, more efficient) to simply hold the Process at a designated point, and then release it once the target system is operational.  Again, it seems to me that the most logical place for this Pause action would be alongside the Stop actions In the Control Room.

The other aspect of the suggested use case is the proactive communication from the target application, with a defined timeframe.  We currently can pause or stop a schedule if that seems the best approach.  The Pause action would give us another option.

Again, thanks for the response.

[chris.strong]

Thank you @Robert Stephens

I had not initially mentally joined up the need for a human operator to choose to Pause individual sessions (process runs) and the need to wait for a target system to become responsive again.

Work Queue are a good solution to leverage to hold “state” for when you need to “stop” a long running automation and pick it back up later [as in a new process run].  It is reliant on the entire automation being in small chunks and the target system(s).

I’ve changed the status to reviewed.

Kind regards

Chris Strong

SS&C Blue Prism Product Manager

[chris.strong]

Related idea: Pause running robot in Control Room