ASG’s new Zenith Digital Automation Platform is now available and has a lot of promise in being helpful for day-to-day business life in many verticals. It’s advertised as a “low” or “no” code solution for automating business processes. While it may be helpful to have some technical knowledge, it is not necessary to be a software developer in order to create some complex applications and workflows. If you do have knowledge of coding, it can help understand the “magic” that happens between the forms and models that are created on the platform as you build your application. I decided to try it out for myself.
Installing ASG-Studio
I installed ASG-Studio on a Microsoft Windows environment. Installing was very simple using the ASG-Studio installer which installed all the prerequisite software. ASG provides tutorials on how to create an application using ASG-Studio in the online help. I decided to start with working through the first tutorial on an Employee Expense Claim Process application.
Prerequisites
This tutorial requires the use of a database for storing employee and claims information, so I installed PostgreSQL to use as that database. The tutorial includes information about the table names, columns and types, but if you’ve never worked with a database before you may not know how to create the tables and add some basic data. I created the script below to use with Postgres’s psql command to create the tables and populate the employee table per the tutorial.
CREATE DATABASE ExpenseClaim; \c expenseclaim; CREATE TABLE Employee ( empid BIGINT PRIMARY KEY, firstname VARCHAR (50), lastname VARCHAR (50), email VARCHAR (200), managerid BIGINT NOT NULL ); INSERT INTO Employee (empid, firstname, lastname, email, managerid) VALUES (1,'John','Smith','john.smith@myorg.com',1); INSERT INTO Employee (empid, firstname, lastname, email, managerid) VALUES (2,'Richard','Brown','richard.brown@myorg.com',1); INSERT INTO Employee (empid, firstname, lastname, email, managerid) VALUES (3,'Michael','Williams','michael.williams@myorg.com',1); INSERT INTO Employee (empid, firstname, lastname, email, managerid) VALUES (4,'Mary','Clark','mary.clark@myorg.com',1); INSERT INTO Employee (empid, firstname, lastname, email, managerid) VALUES (5,'Sarah','George','sarah.george@myorg.com',1); CREATE TABLE Claims ( empid BIGINT, managerid BIGINT, claimamount BIGINT, claimdescription VARCHAR (2000), claimstatus INT, claimid BIGINT PRIMARY KEY );
After finishing my “prerequisites” with the database, the tutorial took me into setting up some server configurations and creating my application.
Datasource
Creating a datasource was very simple. When you have opened the prompt to create a new datasource, you just insert the database information and press the “test datasource” button. Once you have done this with success, you can create “webservices” that perform actions against the database. This feature was very simple and easy to use even without any coding background. You could handwrite queries, but ASG provides a simple user interface that doesn’t require you to know SQL. You select an operation (select, insert, update, delete), the table and columns associated with the operation and any filters. It will automatically create a call to the database to add or look up the correct information. The hardest part of the process was setting up the database beforehand.
UI Model
The UI model lets a designer create pages that are surfaced in the portal. In the tutorial, they are used to start the workflow and provide a user task interface for workflow (process) tasks. When designing a new page, it starts with a blank canvas and you drag and drop UI elements onto it. You can specify a reference name to access the value of these UI elements (e.g., get value of text field by reference name). To add actions to events (such as a button click), I added a script model that let me choose from a number of different actions such as start process. Since my script models were simple, these were always just three elements; start script, some task (e.g., start process), and end script. I could’ve added additional validation logic here. Crafter Studio allowed me to preview the UI Model and see how it looks, but didn’t let me test my script model actions. The best way to fully test this is to deploy the application.
Process Model
The Process Model user interface is similar to the UI model’s script model flow with drag and drop options. All Process Models have a “start event” and “end event.” Every event is dragged and dropped into its location, then you select it and enter in any relevant information.
You can debug a process model with the built-in debugger as well. This tool proves to be helpful in verifying the way information flows before deploying the application to the portal. However, debugging a Process Model was not as intuitive as I hoped for it to be. It was more time consuming and a bit more complex than I expected. To debug my Process Model, I had to go through task by task and input the key-value pairs of all the variables that my Model was expecting from the corresponding UI models on each user task. Mapping the values the Process Model is expecting to the values my UI models were returning was a bit tedious, and, since my workflows were relatively simple, I didn’t find this to be a useful feature given the level of effort. Perhaps it would be more useful on more complex models.
Application Roles
Adding application roles happens after you have packed your UI model. You will select the newly created {UI Model Name}.rp file under the Application Package > prod folder. Assign the appropriate roles that should have access to the UI model. Every UI Model needs to have at least one role assigned for use in the Portal to control user access.
Packaging the application
Once all the UI Models have been saved and packed, you create a new “App Package” and select all the different models and roles that you created in this process. Saving the App Package will create a zip file that can be imported into ASG Zenith’s Portal for use by your organization.
Deploying the application to the portal
Additional steps must be taken to import the application package into the ASG-Zenith portal (context, role mappings, dashboards, etc.). We’ll cover this and some differences between using the on-premise and SaaS/cloud portal in a future blog post.
Conclusion
The tutorial goes over all the basics of “how” to do things but lacks a little bit on the “why.” Fortunately, the product is reasonably intuitive. Through use of the product, particularly when I created a different application without following a tutorial, I could work it out.
Not much prior knowledge is needed to start using this product, making it accessible to many people throughout an organization. Having some basic coding and technology knowledge could be helpful. Since almost everything is drag and drop, it is easy to use and self-explanatory.
The one thing that I, even with my coding background, struggled with was debugging the application in Studio. At the time of publication, there wasn’t comprehensive documentation about debugging in the online help, I had to ask a coworker who had previously used Studio to show me how to use it.
ASG-Studio allowed me to create a workflow based application without having to write any code.