Summary
Currently, the Automation pattern in EMN only accepts Events as input:
Event(s) → Automation → Command → Event(s)
This issue proposes extending the Automation pattern to also accept a Query result / Read Model (View) as input:
Query/View → Automation → Command → Event(s)
Background and Motivation
The Automation pattern is described as a robot reading a todo list — it observes state and reacts without user intervention. This metaphor is powerful and accurate, yet the current spec does not fully reflect it.
A todo list is not a raw event stream. It is a projection — a read model derived from events that represents the current work to be done. The automation reads entries from this list and, for each one that meets a condition, issues a command (marking that todo as done after successful exectuion, when we receive an event as a result). The events resulting from those commands are what update the projection — completing the cycle.
This is precisely the Query/View pattern in CQRS. Yet, current EMN connection rules only allow events to feed into an automation (rule 3), and queries can only flow to views or external systems (rule 5). There is no way to connect a read model as the input to an automation, even though that is often exactly what the "todo list" metaphor implies.
Concrete Example
Scenario: Send a payment reminder to all customers with overdue invoices.
| Element |
Type |
Notes |
InvoiceCreated, PaymentReceived |
Events |
Feed the projection |
Overdue Invoices |
Query → View |
The todo list: projected from events, one entry per unpaid invoice |
Payment Reminder Scheduler |
Automation |
Reads the view; for each overdue invoice, acts |
SendPaymentReminder |
Command |
Issued per item on the todo list |
PaymentReminderSent |
Event |
Marks the todo as done; updates the projection |
With the current spec, this pattern cannot be expressed in EMN. The automation has no way to connect to the Overdue Invoices read model.
References
Summary
Currently, the Automation pattern in EMN only accepts Events as input:
This issue proposes extending the Automation pattern to also accept a Query result / Read Model (View) as input:
Background and Motivation
The Automation pattern is described as a robot reading a todo list — it observes state and reacts without user intervention. This metaphor is powerful and accurate, yet the current spec does not fully reflect it.
A todo list is not a raw event stream. It is a projection — a read model derived from events that represents the current work to be done. The automation reads entries from this list and, for each one that meets a condition, issues a command (marking that todo as done after successful exectuion, when we receive an event as a result). The events resulting from those commands are what update the projection — completing the cycle.
This is precisely the Query/View pattern in CQRS. Yet, current EMN connection rules only allow events to feed into an automation (rule 3), and queries can only flow to views or external systems (rule 5). There is no way to connect a read model as the input to an automation, even though that is often exactly what the "todo list" metaphor implies.
Concrete Example
Scenario: Send a payment reminder to all customers with overdue invoices.
InvoiceCreated,PaymentReceivedOverdue InvoicesPayment Reminder SchedulerSendPaymentReminderPaymentReminderSentWith the current spec, this pattern cannot be expressed in EMN. The automation has no way to connect to the
Overdue Invoicesread model.References
docs/reference-guide/patterns.md)docs/reference-guide/language-specification.md)