Introduction to Comflow Architecture

Introduction to Comflow Architecture

The Comflow (CF) environment consists of a number of different entities. The two main components of Comflow are Comflow Studio and Comflow Portal. This chapter will describe these main entities on a high abstraction level.

Design time architecture for Comflow - Comflow Studio

The CF design time environment, called Comflow Studio, is purely based on Comflow plug-ins in the software development framework Eclipse and software versioning frameworks CVS and GIT (note that other versioning systems are possible to use).

Deployment

All artifacts produced in Comflow Studio (Processes, Workflows, Portlets, Rules etc.) are saved as xml or Java files. They are then deployed to the runtime environment by the Comflow Deploy functions via a direct local deploy to a web server or via the creation of a .war-file, which is manually moved to a web server.

Runtime architecture for Comflow - Comflow Portal

Comflow Applications are deployed into an Application Repository and executed within the Comflow Portal, consisting of Runtime Engine and the Portal Engine. The Portal Engine is normally based on a Tomcat Server and the Runtime Engine is in principal a set of Servlets, that dynamically generates HTML pages to the Clients web browser.
Client interaction is through HTTP and the Portal Engine.
The Comflow Runtime Engine includes a number of connectors towards external resources such as databases, enterprise systems, printers, email servers, file systems etc (see Connectors Chapter below).

Runtime Alternatives

There are a number of different runtime alternatives available, each shortly described below.

Tomcat and Jetspeed

This is the standard “open source set up” where the open source portal server Jetspeed is used. This setup scales by adding other complete setups in a different JVM’s. These setups can be deployed on different physical servers or on the same server. The reason for wanting to scale a solution like this on one physical server is heap size limit of the JVM. If larger heap is needed this is solved by deploying a mirrored setup. With a scaled solution it is possible to define one of the installed setups as Master and let that master cache all artifacts. This enables more efficient memory and processor usage as well as it provides the possibility to support 24*7.

Connectors

Database Connector

The Comflow Database Connector builds on JDBC and SQL and has been adapted for the following - MS SQL Server, Oracle, DB2 for Windows and Linux, DB2 for AS/400/System I and Derby for Windows.
The main development in this connectivity is the Meta Data Repository that helps the connector to retrieve the information it needs to create SQL statements on the ‘fly’. The reason for generating the SQL is that it makes it possible to switch DBMS and generate the optimal SQL for that specific DBMS. It also make it possible to create SQL for Select, Update, Insert and Delete from one single Data Model.

ERP Connectivity Packages – DB, Program API and Repository

The Comflow ERP Connectivity Package is a composite connector that includes DB Connectors, Program API Connectors and Meta Data Repositories for a number of Enterprise systems.
Typically, trivial read and write operations are done through the DB Connector and more complex read and write operations through the API Connector.

SOAP Connector

The SOAP Connector enables any Comflow function to be a Web Service. It also makes it possible for a Comflow function to use a Web Service to retrieve and update information in remote systems.

Email Connector – SMTP/POP3

The Email Connector uses SMTP for send and POP3 receive.

API Connector

The API Connector builds on Java and enables custom connectors against any non-standard external resources.

File System Connector

The file system connector is created to have a unified API to use when accessing resources from the file system. This connector can also be used to access resources remotely over network mapped file systems.

User Directory Connector – MS Active Directory, AS/400 Users

At the moment Comflow supports user integration towards Microsoft AD (Active Directory) and AS/400 Users. The AD Connector builds mainly on LDAP (Lightweight Directory Access Protocol) which makes it possible to retrieve users, user information and groups from any LDAP compatible user directory.
In addition to these two alternatives, users can also be defined within Comflow’s internal authentication.

Comflow artifacts

A Comflow application is built based on a set of artifacts mainly described in xml-files and complemented with java code. Noteworthy artifacts are:

• Metadata Id

Metadata Id

Metadata Id is a logical identity of a data source, like a data base. It pinpoints the logical structure of the data source, so the same Metadata Id can be used for all data source instances that has the same structure, like a test and production data base. 

In Comflow core, 2 Metadata Id's are used; CACORE and CACOREAWF