Bizagi offers an integration layer which allows existing corporate systems (such as ERP, CRM, Core applications, legacy systems and services in the ESB in general), to be integrated by Bizagi corporate solution throughout different possibilities. See integrating external applications.
In scenarios where these above connectors do not suffice and there is the need to extend or customize the logic running at Bizagi servers (e.g, to integrate with specific systems and applications or reuse APIs), you may choose to create your own components to bundle within Bizagi, through Bizagi Connectors (recommended).
If using Bizagi Connectors is entirely not feasible, then you may opt for Bizagi Component library.
This feature is supported in Automation Service, though it not may be the ideal solution for an integration requirement.
Recall that Automation Service, as a cloud-centric architecture, is built for scalability among other pillars.
A high scalability in Automation Service 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 very important that when integrating your systems and services for Automation Service, you can follow modern, service-oriented principles such as using Bizagi Connectors over Component library when possible.
Bizagi Component library
The component library allows you to develop or reuse APIs or your own class libraries, so that you build them by using an IDE of your choice (Visual Studio, Eclipse, Netbeans, etc).
Though it allows you to connect to legacy systems and databases, you may also extend the logic and processing capabilities of business rules by bundling such libraries inside Bizagi (dll assemblies).
An example of Component library use oriented towards business logic enhancement, is when we need to consider Process logic that implements sophisticated calculations or operations, for instance when performing amortization payments simulators or manipulating content inside files. These operations can be so complex that may involve the use of existing components and APIs.
Regarding component library use for integration purposes, a corporate solution may require relying on drivers that connect to other databases or systems, mainly legacy, mainly those which do not have a service-oriented architecture.
The following image illustrates its runtime concept:
Bizagi connectors features powerful extensibility capabilities regarding integration with other systems and applications, especially with those having a cloud-oriented API (using a RESTful architecture).
Bizagi connectors are portable and highly reusable, and are mainly oriented to connectivity and data, without involving this data's processing.
For more information about this feature, refer to Connectors.
How does it work?
The Component library acts as a middleware repository of custom-developed components (which can use in turn, other external APIs or connectors).
This component is registered in Bizagi by including its compilation file (either a built .dll or .jar, according to the platform technology in which Bizagi's Processes will be executed).
For .NET-based environments, components in the Component Library will have a corresponding dll assembly.
Once registered in the Component library of a Bizagi project, components’ public methods can be directly invoked from the Processes’ business rules (from either synchronous or asynchronous tasks).
To view best practices oriented to the use of Component library, refer to Component library guidelines.
Customers are responsible of the developed code and their custom components uploaded in Bizagi 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 tested throughout the different environments, among others.
Components in Production
Once a project has been deployed to the Production environment, it will not be possible to delete its components (registered in the Component Library).
Therefore, in the development environment (through Bizagi Studio) edition of components’ information is restricted according to whether or not this component is already deployed on a productive environment.
Edition of a deployed component’s information will consider:
•You may edit its registered compilation file (dll assembly or jar file).
•You may not edit the component’s name or its defined namespace in the Component library.