Archive for the ‘content automation’ tag
Like most parts of the Nuxeo Platform, we designed Nuxeo Drive as something extensible. And there are indeed different ways you can customize it to fit your needs. I’ll be writing more posts about how to extend Nuxeo Drive in the coming weeks. Today we’ll take a look at what you can do by simply overriding the different operations used by Nuxeo Drive.
Let’s take a very simple example. When Drive detects a conflict, the file is renamed a certain way. This is done using the NuxeoDrive.GenerateConflictedItemName operation. So what we can do is override this operation to specify our own way of renaming a file. Right now what it does is split the name of the file and the extension. Then we generate the contextSection. It’s the user’s first and last name concatenated with the current date formatted as “yyyy-MM-dd hh-mm”. Then it puts them back together.
There’s an interesting question today from milonette, asking how to access labels with MVEL. Sometimes the Content Automation API doesn’t provide everything you need out of the box, hence the question. But the good news is this API is extensible.
While some functions are already available in the automation context, there is currently nothing to access the resource bundles. We’ll need to add our own function into it. This is quite easy to do. First we need to write the new function we need, then we’ll write an operation that adds this function to the content automation context.
Our localized function needs different parameters. We want the locale, the name of the resource bundle, the key of our message and some optional parameters. Here’s a simple implementation:
Now that I have my function, I need to create an operation that will make this available within the automation context:…
Today we have a question from thexman who asks how he can retrieve the list of all possible subject values with content automation. His first thought was to use NXQL, Nuxeo’s query language, which makes perfect sense when you are searching for something. Unfortunately, NXQL is used to search the content of documents, and all the subject values are not stored as documents. The values proposed by Nuxeo when choosing a subject are all stored on what we call a directory. Here’s a definition taken straight from our documentation:
In Nuxeo EP, a directory is a source of (mostly) table-like data that lives outside of the VCS document storage database. A directory is typically a connection to an external data source that is also accessed by processes other than Nuxeo EP itself (therefore allowing shared management and usage).
A vocabulary is a specialized directory with only a few
Now back to the question, how do you retrieve other metadata? The question was about the Android connector but it applies to content automation. The short answer: We have special headers. Here’s the definition straight from the documentation:
This header can be used whenever a document will be returned by the server. The header is forcing the server to fill the returned document up with data from schemas that match the X-NXDocumentProperties filter. So, X-NXDocumentProperties is a filter of schemas.
Here’s a common question: Can an external web service call be included in an automation chain?
There are many uses cases to this. You may want to integrate with an existing application or simply retrieve some metadata from a single web service. This can be a good way to enrich metadata about a specific kind of document. Let’s say, for instance, that you are managing a book collection in Nuxeo. Every book as an ID called ISBN, which stands for International Standard Book Number. It’s a unique numeric commercial book identifier. Using this ID, you can retrieve more information about the book. The openlibrary.org website has a REST API that gives you information from an ISBN. So, all you have to do to use this in an automation chain is to create an operation that makes a call to this API. As Vlad answered, we have some documentation for …
Today we have someone asking how to attach extra files to a document using Content Automation. So I’m going to do this using nuxeo-automation-client. This is a jar that you can add as a dependency to your Java application and that gives you a nice API to make content automation call to a Nuxeo server.
I’ve written a small example that opens a Content Automation HTTP session to a local Nuxeo server as Administrator and execute an operation that adds a file to an existing document. Those operations are wrapped in the DocumentService. This class hides part of the complexity to make an operation request. You can take a look at our documentation for the complete details. Now here’s the code sample, most of it is explained in the comments:…
I met this week Jack (not the real name) one of our System Integrators tech lead for a projects review. Agenda of such a meeting is pretty simple: we review and debrief each project Jack has recently worked on on both functional and technical angles. It’s a win-win meeting : we alert on features the platform already provides and that Jack has missed, while Jack gives us feedback and ideas of improvements on the platform and finally we identify potential contributions from Jack’s work.
One of the points of the discussion on this meeting was about the use of Automation. Jack explained to me that while automation is great for many things, sometime it is simpler to just produce a Java class than to try to chain too many operations. I obviously agreed on this point. He then explained to me what the value of the use of the duo …
Here’s an interesting question from Narcis. He asks how he can test an operation. Quality is of paramount importance here at Nuxeo, as you may have gathered from a previous blog post. Most of us use TDD (Test-driven development), and hence rely heavily on unit tests. We try to make developers’ lives easier by giving them different test cases or runners to use in their tests. Take a look at our documentation on unit tests.
As Benjamin said in his answer, there are a lot of examples in our source code. Let’s go through one of them. I’ve chosen the simple LoginAsTest.
Let’s start with the class annotations. You might be familliar with the @RunWith annotation as it figures in Junit4. The tests run in the specified class instead of the default Junit runner.
Moving to @Features. Here’s an extract from our documentation:
One of the main assets of the Nuxeo Platform is the richness of its APIs: CMIS, REST, WebServices, WSS, Content Automation. Content Automation is a subset of our REST API and is probably the most powerful and simplest means to access Nuxeo. Its strength and richness lies in its ability to provide access to all the services offered within the Nuxeo Platform, but also because of how it integrates with other Nuxeo tools, such as Nuxeo Studio for customizing it, or Nuxeo IDE for extending.
From our wiki:Content Automation is a Nuxeo service that exposes commons actions you do on a Nuxeo application as atomic operations so that one can assemble them to create complex business rules and logic, without writing any Java code.
In other words, content automation provides a high level API over Nuxeo services – an API made up of operations that can be assembled into