Virtualization Restriction

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

<keywords content="keywords"> virtualize, virtualization, restrictions, restrictions </keywords>

Virtualization Restriction

Here are some important technical limitation when facing a Bizagi project involving virtualization.

1. Control limitation in user interface (UI). Let us consider a scenario where Bizagi data model that has been virtualized against an external data model.

In the above graph, entities A and B are related in such a way that for an instance of entity B one or more instances of entity A can exist (and A has a foreign key of B), that would be the normal case in an entity relation such as "Credit Request" (A) and "Customer" (B). It is normal that, during process operation, a form is created for entity B. An example is when you have to select a customer whose subrogated key "idCustomer" must remain in A as a foreign key.

JoinSearch controls, functionalities added to grids, links to forms, "submit" in business rules and the save button among others, cause the id of entity B to be recorded and created an instance in A for such purpose. If at that moment there is no compound key yet (business key) ready to create the record in A, the virtualization will fail. This problem is due to the fact that if there is no business key yet, a record cannot be inserted in the external entity.

Work Around: leave the original model in Bizagi without virtualizing A, create a virtualized entity A’ and, once you have all data ready to guarantee insertion in A, and map data from A to virtualized A’ in business rules, thus avoiding errors.

WorkAround Issue: if this situation arises in many tables the virtualization strategy or the virtualization data model has to be reformulated because keeping many parallel entities may cause complexity problems in the process construction and an additional load for its modeling and maintenance.

Special Case, Stored Procedures in the data source: when the data to be updated in a virtualized entity must be "complete" before updating via a Stored Procedure (that is used by the virtualization interface) that, for example, needs data like "Payment" or "Type of payment", the Stored Procedure must have a logic for waiting for all the information before storing in the data source entities. This happens because for Bizagi all POSTs initiate a transaction where the virtualization interface is ordered to persist information held at the moment. This can cause, as in a dynamic combo, an attempt to save some data that is not yet "complete" at the level of an instance of an entity (record of a virtualized entity).

2. Limitation for subrogated and self-numeric keys in the external entity. If the external entity has as primary key a subrogated key (idEntityName) controlled by the external system (e.g. a database handler that allows to define a self numeric key) the key attribute must be created in the virtualized Bizagi entity and whenever there is a need to make insertions in the entity an interface must be called to the external system which will allow to find out which is the following number for the key, likewise the use of such a number must be "blocked" in order to guarantee that the new record to be inserted in the virtualized entity is the one found out.

Definitely it is not possible to request or to capture this number from Bizagi.

This limitation may bring performance and complexity problems in the implementation if it happens in many or in all the external data model tables for virtualization.

3. Records size considerations for virtualized entities. Whenever an entity is virtualized the information flow between Bizagi and the external system increases to maintain the synchronization of updates, insertions and deletion of entity instances. When entities grow a lot, as it generally happens with entities resulting from many-to-many or from one-to-many relationships (e.g. customer products grid), you may want to watch out for your solution's design to keep up your application's performance. This means that massive data updates in tables which have a really large number of records, need careful design, otherwise this may induce performance issues.

4. Virtualized and Parameter Entities. If an entity is virtualized, the related parameter entities must also be virtualized. If an entity is virtualized and the related parameter entities are not, there may be errors such as those in the following example: if you have the Client entity, which has a document type that can have the values 11, 22 and 33 (corresponding to Colombian Identification Card, Minor’s Identification Card, Foreigner Identification Card), a non-virtualized entity that contains the types of documents with these codes cannot be created, because the Bizagi surrogate keys would not match when it is related to the virtualized entity.

The following 3 actions have been proposed to deal with the restriction.

Action1. Create the parameter entity in the external system and virtualize it.

Action2. Create a Bizagi parameter entity and virtualize it.

Action3. Virtualize using XML format to exchange the data between the requests of the virtualized interface by means of its virtualization interface and the external parameter entity.

5. Complex Filters. Complex filters take place when more than one condition has been established to filter an entity (using the connectors AND and OR), for instance, when you use GetEntityList. There are usually two situations that take place.

In the filter on a virtualized entity, when a filter on a non-virtualized field (without correspondence in the external table) is combined with a filter on a virtualized field. In these cases, there is an error, apparently because Bizagi sends the external system the virtualized field as well as the non-virtualized field in the WHERE clause.

Action1. Apply only one filter (for the virtualized field), and later go through the resulting structure (dataset in case of .NET) to apply the other filters.

When the compound filter on the virtualized entity is filtered by two or more virtualized fields (with correspondence in the external entity), it fails on some occasions because Bizagi cannot properly construct the WHERE clause sent to the external system for this type of situations.

Action1. Apply only one filter (for the virtualized field), and later go through the resulting structure (dataset in case of .NET) to apply the other filters.

6. Linked operations for Virtualized Entities. It must be kept in mind that operations for virtualized entities can generate updates or linked deletions for the related entities, so those operations must be carefully studied to prevent undesired updates or very long execution times. The virtual entities model must be perfectly understood and the implications of the linked operations that may be produced must be considered as part of the analysis and selection of the entities to be virtualized.

7. Data preparation before updates. When the process needs various data to be gathered from different activities (or screens) before a "definitive" update of the virtualized entities, a state must be managed either in the virtualization interface or in the services provided by the data source to prevent the automatic updates ordered by Bizagi of the virtualization interface and to "delay" the updates until the data has been gathered. The most obvious case is when the data from the entities related to the entity in question are not yet known and are necessary for the creation of an instance of the entity.

8. Use replication for parameter entities. Parameter entities are not generally very "dynamic". If those that change very little can be clearly identified, the option of replicating them from the data source is a valid option and can be adopted as a general guideline.

9. Data validation services are the responsibility of the process. In general, validations (conditions necessary due to the persistence of data, decisions that allow you to know whether an activity can be finalized or not) must be done at the level of the process and not within the virtualization interface. When the data is going to persist in a virtual entity, it assumes that all data validation was done in the presentation layer using the Bizagi facilities for carrying out the validations. <comments />