Scenario 1 - Change Automation Manager#

Overview#

This scenario shows how to use the Change Automation Manager action to move Automation Controller Instances from one Automation Manager to another without interrupting production. The definition waits until each instance enters a safe, stable state before performing the move, allowing infrastructure changes without a forced shutdown.

In this example, three cookie factory mixing-line instances move from the mixing-manager-legacy Automation Manager to mixing-manager-nextgen during a year-end holiday shutdown. This operation runs in parallel with Scenario 2, which handles the molding controller update during the same window.

When to Use#

• Host maintenance - OS patching, hardware replacement, or software upgrades on the Manager host that require the service to stop.
• Decommission - retiring an older Manager host and consolidating all its instances onto a replacement.
• Load rebalancing - redistributing instances across Managers when one host is over-utilized or when new capacity is added to the fleet.
• Network topology change - moving instances to a Manager running in a different network segment or closer to the equipment after an infrastructure reorganization.
• Disaster recovery - evacuating instances from a degraded or at-risk Manager to a healthy standby before a failure forces an unplanned outage.

Example#

This is the first operation in the year-end platform refresh. On 28 December, the holiday shutdown begins and infrastructure consolidation starts: all three mixing-line instances currently running on mixing-manager-legacy must move to mixing-manager-nextgen before production resumes. The legacy host is being decommissioned. The other holiday operation, the molding controller update, runs in parallel on separate Resources; see Scenario 2.

The factory is consolidating its mixing infrastructure. The older host running mixing-automation-manager-legacy is being decommissioned; all instances must move to the newer, higher-capacity host running mixing-manager-nextgen. The factory has the following context:

• Resources: 3 mixers (ASA Mixer-01, ASA Mixer-02, ASA Mixer-03).
• One Automation Controller associated with all Resources: MixingController [A.1].
• Source Automation Manager: mixing-manager-legacy (being decommissioned).
• Target Automation Manager: mixing-manager-nextgen (replacement host).

graph LR
    subgraph legacy["mixing-manager-legacy (source)"]
        M1[Mixer-01]
        M2[Mixer-02]
        M3[Mixer-03]
    end
    subgraph nextgen["mixing-manager-nextgen (target)"]
        M1T[Mixer-01]
        M2T[Mixer-02]
        M3T[Mixer-03]
    end
    M1 -->|migrate| M1T
    M2 -->|migrate| M2T
    M3 -->|migrate| M3T

Prerequisites#

Before creating the Definition, confirm the following:

• Load the Scenario 1 Automation master data into MES. It creates the MixingController [A.1] Controller, mixing-manager-legacy and mixing-manager-nextgen Manager records, and all three mixing instances (master data package: 01-automation-masterdata.json).
• mixing-manager-legacy host is running and the three mixing instances are active and connected.
• mixing-manager-nextgen host is running, reachable, and has sufficient capacity for the migrated instances.
• Each Automation Controller Instance is linked to a Resource with a valid state model that includes states such as Standby or Scheduled Down.
• MES Configuration Entry /Cmf/Tutorials/AutomationScheduleAction/Scenario1/NumberOfAvailableSlots exists and is set to the number of migrations you want to allow in this run. Use 3 if you want all three sample instances to pass the capacity gate.
• Notification templates ASA PreAction Template, ASA Success Template, ASA Failure Template, and ASA Ignored Template exist in MES if you intend to use notifications.
• DEE action ASA_Scenario1_CheckNextgenManagerHasCapacity is created and deployed in MES before enabling the Definition (see How To: Create or Import a DEE Action).

Configuration#

Why This Pattern#

This Definition uses the following combination of components:

Table 1: Scenario 1 Component Design

Create the Definition#

Open Automation Scheduled Action and select Create.

Refer to Create Definition for more information.

Tab 1 - General Data#

Start by filling in the general definition fields.

• Give it a name like CF_Migrate_Legacy_To_Nextgen and a description that explains its purpose (for example, "Move cookie line instances from mixing-manager-legacy to mixing-manager-nextgen when lines are stable and ready.")
• Set Is Enabled to Disabled for now; you'll enable it after verifying the task list.
• Set Validity to 2 days.

For Context, select Automation Manager and enter mixing-manager-legacy as the target Manager. All instances currently hosted by this Manager become targets. One task is created per instance.

For the Detector, select Entity State In List and add Scheduled Down to the state list. Adjust the state list to match your factory's state model.

For the Action, select Change Automation Manager and set the target to mixing-manager-nextgen.

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

Table 2: Scenario 1 Notification Templates

Tab 2 - Pre-Conditions#

Select twice to add the following Pre-Conditions in this order:

1. Allowed Weekdays - Set the weekdays to Saturday and Sunday.

2. Allowed Time Window - Set the window to 00:00–06:00.

Tab 3 - Acceptance Gates#

Select twice to add the following Acceptance Gates in this order:

1. Ready Delay - Set the delay to 300 seconds. The line must hold the ready state for 5 minutes before the migration runs. This prevents acting on brief state transitions during a normal production pause.

2. DEE Action - Enter ASA_Scenario1_CheckNextgenManagerHasCapacity as the action. This verifies that mixing-manager-nextgen has enough capacity before the migration proceeds. If the action returns false, the task stays at SkippedGateFailed until capacity is available.

Tab 4 - Post-Action Validations#

Select and select Max Startup Time. Set the timeout to 300 seconds. This confirms the migrated instance returns to a running state within 5 minutes on the new Manager.

How It Works at Runtime#

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

1. Context resolves all instances currently hosted by mixing-manager-legacy and creates one task per instance.
2. Weekday and time-window Pre-Conditions are checked against current UTC time. Tasks are skipped outside the allowed window.
3. The Detector checks whether the linked entity state is Standby or Scheduled Down.
4. The ReadyDelay Acceptance Gate confirms the line has remained in that state for at least 5 minutes.
5. ASA_Scenario1_CheckNextgenManagerHasCapacity confirms mixing-manager-nextgen has sufficient capacity to accept the instance. If it returns false, the task is skipped with SkippedGateFailed and retried on the next pass.
6. The Action moves the instance to mixing-manager-nextgen.
7. Post-Action Validation waits up to 5 minutes for the instance to reach a running state on the new Manager.
8. The task is finalized with outcome and notifications are sent.

flowchart TD
    A([Task per instance]) --> B{"Weekend?<br/>00:00-06:00 UTC?"}
    B -- No --> S1([SkippedPreConditionFailed])
    B -- Yes --> C{"Line state =<br/>Standby or<br/>Scheduled Down?"}
    C -- No --> S2([SkippedNotReady])
    C -- Yes --> D{"Stable 5+ min?"}
    D -- No --> S3([SkippedGateFailed])
    D -- Yes --> G{"nextgen manager<br/>has capacity?"}
    G -- No --> S3
    G -- Yes --> E[ChangeAutomationManager]
    E --> NOP{"Already on<br/>mixing-manager-nextgen?"}
    NOP -- Yes --> IGN([IgnoredNoOp])
    NOP -- No --> F{"Running within<br/>300 s?"}
    F -- No --> FAIL([ValidationFailed])
    F -- Yes --> OK([ProcessedSuccess])

Expected Task Outcomes#

Table 3: Scenario 1 Task Outcomes

Simulating This Scenario#

Confirm that all three instances (ASA Mixer-01, ASA Mixer-02, ASA Mixer-03) are running and communicating on mixing-manager-legacy, and that mixing-manager-nextgen is running and has capacity.

This scenario uses EntityStateInList as the Detector. Readiness is controlled by changing the Resource state and no file operations are needed.

To Trigger Processing for One Line#

1. Navigate to the Resource, for example ASA Mixer-01.
2. Transition its state to Scheduled Down.
3. Open Automation Scheduled Action Task and confirm IsReady becomes true for that task.
4. Wait 5 minutes. The ReadyDelay Acceptance Gate passes, then ASA_Scenario1_CheckNextgenManagerHasCapacity is evaluated. Capacity is read from the MES configuration value /Cmf/Tutorials/AutomationScheduleAction/Scenario1/NumberOfAvailableSlots. If the value is greater than 0, the Acceptance Gate passes, the slot is reserved (value decremented by 1), and the task executes ChangeAutomationManager. Set it to 0 to simulate a full target Manager.
5. Confirm the instance is now hosted by mixing-manager-nextgen in the Automation Controller Instance record.
6. The task transitions to ProcessedSuccess.

Repeat steps 1–6 for the remaining Resources (ASA Mixer-02, ASA Mixer-03). Each Resource is processed independently as it reaches and sustains the ready state.

To Observe the Gate Countdown#

Open the task and watch ReadyStateChangedAt. The Acceptance Gate requires this timestamp to be at least 5 minutes in the past before the action runs. If the line leaves the ready state before the Acceptance Gate passes, ReadyStateChangedAt resets and the countdown starts over.

To Observe the Ignored Outcome#

Before enabling the Definition, manually move one instance to mixing-manager-nextgen directly from the Automation Controller Instance record. Enable the Definition and the task for that instance transitions immediately to IgnoredNoOp because the target is already in the desired state.

To Reset and Repeat#

1. Transition the Resource state back to Running.
2. In the Automation Controller Instance, move the instance back to mixing-manager-legacy.
3. Create a new Definition (the original tasks are in a terminal state and will not re-evaluate).

Troubleshooting#

Lines Without a State Model#

EntityStateInList requires a valid MES state model on the linked Resource. If a line has no state model, the Detector fails closed and the task is permanently skipped.

Use DefinedInWorkflow or CustomDeeAction as the Detector instead when a state model is not available.

Inconsistent Target Mapping#

Every Automation Controller Instance must map cleanly to a single Resource. If the mapping is inconsistent, task creation fails for that target. Verify Resource assignments in the Automation Controller Instance before enabling the Definition.

Piloting the Migration#

Before pointing the Context Resolution at the full Automation Manager, test with a single instance by using Context = AutomationController targeting one Automation Controller. Confirm the outcome is Processed, then switch to Context = AutomationManager to process the rest.