We proudly announce that AnswerModules has recently joined OpenText’s Third Party Solutions program, and that our flagship product, ModuleSuite, will be available for purchase from OpenText’s sales representatives worldwide starting as of May 2016.
This is an important milestone and a great achievement for AnswerModules. Our focus has always been on innovative and enabling technologies in the EIM field. ModuleSuite is a comprehensive solution for rapid application development on Content Server, which includes all the tools you will need to extend, tailor, and enrich your Content Server experience.
We can’t honestly imagine a better moment to be included in OpenText’s price book: the latest release, OpenText Suite 16, is amazing and we are thrilled to discover what customers will be able to achieve combining it with our solutions. You will be thrilled too.
It has been a while since my last post on this blog, but I hope you don’t think I have been lazy.
There is frenetic activity going on behind the scenes at AnswerModules. ModuleSuite 1.7 has been around for a while, with all its revolutionary features. And the team is now deeply concentrated on the next big things.
In less than ten days we will be boarding a plane heading to Las Vegas, NV, to attend OpenText Enterprise World 2015, which we are proud to sponsor once again. We will have a chance to meet some of the world’s most knowleadgeable minds in the EIM field, and really wanted something new to show.
Today we are excited to share a preview of one the new tools we have been working on lately, that will be part of the new ModuleSuite 2.0.
To introduce you to the topic, I will take the lead from various requests I’ve come across recently on the AppWorks Developer community.
Here is one that caught my attention (here the original post). The main focus is the following: “Is there a way to request category information when querying subnodes? Or do you have to make an additional calls for the category information.”
The reason of my interest lays in the fact that the most efficient answer to this question (and to many other similar ones I’ve heard that concerned integrating with Content Server through REST APIs) is to create one’s own request handler to address the specific need.
The problem with this solution is that putting it in practice is not practical at all, as it involves low-level OScript coding in Content Server, which requires some very specific skills.
In the past I have already discussed solutions to this sort of problems by the means of using Content Script. An objection to this could be: “Ok, it’s neat, but we are still talking about writing scripts..”. What I want to show you today is how easy this can become in the very next future.
I am proud to introduce you to the brand new Visual Editor for Content Script.
This new ground-breaking tool is exactly what it seems: a drag&drop, visual editor to manage Content Script objects.
But let me show you in practice how the above problem can be solved: without having to see _any_ actual coding.
Hope you enjoy, and be prepared for the next updates!
Yesterday I managed to find some time to dedicate to my explorations and decided to try to channel my previous experience into something new, but with an immediate practical use. Having had a chance to give a close look at Google Drive REST APIs lately, I fancied of an application capable of synchronizing contents between Google Drive on one side, and Content Server on the other.
The app I had in mind should have been able to keep in synch two different spaces, one on Content Server and its corresponding space on GDrive, and:
provide basic search functionalities on both locations;
keep track of the connection between corresponding documents on the two repositories;
provide fast feedback on the status of the document: if new versions where added since last synch, surface that information to the user and prompt for action;
be capable of instantly re-synchronizing contents (in both directions);
allow easy drag&drop of new contents in the repositories.
Yesterday I posted about my experience with Content Server REST Services: a practical introduction to consuming REST services and the ease of extending the standard set of available APIs with a tool such as Content Script.
For those of you who might have missed it, the post is available here.
Today I got a chance to dive a bit further in that topic. But first of all, I wanted to find a simple workaround for a known issue I found myself facing with standard REST services.
But let’s get to far more interesting stuff.
As we’ve gone through in my earlier post, Content Script (and it’s underlying APIs over Content Server) can be leveraged to easily create fully-compliant REST Services.
Today I tried to apply it to a field that we are very interested in (see our Beautiful WebForms solution), and that is a hot topic for many Content Server users and developers: forms.
Using Content Script, I tried to create a service that could support the JSON serialization/deserialization and manage the submission and retrieval of Content Server Form objects. Once again, it came out that it was not too hard a task.
Hypothetical scenarios I can imagine for this service? Publishing a Content Server form in your intranet, or any other external tool, perhaps to start a Content Server workflow…
I think that a brief video is more effective than lots of words here.
On our road for the next major release of our Module Suite, yesterday I gave a look at AngularJS.
I was seeking for possible ways of leveraging OTCS standard Rest Services and OTCS Content Script backed REST Services, to create UI widgets to be integrated in external systems.
After a day of coding (starting really from scratch with AngularJS) I came out with a playground application, that even in it’s simplicity, solves some tricky issues related with the combine usage of AngularJS and Content Server REST services.
Managing subsequent requests authorization with OTCSTICKET
Managing authentication ticket renewal
Managing standard REST Services operation through Restangular
Working around OTCS Rest Services implementation current limitations: https://developer.opentext.com/awd/forums/questions/11095612#r11098895 (UPDATE: I found a possible workaround at least for LLServlet. I wrote a simple Filter that basically creates the ficticious “body” parameter out form the request body. This way I can use modern REST-oriented JS library (such as Restangular) much easier. It’s prototype code, but if you’d like to give it a look, just drop me an email.)
Creating and testing custom Content Server REST APIs
The interesting part of this test was extending the standard OT Rest API in order to cover functionalities that are not yet available.
The main reason you might want to do so is not just because the API you are looking for is not yet being exposed, but most likely because you want to reduce the amount of client server round-trips needed to get the task done.
Using standard API, to create for example a recurrent structure of plain folders requires a number of calls exactly equal to the number of folders you are creating.
Business driven requirements should lead to the creation of most efficient services, which are able to complete complex tasks as if they were a single operation.
I mean, what if in the middle of your work of folder creation task, the network become unreliable?
Business critical operation, or data consistency cannot be based on client side logic.
In order to achieve my goal I made use of Content Scripts, which, as you might know, can be invoked as any official REST API.
In order to create my own REST Service the only thing I need to do, is creating a Content Script under the Content Script Volume in the CS-Services folder.
The Content Script name will be our REST API endpoint.
Using the scripting library, I can quickly set up the skeleton for my new REST service and voilà, a new service was born.
Next step is about coding the behaviour of our new REST Service.
For this example, imagine we want to manage a collection of vendors. Basically a set of plain folders with a category “Vendor” attached to them.
List method example (List all vendors)
The first thing we need is a default “List” service. We can implement it as the response of a GET request to the base endpoint, which is a kind of standard for web services.
In order to gather all the existing vendors on my system I am going to use our search service.
The search query builder allows me to create complex queries programmatically and with no effort.
The attributePath will be “Vendor” which is our category followed by “Company Code” which is our attribute.
Since we want all the existing vendors, we use star in the filter expression.
We also add a subtype filter in order to fetch only folders.
We collect the results and return a subset of the available information.
We just need the id, the name, the code and the country for each vendor.
In our controller we have to consume the newly created service and populate context variables. To do so, I am using the very nice Restangular module
Let’s test it, perfect.
GET method example (Vendor detail)
We now might want to create a detail-view for each vendor.
This will be again populated through our vendor REST service.
This time we are going to call it for a specific vendor.
For the detail view we also want to load documents information and creator information.
Let’s test it and check once again everything is working as intended.
Custom method (Merge all documents)
We declare in our scope a merge functions that basically will submit a custom Post to our Vendor service.
The reason why we are using a custom POST is mostly because we have to change the default Content Type, since Content Server does not support “application/json”.
On Content Script side, things are more straightforward.
We add a function to our Vendors service, and use the pdf service to complete our tasks.
POST method example (Create new Vendor)
The last thing I am going to do is to manage the creation of new Vendors, which is basically a POST to the base endpoint of our service.
Custom REST API: Workflows
A similar approach can be used to manage workflows. In this example we were able to create a super simple workflows management console that allows us to rename flows, stop and delete them and fetch all the available workflows information, such as attributes attachments, forms etc.. BTW the script that implements this service is 60 lines of code and can be downloaded from our support portal.
Some time ago our CTO made a claim that sounded quite odd at first:
You know what? I bet that, I can create a cool application on Content Server to ingest and organize the event pictures I am shooting with my mobile and saving to DropBox. And guess what: you will owe me a cup of coffee if I can do it in less than 10 minutes.
If you remember I was quite confident it couldn’t be done THAT quickly, and I accepted the bet and I lost (as you can see in the video).
Today I finally had my revenge.
This morning, I was the guy with the odd claim, willing to bet. A the end we were both so surprised by the result that we could not resist from publishing it.
My 10 minutes application challenge
Design a document approval workflow, where the approval step has to be assigned to an user who is a member of a precise group.
The workflow must be triggered directly from the document.
A shortcut to the document has to be created in the workflow attachments.
The document has to be reserved automatically when the workflow starts.
since I know you need to see to believe, here below the recorded video
How to effectively use Content Script to manage long-running tasks
We have been asked several times about how to effectively use Content Script to manage long running tasks, thus we decided to provide a short example on the subject.
The simple idea, is to leverage the ability to programmatically schedule Content Scripts to divide a task’s load in several chunk, and execute them in parallel. You might think that the same thing can be achieved using the distributed agent infrastructure, well guess what, is exactly what Content Script does !
Upgrading a category
Upgrading a category applied to Content Server objects, is a very common task, unfortunately the standard UI does not allow you neither to perform the task asynchronously, nor to execute it in parallel.. The following script demonstrate how to do it in a faster and reliable way.
The goal is to demonstrate how Excel files could be used as a valid replacement for standard WebForms views.
Basically, how you can use an Excel spreadsheet in place of a webform.
The idea for this post came from a recent discussion we had internally about the possibilities one has of providing access to form-based workflows, to occasional (internal and external) users.
My first choice would be obviously Remote Beautiful Web Forms, a solution through which a Content Server administrator can create a WebForm view on Content Server (with our visual Form Builder) and provide access to external users to the very same form.
Even though this is a secure and robust solution, this scenario requires the usage of a third component (the Script Console), which has to be published somewhere. My colleagues were instead investigating a solution that doesn’t involve anything but Content Server.
A valid response came, as frequently happens, from the field.
We have recently used our Content Script Extension package for Excel combined with Beautiful WebForms to provide users with a more productive data-entry interface.
The requirement was simple. Users wanted to use their existing spreadsheets to compute and enter information. At the same time the system should automatically synch, from that very same spreadsheets, the minimum information required to route a work-flow.
A Form-Based workflow where there are no forms, just an Excel file.
I have oversimplified the scenario for this post.
The business case
Imagine your company is working with freelancers. Every month you have to collect expenses reports from them, to be approved and routed to accounts payable.
The best way to do so is starting an approval workflow for each freelance.
If you are neither a computer programmer nor a Module Suite’s licensee you might want stop reading here, and just have a look at the one-minute video the see the final result, otherwise keep reading for a detailed explanation of how we did it.
The secret recipe
First step: create a very simple form template to keep track of the most significant report details.
Second step: build an Excel file template (you can see in the picture below) to be filled in by our freelancers.
We need a workflow to approve the expenses report…
and we want these workflows to be started automatically on a monthly basis. To do so, we rely on a scheduled Content Script that starts an approval workflow for each active freelance, every month.
The next step is about notifying external users and sending them a copy of the Excel file, together with the instructions they need to fill in the required information.
These users do not have access to Content Server: nevertheless we want them to be able to provide us useful information (such as the internal reference for this expenses approval request). For this reason, we are going to push in the Excel file some additional data that can simplify the data input task.
To to meet this requirement, we are going to use the extension package API that allows us to set validation constraints on spreadsheets cells.
All this can be done by a Content Script executed as first step of the approval work flow.
I am really proud to announce that Content Script for WorkFlows is now GA.
This add-on for Content Script represents a major breakthrough in the way Workflows are conceived and developed.
Content Script for WorkFlows allows developers to leverage all the flexibility of Content Script in any Content Server Workflow, opening up brand new usage scenarios.
The main components of CSWF are:
A new workpackage available to the workflow’s designer, where to define Content Scripts that will be runnable during workflow execution
A new workflow step that brings together the possibility to execute any Content Script (to automate tasks or to integrate external systems) and the possibility to take decisions over the outcome of the execution of the script, in order to determine the next step of the workflow.
To better understand the true potential of this tool, have a look at the following use case (derived from past projects experiences).
An online newspaper requires to automate the management of freelance contributions with a Content Server Workflow.
The Workflow should keep monitored an email inbox folder where freelances send their articles as emails with attachments.
Each time an email is received, the system should trigger a workflow to route the freelance material to copywriter, web designers and editors.
Web Designers should be involved in the workflow only if the email contains image attachments.
The system should notify the IT-Helpdesk in case of an error.
The above requirements can be fulfilled thanks to two Content Scripts and the Workflow presented in the figure here below.
The first script is used just to start a new Freelance-Workflow each minute.
Content Script’s Specific Tab
Content Script’s Source
The WorkFlow uses the second Content Script to fetch messages from the email inbox, to store them (with their attachments) on Content Server and to add shortcuts to message and message attachments to the workflow attachments folder.
Content Script’s Source
Finally, we used the Content Script outcome to route the Workflow to the most appropriate next step.
Content Script Workflow Step Configuration
As ever this new component will be available free of charge to AnswerModules ModuleSuite owners.
Share your thoughts with us ! p.vitali[at]answermodules.com.
When I firstly conceived our ModuleSuite and decided to start this company it was pretty clear in my mind where I would like to go. The first picture of our ModuleSuite was an organic collection of seven modules that play together to build stunning new functionalities, dramatically reducing the effort required to achieve even the most complex tasks. We would really like to build something capable of being at the same time valuable by its own and a precious part of an even more valuable ecosystem.
Today, having traveled halfway (we have released three out seven modules), we are experiencing what I like to define the “domino effect”, and that’s what you are about to read.
Believe it or not Content Script wasn’t the first module that came in my mind.
My starting point were the Beautiful WebForms: I was thrilled by the possibilities offered by the Content Server’s Form framework, but so frustrated about things that were missing, that I started reasoning about how I would fill in the gap. Content Script came out as our answer to the questions:
How can we enable users and developers to immediately used the information they are submitting ?
How do we enable users and developers to prefill forms with information coming from external systems ?
Content Script was the first domino. (Tac)
Our team made an outstanding job with it: Content Script has gone far forward than expected, being at the moment probably the most interesting module of our Suite.
Its progress (Tac) obliged us to rethink completely the role of the Script Console, that was originally conceived as a simple shell application capable of execute remotely Content Script’s scripts. Script Console it’s now a complete runtime that features different execution modes (a shell, a script interpreter and a lightweight webserver) becoming this way the perfect solution when it comes to integrate Content Server with external systems (see an example here).
The number and, most importantly, the kind of Content Scripts scripts that we can now run on the Script Console evolved (Tac).
The possibilities opened by the new execution runtime and the enhanced script API’s that allow us today to embed any number of Content Server Web Form in any Content Script generated page (Tac) brought us to the next step: Remotable Beautiful WebForms.
Beautiful WebForms Forms can now in fact being exported and delivered through the Script Console to anyone or integrated to any web solution.
You can create a stunning Form with our FormBuilder, start compiling it and than simply send it to your external partner to be completed (the same way you send him a contract to be revised). Through the Script Console, external users will experience the same kind of experience of Content Server users, the same interface, the same validation constraints, in a word: the same Form.
Remotable WebForms can also come handy when you want to keep working with your form application while offline: just download your Form before to go and keep working on it with your local it Script Console installation, as soon as you’ll be back online the system will synchronize your local data with the original Form.
Remotable-WebForms were not something that we actually “planned”, but much more a result of the incredible “domino effect” we are living.
Have you ever experienced this kind of effect ?
Share your thoughts with us ! p.vitali[at]answermodules.com.