## Problem / Motivation The `orchestration_eca` submodule currently bridges ECA and the Orchestration module in one direction only: it exposes ECA models _as_ Orchestration services, so external callers can invoke ECA workflows via the Orchestration HTTP API. The reverse direction is missing. There is no ECA Action plugin that allows an ECA model to `_invoke_` a registered Orchestration service. This means ECA cannot use its rich event and condition system to trigger any of the services registered by other `ServicesProviderInterface` implementations. Current: External → Orchestration → ECA (ECA as a service) Proposed: ECA → Orchestration → any ServicesProvider (ECA as a trigger) ## Proposed Resolution Add a new configurable ECA Action plugin: **Execute Orchestration service**. The action would: - Present a configuration form listing all services registered with `ServicesProviderManager::getAllServices()`, allowing the editor to select a target service. - Accept a token-aware parameter input mapped from the current ECA token environment. - Call `ServicesProviderManager::executeService($serviceId, $config)` directly via PHP — no HTTP round-trip needed. - Optionally push the service result back into the ECA token environment (e.g. as `[orchestration_result]`) so downstream ECA actions can consume it. ## Practical Use Case Any module that implements `ServicesProviderInterface` and registers its functionality as Orchestration services can immediately be triggered from any ECA model — reacting to any of ECA's 230+ Drupal events, filtered by ECA gateway conditions — without requiring a dedicated ECA integration module of its own. Example ECA model: [Node presave event] → [Bundle = 'article'?] → [Execute Orchestration service: my_service] ↓ [Send email with [orchestration_result] ]