Data Virtualization

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Process wizard > Data Modeling > Connecting to external data sources >

Data Virtualization

Overview

Data Virtualization in Bizagi is a data-level integration mechanism that allows the Process data model to connect to external data sources, as described at Connecting to external data sources.

 

With Data Virtualization, Processes in Bizagi can access information stored across multiple data sources (RDBMS, XMLs etc.), and present it as part of the business information.

Integration is done transparently for end users in execution time (information is synchronized in run-time), and the information of a virtual entity is viewed and updated throughout the course of Activities in Processes.

Examples of information handled through Data Virtualization are: customers or vendor details, invoices, purchase orders, amongst others (records from tables which are seen as transactional).

For table data integration where updated information is stored as a predefined set of values (Parameter entities), refer to Data Replication.

 

How does it work?

To use Data Virtualization in Bizagi, you need to first ensure that your external data source adheres to best practices and requirement guidelines, such as having read and write access permission (a login with granted privileges).

 

Configuring the Data Virtualization is done by defining the external system and its data provider (connection to the external data source).

Bizagi offers a assisted graphical wizard so that minimum configuration is required.

 

Once the synchronization occurs, the information will be presented to end users to manage it as part of a business process in Bizagi.

 

Data_virtualization

Major Benefits

Using Data Virtualization in a Bizagi solution promotes:

 

Reusability by allowing  processes to be integrated with existing data sources (applications) and legacy systems.

This is a frequent requirement when there are legacy systems with no Service Oriented Architecture design for integration at a higher level (data-level integration is required).

 

For the actual implementation of the project, Bizagi's Data Virtualization has the following benefits:

 

The distribution of work amongst team members in Bizagi project is made clear.

The work is separated according to different roles: business analysts design, model Processes and Business Rules; while the IT personnel design, configure and implement the entities data model and integration solution.

 

Offers the business analysts a clean and corporate data model for both managing and exchanging Process information.

Business analysts deal with the data used by the Process as if it was directly available in the Bizagi Process repository (i.e, as local data).

In this way, they do not have to understand the complexities associated with the real data physical location.

 

Processes Workflows do not need to include any technical activities oriented for this type of integration (such as data access to another source.

Therefore, organizational Processes remain easily readable and understandable by a business audience.

Business Rules for instance, also do not have to deal with data access or field-mapping configurations.

 

Having a single component providing all the necessary data access management for Activities.

Through it, the solution's maintenance is greatly simplified, as the number of interfaces with external systems is significantly reduced.

 

The following image illustrates the powerful capabilities of Bizagi's Data Virtualization, and the benefits provided by this architecture:

 

Virtualization_OV

 

Notice that either through activity forms, business rules (in activities, as part as the decisions in the workflow, etc), or through automatic tasks, access to data in external sources is transparent. Through Data Virtualization, Bizagi will easily link up to the architecture of your existing systems (and the corporate ESB).

 

Prerequisites

In order to use Data Virtualization, the external data source must meet the following conditions:

 

1. Access to the external information system must be available in real time (for online synchronization); if this is not the case, data Replication in batch mode should be implemented.

Such access involves granting both read and write rights to that data source.

 

2. When accessing a database, it is recommended that this database has normalization in its design. It is required to clearly identify the keys in each entity (Bizagi supports compound key configuration), so that Bizagi can uniquely identify one instance.

Additionally, the relationships between Bizagi's entities (to virtualize), must exist between the corresponding ones as well in the external source.

 

 

Important Characteristics

Data Virtualization only applies to tables in external data sources which are regarded in Bizagi as Master Entities (those entities which are transactional; and where new rows are created in a new process instance)

To view more information about Master Entities, refer to Entity Types in Bizagi.

If you wish to use this integration feature for tables containing lists of values; that is, Parameter Entities which have records that are not deleted, refer to Data Replication.

 

Configuring Data Virtualization in Bizagi is easily done through a graphical wizard.

The Data Virtualization Wizard assists the definition for the data provider's connection, to either Oracle or SQL Server databases (done in few steps and without the need of programming).

 

Supported database versions by the Data Virtualization Wizard (for native Oracle and SQL Server connection) are:

 

Database Engine

Version

Microsoft SQL Server

2016

2014

2012

2008 R2

2008

2005

Oracle

12c

11g R2

11g R1

10g R2

10g R1

9i

Supported version by the Virtualization Wizard (native connection).

 

When a project requires Data Virtualization against a different data source other than Oracle or SQL Server (such as MySQL, XML files, Microsoft Access, etc), then it is possible to include a custom implementation and set up Data Virtualization through the Advanced Configuration.

 

This means that any other database engine not listed in the table above is supported for Bizagi Data Virtualization as well, but with an additional developed component required. To view more information about this option, refer to Customizing Virtualization.

 

note_pin

When virtualizing entities against an Oracle database, and in order to use the Wizard, it is required to install Oracle Data Provider for .NET.

  To view information about this requirement, refer to Installing Oracle Data Provider for .NET.

When using data replication or data virtualization against an unicode database, ensure that your Bizagi database supports unicode characters as well.

 

Bizagi supports a comprehensive set of source data types out-of-the-box (in Oracle or SQL Server data source).

To view more information about the supported data types by default, refer to Data type support.

Any data type not listed in the table at the link above, is supported for Data Virtualization as well, but with an additional developed component required (through the Customizing Virtualization feature).

 

Deleted values at the source are never deleted in Bizagi.

When synchronizing values for virtual Entities, Bizagi will disable those records which are deleted at the source (will be flagged, using a database logical delete instead of a physical delete).

This is done in order to preserve data integrity for existing cases in Bizagi.

 

 

To view more information about guidelines and advanced subjects related to Bizagi Data Virtualization feature and options, refer to Guidelines for Virtualization best practices.

 

 

Configuring Virtualization 

As mentioned above, configuring Virtualization can be done in two ways.

In most scenarios the assisted graphical wizard will cover all your needs.

To view information about this first method, refer to Using the Virtualization Wizard.

 

However, for more complex scenarios you may want to use the Advanced Configuration options.

Such scenarios mainly involve:

The usage of data source which is not SQL Server or Oracle (using Custom Virtualization).

The requirement for advanced configuration (e.g. wanting to use an Oracle column of an unsupported data-type).

The need to manually adjust the configuration. This may happen in sophisticated scenarios where you have a whole set of tables which are related to each other. This may involve relationships with replicated entities, and therefore this configuration requires that all of these tables are replicated and virtualized with some considerations.

 

To view information about this second method, refer to Using advanced Virtualization configuration.