Architecture
From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS
Contents
|
BizAgi’s Logical Architecture
BizAgi provides the most complete variety of tools and functionalities, which rigorously satisfy the requirements to model, modify, control and administrate from the simplest to the most complex processes of the organization.
It is essential to understand BizAgi’s logical architecture, not only because it allows you to use different tools in accordance with the functionality they were designed for, but it also guarantees agile implementations and excellent quality.
Figure 1: BizAgi’s Logical Architecture
Figure 1 illustrates the logical layers and the structural components of BizAgi, as well as the interaction between them.
The top layer includes the organizational processes. These processes generally include a combination of manual activities (carried out by people) and automatic activities (carried out by systems).
Both types of activities require sophisticated data processing (located in BizAgi entities) and decision making based on specific values of said data (business rules). This functionality is supported by the components in the business object layer.
In BizAgi, the person who models the process always assumes that the data is local, that is to say, it is present in the entity-relationship model (ERM) of BizAgi. The organizational process should never contain activities to access and/or update data; the automatic activities (which involve interaction with third party systems) should be used only to carry out transactions on external systems.
In addition, the business rules assume that all the information elements required to make decisions are inside the BizAgi entities and therefore should not involve the data mapping and access logic (knowledge that is foreign to the business analyst profile).
If the data is available on an external system, BizAgi supports the virtualization of the BizAgi entities (tables). BizAgi’s virtualization technologies support the transparent access to data administrated by third party systems using Web Services, solutions to automate enterprise application integration (EAI), messaging systems (for instance, IBM MQ Series) and direct access to databases, among others. When the issue of external data access is focused on a single component – virtualization – the number of interfaces decreases drastically, application maintenance is simplified, and a better quality of the overall solution is guaranteed.
Another alternative to carry out B2B integrations is in the Enterprise Service layer, through which BizAgi publishs its main functionalities for other applications to invoke and consume the public services, which allows the orchestration of similar automatic tasks and processes with architecture styles aimed at the services existing in the organizations.
In actual BPM projects, certain business rules may require complex calculation or processing. In order to keep the business rules understandable and guarantee their proper performance, BizAgi allows the easy registration and access of these programming components, by means of the Component Library and Functions.
Certain activities within a process may also require specific tools invoked by a specific activity, such as a calculator – used in a credit analysis activity – to determine the monthly payments of a mortgage. These tools should be developed using traditional programming tools and can later be easily integrated in BizAgi.
Process Automation Solution
A process automation project consists of several components, which must be clearly identified before its implementation:
The process. Consisting of all the elements that make it up, including, among others, the performer, forms or screens, business rules, etc. All these elements are defined and administrated in BizAgi.
Tools. Which are software components with specific functions that are used in one or several activities of the process. These tools are developed using traditional programming systems and BizAgi allows their agile integration.
Computational business rules. These are programmatic components that, due to their complexity and/or performance, are developed in environments outside BizAgi and are later integrated in order to be used easily by the process and its business rules. For instance, a procedure that accesses systems located in different geographies and calculates the average historic increase in wages of a multinational organization over the last 10 years, should be a programmatic component.
Virtualization classes. Classes that support the access of data with third party systems. BizAgi by default supports several access and transport technologies, but certain specific systems may require the generation of an additional class during the automation of the process.
Interfaces with third party systems. An automatic activity of the process may require the launching from BizAgi of a transaction on an external system, such as debiting a checking account on the bank’s core system. These specific interfaces should be developed and later integrated in BizAgi.
BizAgi’s Technical Architecture
Seeking the agility required nowadays by companies in the daily execution of processes, BizAgi has four fundamental layers for its operation:
Client
It is the front-end of the solution to the final user. Using an internet browser the user can view and use the BizAgi Web application.
Web Server
The web Server is in charge of processing the requirements from the client. It is at the Web server where all the graphical user interface objects are managed.
Application Server
The application server processes all business information and its components:
Cache Manager: it provides improved performance by the optimization of data access in the application.
Workflow Manager: a very powerful and expressive process engine.
Entity Manager: in charge of managing process information in a structured way.
Business Rules Manager: it is the component that implements the business rules.
Authentication Manager: it offers different mechanisms of authentication.
Enterprise Manager: it manages application users, grouping them by features, skills, roles.
Query services: it is the runtime Query in BizAgi.
Analysis (BAM): this component solves queries for BizAgi.
Interoperability services and component library: these components offer a complete functional integration with other systems.
Storage
The Data Access Components provides the connectivity between the Application Server and the Database. In the logic data layer (back-end) this component is BizAgi's database (ORACLE / SQL)
The complete modeling process is offered in a single, powerful tool: BizAgi Studio. It provides all the functionality to easily create the process automation solution with unsurpassed agility and performance.
All of BizAgi’s components interact in harmony to provide the organization with the agility to continuously improve their core business processes.
BizAgi BPM Architecture
The following are the different architecture options that you can choose from to implement BizAgi BPM in an organization considering the different layers that may exist in a production infrastructure.
Standard
Standard with Proxy
Multilayer
Multilayer with Proxy
Multilayer with high availability schema
Standard Architecture
The standard version of BizAgi BPM consists of a web server and application coexisting on the same machine; said server interacts with the database server. End users connect by means of the Corporate LAN.
Description
In this scenario, the BizAgi server takes care of carrying out the construction and display of the forms that will be presented to the users and will execute the business rules for each process that is defined.
Advantage
Simple configuration and administration
It easily evolves into a high-availability architecture
Secure scenario for clients located within the organization
Disadvantages
For external publication (Internet) the users cannot be authenticated based on LDAP/Active Directory services, reason for which another authentication mechanism must be adopted, such as the validation of users based on the database known as BizAgi authentication.
Standard Architecture with Proxy
As you can see, in this architecture, a Proxy is placed before the BizAgi Server. Said proxy carries out the authentication of external and internal users, creates packet and content filters and last but not least, offers the possibility of web cache management.
Description
The variation as regards the previous scenario consists of placing a Proxy before the BizAgi server, for the internal users located on the Corporate LAN. There can also be the variation of directing them directly to the BizAgi server without the need to go through the Proxy.
Advantages
The Proxy offers protection to the BizAgi server from external users
User authentication is carried out based on the organization’s LDAP/Active Directory services
Functional publication of BizAgi for internal or external users
Proxy configuration is relatively simple
Disadvantages
Acquisition of the Proxy tool and the infrastructure is necessary for its operation (licenses, equipment, etc.)
Multilayer Architecture
This version offers the possibility of separating the BizAgi BPM solution in presentation and application layers.
Description
In this scenario, the Web Server is separated from the Application Server. This schema considers the publication of the web server in a public or demilitarized zone to be accessed by internal or external users and locates the application server in a militarized or protected zone. This way the Web Server takes care of presenting the end user with the forms to interact with BizAgi and the Application Server executes the business logic of the process. This figure maintains a clean, three-layer architecture of Presentation, Business Logic and Data.
Advantages
Publication of BizAgi BPM in external (Internet) and internal environments
Authentication based on LDAP/Active Directory services
Separation in specialized layers that facilitate the administration of corporate solutions
You can incorporate the Application Center figure to offer high-availability services for servers located in the application later.
Disadvantages
The configuration needed for communication between the Web Server and the Application Server to be successful requires a major effort.
The administration and maintenance of the servers involves more infrastructure, the testing environments must simulate the same architecture in order for the changes to production not to present errors due to configurations that were not taken into account in the certification environments.
An additional server is required to separate the presentation and application layers.
Multilayer Architecture with Proxy
In this scenario, a Proxy is added before the BizAgi web server. In this schema, you get the separation by functional layers, plus the functional possibilities of the proxy.
Description
The use of a Proxy in this scenario provides greater control over the access of external users.
Advantages
Possibility to maintain a separate architecture by specialized layers with increased protection
Secure publication to external users
Authentication based on LDAP/Active Directory services
Disadvantages
This scenario require the most infrastructure as regards hardware and software
The administration and maintenance of the servers involves more infrastructure; the testing environments must simulate this architecture in order to simulate the production environment in full.
Multilayer Architecture with High-availability Schema
Description
In this scenario, the presentation and application layers handle redundant nodes with load balancing and fault tolerance mechanisms. Last but not least, the data access layer has a cluster of servers with an active/passive schema. Should one of the servers fail, the failover will take place and the server in a passive state will take control over the operation.
