Present and Future of Nuxeo Automation, the Business Logic Module of Nuxeo Platform

Today we will talk about the “Business Logic” area of the Nuxeo Platform - the “Nuxeo Automation” module.

Nuxeo Automation: The Nuxeo Platform Business Logic Implementation Framework

Nuxeo Automation provides an engine that knows how to execute operations and chains of operations. An operation is a granular instruction that “does something” in the platform. The core part of the platform exposes a set of operations, and each new module can (and should) also expose its own list of operations.

Your own customization code can even add new operations. Overall, the list of existing operations represent the coarse-grain Nuxeo Platform’s API. Since operations appeared progressively with the uses cases the Nuxeo Platform was confronted by, their signature fits quite well in most situations. Implementing your business logic and custom rules becomes easy. You just compose chains of existing operations.We plugged Automation into many places in the Nuxeo Platform:

• User interface, calling a chain from a button,
• Workflow, with the possibility to fine tune at which moment of your process which chain is executed,
• Event Bus, with ability to declare Event Handlers. These ones are equal to triggers in a database. They fire the execution of automation chains.
• REST calls, via the Command Endpoint of our API. This one exposes each operation on the nuxeo/site/automation endpoint.

You can read a full introduction on Automation on the Nuxeo documentation site.

Strengths and Weaknesses of Nuxeo Automation

After four years, we start getting good feedback on Automation. Among the likes, we have:

• The ease of the use of the REST bridge (Command) along with the clients (Java, Javascript, etc.).
• The “no dev” implementation cycle. Consider there is no compilation. Everything is declarative. That makes programming the repository accessible to a wide range of content management buddies!
• The extended coverage of this API, there is an operation for everything :) (well, nearly ;))
• A layered API. Operations isolate newbie users from the Core Java API of the backend components. That way the user is never lost in some low level lists of methods, where she would feel unqualified for determining which one to use.
• The ability to write your own operations the same way Nuxeo Platform developers wrote the built-in ones.

Among the dislikes:

• Loops and conditions - yes, the basics of programming - are a bit “loopy” to write in Automation. You can use the Run Chain and other execution flow operations. Our CTO sometimes makes fun of it saying it is a bit like Grafcet programming ;-)
• Debugging could be improved, with a step by step mode.
• The “Run Script” operation requires you to write MVEL for which you must fully name every class. This is a bit cumbersome.
• Sometimes you have 20+ operations in your chains and it starts getting complex! This point is also a sign of success :)
• The input and output types make it sometimes hard to put “circle into squares”. The piping logic is an ingredient of the success of Automation, making the model comprehensive. But sometimes, you want to deal with a bit more different structures than blob, blobs and document, documents!

Improving the Edifice Stone by Stone

We are working on all that feedback.

• We added a trace tool for the Nuxeo Platform 5.8. It allows you to see, when enabled, the full stack of your chain execution. We still need to improve the MVEL expression resolution in those stacks though.
• We have recently added the ability to declare parameters in a chain. This will help you write shorter and more reusable chains, easing the maintenance of your Studio project. So far, you can leverage those parameters with operations from the Execution Flow category (Run Chain, etc.) or doing REST calls.
• In the future you will be able to fill parameter values on all chain binding places. Nuxeo Studio will allow this on the Workflow, Event handlers and User Actions features.
• We will expose Exception Management in Studio. Studio users will have the ability to define what happens when the Automation service catches an exception in a chain.
• The Nuxeo Studio 19 release brought some evolutions on the Automation module. We targeted user experience improvement:
  • The “read” mode now displays parameter values in a compact mode. That way you understand immediately what a chain does. A bit like what happens when you open a Java class
  • The operation edit mode (with a new “edit all operations” action) has also been made more compact than before. We reworked the position of the operation description links and online help links. The effect is that you see more operations on the screen than before, even in edit mode.

• A new text mode will be added for the Studio 20 release, with automated conversion of automation chains to YAML format and vice verse. That way, one can easily export a chain definition for posting on a support ticket or on Answers. You’ll also be able to directly edit the YAML definition, as long as you respect the grammar. It will be a great way for you to import into your project samples we will make available via the documentation. This is going to be a fabulous exchange format!
• Finally, the new Nuxeo AP Playground provides a way to test each and every operation available via the Command endpoint.

Experimenting on a Long Awaited Feature

One of our consultants, Michaël, has recently come up with a concrete prototype of a long time expected feature. He has tooled up the implementation of pop-ups that display forms that are submitted to automation chains. The result is available on GitHub in the labs area. It already helps a lot although it is not yet in the supported platform. No doubt the roadmap will eat it some day.

And Sometimes Breaking Ground!

One of the great things we would like to do is to add a new binding to automation, besides REST, Workflow, UI, etc.: a script binding! Instead of using script in automation, what about binding automation to a scripting environment ? Thierry Delprat, our CTO, has recently made a more concrete proposal on that one. The plan is to provide a scripting sandboxed environment. In this environment, the only way to call a service of the platform would be via a bound operation. That way, looping, conditional and input/output type handling would be made much easier. It could look like:

mailDocument = Document.Create(mailFolder, "{
    type : 'MailMessage',
        name : mailDocumentName,
        properties : {
        'messageId' : messageId,
                'dc:title' : subject,
                'mail:recipients' : recipients,
                'mail:sendingDate' : sendingDate
    }}");

for (attachment in attachments) {
    Blob.Attach(attachment, "{document : mailDocument,
                             'save' : false,
                             'xpath' : 'files:files'}");
}
Document.Save(mailDocument);

We are pretty confident this approach will meet with great success and would be yet a new way to leverage this great module!

Do not hesitate to share your feedback and ideas on this post.