蜜豆视频

Use case: supervise your workflows supervising-workflows

This use case details the creation of a workflow that lets you monitor the status of a set of workflows that are 鈥減aused鈥, 鈥渟topped鈥 or 鈥渨ith errors鈥.

Its purpose is to:

  • Use a workflow to monitor a group of business workflows.
  • Send a message to a supervisor via a 鈥渄elivery鈥 activity.

To monitor the status of a set of workflows, you need to follow these steps:

  1. Create the monitoring workflow.
  2. Write the JavaScript to determine whether workflows are paused, stopped, or with errors.
  3. Create the Test activity.
  4. Prepare the delivery template.
NOTE
In addition to the workflow, Campaign Workflow Heatmap allows you to analyse in details the workflows that are currently running. For more on this, refer to the dedicated section.
For more on how to monitor your workflows鈥 execution, refer to this section.

Step 1: Creating the monitoring workflow step-1--creating-the-monitoring-workflow

The workflow folder that we are going to monitor is the 鈥淐耻蝉迟辞尘奥辞谤办蹿濒辞飞蝉鈥 folder stored in the Administration > Production > Technical workflows node. This folder contains a set of business workflows.

The Monitoring workflow is stored at the root of the Technical Workflows folder. The label used is 鈥淢辞苍颈迟辞谤颈苍驳鈥.

The following schema shows the sequence of activities:

This workflow is made up of:

  • a 鈥沦迟补谤迟鈥 activity.
  • a 鈥淛avaScript code鈥 activity responsible for analyzing the business workflows folder.
  • a 鈥淭别蝉迟鈥 activity to send a delivery to the supervisor or re-start the workflow.
  • a 鈥凄别濒颈惫别谤测鈥 activity responsible for message layout.
  • a 鈥淲补颈迟鈥 activity that controls the lead times between workflow iterations.

Step 2: Writing the JavaScript step-2--writing-the-javascript

The first part of the JavaScript code coincides with a query (queryDef) that lets you identify the workflows with a 鈥減ause鈥 (@state == 13), 鈥渆rror鈥 (@failed == 1) or 鈥渟topped鈥 (@state == 20) status.

The internal name of the workflow folder to monitor is given in the following condition:

<condition boolOperator="AND" expr="[folder/@name] = 'Folder20'" internalId="1"/>
var strError = "";
var strPaused = "";
var strStop = "";

var queryWkfError = xtk.queryDef.create(
  <queryDef schema="xtk:workflow" operation="select">
    <select>
      <node expr="@internalName"/>
      <node expr="@state"/>
      <node expr="@label"/>
      <node expr="@failed"/>
      <node expr="@state"/>
    </select>
    <where id="12837805386">
      <condition boolOperator="AND" expr="[folder/@name] = 'Folder20'" internalId="1"/>
        <condition boolOperator="AND" internalId="2">
          <condition boolOperator="OR" expr="@state = 20" internalId="3"/>
          <condition expr="@state = 13" internalId="4"/>
        </condition>
    </where>
  </queryDef>
);
var ndWkfError = queryWkfError.ExecuteQuery();

The second part of the JavaScript code lets you display a message for each workflow based on the status recovered during the query.

NOTE
The strings created must be loaded in the workflow鈥檚 event variables.
for each ( var wkf in ndWkfError.workflow )
{
  if ( wkf.@state == 13 )  // Status 13 = paused
  {
    if ( wkf.@failed == 1 )
      strError += "<li>Workflow '" + wkf.@internalName + "' with the label '" + wkf.@label + "'</li>";
    else
      strPaused += "<li>Workflow '" + wkf.@internalName + "' with the label '" + wkf.@label + "'</li>";
  }

  if ( wkf.@state == 20 )  // Status 20 = stop
    strStop += "<li>Workflow '" + wkf.@internalName + "' with the label '" + wkf.@label + "'</li>";
}

vars.strWorkflowError = strError;
vars.strWorkflowPaused = strPaused;
vars.strWorkflowStop = strStop;

Step 3: Creating the 鈥楾est鈥 activity step-3--creating-the--test--activity

The 鈥淭别蝉迟鈥 activity lets you determine whether a delivery needs to be sent or whether the monitoring workflow needs to run another cycle based on the 鈥淲补颈迟鈥 activity.

A delivery is sent to the supervisor if at least one of the three event variables 鈥渧ars.strWorkflowError鈥, 鈥渧ars.strWorkflowPaused鈥, or 鈥渧ars.strWorkflowStop鈥 is non-void.

The 鈥淲补颈迟鈥 activity can be configured to re-start the monitoring workflow at regular intervals. For this use case, the wait time is set to one hour.

Step 4: Preparing the delivery step-4--preparing-the-delivery

The 鈥凄别濒颈惫别谤测鈥 activity is based on a delivery template stored in the Resources > Templates > Delivery templates node.

This template must include:

  • the email address of the supervisor.

  • HTML content for inserting personalized text.

    The three variables declared (WF_Stop, WF_Paused, WF_Error) match the three workflow event variables.

    These variables must be declared in the Variables tab of the delivery template properties.

    To recover the content of the workflow event variables, you need to declare the variables specific to the delivery that will be initialized with values returned by the JavaScript code.

    The delivery template has the following content:

Once the template has been created and approved, you need to configure the Delivery activity to:

  • link the 鈥凄别濒颈惫别谤测鈥 activity to the delivery template created previously.
  • link the workflow鈥檚 event variables to those specific to the delivery template.

Double-click the Delivery activity and select the following options:

  • Delivery: select New, created from a template, and select the delivery template created previously.

  • For the Recipients and Content fields, select Specified in the delivery.

  • Action to execute: select Prepare and start.

  • Uncheck the Process errors option.

  • Go to the Script tab of the Delivery activity, add three character string type variables via the personalization field menu.

    The three variables declared are:

    code language-none
    delivery.variables._var[0].stringValue = vars.strWorkflowError;
    delivery.variables._var[1].stringValue = vars.strWorkflowPaused;
    delivery.variables._var[2].stringValue = vars.strWorkflowStop;
    

Once this monitoring workflow is launched, it sends the following summary to the recipient:

recommendation-more-help
601d79c3-e613-4db3-889a-ae959cd9e3e1