Cloud workflow
Several people can work collaboratively to design, create, and test a decision service. When they finish the decision service, they can promote it to runtime environments for testing and production.
Users are given roles and permissions in the cloud portal. For more information, see User roles: Decision roles
in the IBM
Cloud Pak for Business Automation as a Service documentation.
The following diagram shows how predefined user roles work with the product components during the lifecycle of a business rule application. The cycle includes development, testing, and production. The collaborators work in the different cloud environments:
Setting up the user roles
When a cloud tenant is created, it is given an account administrator. This person is responsible
for inviting people to work in the tenant. The administrator is also responsible for creating
groups, and assigning roles and permissions. The administrator gives users access to the components
and environments in the tenant. A user can have more than one decision role. For more information
about the account administrator, see User roles: Cloud Portal roles
in the IBM
Cloud Pak for Business Automation as a Service documentation.
Collaborating on the decision service
A rule developer creates the decision service in Rule Designer, an Eclipse-based rule editor. The initial version of the decision service contains artifacts that include rules, ruleflows, and deployment descriptions. The developer can also test the decision service in Rule Execution Server in the development environment.
The following diagram shows the creation and testing of the decision service in Rule Designer. When decision service is ready, it is published to Decision Center in the development environment:
In the Decision Center various users can work on the decision service. For example, a business user can update existing rules, and a configuration manager can create new branches, edit rules, and deploy RuleApps to Rule Execution Server. Governance tools help manage activities through versions and work assignments.
In the following diagram, the decision service is updated and deployed to Rule Execution Server:
Testing and promoting the decision service
When the decision service is finalized in the development environment, the configuration manager promotes it to Rule Execution Server in the test environment. The performance of the decision service is evaluated by using benchmarks that have standard software development validation procedures. The objective is to reproduce the conditions under which the decision service is going to run when live. If problems arise during testing, the decision service is further worked on in the development environment.
In the following diagram, a web application calls the decision service from the test environment:
When the decision service passes the benchmarks, the configuration manager promotes it to Rule Execution Server in the production environment. A client application can now call the decision service to apply company policies. The decision service can be further developed in the cloud portal, and new versions pushed to the production environment. Because the connection between the client application and the decision service remains intact, production continues without loss in service time during a decision service update.
The following diagram shows the promotion of the decision service to the production environment. When customers use the web application, it calls the decision service.
