Overview
The first step when deploying business applications to Automation Service, as described at From Studio to the cloud, is to design, build and automate your processes.
Process automation is how you can convert your process flows into technological applications, while relying on Bizagi Studio.
Before doing so, it is important to review how you use Bizagi's features to automate the processes in your applications, so they are aligned with your expectations for a Production environment.
Rapid prototyping, early validations, and unit tests
Bizagi Studio integrates a runtime Work Portal within the Development environment. This lets you do rapid prototyping of the UI, or overall tests on the behavior of the business applications, while you are developing them.
As this building/implementation stages proceed, the runtime Work Portal reflects all the changes performed directly in Bizagi Studio in real time, and just as end users in a Production environment would see them.
Once verification in the Development environment is complete, you may plan your deployment to the Testing environment in Automation Service.
Designing business applications with Bizagi
Before you publish business application to a testing or a Production environment, make sure you completely understand the following concepts associated with working with Bizagi:
1. Bizagi projects
With Bizagi Studio, you create business applications inside of a Bizagi project.
Within that project, you may create an unlimited number of processes, while having them share a single data model if desirable (e.g, relying on a single entity definition for customers), a single set of end users and a single authentication mechanism, and a single URL for end user access. A project makes use of its three default environments: development, testing and production.
Even though through Studio you may create multiple projects, these are not often needed/ideal and mainly valuable when wanting to deliver different products or implementations of a product targeted for different setups.
Deployments to Automation Service environments consider business applications stored in one project only, and merging processes spread across several projects is not supported.
Note that, within a project, you may design separately a hierarchy for your processes belonging to the different business units, while relying on ACLs for each.
To learn more about how to define your company's processes architecture, refer to this article.
2. Organizational elements definition
With Bizagi Studio, you define elements in your organization (such as areas, positions, skills, roles, and user groups) that will be involved in processes, either for workload allocation (participants assigned to tasks) or to configure access rights for menu options and process visibility.
You define the elements directly in the Development environment and deploy them into live environments (i.e, testing or production), though end users are managed directly in live environments so their areas, positions, skills, roles, and other details are configured at any time.
You can edit user groups in the testing or Production environments, where you can include or remove users; however for Automation Service, you cannot create new user groups or delete existing ones.
To learn more about organizational elements definitions with Bizagi, refer to organization.
3. Types of entities in Bizagi
When designing your data model, note that Bizagi offers five types of entities, each having a different treatment at runtime.
Of the five, there is one entity you need to fully understand and will be working the most to leverage best practices for your business applications' maintainability and performance.
This key entity type is parameter entities.
Parameter entities let you to define a list of values you can either deploy from your Development environment (like a preset status such as Approved or Rejected), or manage directly in your live environments (like a list of cities or offices that you can dynamically update).
To learn more about parameter entities and how you can manage them in Production environments, refer to Where to manage parameter entities.
4. Business keys for entities
A Business key is the column or set of columns that uniquely identifies each row in an entity.
Through definitions of business keys, you guarantee that the information held in the key column (or columns) of each record differentiate it from all the other records in the same entity (avoid duplicates).
Bizagi will not allow inserting a new row that has the same business key value as that of an existing row.
This will be useful if you rely on such definitions for your entities.
Though it is a recommended practice to explicitly define business keys (especially for parameter entities), not every entity necessarily benefits from using them.
If you define business keys for your entities, remember that you cannot change this definition for an entity after the entity has been deployed to a Production environment.
To learn more about setting business keys in Bizagi, refer to business_keys.
5. Integration with external systems
Bizagi offers a powerful integration layer that supports the different integration possibilities involved in an enterprise-class, digital transformation initiative.
You can easily connect Bizagi with Identity Managers, service-oriented systems offering web services, document management systems, enterprise content managers, email servers or other general applications and cloud services.
For your integration points, It is important that you rely on the use of asynchronous activities and their properties whenever possible.
To learn more about asynchronous activities, refer to Asynchronous Activities.
For Automation Service, connecting to certain other applications such as legacy systems, or point-to-point integration with databases or similar repositories such as Active Directory for users (or in general any corporate system which is hosted on-premises), requires a VPN setup.
Plan adequately and consider validating and testing how well integration points behave in terms of performance. A VPN will not address any external issues caused by a high latency in the communications between the cloud and your company server's physical location.
Important
Consider the following aspects to make sure that your implementation is eligible for a deployment to Automation Service and that your processes comply to Automation Service requirements:
1. You may not run processes in Automation Service which were downloaded from the Bizagi Process Xchange.
2. You may not run processes in Automation Service if your project uses Oracle as the database engine.
3. Even though certain features are configured through Bizagi Studio, not all of them can be taken into Automation Service as per the defined configuration.
For example, features like Bizagi database encryption, make sense for on-premises setups, are not targeted for nor taken to Automation Service, since Automation Service, already manages encryption for data at rest within its cloud-centric architecture.
|
In addition to the above, we strongly recommend that you confirm that you are using a Bizagi Studio of the same major and minor version as your Automation Service environments. The update and build numbers may be different; but we recommend that the update + build number be the same as or lower that your Automation Service environments. For example, you could be using Bizagi Studio with version 11.1.0.2235 and deploying to the cloud version 11.1.0.2241. |
What should I do next?
Once you are comfortable with the above concepts and recommendations, and have finished implementing your processes, prepare these processes so you can deploy them to Automation Service.
For information about this next step, refer to Prepare processes for export.
Last Updated 7/18/2023 9:29:49 AM