Bizagi provides programmatic access to the processes functionality and to the business information underlying in your data model, by featuring a powerful service-oriented API which is ready-for-use in every Bizagi project.
Whenever there is the need to integrate Bizagi, driven by any of your existing systems or applications (i.e, fire new process instances, trigger business events in them, cancel them, get reports, or simply update business information, among others), you may rely on 2 different Bizagi APIs.
Bizagi API features a SOAP compliant (message-oriented), comprehensive set of web services with convenient and easy-to-use methods, while supporting WS-Security and other features and standards.
Features provided by the 2 Bizagi APIs are those allowing you to rely on the Experience Design features, Bizagi's BPMN/workflow engine, data access engine and queries/reports engine.
In case you wish to leverage Bizagi's UI engine (embed user interfaces or Bizagi's complete Work portal into your system), refer to Portals integration.
Bizagi product architecture follows best practices regarding integration between systems and applications, to support scenarios involving heterogeneous platforms and while promoting the use of a service-oriented architecture that in turn enables integration with corporate assets, such as an ESB (Enterprise service bus).
To use Bizagi API you do not need to incur in any technical steps (e.g, generate, rebuild or publish) in order to consider the definitions included by your specific processes or data model.
Bizagi Web services are ready-for-use and already published in every Bizagi project, while considering all possibilities contained in your processes, in order to speed up the implementation of your integration requirements.
Web services are already developed and available, though you may choose to publish them or disable them in case these are not needed (as per your business requirements).
For a production environment, you may too configure additional aspects for them (e.g, hardened security measures) at the Web application server.
To view detailed information about the two types of APIs, refer to the links below:
1.SOAP web services:
Enable you to fire new process instances, trigger business events in them, cancel them, get reports, or simply update business information.
For more information, refer to SOAP web services.
Enable you to leverage the Experience Design features, where you have Stakeholders configured.
Though such features, you may fire new process instances for those relevant processes (or from available actions), execute searches, or obtain general information regarding cases, My stuff, etc.
For more information, refer to OData services.