Navigation: » No topics above this level«
Bizagi presents an Enterprise mapping layer which provides easy configuration for application integration.
Through this feature, processes in Bizagi can directly connect to other systems or applications to exchange business information.
We recommend that your business processes integrate with other systems and applications using a service oriented architecture that can use web-based services such as RESTful or SOAP services.
Integration points in processes
Consider as an example a Credit Request process in which the process looks up in a Credit Bureau whether the applicant is on a black list.
The process eventually verifies the borrowing capacity of the applicant.
Both being on the black list and the borrowing capacity are information that is managed in another system.
When you design your processes, integration points are the activities you include in them where you know there is the need to exchange information with another system.
The image above shows four integration points (Verify in black list, Import applicant information, Check borrowing capacity, and Lookup in Credit Bureau).
In general, integration points should be defined as BPMN Service Tasks which execute asynchronously.
BPMN Service Tasks are identified visually in the flowchart by a gear icon located at the upper left corner:
Integration best practice
For application integration, best practices for interoperability and maintainability dictate that you integrate with other systems and applications via web services (i.e, service-oriented architectures).
For this, make sure that web services are available for those systems and applications you wish to integrate with Automation Service, and make sure that the services are accessible through the internet (have a public endpoint) and follow best security practices.
Once you make sure this, it is easy to invoke web services in Bizagi without any coding.
You may double-check that your web services are accessible through the internet by checking with third-party web sites which allow you to verify that your URL has a valid DNS record for internet access.
For this, you may choose to rely web sites such as https://mxtoolbox.com/, where the result should indicate that a DNS record is published and found.
To implement best security practices for your web services, you can rely on different industry-standard ways to secure them from unintentional or malicious outside access, by:
•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 using instead a proxy server that requires authentication.
•Relying on authentication: This means ensuring that your services implement a token-based authentication mechanism such as OAuth to block unauthenticated access.
•Filtering IP addresses: This means restricting the IP addresses that can target your services to those you have configured in Automation Service. By having your proxy filter out IP addresses not explicitly included as approved in the list, you enforce protection of your services.
•Other assets: This means having assets such as IDS, IPS, logging systems, or WAFs, in place to identity, prevent and mitigate attacks.
Using a DMZ on your side is a best practice, especially when you expose certain services to applications outside of your network, to protect the internal network and its resources.
Relying on secure protocols to protect transmitted data, such as HTTPS, is also a best practice.
Note that Bizagi does NOT require any of these measure.
We list them common security measures that you may want to consider to harden your services when make them accessible from the internet, so you can be confident you have mitigated potential vulnerabilities.
The following possibilities reflect the multiple features offered by Bizagi for a range of integration requirements.
1. Invoking SOAP web services from Bizagi
Bizagi features a generic SOAP Web service connector which you can easily configure using graphical mapping of inputs and outputs (without the need of programming).
Even though this generic Web services connector supports RESTful services, it is recommended for SOAP services.
For RESTful services, Bizagi Connectors offers support for advanced options not supported by the Web services connector, such as including headers or using OAuth (described below).
Consider that you should integrate web services using HTTPS endpoints (instead of HTTP).
For more information about this feature, refer to Web services connector.
2. Invoking RESTful APIs or connecting to other applications from Bizagi
You can accelerate your implementations by plugging in ready-to-use connectors (or modifying and tweaking them according to your needs).
Such ready-to-use connectors target specific services (such as Amazon Web Services, Google Services, Office 365 services, and others).
To choose from a comprehensive set of more than 50 connectors, browse the Connector Xchange.
Bizagi connectors allow powerful extensibility options to support integration with other systems or applications.
For systems or application featuring modern architectures such as services which are cloud-ready, offering a RESTful API, no programming is needed.
You can also choose to create your own connectors and integrate a third-party API for this purpose, through the Connector Editor.
For more information about this option, refer to Bizagi Connectors.
3. Extending logic with APIs or custom code in Bizagi
You can also extend the logic behind business rules in Bizagi, by including your own components or bundling third-party APIs.
You can write you own code to directly integrate APIs, or 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.