Application integration

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

Application integration


Bizagi presents an Enterprise mapping layer which provides easy configuration for application integration.

Through this Enterprise mapping layer, processes in Bizagi can directly connect to other systems or applications in order to exchange business information.


It is recommended that your business processes integrate with other systems and applications based on a service oriented architecture (i.e, the possibility to call out web-based services such as RESTful or SOAP services).



Integration points in processes

Consider as an example, a Credit Request process in which such process looks up in a Credit Bureau whether or not the applicant is in a black list.

The same process eventually verifies the borrowing capacity of the applicant.

Both the black list and the borrowing capacity are part of certain information that is managed in another system.


When designing your processes, the activities you include in them where you know there is the need to exchange of information with another system, are referred to as integration points.



The image above shows four integration points (Verify in black list, Import applicant information, Check borrowing capacity, and Lookup in Credit Bureau).

Note that as a general recommendation, integration points should be defined as BPMN Service Tasks which execute asynchronously.

BPMN Service Tasks are identified visually by a gear icon located at the upper left corner:


Integration best practice

For application integration, best practices in terms of interoperability and maintainability dictate that you should integrate with other systems and applications via web services (i.e, service-oriented architectures).

For this, ensure that web services are available for those systems and applications you wish to integrate with Bizagi PaaS, while making sure that such services are accessible through the internet (i.e, have a public endpoint) and follow best security practices.

Once you ensure this, invoking web services is easily done in Bizagi without the need of coding.


As a general recommendation, in order to implement best security practices for your web services, you may rely on different industry-standard ways to secure them from unintentional or malicious outside access, such as:

Using a proxy: This means not allowing direct external access to your services (e.g, by relying on a DMZ, port forwarding mechanisms, etc), but considering instead the use of a proxy server that requires authentication.

Relying on authentication: This means ensuring that your services implement a token-based authentication mechanism (such as OAuth or others), so that you restrict unauthenticated access.

Filtering IP addresses: This means configuring the IP addresses employed by Bizagi PaaS as only allowed IP addresses to target your services. By having your proxy filter out other IP addresses not explicitly included as approved in the list, you enforce protection of your services.

Other assets: This means having assets in place such as IDS, IPS, logging systems, or WAFs, so that you may identity, prevent and mitigate attacks.



Using a DMZ on your side is best practice, especially when exposing certain services to applications outside of your network, while still protecting the internal network and its resources.

Relying on secure protocols to protect transmitted data is also a best practice (such as HTTPS).


Note that per se, Bizagi does NOT require any of the above.

These are simply listed as common security measures that you may want to consider to harden your services when made accessible from the internet, so that you feel more reassured about mitigating potential vulnerabilities (for your own convenience).



The following possibilities reflect the multiple features offered by Bizagi for the diverse integration requirements.


1. Invoking SOAP web services from Bizagi

Bizagi features a generic SOAP Web service connector which is easily configured by means of graphical mapping for inputs and outputs (without the need of programming).




Even though this generic Web services connector supports RESTful services, it is recommended for SOAP services.

This is so because for RESTful services, Bizagi Connectors is featured with support for advanced options not supported by the Web services connector such as the possibility to include headers or use OAuth as described next.

For more information about this feature, refer to the Web services connector.


2. Invoking RESTful APIs or connecting to other applications from Bizagi

You may accelerate your implementations by plugging in ready-to-use connectors (or modify and tweak them according to your needs).

Such ready-to-use connectors target specific services (e.g, Amazon web services, Google services, Office 365 services, etc).

To choose from a comprehensive set of more than 50 connectors, browse the Connector Xchange.




Bizagi connectors allow powerful extensibility options regarding integration with any systems or applications.

For those systems or application featuring modern architectures (e.g, services which are cloud-ready, offering a RESTful API), no programming is needed.

Alternatively, you may choose to create your own connectors and integrate a third-party API for this purpose, through a Connector Editor.




For more information about this option, refer to Bizagi Connectors.


3. Extending logic with APIs or custom code in Bizagi

You may also extend the logic behind business rules in Bizagi, by including your own components or bundling third-party APIs.

You may write you own code in order to directly integrate APIs, or especially to perform additional processing.

This way you end up registering and bundling in Bizagi your own .DLL assemblies.




For more information about the possibility to integrate APIs or custom code, refer to Custom components.