From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS

<keywords content="keywords"> virtualize, virtualization, include external data </keywords>

Virtualization

Overview

Virtualization of entities in Bizagi is an integration feature that allows Bizagi processes to access different data sources (RDBMS, XMLs etc.), and to present the information residing in these external repositories as part of the business process.

This is a data-level integration mechanism, which is carried out by synchronizing the information existing in the original repository with the Bizagi database, in execution (run) time.

With this feature and approach, the information of a virtualized entity (in a virtual entity in Bizagi's data model) can be consulted or updated throughout the course of activities in a modeled business process.

Bizagi offers a graphical wizard to assist the configuration for this access to the external sources, such as SQL Server and Oracle. This wizard's configuration has no need of programming.

Bizagi includes in its default virtualization library (that one used by the graphical wizard), support to the following database versions: MSSQL (2000, 2005, 2008) or Oracle (9i, 10g R2, 11g R1, 11g R2) releases.

Should it be required to access another type of data source (such as MySQL database, an XML file, Microsoft Access, etc), then an custom implementation can be included to access that specific source. This is done by overriding the methods and layer used in Bizagi in this feature.

Requirements

The external data source must meet the following requirements:

Access to the external information system must be available in real time; if this is not the case, data replication in batch mode should be implemented.

If the virtualization will be accessing a database, this database should be normalized. It is required to clearly identify the keys in each entity so that Bizagi can uniquely identify one instance. Additionally, the relationships between Bizagi’s entities which will be virtualized must also exist in the external source.

The external source must expose mechanisms for select, insert, update and delete entity instances (by using functions, stored procedures, Web Services etc.).

If necessary, data mapping and data type validations should be performed (manually, and perhaps also in the virtualization interface) to evaluate possible translations and conversions from Bizagi to the external data source.

Synchronization of records is done on demand (when updating, creating or searching for a record). For this feature it is required that the connection information for the data provider has the priviledges to read and write at the source.

How does the virtualization work?

Bizagi's entity manager is the application server component which manages virtual entities accessing data in external systems.

Once an entity is defined as “virtual”, the entity manager tries to use a virtualization interface to access the external system.

Bizagi provides an interface to access entities in SQL Server or Oracles DBMS, but it is possible to integrate in Bizagi a custom component having the interface implementation to access any other system.

Once the virtualization layer has the required information to connect and transport data to the source database, it executes the requested functions by Bizagi (select, insert, update or delete) and returns values or data; in this way business analysts will be using "external" entities in the same way as “local” entities (forms, business rules, notifications, etc).

Virtualization of entities applies for Master-type entities in Bizagi (those which have transactional data). To use data-level integration for parameter entities (lists of values), refer to Bizagi's replication. Compound key configuration in external entities is supported in Bizagi's virtualization.

Benefits

Bizagi’s capability to virtualize any entity defined within Bizagi, provides the following benefits:

It enables Bizagi to offer the Business analyst a clean corporate data model for managing and changing process information.

Business Analysts always deal with data used by the process as if it was available in Bizagi’s entity manager, i.e. as local data. In this way they do not have to understand the complexities associated with the data’s current physical location.

The process flowchart never has to include technical activities (such as data access) and therefore organizational processes remain readable and understandable by a business audience.

By having a single component providing all external data access activities, the solution’s maintenance is greatly simplified. The number of interfaces with external systems is drastically reduced.

Business Rules never have to deal with data access or field mapping issues.

This feature promotes integration with existing models and systems, as having such systems is a frequent scenario in corporate BPM solutions.

Distribution of work in BPM projects becomes very clear: business analysts design and implement processes and business rules, while IT personnel design and implement entities and components.

The following image illustrates the main benefits of Bizagi's virtualization.

In the above diagram, the process data model represents the entities for the business process, but some of them may already exist as entities in other systems (databases, mainframes, files, etc).

The virtualization layer provided by Bizagi's entity manager offers the mechanism to deal, transparently, with the “remote” entities in the external systems.

In order to access remote data, the virtualization layer uses a class provided by Bizagi that works with external entities in SQL Server and Oracle Databases using OLEDB as a connection and transport layer.

It is possible to access different data sources implementing a specific virtualization class for the system or database engine using any connection and transport mechanism (ODBC, OLEDB, Client Access, HTTP, Sockets, etc.).

These virtualization interfaces could implement different methods required by Bizagi for data access and manipulation (select, insert, update, delete, etc.).

General Guidelines and Issues

It is highly recommended to make the virtualization design before starting the creation of the entities in Bizagi. This means define the entity- relationship data model for virtualization at the beginning of the project.

Once the system is in a production environment, Bizagi's current version of the deployment component does NOT support the automatic conversion of virtualized tables into non-virtualized or vice versa (that is, if a table is virtualized in the testing environment, this action will not be executed automatically by the deployment once a process is transferred to the production environment). This means that the correct identification of which tables should and should not be virtualized must occur prior to setting the system into production.

When developing a customized virtualization class take into account performance; access to the Bizagi database from the virtualization class is not allowed and obviously the least number of accesses to the source database is the best strategy to reach maximum performance.

It is highly recommended that the Process Entity relationship model is in the 3rd normal form (normalized).

The data types in the external data source should be as similar as possible (ideally equal) to the Bizagi data types. If the data types cannot be mapped naturally to the Bizagi data types then the virtualization interface must implement these mappings.

The name of Bizagi’s virtual entities must be shorter than 15 characters (mandatory); make plans for the nomenclature of the local entity name definitions in advance, keeping this restriction in mind.

Entity Instances Deletion

One of the main issues that arises when working with external data sources, consists of the synchronization in the “deletion” of instances between Bizagi entities and external entities.

Bizagi is responsible for maintaining the integrity of cases that reference entity instances; since external instances can be deleted by third party applications, this could result in possible invalid references from a case to the deleted entity instances.

To avoid this, Bizagi stores all entity references to the instances and if the external source instance is deleted then Bizagi marks it as “deleted” but the entire information of the deleted instance is saved in Bizagi's structures to maintain case information integrity.

Bizagi will know that an instance has been deleted the next time the process tries to access the instance. At that moment, Bizagi will call the appropriate interface within the virtualization layer and this interface will raise a pre-defined “deleted instance” exception that Bizagi will manage automatically.

On the other hand, the local deletion of entities is immediately reflected into external source if the virtualization layer (timeout and methods) are configured this way.

Enterprise JEE consideration

To configure virtualization or replication in a Test or Production environment using a JEE Application server (applies for Bizagi Enterprise JEE edition), an additional step is needed so that the external data source is configured at the Application server's level.

To carry out this step, ensure that your JEE Application server is already configured to work with Bizagi.

Take into account that this step is only needed in an environment different than the Development environment (in which case, Bizagi Studio automatically configures the JBoss 7.1.1 Application server's data source).

View How to configure virtualization and replication in a JEE Application server.

Related Articles

• Virtualization Restriction
• How to Virtualize an Entity with the Wizard Method.
• How to Virtualize an Entity with the Standard Method
• Virtualization of related entities example
• Virtualization for data sources different from MSSQL and Oracle
• Data Type Support

<comments />