Introduction to Verj.io

This document provides a quick summary of the Verj.io system; it gives an overview what you can create, how it works and a little about the underlying architecture. It’s a good place to start if you are new to the product. For more information on any subject follow the links at the end of each topic.

What is Verj.io

Verj.io is a rapid application development environment that lets you:

Create web applications
Create workflow processes (business processes)
Create and publish web services

Under the covers, Verj.io uses the Ebase Xi RAD software and you will see references to both Ebase Xi and Verj.io in this documentation.

The focus is on productivity throughout: the aim is to allow you to create your applications as quickly as possible. We provide a rich set of tools that allow you to deal with all the technologies that you need without necessarily knowing all the details, this includes HTML, CSS, Javascript, JDBC (databases), XML, Web Services, Email, PDFs and much more.

Let’s look at these three things in a little more detail.

Create Web Applications

In the Verj.io system, a web application is called a Form and this can be anything from publishing a few static information pages through to a multi-user, multi-page, complex application. The user can be running any device that supports a browser: phone, tablet, laptop, desktop. Here’s a quick look at some of the basic building blocks that you use to construct a form:

Pages: each page contains a number of controls e.g. panels, buttons, fields, tables, menus, grids, images, tabsets and many more. You configure these controls in a WYSIWYG page editor to get the design that you want. Layouts are used to set the basic layout of each section of a page e.g. horizontal, vertical, column etc, and styling assistants are used to style each control – typically by selecting pre-defined styles from a template. At runtime, the server dynamically constructs the HTML from these controls and sends it to the user’s browser; it’s important to realize that there are no static HTML pages that you are required to edit.

Fields: a field is a variable i.e. something with a name and a value. Fields are independent of pages and they exist for the duration of the application. Field values can be set by the user entering data, by a program, or they can be loaded from an external source like a database or a web service. Validators are used to check data entered by the user.

Tables: these are what you would expect from the name: each table consists of a number of rows where each row is a set of fields. You can present tables to the user in a variety of different ways or you can use a table just for programming purposes.

Texts: all texts are automatically multi-lingual; this means that once you’ve created your application, you can run it in any language just by getting a translator to enter texts in the new language. The details of presenting dates and numbers in the appropriate format for each language are dealt with automatically.

The four elements above are all contained inside a form. There are also a number of additional standalone elements that you create which a form can use, including:

Server-side scripts: these are programming snippets and they are called from a form using an event model e.g. a Button Control has an on-click event to which you can attach a script – you might use this event to load some data from a database based on what the user has entered and then present this on a page. Verj.io supports two programming languages: Javascript (note that this is server-side Javascript) and FPL (Verj.io’s builtin English-like programming language).

Client-side scripts: similar to server-side scripts, these are programming snippets that run in the browser instead of on the server. They are written in Javascript and are also driven by an event model e.g. the mouseover event for an Image Control might be used to popup an information panel. Typically you use client-side scripting to introduce “rich client” effects into your applications and you can use any of the powerful Javascript libraries available e.g. jQuery. Note that client-side scripts can also talk directly to server-side scripts and this feature is extremely useful when you need to download data from the server to the browser client e.g. to create a chart or graph.

Resources: these are used to access external systems including databases, XML, REST and SOAP Web Services, Email and many more. Typically resources are created semi-automatically by wizards which read and process metadata e.g. database resources and web services resources. Most of the intelligence – the configuration details – are contained within the resource and do not need to be explicitly programmed. A resource can then be asked to do something by a script e.g. to call a web service:

resources.stockQueryWs.call();

Lists: as the name implies these are lists that are presented to the user, usually as dropdowns.

Presentation Templates: these contain a set of pre-defined styles – a bit like a “skin” – and are used like Word styles.

More info: Introduction to designing forms, Form Editor

Create Workflow Processes

In Verj.io, a business process is called a Workflow Process which uses the same underlying framework as a Form and shares many of the same constructs: fields, tables, resources etc. Each workflow process consists of a number of tasks and you pull these together into a flow diagram that represents the business process. There are two task types:

Interactive tasks: these are performed by a user i.e. a person, and are usually implemented as Forms. Each task is first assigned to a user, or possibly to a team; the assignment mechanism is very flexible and supports extracting information from external security systems e.g. Active Directory. Once assigned, interactive tasks are usually presented to the user in a task list.

System tasks: these represent a programming task performed by the system e.g. loading data from a database, sending an email etc

The business process flow diagram will usually include both task types joined together with decisions (branches) and splits. At runtime, workflow processes are executed by the Workflow Engine. The sequence of tasks to be executed might be fixed or it might be dynamic: for example, if a loan application gets approved then the workflow goes one way; if it’s rejected it takes a different route.

Workflow processes also support escalations: these occur when process execution has failed to reach a specified point in the time allowed; for example a freedom of information request might require an initial response within 10 days and a final response within 30 days. You can configure the action taken when each escalation fires.

The status of all workflow jobs can be viewed and controlled using an administrator dashboard application.

More info: Workflow Index

Create Published Web Services

A web service is an application that can be called by external programs (though it might also be called internally – by a form or a workflow process). Verj.io supports both REST web services (a RESTful Web Service) and SOAP web services (an Integration Service). In practice both of these services are really a cut-down form with all the user interface bits – pages and controls – removed.

More info: REST Web Services, SOAP Web Services

Verj Components and Architecture

The system consists of two main components: Verj.io Studio and Server.

Studio

This is a standalone Java application and it is used to create and test all the various constructs – forms, workflow processes, integration services, scripts, resources etc – that comprise an application. These are collectively referred to as entities and this term is used throughout this documentation. These entities are saved in a workspace which is a local file system on the studio system; the entities themselves are mostly saved in XML format.

Each studio is linked with a test server and this server is used to test the applications as they are developed. Usually this test server is configured to be the Integrated Test Server – this is a special server packaged with the studio, which is started and stopped automatically as the main studio application is started and stopped. There is also an option to connect the studio to a full external server.

The studio can run on most platforms including Windows, Linux and Mac systems.

More info: Introduction to the studio, Starting, stopping, configuring the studio

Server

This is a Java servlet application and can be either:

A cloud server running in the Verj.io cloud
An on-premise server – this can run under any J2EE application server, and on pretty much any platform including Windows, Linux, Unix, Mac and others. In the distributed system the server component is packaged within an instance of Apache Tomcat.

The server is highly scalable and can be clustered to support high transaction volumes.

The figure below shows the server architecture.

The server accepts two types of external requests via URL:

requests from browsers to execute Forms
requests from external systems to execute published web services (Integration Services)

In addition to these external requests, the server also provides some internal services: this includes the Workflow Engine which works by monitoring its runtime database for tasks to run, and a Scheduler which can be used to run forms and other programs at scheduled times.

In all cases, the server loads the required entities from a workspace which acts as the server’s “database”.

The server can be administered and monitored using the Server Administration Application.

More info: Introduction to the server, Starting, stopping, configuring the server, Server Administration Application

Deployment

Once you’ve created and tested your application, the next step is to deploy it, either to a test server or into production. To do this you collect the entities that make up your application – there are tools to do this - and then deploy them to a target server. The list of deployed entities can optionally be saved as a deployment package so that it’s easy to repeat the deployment. The changes are introduced into the target system in a controlled way so that any users currently running the application are not affected.

More info: Deployment Overview

Team Working

So far we’ve been talking about a single developer. So how does this work if you’re working as a team? The best way to achieve this is to use a source control system such as SVN or CVS to contain the workspace file system and then check your work into and out of this. In fact it’s a good idea to use a source control system even if you’re just working on your own, as a source control system provides many advantages: backup, versioning, reversion, tagging etc.