NodeJS Automation

An article by Valentina Lanz, Consultant, Diso AG

Process automation has been one of the biggest revolutions brought to us; starting from street lights all the way to robots, automating trivial operations has been a major point of innovation and development in IT. But exactly how hard is it to automate processes for a developer? In this article I will demonstrate how we – as a team – proceeded to analyse and automate an everyday office job by the means of a sequential automation of jobs.

Challenge

One of the products Diso offers, DaaS (Desktop as a Service), allows anyone to enroll for a trial period through the internet. Until now this meant an email being sent to the account manager, who would then work through a set of tasks resulting in the customer receiving test account credentials. Let’s take a look at said tasks:

  1. Assure client data integrity

  2. Save client data to Salesforce CRM

  3. Create new AD account

  4. Send new credentials by email

Beside the fact that this work is quite tedious and repetitive, there are also some security issues involved in the last step that can’t be overlooked. Avoiding sending credentials by email, however, would mean using other secure services (mostly entailing additional costs), or writing a secure sharing platform of our own.

Automation

At the moment, customer data is sent directly via email from a CMS form to one of our co-workers. However, the CMS also allows for a REST call to be fired on form submission, which is exactly what we need.
The REST request Endpoint is represented by a NodeJS server, set up in the blink of an eye with help of the Node Express library.

First things first, upon receiving customer data the application should check if the provided user information has already been used (and was therefore saved to the database). If a duplicate is found for (e.g.) the email address, the request is denied and an error message is sent back to the CMS frontend. If no duplicate is found, the new user data is saved to the database and we can proceed to the next step.

Luckily all major tools we use to manage client data and DaaS accounts provide APIs for us to use when automating tasks like this one. Implementing a few APIs in our Javascript code gives us the ability to execute all necessary steps for the creation of a test account directly from our new Node application.

Nonetheless, there are still limitations to what a machine can and can’t do on its own. In our case, being able to recognize if user data is trustworthy or not is still very difficult to leave up to an automated process – the human factor missing. So why not reintroduce it in a more automated way?
Since Slack is our primary internal communication platform, using the Slack API we can send a message containing client details to a specific Slack group. Through this message one of our co-workers is able to „Allow“ or „Deny“ the test account request by simply clicking a button.

The answer being sent back determines the continuation of the server workflow.

The above snippet represents a typical JSON-formatted content of a service API call. One thing to notice is that the callback_id provided is actually the user.id the Node application generated upon receiving the test account request – this way, the Node application can remember which user was actually accepted or denied.

If the request is denied, an automated email is sent to the provided email address mentioning the rejection. Mailchimp offers a REST API that can be called from our Node application. I won’t go into detail, but a new contact is added to a Mailchimp List and a „Sorry, your request has been rejected“ campaign gets sent to the new contact. The same (with different campaigns) goes for all other emails sent through our application.

If the request was accepted, contact information is saved to our Salesforce CRM for marketing purposes and transformed into several different Salesforce entities. If everything runs successfully, a new User is created on the DaaS Active Directory. All of this through API requests to the involved services.

In a confirmation email, the client will now receive a link with his hashed ID as a URL parameter – making it possible for our Node application to determine which user wants to access confidential data while diminishing the possibility for URL manipulation attacks. A webpage is served over SSL containing the credentials, and using said credentials, the end user will be able to log into his test account on the DaaS Platform.

Architecture and Mechanics

All external APIs are basically services we call from our application. Thus dividing each API into a service gives us good control over the project’s modularity. A „main“ service could then represent the entry point to our application logic and contain the step sequence for our services to be called.

A service interface defines a mandatory function each service needs to implement. We are going to use this function as an automated entry point to the next chain-step. At step completion each step starts the next through a call back to the main service. This way, we can add as many steps to the main service as required, even changing step order without having to touch any service’s business logic.

Conclusion

The wide availability of APIs makes the automation of tool interaction tasks trivial to implement. Employees are only involved by the automation application when needed and are otherwise left without the burden of performing repetitive business tasks. Through automation we can ensure the sequential execution of various mandatory steps and prevent human errors that typically occur in repetitive tasks.

The security aspect of our automation could surely need some improvements; however, the most difficult step in the right direction has been taken and improvements are sure to follow.

I hope this article gave you some inspiration to start automating different things in your life!
Happy automation coding!

A service interface defines a mandatory function each service needs to implement. We are going to use this function as an automated entry point to the next chain-step. At step completion each step starts the next through a call back to the main service. This way, we can add as many steps to the main service as required, even changing step order without having to touch any service’s business logic.

Diso AG – The Swiss Data and Cloud Expert

Diso AG is a renowned IT service provider and long-standing Oracle distribution partner with headquarters in Switzerland focusing on database and cloud solutions. For instance, Diso offers its customers Oracle’s “Platform as a Service” solution and the associated data migration. Moreover, Diso’s customers benefit from the complete solution offering featuring planning, integration, support including the operation and the monitoring of IT infrastructures and database systems.

In the field of software engineering, Diso develops tailor-made IT and software solutions for company-specific applications – whenever appropriate with a mobile-first approach. Last but not least, Diso is the expert when it comes to software-based performance optimization. For many years, numerous prestigious customers of key industries such as banking, insurance, retail and public administration have put their confidence in the competence of this mid-sized established IT service provider.

Diso AG designs adaptable IT systems, develops tailor-made software, and allows the efficient use and analysis of data and information.

Über den Autor:

Valentina Lanz is employed at Diso AG as Software Consultant, working with Javascript, Java, Docker and DevOps. During her Bachelor studies program in computer science at the Bernese university  of applied sciences, she specialized in IT security and was dealing with topis such as Webapp and information security. During this time she received various certificates, including the OSSTMM Professional Security Tester certificate.