State of ECA: What's new in Drupal's new rules engine with beta-2

Development in ECA has been intense over the last 4 months, since we first presented this new module to the Drupal community. Let's catch up with all the features and ideas, that already made it into it.

Who is working on it

In addition to the code maintainers Daniel, Jürgen, Max and Richard we also have supporting team members like Nico who contributed a nice logo, Ralf who helps us to get the word out and provides feedback - and a few others who already started using ECA and report back in the issue queue with issues and feature requests. This helped us a lot to stay focused and move towards a first stable release in such a short period of time.

How we moved forward

Although still in early stage, we optimized the core components by changing how ECA stores its config entities, as well as the caching mechanism to further reduce the performance impact when using ECA in production environments. The overhead ECA brings to your live site is negligible, it only consumes resources if something needs to be done as a result of configured events that your ECA models want to react upon.

The code structure got an overhaul too. There is now ECA Core which provides the config entity handling, the ECA processor, all required plugin managers and numerous interfaces, traits and base classes used by the now 10 submodules that comes with ECA:

• ECA Base: provides access to context, cron, custom events, state system and tokens
• ECA Config: integrates with Drupal's CMI
• ECA Content: supports content entities, fields API and more tokens
• ECA Form: integrates with Drupal's form API
• ECA Migrate: integrates with events of the migrate module
• ECA Misc: make available events from Symfony's kernel, Drupal core and the routing system
• ECA Queue: allows to enqueue tasks for asynchronous or scheduled processing
• ECA User: integrates with user account related events and actions like login, logout, cancel, account switching and roles
• ECA Views: allows processing of views with further processing or exporting of the result set
• ECA Workflow: integrates into Drupal's content moderation framework

Note that all of ECA depends solely on Drupal core and the new remarkable Context Stack module from Max, which we extracted from the ECA code base simply because its functionality is useful for other tools too. This is intentional so that you can easily onboard ECA without the requirement to have any other components being installed or enabled.

General features built into ECA core

With all the submodules enumerated above, you already get comprehensive lists of events, conditions and actions from either ECA or from Drupal core. Additionally, ECA has baked-in support for crucial APIs and functionality, that needs highlighting:

• Context Stacks: each process triggered by any event as well as any action of such processes get executed within their own (stackable) context, so that ECA can restore the context after execution to the state it was right before processing. This not only makes each process predictable, but also allows to forward the current context into the queue, should a model want to process actions asynchronously.
• Caching: all ECA models get cached in a special way such that ECA can determine, with almost no overhead, whether any of the triggered events in your Drupal site needed to be processed by ECA.
• Loops: by default, actions in an ECA model operate on some data object, which often is something like a content entity, a route, an HTTP request or any other arbitrary value. If you provide a list of objects instead of a single instance, then ECA automatically loops over each of them with the subsequent actions in the process model.
• Logging: everything in ECA is built to provide detailed log information, which is written to Drupal's logger service. It depends on your own setup, if that logging information is being written to watchdog, syslog or elsewhere. To avoid overwhelming logs just from ECA, you can configure the level of log information coming from ECA with a single setting, defaulting to error messages and exceptions only.
• States: reading and writing from and to Drupal's state system helps to persist some data for later use, even if this is required over a longer timeframe.
• Tokens: Drupal core's token environment is already pretty powerful. ECA builds on top of it and enhances it by introducing DTOs (Data Transfer Objects). This mechanism allows any event, condition or action in an ECA model to store any data into the token environment so that subsequent components of that model can access that data for further processing if needed.
• TypedData: one of the most significant features and presumably the most used conditions and actions are around entity fields. Those fields can be more complex than just storing individual values, they can even store values with any cardinality. To allow ECA models generic access to any component of such fields, the TypedData API is the ideal tool provided by Drupal core, which has been utilized by ECA.
• Recursion prevention: it may happen unintentionally, but ECA models, like any other rule definition, can quickly end up in a recursion. The simplest use case might be an entity update, which results in a process that makes additional modifications to that entity - being another entity update that already starts a recursion. As this would always lead towards an infinite loop, something you prefer not to experience on your production site, ECA inevitably prevents that from happening. Even at the cost of preventing you from building certain models. However, there should always be a way around that - and the issue queue on drupal.org or this Slack channel are great places to seek help in such situations.

Working on test coverage

We've already started building tests, from simple unit test to kernel and functional tests, but also a powerful framework to test any ECA model regardless how complex they are. This helps us to keep moving with ECA development while ensuring that existing functionality remains intact. Having said that, there's a lot that needs to be done to bring the test coverage to the necessary level. This is what we're focussing on in the weeks to come.

Integrating with other modules

Now that ECA core with all its integrated submodules stabilizes its own APIs, the time is right to start working with other maintainers of popular and useful modules, to make their functionality available to ECA and its models. The list of modules, we would like to integrate with, is being tracked in this issue and if anyone wanted to add more modules to the list, this is the right place to get the ball rolling.

Talking about the UI provided by modellers

As powerful and feature rich the ECA framework already is, it still requires the UI component which allows users to create and maintain their models. This is a separate task and completely decoupled from ECA as the backend processor. The component we're talking about here is called a modeller. And there can be more than just one. BPMN as one of the popular standards to describe business processes is supported by a variety of applications that allow to work with such models, two of which have already been integrated with ECA: Camunda and BPMN.iO. But others, even such that are not based on BPMN, can be integrated as well, and we hope to see initiatives who want to get started on such modeller development.

However, what matters to all the existing and future modeller UIs, is a great user experience (UX). This is what we haven't worked on yet for the existing integrations, and that's one of the areas where we have to spend more resources - but we also need help for that. The existing ECA team is busy with all the processing and background tasks. To move more quickly with the UI too, we're seeking for help.

Conclusion

A lot has been achieved! And I mean, A LOT. The team is really proud of it and feedback we receive is very positive too. We even consider ECA very close to being feature-complete for its 1.0 release soon. Yes, we admit, there is a way to go before it will be usable by "mainstream" users. The UI components mentioned above as well as comprehensive documentation are just the 2 main tasks that come to mind.

Having said that, it turns out that ECA not only accomplished its original objective to provide a "Rules" replacement for Drupal 9 and beyond, it also delivers benefits above and beyond that mission with 2 additional wins:

1. Reduce the likelihood of writing a custom module for a client, only because you required a hook or a form alter function, that can now also been done with ECA.
2. Eliminate the requirement for a number of helper modules that provide simple functionality like redirects after login or validating, stripping, trimming or otherwise manipulating certain fields.

In other words, the feature set provided by ECA is huge, yet it can reduce the complexity of any Drupal installation out there. And while doing it this way, ECA also improves transparency and maintainability by storing all the rules in one place, where it can be visualized, reviewed and even moderated so that all stakeholders get a better understanding of what's being implemented and configured at any given time. It also increases accessibility for users who understand the business logic implemented into a Drupal site but wouldn't ever be able or willing to dive deep into Drupal logic or even code base.

Let's move on with ECA, it's got that far that we're all very excited and motivated to move it over the finish line. Watch this space to stay up to date - or reach out on drupal.org or in Slack, if you either have ideas, feature requests or resources to help us get all this done.