How to make script wait for Workflow status

We are running workflow (A) from a perl script. This script is first running workflow A and then after checking the status of workflow it carries on.

What we want is that the script should wait for the workflow A to finish and then go ahead.

One method to do this is to continuously (while loop) check the status of workflow A. When workflow A is finished then get out of loop and do rest of its job.

Is there any other way to do the same?

Find more posts tagged with

Comments

iw_store

We are running workflow (A) from a perl script. This script is first running workflow A and then after checking the status of workflow it carries on.

What we want is that the script should wait for the workflow A to finish and then go ahead.

One method to do this is to continuously (while loop) check the status of workflow A. When workflow A is finished then get out of loop and do rest of its job.

Is there any other way to do the same?

Look at nested jobs using testing task.

Adam Stoller

We are running workflow (A) from a perl script. This script is first running workflow A and then after checking the status of workflow it carries on.

What we want is that the script should wait for the workflow A to finish and then go ahead.

One method to do this is to continuously (while loop) check the status of workflow A. When workflow A is finished then get out of loop and do rest of its job.

Is there any other way to do the same?

That's probably the simplest way - though you won't be able to determine if the workflow ended gracefully or if it was aborted - which might have an effect on your Perl script.

You could probably use a combination of techniques to determine whether the workflow ended gracefully (the method you are using to determine if the workflow is still running, and an externaltask just prior to the endtask that creates a file somewhere to indicate the workflow concluded properly)

Alternatively, you could split your script in two - and have the first part launch the workflow and use an externaltask script just prior to the endtask to launch the second half of the script (doing a callback prior to invoking the other script)

The advantage of the first method though, is that you can also tell if the workflow was aborted - and have your script "handle" that situation. It really depends on what the script is doing and what you want it to do.

Amanpreet

Thanks for the suggestion .But we cannot split script into two.

Bhargav Coca

I personally like Adams idea of having two scripts. If you still want to stick with one script you need to have an external task before the end task, basically calling the same script and have a logic that says that the final external task was called successfully with some flag and use that flag to end the workflow ( the Workflow A gets a Success callback and the first workflow is over) then do whatever you want to do in the same IPl file after that.

Thanks

ISCBorisB

Thanks for the suggestion .But we cannot split script into two.

It seems that you want not just one script (that too) but rather single run-time process: StartWF - Wait till WF ends - Post Process.
The issue here is standard problem of parallel processes resynchronization. There are various techniques to do that, all of them are
flavors of the following approaches:

1. Continuous polling with some time interval (are you done, are you done, not done still!?). That has been already mentioned.
    It is the easiest one to code, note though that it is often a bad drag on System Resources.
2. Event-based synchronization. Originating process *subscribes* for some events(like WF termination) that will wake it up and goes
    to hibernation.
3. Call-back based synchronization. Spawned process calls back to the hibernating originator (like FormAPI callServer). The difference
    between #2 and #3 may seem terminological, it boils down to the presence (or absence) of Event System with exposed
    API (the third process in our equation).

Any of that can be done in your case in one form or another (TS does have event triggers). If I were you I would seriously consider
Adam's proposal though. It really belongs to the best category of solving the problem by avoiding it in the first place.