nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can we invoke Workflow on server Startup??

SE123

Hi,

I am using TS 6.7.1 with WFT, I want to invoke workflow on Server start up. Is it possible or it always requires some even to trigger???

Thanks in advance.

Find more posts tagged with

Comments

Adam Stoller

Hi,

I am using TS 6.7.1 with WFT, I want to invoke workflow on Server start up. Is it possible or it always requires some even to trigger???

Thanks in advance.

You need an event to trigger it - take a look at the events that are fired off when you start the service by examining the contents of IWHOME/local/logs/iwevents.log

Out of curiosity, what is this workflow supposed to do / why do you need to have it automatically run whenever the server is started?

SE123

You need an event to trigger it - take a look at the events that are fired off when you start the service by examining the contents of IWHOME/local/logs/iwevents.log

Out of curiosity, what is this workflow supposed to do / why do you need to have it automatically run whenever the server is started?

Thanks for the response Ghoti, My requirement is that my workflow will be invoked by an end user and it will run indefinitely after every 10 hrs(kind of scheduling but can't use cronjob) which I can achieve using an external task followed by a dummy task which will invoke external task at every 10 hrs. The above approach is working fine but if someone restarts the server my workflow gets hanged and not able to resume from that state. Hence I am looking some way where on server startup I can reinvoke the same workflow with same job Id or new workflow altogether after removing the old inactive workflow.

ChartWithHTMLButtons.rptdesign

nipper

OK, this sounds quite convoluted, and me providing an answer does not mean I validate the approach

What OS? Both DOS and Unix have startup functions that you can extend. It is quite easy in Unix. DOS, you need to play with the registry.

Either case you need to make certain it is up an dunning after TS completes.

Adam Stoller

Thanks for the response Ghoti, My requirement is that my workflow will be invoked by an end user and it will run indefinitely after every 10 hrs(kind of scheduling but can't use cronjob) which I can achieve using an external task followed by a dummy task which will invoke external task at every 10 hrs. The above approach is working fine but if someone restarts the server my workflow gets hanged and not able to resume from that state. Hence I am looking some way where on server startup I can reinvoke the same workflow with same job Id or new workflow altogether after removing the old inactive workflow.

While I don't really like the architecture you're suggesting, if you have a timeout handler in your workflow that transitions back to the task that timed out - it should work across reboots.

Another option would be to use the OD Scheduler to kick off a no-op deployment every 10 hours (?) that runs a DNR script to invoke your workflow - it's a tad bit cleaner than leaving a workflow running indefinitely.

SE123

What OS? Both DOS and Unix have startup functions that you can extend. It is quite easy in Unix. DOS, you need to play with the registry.
Either case you need to make certain it is up an dunning after TS completes.

I am using Unix.

While I don't really like the architecture you're suggesting, if you have a timeout handler in your workflow that transitions back to the task that timed out - it should work across reboots.
Another option would be to use the OD Scheduler to kick off a no-op deployment every 10 hours (?) that runs a DNR script to invoke your workflow - it's a tad bit cleaner than leaving a workflow running indefinitely.

I don't want to deploy any file from one server to other using OD, I just want to run a script using an external task. The script is kept at remote machine. Reason being chosing the workflow and not any cronjob is to make the process auditable so that user can check the status that how many times the script is invoked and what is the status of each invocation, whether it is completed or it is still in progress. Now the only problem with this approach is that I am not able to resume the same job after server restart. I think it should be taken care by IW itself may be I am missing some configuration changes or the feature itself is not supported by IW.

I think using retry option as an attribute of external task, I can meet my purpose. I can configure 1 min in iw.cfg so that every minute the status of workflow will be checked and in case it fails IW itself will invoke the external task.

Any help would be appreciated.

Adam Stoller

I am using Unix.

I don't want to deploy any file from one server to other using OD, I just want to run a script using an external task. The script is kept at remote machine. Reason being chosing the workflow and not any cronjob is to make the process auditable so that user can check the status that how many times the script is invoked and what is the status of each invocation, whether it is completed or it is still in progress. Now the only problem with this approach is that I am not able to resume the same job after server restart. I think it should be taken care by IW itself may be I am missing some configuration changes or the feature itself is not supported by IW.

I think using retry option as an attribute of external task, I can meet my purpose. I can configure 1 min in iw.cfg so that every minute the status of workflow will be checked and in case it fails IW itself will invoke the external task.

Any help would be appreciated.

That's not what the retry attribute is for.

A timeout handler (another externaltask with custom code) on the workflow should suffice and should carry through across server reboots.

I still don't like the idea of having an indefinitely running workflow, but that's your decision.

SE123

That's not what the retry attribute is for.

A timeout handler (another externaltask with custom code) on the workflow should suffice and should carry through across server reboots.

I still don't like the idea of having an indefinitely running workflow, but that's your decision.

I completely agree with you but do you think that scheduled deployment would be good approach here as I am not transferring any file, I just want to execute a job or script in background without any user interaction which I can very well achieve through cron job but as i told you earlier I can't use it as user want to see the status of his request.

Also in your earlier post you have mentioned about external task with custom code for timeout, will it make any difference if I use dummy task??

The only problem I can see with dummy task is when user clicks on tasks tab it throws NULL Pointer exception on server and I think it is because that dummy task does not accept areavpath and owner, but IW should handle this exception in task_detail.jsp by its own. Is this a miss from IW or the exception is coming due to some other reason...

Adam Stoller

I completely agree with you but do you think that scheduled deployment would be good approach here as I am not transferring any file, I just want to execute a job or script in background without any user interaction which I can very well achieve through cron job but as i told you earlier I can't use it as user want to see the status of his request.

Using the OD scheduler is pretty much the same thing as using cron - if the job hangs, the user can see that it hung. Cron is actually probably better, because you can set the job to run under their crontab so the process will be owned by them and they can see the workflow status (while its active) - and you can always enable some form of workflow reporting and/or email notification in the workflow to provide them more feedback about it having executed.

Also in your earlier post you have mentioned about external task with custom code for timeout, will it make any difference if I use dummy task??

It depends on what you want it to do when the timeout is reached - but there's also a case of the externaltask getting interrupted or hanging, and if you don't have a timeout handler built into your workflow - that will continue to hang until someone goes in and manually transitions or kills it.

The only problem I can see with dummy task is when user clicks on tasks tab it throws NULL Pointer exception on server and I think it is because that dummy task does not accept areavpath and owner, but IW should handle this exception in task_detail.jsp by its own. Is this a miss from IW or the exception is coming due to some other reason...

Feel free to open a case with Support about things like that.