# Controller Extensibility

## Overview

The workflow `doCommonLogic` is a generic, event-agnostic subworkflow — used by `ItemTransferIn` and `ItemTransferOut` (see [Event Handling](events.md)). It reads the triggering event's name, looks up a matching `CAMX_<EventName>_useDEE` key in `IoTMetadataDefinition`, and invokes that DEE. This means any additional standard event exposed by the CAMX driver can be connected to a DEE the same way, without driver or code changes — only an Automation Workflow and a configuration entry.

## Additional Template Events

| Event Name | URI | Description |
|------------|--------|-------------|
| EquipmentAlarm | http://webstds.ipc.org/2541/EquipmentAlarm.xsd | Equipment enters an alarm condition |
| EquipmentError | http://webstds.ipc.org/2541/EquipmentError.xsd | Equipment enters an error condition |
| EquipmentHeartbeat | http://webstds.ipc.org/2541/Heartbeat.xsd | Periodic liveness signal from the equipment |
| EquipmentRecipeSelected | http://webstds.ipc.org/2541/EquipmentRecipeSelected.xsd | Equipment selects a recipe |
| EquipmentInformation | http://webstds.ipc.org/2541/EquipmentInformation.xsd | Equipment reports general information |

!!! info "Requirements"
    Extra events need to be properly defined and assigned in the driver definition or in the workflow itself using the `Custom Template` task.
    To enable a specific event-driven feature, an `IoTMetadataDefinition` entry should be added (similarly to ItemTransferIn and ItemTransferOut).

## How doCommonLogic Resolves the DEE

When invoked, `doCommonLogic`:

1. Reads the resource name (`LinkedEntityName`) from persistency
2. Reads the triggering event's name from its `EventType` input
3. Looks up `IoTMetadataDefinition` for a `CAMX_<EventName>_useDEE` entry matching that event name
   - If none is found, the workflow ends without calling any DEE
4. Optionally reads `CAMX_<EventName>_retries` for the max retry count (default: 1)
5. Calls the configured DEE with `ResourceName`, `EventType`, `Attributes`, and `Extensions`
6. Retries on retriable errors (deadlock, data changed, connection refused) up to the configured max

## Wiring a New Event to doCommonLogic

To connect an additional standard event (e.g., `EquipmentAlarm`) to `doCommonLogic`:

1. **Create a new Automation Workflow** for the event (e.g., `EquipmentAlarm`)
2. **Add an "On Equipment Event" task**, setting its Event Name to the target event (e.g., `EquipmentAlarm`)
3. **Add a "Merge Object" task** (optional) to combine the event properties you want to expose to the DEE into an `Attributes` object — e.g., `alarmId`, `alarmType`, `laneList`, `zoneList`
4. **Add a "Call SubWorkflow" task** targeting `doCommonLogic`, wiring:
   - `EventTypeIn` ← the "On Equipment Event" task's raw event output
   - `AttributesIn` ← the "Merge Object" task's output (or leave unbound if not needed)
   - `ExtensionsIn` ← the "On Equipment Event" task's `Extensions` output
5. **Save and publish** the workflow
6. **Configure** `CAMX_<EventName>_useDEE` (and optionally `CAMX_<EventName>_retries`) in `IoTMetadataDefinition` for the resource
7. **Restart the Automation Controller**

### Example: Enabling EquipmentAlarm

```text
Resource: MES Resource

CAMX_EquipmentAlarm_useDEE = CustomAlarmNotificationDEE
CAMX_EquipmentAlarm_retries = 3
```

!!! info "Driver Definition"
        The properties declared and defined in the scope of the Driver Definition should represent the expected event attributes.

!!! warning "Extensions"
        Should there be extensions within the event, they shall be exposed as a JSON object in a variable named "Extensions".