Scenario 5 - Custom DEE Action at Every Stage#

Overview#

This scenario shows how to use a Custom DEE Action at every stage of the pipeline, for example for Context Resolution, Pre-Condition, Detector, Acceptance Gate, Action, and Post-Action Validation. It also demonstrates how to combine a native built-in check with a DEE action in the same Pre-Conditions list, so the cheap native check runs first and the DEE Action call is only made when needed. Use this as a reference when built-in component types cannot express your readiness or maintenance logic, or when an external system owns the data that drives each decision.

In this example, the cookie factory's baking oven recalibration is governed entirely by an external QMS. The QMS owns the recalibration schedule that determines which stations are due this cycle, per-oven readiness signals, change approval records, the recalibration procedure, and acceptance results - none of which are visible to MES directly.

When to Use#

• External system integration - when readiness, execution, or validation data lives outside MES in a QMS, ERP, CMMS, or calibration service and must be queried at runtime for each target.
• Change management enforcement - when company policy requires a registered work order, change request, or digital approval before any maintenance action can proceed on a specific piece of equipment.
• Custom maintenance operations - when the Action is not a standard version update but a bespoke procedure (setpoint adjustment, certificate renewal, sensor calibration, firmware flash) driven by an external system.
• QMS-owned target selection - when the external system determines not just whether a target is ready, but which targets should be in scope at all. Using a DEE Action for Context Resolution avoids creating tasks for stations the QMS has not scheduled, eliminating unnecessary polling overhead for out-of-cycle equipment.
• Dynamic or computed readiness - when the conditions that determine per-target readiness change frequently, depend on cross-system state, or cannot be expressed as a fixed MES entity state or material count.
• Full audit trail through DEE Action - when each decision point (schedule check, window check, readiness signal, approval, execution result, acceptance test) must be logged in an external system of record, and the DEE actions provide that integration at every stage.

Example#

The cookie factory's baking oven recalibration is managed entirely by an external QMS. The QMS owns which stations are due for recalibration this cycle, whether each oven is ready, whether a change request has been approved, and whether calibration passed acceptance. None of this data is available in MES directly, so every decision point is delegated to a DEE action that queries the QMS at runtime. Each DEE Action has a single, well-defined responsibility: answer one question or perform one operation, keeping each independently testable and replaceable.

• Resources: ASA Baker-01, ASA Baker-02.
• Controller: BakingController, revision A, version 1.
• Operation: baking oven recalibration fully driven by an external QMS.

graph LR
    QMS["External QMS"] -->|"**Context Resolution**: which stations are due?"| ASA[ASA Definition]
    ASA -->|task| B1[Baker-01]
    ASA -->|task| B2[Baker-02]
    B1 <-->|"per-oven checks & calibration"| QMS
    B2 <-->|"per-oven checks & calibration"| QMS

Prerequisites#

Before creating the Definition, confirm the following:

• Load the Scenario 5 automation master data into MES so it creates the BakingController [A.1] controller definition, baking-manager record, and both baker instances (master data package: 01-automation-masterdata.json).
• All target instances are currently running BakingController revision A, version 1.
• The following DEE Actions are deployed and tested. Each must return a Boolean unless noted otherwise:

Table 1: Scenario 5 DEE Actions by Stage

• Notification templates ASA PreAction Template, ASA Success Template, ASA Failure Template, and ASA Ignored Template exist in MES if you intend to use notifications.

Configuration#

Why This Pattern#

This Definition uses the following combination of components:

Table 2: Scenario 5 Component Design

Using a DEE Action for Context Resolution means the QMS controls which stations enter the pipeline at all, as stations the QMS has not scheduled never receive a task. Using a DEE Action as a Pre-Condition vs. an Acceptance Gate has different semantics: a Pre-Condition applies globally to all tasks on a polling pass; an Acceptance Gate applies per task and only blocks that specific task if it fails.

Create the Definition#

Open Automation Scheduled Action and select Create (see Create Definition). The wizard has four tabs.

Tab 1 - General Data#

Start by filling in the general definition fields.

• Give it a name like CF_BakingOven_Recalibration_A1 and a description that captures its purpose (for example, "Run baking oven recalibration when the QMS signals all conditions are met.")
• Set Is Enabled to Disabled for now.
• Set Validity to 5 days.

For Context, select DEE Action and enter ASA_Scenario5_ResolveStationsDueForCalibration as the action. The Context Resolution queries the QMS recalibration schedule and returns the entity names of stations due this cycle, creating one task per returned station. Stations the QMS has not scheduled are excluded entirely: no task is created for them and no downstream DEE Action is ever invoked on their behalf.

For the Detector, select DEE Action and enter ASA_Scenario5_CheckStationHasNoPendingTests. This is a per-task readiness check that receives the target entity as context, so QMS lookups are scoped to the correct oven.

For the Action, select DEE Action and enter ASA_Scenario5_ExecuteStationRecalibration. This runs the recalibration procedure for the target oven via the QMS API, and executes exactly once when all checks pass.

Optionally, configure notification templates to be alerted at key moments:

Table 3: Scenario 5 Notification Templates

Tab 2 - Pre-Conditions#

Select twice to add the following pre-conditions in this order:

1. Allowed Weekdays - Set the weekdays to Monday through Friday. Baking oven maintenance is never scheduled on weekends. This check is evaluated first and is inexpensive, so it prevents the DEE action from running unnecessarily on weekends.

2. DEE Action - Enter ASA_Scenario5_CheckMaintenanceWindowOpen. This is a global check: if the QMS maintenance window is closed, all tasks are skipped on that pass without evaluating individual station readiness.

Tab 3 - Acceptance Gates#

Select and select DEE Action. Enter ASA_Scenario5_CheckChangeApprovalRegistered. This is a per-task Acceptance Gate that checks whether an approved change request exists for this specific oven in the QMS. If it returns false, only that oven's task is skipped, and other ovens continue to be evaluated.

Tab 4 - Post-Action Validations#

Select and select DEE Action. Enter ASA_Scenario5_ValidateCalibrationResult. This checks whether the QMS reports the oven passed post-calibration acceptance tests. A false return marks the task as ValidationFailed.

How It Works at Runtime#

After you enable the Definition, the system processes each task on every polling pass as follows:

1. ASA_Scenario5_ResolveStationsDueForCalibration queries the QMS recalibration schedule and returns the entity names of stations due this cycle. One task is created per returned station. Stations not on the schedule are excluded - no task is created for them and no further DEE Action is invoked.
2. The native AllowedWeekdays Pre-Condition runs first. If today is a weekend, all tasks are skipped with SkippedPreConditionFailed immediately and the maintenance window DEE Action is not invoked.
3. ASA_Scenario5_CheckMaintenanceWindowOpen runs once per pass. If it returns false, all tasks are skipped with SkippedPreConditionFailed and no further evaluation happens on this pass.
4. For each task individually: ASA_Scenario5_CheckStationHasNoPendingTests runs for the target oven. If it returns false, the task is skipped with SkippedNotReady.
5. ASA_Scenario5_CheckChangeApprovalRegistered runs for the target oven. If it returns false, the task is skipped with SkippedGateFailed.
6. ASA_Scenario5_ExecuteStationRecalibration runs the recalibration procedure via the QMS API.
7. ASA_Scenario5_ValidateCalibrationResult checks whether the oven passed acceptance tests. If it returns false, the task is marked ValidationFailed.
8. The task is finalized with outcome and notifications are sent.

flowchart TD
    R["ResolveStations<br/>DueForCalibration"] --> RS{"Station<br/>scheduled?"}
    RS -- No --> NOTASK([No task created])
    RS -- Yes --> A([Task per scheduled station])
    A --> W{"Mon–Fri?"}
    W -- No --> S1([SkippedPreConditionFailed])
    W -- Yes --> B{"CheckMaintenance<br/>WindowOpen = true?"}
    B -- No --> S1
    B -- Yes --> C{"CheckStationHas<br/>NoPendingTests = true?"}
    C -- No --> S2([SkippedNotReady])
    C -- Yes --> D{"CheckChangeApproval<br/>Registered = true?"}
    D -- No --> S3([SkippedGateFailed])
    D -- Yes --> E["ExecuteStation<br/>Recalibration"]
    E --> F{"ValidateCalibration<br/>Result = true?"}
    F -- No --> FAIL([ValidationFailed])
    F -- Yes --> OK([ProcessedSuccess])

Expected Task Outcomes#

Table 4: Scenario 5 Task Outcomes

Simulating This Scenario#

Confirm the Scenario 5 master data is loaded and all baker instances are running on baking-manager before starting. All six DEE Actions must be deployed. The recommended simulation approach is to back each DEE Action with a MES Configuration Entry so you can toggle each condition independently from the MES UI without redeploying code.

Recommended Configuration Entry Paths#

Table 5: Scenario 5 Simulation Configuration Entries

In the shipped sample, the Context Resolution maps station keys Baker-01 and Baker-02 to the MES resources ASA Baker-01 and ASA Baker-02. All downstream DEE Actions use the MES resource name from the task, so the resourceName examples below include the ASA prefix.

To Trigger Processing for One Oven#

1. Set …/CalibrationScheduled/Baker-01 to true (schedules ASA Baker-01 in the Context Resolution).
2. Set …/MaintenanceWindowOpen to true.
3. Set …/NoPendingTests/ASA Baker-01 to true.
4. Set …/ChangeApprovalRegistered/ASA Baker-01 to true.
5. Set …/RecalibrationSucceeds/ASA Baker-01 to true.
6. Set …/CalibrationPassed/ASA Baker-01 to true.
7. Enable the Definition. The Context Resolution returns only ASA Baker-01, so one task is created. On the next polling pass, ASA Baker-01 passes all checks and ASA_Scenario5_ExecuteStationRecalibration runs.
8. The task transitions to ProcessedSuccess.

To Demonstrate the Context Resolution Excluding One Station#

1. Set …/CalibrationScheduled/Baker-01 to true and …/CalibrationScheduled/Baker-02 to false.
2. Enable the Definition. Confirm only one task is created, for ASA Baker-01. No task appears for ASA Baker-02.
3. Set …/CalibrationScheduled/Baker-02 to true and create a new Definition so both stations are now included.

To Demonstrate Precondition Blocking All Tasks#

1. Set both CalibrationScheduled entries to true, then set …/MaintenanceWindowOpen to false.
2. Enable the Definition. Confirm both tasks show SkippedPreConditionFailed so no individual station checks run.
3. Set the entry back to true and the system evaluates tasks individually on the next pass.

To Demonstrate Gate Blocking One Oven While Others Proceed#

1. Set all Configuration Entries to true.
2. Set …/ChangeApprovalRegistered/ASA Baker-02 to false.
3. Confirm ASA Baker-01 proceeds to ProcessedSuccess while ASA Baker-02 stays at SkippedGateFailed.
4. Set ASA Baker-02's approval to true and the task processes on the next pass.

To Simulate a Validation Failure#

1. Set all Configuration Entries for ASA Baker-01 to true, but set …/CalibrationPassed/ASA Baker-01 to false.
2. The action runs but the post-action validation returns false.
3. The task transitions to ValidationFailed. Inspect LastError for the DEE Action output.

To Reset and Repeat#

1. Set …/CalibrationScheduled/Baker-01 and …/CalibrationScheduled/Baker-02 back to false so that the Context Resolution no longer returns those stations.
2. Create a new Definition (the original tasks are in a terminal state and will not re-evaluate). The Context Resolution runs fresh and creates new tasks for any stations that are scheduled.

Troubleshooting#

All DEE Actions Are Fail-Closed#

If any DEE Action throws an error, returns an unexpected type, or times out, the system treats it as a failed check. A runtime error in ASA_Scenario5_CheckMaintenanceWindowOpen skips all tasks on that pass. A runtime error in ASA_Scenario5_CheckStationHasNoPendingTests skips that specific oven's task. Design each action to return false explicitly for expected negative conditions rather than raising exceptions.

DEE Actions Receive the Target Entity as Context#

The Detector, Acceptance Gate, Action, and Post-Action Validation DEE Actions each receive the specific target entity (the Automation Controller Instance and its linked Resource) when they run. Use this context to scope QMS lookups to the correct oven. The Context Resolution and Pre-Condition DEE Actions run without a target entity as the Context Resolution returns the entity list, and the Pre-Condition evaluates a global condition only.

Test Each DEE Action in Isolation Before Enabling the Definition#

Deploy and test each action independently using a DEE Action test runner before creating the Definition. Confirm return types, error handling, and Configuration Entry toggling all work as expected. This avoids situations where a DEE Action bug prevents any task from progressing.

Mixing DEE with Built-Ins#

Not every stage needs to be a DEE Action. This scenario itself uses a native AllowedWeekdays Pre-Condition alongside the DEE Action maintenance window check. If your process has a fixed time window, use AllowedWeekdays and AllowedTimeWindow as Pre-Conditions and reserve DEE Actions for the stages that genuinely require external logic. See Scenario 4 for an example of mixing built-ins with a custom Post-Action Validation.