Considerations when building for the cloud

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

Considerations when building for the cloud


Bizagi offers a Platform as a Service (PaaS) that provides all the power of the Bizagi Digital Business platform directly in the cloud.

This means that with Bizagi PaaS, customers get to use Bizagi digital business platform, using its powerful capabilities, plus the system architecture enhancements and optimizations that are precisely built for the cloud.


Within its powerful capabilities, Bizagi PaaS offers that same core principles which are trademark and characteristic in Bizagi; such as: collaborative modeling centered in the business, a build-once-and-execute-anywhere paradigm with a WYSIWYG approach for UI, no need of programming, and re-usability of rules, forms, or the data model components, among others (i.e. by using the same Bizagi Studio).

In terms of the complete list of features, even though a comprehensible set of them are available for Bizagi PaaS, there are some exceptions regarding features and options for integration with other systems which are not available/applicable to the cloud.


This document presents all important considerations you need to consider when building applications to deploy in Bizagi PaaS, so that you can ensure that your implementation follows best practices for a cloud-centric architecture (service-oriented), and complies to Bizagi PaaS runtime.




Platform considerations

Consider you may not run processes in Bizagi PaaS which:


1. Were downloaded from the Bizagi Process Xchange.

2. Were created in a project using Oracle as the database engine.

3. Were created in a project using a JEE platform.



Options not applicable (IT-oriented features or toolkits)

Even though certain features can be configured with Bizagi Studio, not all of them will necessarily be taken into Bizagi PaaS as per the defined configuration.

This is so because a same Bizagi Studio is used to build business applications for both on-premises and for the cloud, while Bizagi Studio not being aware of which of the two will be the final target of your implementation.


For example, features like the Bizagi database encryption, make sense for on-premises setups, where the customer is fully in charge of the technological stack (managing the database server and its access, operating systems, redundancy options, etc), and may rely on this feature to choose to encrypt sensitive/confidential information.

Such configuration is not targeted for, nor taken to Bizagi PaaS, given that for the cloud Bizagi already manages encryption for data at rest.

Encryption for data at rest is in place with Bizagi PaaS, and this is taken care by expert cloud operations team personnel, rendering customer data secure in terms of integrity, privacy and availability.


The following options are not applicable because Bizagi PaaS already offers another measure which covers up that same objective (these should not be needed):

Bizagi database encryption (at columns level, as mentioned above).


The Archiving toolkit.

Analytics data store toolkit.

Bizagi Diagnostics toolkit.

One-click deployment (and the advanced deployment is replaced by exporting/importing .bex files to cloud).

Options to manage or configure the Scheduler service.

Options to manage servers and clusters, and their licensing.

Any other very specific options oriented to IT-related aspects, such as the path to store attachments.  


Options not available

Consider the following notes on options available and not available for the cloud:


1. Authentication and identity management

Authentication types available are:

SAML 2.0-based authentication (recommended).

Among supported Identity Managers which are SAML 2.0 compatible, are: Azure AD, ADFS, NetIQ; PingFederate and Okta.

OAuth (plus the OpenID extension) .


LDAP (requires a VPN).


Other authentication options not listed above are not applicable to Bizagi PaaS.

Importing users from an Active Directory is supported while using a VPN.

It is highly encouraged to rely on SAML 2.0 features, given that it will support SSO (and SLO), can rely on multi-factor authentication, and delegate Identity and Access Management to your corporate systems.


2. Integration with other systems and services.

Consider the following when integrating with your systems or services:

ECM integration is eligible to store case attachments directly in your corporate documents repository..

You may integrate your CMIS compliant ECM/DMS if it is cloud-ready (published and accessible via HTTPS through internet), or by using a VPN when otherwise.

Invoking services is highly recommended by using Bizagi Connectors or the Web services Connector.

You may integrate web services (SOAP or RESTful) through either Bizagi Connectors or the Web services Connector, and establish direct communication if these are cloud-ready (published and accessible via HTTPS through internet), or by using a VPN when otherwise.

Custom jobs are supported.

Custom jobs are configured and ran the same as in on-premises projects.

Component library is supported, through consider that you are solely responsible of the code developed in custom components added through this feature.

This entails: watching after an adequate performance while ensuring that locks or issues are not generated, being accountable for uploading secure code, and ensuring that such code is thoroughly testing throughout the different environments, among others.


Consider that components must be self-contained (i.e, all libraries needed by a component must be uploaded via the component library). This means that a component may not rely on driver, DLL, file in general, or connectivity setup that needs to be installed separately into the local machine.


Recall that Bizagi PaaS, as a cloud-centric architecture, is built for scalability among other pillars.

A high scalability in Bizagi PaaS considers that computing power, storage services and other capabilities, are made available on-demand as elastic resources which operate behind a load balancer, and therefore, point-to-point integrations which demand the installation of a component in a specific location is not a best practice.

For this reason, it is important that when integrating your systems and services you can follow modern and service-oriented principles such as using Connectors when applicable.

Other integration options such as using the SAP Connector (for R/3 systems) are not eligible.


3. Integration with other databases.

Consider the following when integrating with your databases through Data Virtualization and Data Replication:

Integrating with Oracle databases or other engines different than on-premises SQL Server instances, is not supported.

Data Virtualization and Data Replication will require a VPN.

Even though you may use a VPN for Data Virtualization and Data Replication, you will need to use this feature wisely due to performance considerations.

Access to an external databases over the internet (from Bizagi PaaS), inherently depends upon factors which are beyond Bizagi's control, such as a higher latency in data transmission, fluctuations, interference and congestion affecting the speed of the channel, the quality of the networks used during transmission, etc.

Using this feature wisely means that you will have to analyze beforehand and assess thoroughly your use cases, so that you can determine if the performance impact is adequate for them.

Most often, working on information of one record specifically will be Ok; while fetching multiple records and work in them may not result as usable.


4. E-mail services

You may rely on Bizagi's cloud e-mail service to send out notifications from your applications.

You may also directly integrate your corporate SMTP e-mail service if it is cloud-ready (published and accessible via HTTPS through in), or by using a VPN when otherwise.


Regarding completing tasks via e-mail, Exchange is eligible as the service mailbox.

Other protocols and options different from Exchange, such as those based on POP3 or IMAP, are not eligible.


5. Bizagi API

Bizagi SOAP web services API can be enabled in your project if needed.

OData services are available and highly encouraged to be used when applicable (i.e., for a Stakeholder-based experience).


6. Bizagi Web parts

Bizagi Web parts, either for SharePoint or other portals are available.

However, consider that given that Bizagi PaaS is based in the cloud, your applications using web parts should also be cloud-based (e.g, SharePoint online), and ideally set up on the same region on which Bizagi PaaS data centre runs.

This will render the use of web parts as a feature enhancing usability and achieving optimal performance.


This means that using Bizagi Web parts from an on-premises SharePoint (or other on-premises applications), is not eligible for the cloud.


7. UI extensibility and Work portal customizations

Widgets are completely supported and highly encouraged for Bizagi PaaS when wanting to extend user interfaces.

Performing bespoke adjustments or customizations that modify directly the files, as shipped in with Bizagi (such as JS, HTML or CSS overrides and modifications), is not allowed.


Similarly, you may not modify the web.config file; nor any other aspects of Bizagi Work portal by different means other than by using the theme builder or out-of-the-box features in general (modifications regarding IIS settings are not allowed as well).

Recall that within the subscription to Bizagi PaaS, a team of experts is appointed in Bizagi, taking care of all infrastructure and services, and its related IT tasks involving provisioning, maintenance and tuning, or technical support (includes 24x7 monitoring), so that you as a customer do not need a DBA, platform admins or other IT-related profiles.



Other considerations

In addition to the above, consider:

1. Versions compatibility

It is strongly recommended to ensure that you are using a Bizagi Studio whose major and minor version is the same as the Bizagi Engine version of your Bizagi PaaS environments.

The update and build number may be different, though it is recommended that such update + build number is the same one or lower than the one of your Bizagi PaaS environments.

For example, it is encouraged to use a Bizagi Studio with version, and deploy to cloud environments using version or for example, cloud environments using version


2. Multiple projects

You may not merge applications from multiple projects.

Recall that a Bizagi PaaS subscription entitles you to use one project in the cloud.

Only if your subscription explicitly supports multiple projects as agreed by contract, then you may deploy multiples projects to the cloud, but each will use separate environments (merging would still not be possible).


3. VPN considerations

When integrating corporate systems which are not cloud-ready, through a VPN, acknowledge that using a VPN from any on-premises system to a cloud environment, does not resolve any potential performance issues caused by a high latency in the internet channel.



Consider as cloud-ready, systems and services which are either cloud-native, cloud-enabled or simply published for access through a public channel such as internet.

This means basically a service which has an HTTP/HTTPS (the later preferred) endpoint.


Recall that a VPN establishes a connection between two endpoints as if these were physically wired (in terms of visibility, but not in terms of performance).

Having said the above, it is important that you evaluate any potential performance impact when using a VPN, especially for online requests (non-scheduled jobs), so that you can determine if inherent factors to the on-premises-cloud communication design significantly affect your requirements.

Some of the inherent factors which are beyond Bizagi PaaS' control are: a higher latency in data transmission, fluctuations, interference and congestion affecting the speed of the channel, or the quality of the networks used during transmission.


This is also important to acknowledge and keep in mind when using an on-premises development environment (which is not subject to the factors described above), so that you can anticipate to what is expected on the cloud-based environments (testing, staging or production).