Skip to main content

Workflow Engine Strategies and Tips

The Moogsoft Onprem Workflow Engine is a powerful tool that gives you access to your event, alert and Situation data and lets you control data processing flow. This topic covers some strategies to help you get the most out of the Workflow Engine.

Before you begin

Taking some time to prepare before you start creating workflows in Moogsoft Onprem can help improve your experience. The following include some suggestions to help you get ready:

  • Watch the Introduction to Workflow Engine video and the other Workflow Engine Tutorials.

  • Take time to define outcomes you want to accomplish with the Workflow Engine. Read through the example use cases listed in the Workflow Engine topic to gather ideas.Workflow Engine

  • Pick one use case and think about the supporting data that can help you define your workflow. For example, you want to stop processing of clear, severity 0, events if they are going to create a new alert. In this case, you need the severity field. For more information see Alert and Event Field Reference.

  • Look through the Workflow Engine Functions Reference to find the right function you need to accomplish your task. For example, to see if an event will create a new alert, you can use willCreateNewAlert.Workflow Engine Functions Reference

  • If possible, set up a REST LAM so you can send sample data to test out your workflows. See REST LAM. You can use cURL or a graphical API client to send event data to the REST LAM.

  • If possible, get SSH access to the machine running Moogfarmd so you can access the log for troubleshooting. See Troubleshoot the Workflow Engine for more information.

Creating workflows

Workflows are containers for a set of actions to process your data. In a complex system, you may create hundreds of workflows to handle all kinds of scenarios. Consider the following as you define your workflows:

  • Workflow Engines process data through individual workflows in the numeric order from the UI. If possible, work with one active workflow at a time while you design and configure your workflow. This way you can focus on a single behavior without worrying about an upstream or downstream workflow.

  • Whenever possible, use an entry filter to limit the number of objects entering your workflow. Running a workflow takes processing power and time. Using an entry filter ensures that only pertinent objects pass through a workflow. Entry filters are also more performant than action based filters. For example, if I want to stop processing clear events, I can create a filter: severity = "Clear". See Filter Search Data for information on filter syntax.

  • If you want to use a sweep up filter to process multiple alerts or Situations, verify that the function you plan to use works with sweep up filters. You can check the Workflow Engine Functions Reference or the topics for individual functions.Workflow Engine Functions Reference

  • When objects enter a workflow as part of a sweep up filter, the workflow processes each action on all objects in turn. For example, it executes action one for all objects before proceeding to action two.

  • When you enable multiple workflows, consider the impact of upstream workflows on downstream ones. For example, keep the default Closed Alerts Filter early in the workflow chain. This prevents those events from entering later workflows. Also consider the impact of event workflows on alert and Situation workflows.

See Manage Workflows for steps to create a workflow.

Adding Actions to workflows

You add actions to a workflow to manipulate data and control the data processing flow for events, alerts, enrichment, and Situations. Consider the following as you add actions to your workflow:

  • The UI validates that the data you enter for function arguments as JSON. Where possible, it checks validity of number and string data. For example 0-5 are the only valid severities. It does not check for valid field names or value data.

  • Unless instructed, you do not need to enter quotation marks around values, except strings where they represent elements in an array.

  • The Workflow Engine uses JavaScript regular expression notation. Consider using a third-party regular expression validator to help with syntax. For example, regex101. Moogsoft does not endorse any specific tool. Before using any tool, verify that it meets your organization's standard for security and privacy.

  • The forwarding behavior applies when the action returns false. For more detail, see Action types and forwarding behavior.

  • Actions execute in numeric order. Test your workflow for both negative and positive cases with the addition of each new action.

See Manage Workflow Engine Actions for steps to add actions to a workflow.

Action types and forwarding behavior

The Workflow Engine has several types of actions to choose from. Each action lets you set the forwarding behavior to control the downstream flow of the object in the case that the action returns false. The type of action should influence how you choose your forwarding behavior. Action types include:

  • Conditionals that return true or false to let you control whether or not to proceed with the current object. You can use these as an "action" based filter if you need to filter data within a workflow after the execution of previous actions. For maximum efficiency, you may consider breaking a workflow into multiple workflows and using the entry filter for the subsequent workflow.

  • Transformers that update object data. In general transformer actions should Always Forward unless doing so compromises the workflow. For example, when a failed action impacts the subsequent action.

  • Data actions that action retrieved data and pass it to a consecutive action or that send data asynchronously to an external data sink. Treat data retrievers like conditionals. For example, stop the workflow if it returns false since subsequent actions may not run. An asynchronous exporter always returns true regardless of the result from the asynchronous return.

In this section: