Welcome!

Introduction and Installation Scenario

Difficulty:beginner

Estimated Time:40 minutes

The Business Background

It is your first day working at Pecunia Corp. One of the divisions of the company is the Issuer, and one of the most common, yet expensive, tasks is the dispute of a credit card transaction.
In this scenario we will look at the installation process of Red Hat Process Automation Manager (RHPAM) 7 on OpenShift Container Platform, as well as some of the tasks that a production installation will require.
Note: Because of the limitations of the workshop environment, all of the topics regarding persistence will be omitted.

One of the processes that the bank has identified as a candidate for automation is the credit card dispute process. The processing cost of this business process is very high, regardless of the amount that is being disputed. Second, it is also a heavily regulated process that requires:

Audit trails

Mandatory steps to be taken

In this workshop we will automate this process to:

reduce the processing cost.

improve customer satisfaction by reducing turnaround time through automation.

make decisions reproducable by automating business rules.

provide insight into the process, enabling the use of analytics to analyse and optimize the dispute process.

Congratulations!

You've completed the scenario!

Scenario Rating

This scenario has explained how to create and configure your environment to author business automation assets, in the next scenarios you will learn how to build those assets based on the Functional Requirements defined.

Steps

Introduction and Installation Scenario

Use Case Introduction

Use Case Overview

The requirements that are handed to you:
These requirements are the policies of Pecunia Corp. to solve a Credit Card Dispute.

Background

The cost of processing a credit card dispute is very high, and also critical from the customer experience perspective.

Usually the credit card holder is stressed to protect the assets trusted to the bank, therefore one of the requirements for the interaction with the dispute system is the constant feedback to the customer, informing the latest status of the dispute. E.g., who is currently processing the dispute, is additional information from the customer required, has the dispute been automatically accepted, has something gone wrong with the dispute, etc.

Most of the complexity with the CC Dispute process comes from the fact that is a multi-step process where every dispute is a one-off situation, the actual outcome of the dispute is a result of the interactions between the different actors and the decision logic. On top of that, the information regarding the case, has to be the input and output of every interaction, everybody need to look at the same data and be observers of changes in it.

The actors that we can identify are:

Credit Card Holder: aka Customer

Credit Card Issuer: In this case Pecunia corp.

Card processing network: The organization that oversees the process. Some differ in their procedures than others.

Credit Card Acquirer: A financial institution that obtains the rights to the merchant’s account and tasked with getting payment on the merchant’s behalf.

Merchant: Seller of the goods and must either fight or accept the chargeback.

We can resume the process in the following diagram:

The basic steps are:

1- The Credit Card Holder starts a dispute with the CC Issuer.

2- The CC Issuer needs to decide what type of processing is required for the dispute (automated chargeack or normal processing).Jump to step 3.1. or 3.2.

3.2 - The CC Issuer needs to do standard processing, contact the Card Processing network to start the dispute, the Credit Processing Network then contacts the CC Acquirer that requests evidence to the merchant and a formal response to the dispute.

3.3 - The Merchant send the evidence and response to the CC Issuer

4- The CC Issuer assess the risk of the dispute.

4.1- The CC Issuer requests a manual approval for the dispute from a knowledge worker. Jump to step 5.1. or 5.2

4.2- The CC Issuer based on the data resolves the case. Jump to step 5.1. or 5.2

5.1- The dispute is accepted and the money reimbursed to the CC Holder and the backoffice chargeback for fee transactions started

5.2- The dispute is rejected

6- The CC Issuer informs the CC Holder of the result.

Business Requirements:

There are two points in the process where depending on a business decision, the processing path bifurcates. The decision making is right now subjective, as a human - in this case a CC Issuer agent- is responsible to reach a conclusion based on his/her individual knowledge.

Hence there are two decision's sets that change the overall processing making: One set that determines whether the dispute can be qualified for automated chargeback, and a set that determines the risk of the dispute for manual approval and resolution.

For the first scenario, going back and forth in the whole processing chain is costly for all the parties involved, plus the amount of the dispute can be less than the cost of processing the dispute, in addition to that the CC Issuer can offer automated chargeback to it's highly loyal customers.

So the first bifurcation point gives Pecunia corp the ability to gain loyalty with strategic customers and avoid cost, this scenario is Automatic vs Standard Processing. The following diagram describes the scenario:

The second use case has the decisions to determine the risk of the transaction and if a manual approval is required.

Once that is decided that the dispute will be processed in a standard way, by contacting all the chain of CC transaction processing (3) we have the next bifurcation in step 4 of the processing, based on the case information we need too determine if a dispute needs a manual approval, to such effect we have the following rule:

Every amount larger than 1000 should be manually approved.

An also at this point we need to determine the risk profile of the dispute, this risk scoring will be part of the input for both the manual approval path and the automated resolution.

The risk of the transaction is determined by the status of customer and the amount of the dispute:

For a standard customer, and a dispute amount between 0 and 100, the risk is low.

For a standard customer, and a dispute amount between 100 and 500, the risk is medium

For a standard customer, and a dispute amount above 500, the risk is high.

For a silver customer, and a dispute amount below 250, the risk is low.

For a silver customer, and a dispute amount between 250 and 500, the risk is medium.

For a silver customer, and a dispute amount above 500, the risk is high.

For a gold customer, and a dispute amount below 500, the risk is low.

For a gold customer, and a dispute amount over 500, the risk is medium.

Functional Solution:

Have business rules that will take into account consistent criteria defined to assess risk and automate processing. The business user must have the ability to change these criteria anytime if needed, and apply the changes according to the release process of Pecunia corp..

Non Functional:

Allow the user to change the criteria without technical assistance. Have the tooling for the user to update the rules but using standard spreadsheet-like decision tables or cuasi natural language.

Understanding the components and installation methods

Setting up your work environment

Red Hat Process Automation Manager enables you to automate different pieces of your requirements, you can automate the decision making, the flow of the decision making, the interaction between the people and systems, etc.
In order to be able to correctly install and provision the environment, you need to be familiar with the various platform components and the various ways the product can be configured to support different use cases. Tools like the OpenShift self-service console will allow you to provision, recreate, destroy your working environment and be autonomous from other users .

The following diagram depicts the main components of Red Hat Process Automation Platform.

High Level Capabilities Components

Decision Management

A high-performant, lightweight and scalable rules and decision execution engine based on the open-source Drools community project. Allows business and IT users to define rules in decision tables, guided rules and the DMN (Decision Model and Notation) standard.

Business Optimization

An AI Constraint Satisfaction Solver that optimizes business resource planning use cases such as vehicle routing, employee rostering and conference scheduling. The platform optimizes the goal of a problem based on limited resources under specific constraints. The engine is based on the upstream OptaPlanner project.

Process Management

A high-performant, lightweight and scalable, BPMN2 compliant, process execution engine based on the open-source jBPM project. Provides functionality like business process management, case management and human task management, to enable the automation and optimization of processes and cases.

Business Central Console

A modern workbench that provides user the tooling to build business automation projects consisting of processes, rules, cases, and forms. Second, the workbench provides the management and monitoring functionality to build, deploy, run, manage and monitor business automation and process driven applications.

Architectural components

Business Central Authoring

To build and author the assets available in RHPAM, like rules, processes, cases, etc.

Asset Repository

To be collaborative, all of the assets that you develop are stored in a Git based asset repository. This allows you to version, index, search and share your work with the rest of your team.

Artifact Repository

Once you have completed the authoring phase and you are satisfied with the work you can package your assets into a Deployment Unit. This unit is a standard Java Archive (JAR) and will be stored in the artifact repository.

Controller

The deployment units are deployed to the Execution Engine by the Controller. The Controller abstracts the complexity of the runtime environment through the use of so called Templates, or Server Configurations. This greatly reduces the complexity of managing clustered and/or heterogeneous topologies, for example topologies in which Execution Engines are deployed and managed per line of business.

KIE Server

The lightweight, cloud-native, execution engine that runs the rules and processes contained in the deployment unit. KIE-Servers can be scaled horizontally and/or vertically in an automated fashion using the cloud native capabilities of OpenShift Container Platform. Since the state of the processes is stored in a persistent store (by default a relational database) you can consider the KIE-Servers to be stateless when it comes to process execution.

Smart Router

Provides a runtime abstraction layer over the KIE-Server topology, allowing clients of this topology to interact with a single endpoint. Smart Router contains the information of which processes and rules (deployment units) are deployed on which runtime engine/KIE-Server, and provides routing functionality to the correct server instance based on the client request. In a classical enterprise environment where you have multiple instances running and different nodes, starting and shutting down in an elastic way, the complexity of tracking these changes in order to correctly load-balance the requests is the responsibility of the Smart Router.

For this course you will install an environment containing only the components needed to author, deploy, test and run your assets.
Because a critical capability of a digitally enabled product is to be available as a service, we are going to leverage OpenShift Container Platform has a self-service console where you can choose the different tools needed depending on your skills, LOB and solution.

Cloud installation

Red Hat Process Automation Manager is part of a rich set of tools to develop enterprise solution with multiple capabilities, thought to support multidisciplinary teams with the right tools for the tasks at hand.

The cloud native OpenShift environment has already been provisioned for you. You can access it either via a terminal command line (for example if you're an IT professional) or via a web-based console.

Login

Command Line

If you want to login to the OpenShift system via the command line interface, you can do so by executing the following command in the terminal: oc login -u developer -p developer

As you can see, the IT engineers have already provisioned an environment for you in a project called credit-card-dispute.

Web Console

You can also interact with the OpenShift Container Platform via the Web Console. The OCP Console is available on one of the tabs on the right side of your screen.

Click on the OpenShift Console tab to open the web-console's login screen

Login with username developer and password developer

You will see a list of the projects that you have access to. In this case this is only the Credit Card Dispute project. Click on the project to open the project page.

Red Hat Process Automation Platform

When you click on the project you can see there are 2 deployments listed:

cc-dispute-kieserver

cc-dispute-rhpamcentr

The overview page shows you your working environment. But what if you have special needs of tools and components? Or you simply want to know what you are working on. Lets go ahead and delete the whole project and start a new deployment based on your requirements.

Go back to your home page by clicking the home icon on the top left hand side.

Click on the kebab on the right hand side of your project name

Select Delete Project.

Type in credit-card-dispute

Click on Delete.

Templates

What is a template? Red Hat Process Automation Manager's new design is activity focussed. This means that you have predefined environments available for you to deploy depending on what you want to accomplish. The definitions are modelled in the form of templates. A template describes an environment that follows a Red Hat prescriptive deployment architecture. Templates are provided that define and deploya fully working platform for development, test, production, etc. Depending on whether you want to develop, integrate, test or run processes and other assets, you can choose your environment of choice.
Some examples of the available templates are:

rhpam70-authoring: The environment of choice if you are a business user or developer that wants to author business automation projects, assets and applications. Provides an authoring environment including the workbench and an execution server.

rhpam70-authoring-ha: Same as the previous environment, but with high availability features. This implies that there are multiple (by default 2) instances of workbench and execution server deployed.

rhpam70-trial-ephemeral: If you want a quick demo environment to test the platform. Provides the same environment as the authoring template but without persistent storage.

rhpam70-prod: If you are the administrator of the platform and you want a production like environment. The template provisions a monitoring and management environment, a smart router and 2 execution server groups.

What kind of environment is right for your you depends on your requirements:

In which deployment environment is the platform going to be provisioned?

Is the environment to be used for process and/or rules development

Is the environment used for integration testing

Is the environment intended to be used in production?

What kind of deployment architecture and methodology do you use?

Do you want to be able to install and update process definitions and rules via the management console?

Do you use the concept of immutable containers, and thus don't allow the provisioning of applications through the management console?

Do you have a requirement for high availability of the platform?

What kind of database do you want to integrate with?

For example, if you want an environment to author rules and processes, you can use the rhpam70-authoring.yaml that contains all the components necessary to do so. See the image below.

Quiz: From the previous step what components do you recognize in this template?

In the case of this workshop, because you need a complete authoring environment with a process server where you can test your assets, we could (or should) deploy the authoring environment. However due to the restrictions of this environment (the Katacoda platform does not provide persistent storage), we will use the ephemeral template instead.

Cloud installation continued

Our next step is to create a new project and provision the RHPAM Trial Ephemeral environment.

If you are not already logged in into the OpenShift Web Console, open it on using the tab on the upper right side of your screen. Login with username developer {{copy}} and password developer

Click on the + Create Project button to create a new project. Use the following values for your project

The Add to Project window will open. We will provision a new RHPAM environment from the OpenShift catalog. In the Browse Catalog tab, click on Uncategorized and click on the Select button in the Red Hat Process Automation Manager 7.0 ephemeral trial environment tile.

In the form that opens, fill-in the following values:

Application Name: cc-dispute

Default Password: developer

KIE Admin User: developer

KIE Server User: developer

Scroll down to the bottom of the form and click on the Create button. This will process the template and provision the new environment. Click on the Continue to overview link on the top of the page to go to the overview page of the your newly created project.

When the provisioning is complete, the overview page will show a cc-dispute-kieserver deployment and cc-dispute-rhpamcentr deployment. The first represents the execution server, the latter the Business Central workbench.

Verifying the installation

Verifying your installation

So far you have requested in your self-service console a working environment to author process and policies. Now we will verify the environment and the tools available to you. Earlier we saw that Red Hat Process Automation Manager has authoring tools both for developers as well as subject domain experts.

For business experts, the platform provides the Business Central console, a web-based business workbench with capabilities to manage the full lifecycle of your automation assets.

Business Central

1- Go to your Openshift console tab. Go to step 2 if you're already logged in. If you're not yet logged in, or have been logged out, login using the same credentials as before:

user: developer

password: developer

2- Once logged in you should see your project or workspace called Credit Card Dispute

3- Click on your project to see the components.

You will see listed 2 components the cc-dispute-kieserver and the cc-dispute-rhpamcentr. All you need to know is that the first one is for execution of your automation assets and the latter for authoring of your automation assets.
At this point we are interested on the authoring environment.

4- Select the cc-dispute-rhpamcentr deployment and look at the details of the component.

5- In the network segment you have the information of the location of your console. Click on the link that to the right that says Route to external traffic and in a new window the login page for your business central should open.
Use the credentials:

user: developer

password: developer

And you should see the console as follows:

Security of the platform console

Security and configuration

Enterprise applications require enterprise class security implementations. At the same time, the security system, the system in which you define users, roles, groups and their respective authentication and authorization configurations, needs to be easy accessible and easy to use.

Red Hat Process Automation Manager provides a comprehensive security system, that's easy to configure and use. By default, the security system uses the local filesystem to store it's configuration, but, being an enterprise solution, can easily be configured to connect to, for an example, an enterprise LDAP system.

Second, Red Hat Process Automation Manager comes with the Red Hat Single Sign-On (RH SSO) platform, which enables you to secure your web applications by providing Web single sign-on (SSO) capabilities based on popular standards such as SAML 2.0, OpenID Connect and OAuth 2.0. This allows you to, among other things, secure the Red Hat Process Automation Manager web consoles, the REST endpoints to interact with the platform and the access to Git.

In this scenario we will learn how to use the out-of-the-box security management system of Red Hat Process Automation Manager to create new users and groups, which we need to implement our use-case.

In RHPAM, you have 2 different types of users:

platform users: these are the users that interact with the authoring environment, for example the developer user that you used to log into the platform

application users: these are the users that will interact with the process driven application that you're building with, and running on, the platform. In the case of our Credit Card Dispute system, we have identified 3 different roles that will interact with the process:

In fact, we can see these are not individual users, but groups that the different user can belong to. Our bank has these 3 groups defined, and the tasks for each group will be defined and configured as you automate the process.

User Configuration

RHPAM's workbench uses and activity-centered design approach, in which functionality is grouped according to the tasks that a user can (or must) perform. The functionality to administer users and groups can be found in the Settings menu, which can be accessed by clicking on the gear icon in the upper right of the screen next to the questionmark icon.

The Settings menu shows all components that you can configure in your environment. In this step we will focus on the users and groups.

Click the groups icon and you'll see the group administration menu, where you can list the groups that currently exist, update or delete them or create a new group.

Click on New Group. We will add the following new groups:

card-holder

agent

agent-manager

After you type in the name of the group, in this case card-holder select the adminUser and click on Add selected users to add it to the card-holder group. In a real world scenario all these groups will be associated with different personas but for the sake of simplicity, your user will be part of all the groups needed, in order for you to be able to test the processes and application.

Help

Katacoda offerings an Interactive Learning Environment for Developers. This course uses a command line and a pre-configured sandboxed environment for you to use. Below are useful commands when working with the environment.

cd <directory>

Change directory

ls

List directory

echo 'contents' > <file>

Write contents to a file

cat <file>

Output contents of file

Vim

In the case of certain exercises you will be required to edit files or text. The best approach is with Vim. Vim has two different modes, one for entering commands (Command Mode) and the other for entering text (Insert Mode). You need to switch between these two modes based on what you want to do. The basic commands are: