Javascript as a LowCode Solution in Hyperautomation and Workload Automation
In the argument between lowcode and nocode automation, I’ve always felt there is an 80/20 rule. 80% of your workflows should use very little code, if any, while 20% will use a modest amount. If you’re not getting to 80%, your tools are not doing enough. But for 20%, there are real reasons why you need to write some code, and if your tool does not have a rich API with a powerful language behind it, inevitably you will need to go outside the tool to perform certain tasks. That gets very messy, hard to manage and steps outside best-practices for self-documenting workflow.
At Xonasoftware, we chose to leverage Javascript (ECMAscript) as an interpreter that executes as part of every automation workflow.
Why Javascript?
Ubiquitous
It’s everywhere. It’s a language that looks a lot like every other language. It’s easy to use; easy to learn. Everyone who's built a website has used some of it.
A Small Piece Goes a Long Way
Functions in Javascript are first class objects. Practically, that means small pieces of Javascript can go a long way, and it's easy to have just a snippet of code here and there without having to even write a full function.
If you have ever built a simple website, you know it’s common to place little pieces of javascript that do certain things as the page changes. For example, <body onload="myFunction()">, causes myFunction() to run when the page loads.
With automation, the framework should do 80% of the work. That leaves places where you need to write just a bit of code. For example, a lot of people read .CSV files or spreadsheets to pull data out and process it. Our solution allow you to specify some Javascript with each column to be executed as each cell of that column is read. That code can then “fix” the data, convert the value to something more useful, etc.
It’s also useful because within a workflow you can have decisions like…
The configuration of the line from "Digest_Clearing_Data" to "Task_2" is simply customer == 'acme'. So if the customer is ACME, "Mark_to_Market" is bypassed. That’s pretty simple!
The DOM Model
In a website, Javascript interacts with your web browser via the DOM (Document Object Model). It is through this that all the fancy controls, expanders, animations, etc. work. Javascript manipulates the page via the DOM.
In our automation framework, Javascript interacts with a data model (similar to the DOM) that allows access to not just the workflow but to the entire ecosystem of all the workflows, all the computers, users, calendars, output from commands, etc., etc. Everything.
For example, if a workflow runs a command on another computer (Task_1), maybe at another site even, I can simply write something like Task_1.getLog().tail(50) to get the last 50 lines of output and then pass that on to the next steps in the workflow. So a little code can do big things.
Web Services
The world is moving to machine-to-machine communication. We believe RPA (programmable robots that run things like Excel and Chrome) will give way to hyperautomation where workflows will only communicate with machine-to-machine interfaces such as RESTful APIs.
The data format exchanged by these services is JSON (Javascript Object Notation), the very same format Javascript uses to define objects. So when it comes to web services, you could not pick a better "glue" language than Javascript. The automation framework along with some simple Javascript allows these services to be easily integrated.
For example, here at XonaSoftware, we use Stripe (stripe.com) to process credit card transactions. Stripe has a very well-designed RESTful API. So when a customer purchases a product or updates a license, the resulting workflow can update his billing information in stripe, perform a pro-rated billing, generate and deliver a new license and send the customer an invoice all within a second.
