Want to create a monitoring workflow that restarts the workflows automatically in finished state

[Maliha27]

Hi,

I want to create a workflow that picks up all the workflows in finished state and restart them automatically without manually doing it. Wanted to know if there is any way that the restart can be done through a monitoring workflow and without an API call?

Reason being, we have been observing workflows going to finished state without processing (Scheduled workflows or external signal). The root cause and fix is not known yet, so wanted to restart the workflow automatically to avoid any delays sending communications.

Thanks,

Maliha

[LakshmiPravallika]

Hi @Maliha27 ,

Yes you can create a workflow which makes the state to "Started" for all the workflows which went to "Finished" State as per your requirements.

There is a schema called "xtk:workflow" OOTB Schema where you can update the particular workflows state what ever you want by doing a query a

nd then Update Data.

Example:

In the First query activity, please take the base schema as "xtk:workflow" and then select the Internal names of workflows as per your requirement and the state is equal to Finished for them.

In the Update Data activity, Please updates those status to "Started" as below:

you can manually do this process as shown above instead of doing for each and every workflow.

Regards,

Pravallika.

[isahore]

Hi @Maliha27,

Another (alternative) way to do that would be via JavaScript, where you can write a function like this:

function startFinishedWorkflows(){
  var query = NLWS.xtkQueryDef.create(
  {queryDef: {schema: "xtk:workflow", operation: "select", 
    select: {
        node: [{expr: "@id"}] 
    }, 
    where: {
      condition: [{expr: "@state = 20"}]
    }, 
    orderBy: {
      node: {expr: "@id", sortDesc: "false"}
    }
  }})

  var res = query.ExecuteQuery();
  var workflows = res.getElementsByTagName("workflow");
  for each (var w in workflows)
    xtk.workflow.Start(w.getAttribute("id"));
}

You can call this function from a javascript activity inside a workflow. But you will have to run at least this workflow manually everyday.

You might want to refine the query to select and start only those workflows which you intentionally want to start, as there might still be some workflows in the finished state that you do not wish to start.

If you have an on-premises installation with access to the server, to avoid doing this from a workflow you can also execute this function via command line (optionally, with arguments too). To further automate the whole thing, you can also write a cronjob on your server to execute it on a scheduled basis.

Thanks,

Ishan

[jjwatson79]

@isahore, another technically sound answer, and we agree on being careful with your selection.

In what instances would you prefer the JS activity over a normal query and update?

The JS activity is for a more advanced audience, and not in the skillset of less technical users. Can you elaborate a little on when you feel the JS activity or server-side command would be better than a simple workflow?

[isahore]

Hi @jjwatson79,

I have not tried the update data activity to start workflows, but used the javascript most of the times.

Yes the js activity is for more advanced audience, but not that complicated if the user knows what they are doing.

Using either of these would mean a workflow needs to be manually run everyday. In order to avoid this, the script can be run and automated on the server command line. Hence no workflow needs to be run manually at all.

Thanks,

Ishan

[jjwatson79]

I thought that I had done it via update previously, but I think I must not have. Yes, JS is the minimum option to get the workflow started.

[Maliha27]

Thank You all for the suggestions!

@jjwatson79 @ParthaSarathy @isahore @LakshmiPravallika 

[jjwatson79 · Accepted solution]

The issue with this approach is it does not actually start the workflow. I have run a test on a few instances, and all the happens is the logs show the workflow starting and finishing, with none of the activities carrying out any actions.

@isahoregave the JS method approach that would activate the workflow completely, rather than just changing the status.

I prefer a mixed approach. I would recommend building up the list of workflows using a query activity to simplify the approach. I would follow the query activity with a JS activity, containing the following code.

//Query the schema to extract the XML from eventData
var query = xtk.queryDef.create(
  <queryDef schema={vars.targetSchema} operation="select" lineCount={vars.recCount}>
    <select>
      <node expr="@id"/>
    </select>
  </queryDef>
)
var workflowsToStart = query.ExecuteQuery();

for (i=0; i < vars.recCount; i++ ) {
  xtk.workflow.Start(workflowsToStart[i].@id);
}

This approach allows for a less technical user to configure the logic using a query activity, and execute the backend method that will actually start the workflow. @isahore , you are correct that this requires the workflow to run in order to execute, but it seems a reasonable trade-off to me.

[ParthaSarathy]

Hi @Maliha27 and @jjwatson79 ,

As you want to restart your workflow, Instead of using xtk.workflow.Start, you can try using xtk.workflow.Restart

Start > Start or Resumes execution of a workflow

Whereas, Restart > Links together a workflow stop and a workflow start from beginning.

Solution:

Workflow should be like, 

Query:

Targeting dimension: xtk:workflow

Filtering dimension: xtk:workflow

Make sure not to give all workflow name in your instance. So you can give the selected Workflows internal name here, which you founds to be restarted.

Javascript:

var query = xtk.queryDef.create(
<queryDef schema="temp:query" operation="select">
<select>
<node expr="@id"/>
</select>
</queryDef>
);
var record = query.ExecuteQuery();

for each (var variable in record) {
vars.workflowID = variable.@id;

xtk.workflow.Restart(vars.workflowID);

}

Now When I ran the above workflow, I can see all the 3 workflows mentioned in Query activity have restarted in my environment.

But as part of BEST PRACTICE, Keep this solution as a temporary solution and try to figure it out why the workflows are going to finished state without processing and fix the issue.