Reactor

Product Introduction

Summary

In times when thick client solutions were in use, it was entirely normal to execute client data changes in transactions. Transactions denote a user applying a number of successive changes to a client or their services and hitting Save, finding everything in order. Thick clients typically contained all business logic that ensured an orderly execution.

However, the world of thin clients was faced with a specific problem, namely that logics implemented in clients could not be opened on APIs, therefore they were created in different clients at the same time.  One of the characteristics of the world of thin clients is that each channel uses a different technology, therefore all solutions differ from one other, repeatedly creating new client and service manipulation logics. This led to the use of all the different channels becoming a nightmare, as in the case of multi-channel sales and customer service, it is basically impossible to guarantee that the same thing will happen to clients logging on different channels.

Another characteristic of thin clients is that they usually work with a single modification - single refresh logic, therefore they cannot handle complex transaction-method operations with multiple steps. This has also led to the loss of well-functioning cross-selling and extension logics and it required a radical simplification of product portfolio. The radical simplification of product portfolio can lead to even more painful income losses than the loss of cross-selling and extension options.

The most similar solution to thick clients is the shopping carts seen in web shops, yet these typically are unable to handle the manipulation requirements of continuous services or the initial step that the basket should include the customer's current service image and contractual status already upon opening. Therefore, there is no real solution for companies operating in the service sector (such as telecommunication, insurance or financial services).

They require a transaction engine that can be used through APIs and can provide answers for all the problems and needs listed above.

This is Reactor.

Reactor is part of a transaction CRM solution family that covers front-end, human processes, the cache of background systems and the field of order execution.

Functional abilities

Reactor simultaneously performs in 3 main roles, which are described in the paragraphs below:

• transaction engine (T)
• regulation (or rules) engine (R)
• pricing engine (P).

Transaction-Based Operation (T)

In practice, Reactor runs transactions containing the manipulations of Product Recommendations. These transactions are very similar to database transactions: they can be created, you can make a great deal of changes and approve or discard them.

Possible operations range from green field client creation to simple operations such as setting up a call-forwarding number on a Product Offering.

To ensure data consistency, Reactor uses a special locking mechanism for clients that are affected by a transaction. The mechanism is called "optimistic locking", which works by comparing the status of the customer with the status of the approval when the transaction is opened. If there is no discrepancy between the two statuses, the transaction can be handed over for execution. This approach avoids the locking problems that occur when opening (such as stuck locking), and makes parallel transactions (so called "what if" examinations) possible.

Rule-Based Business Logic (R)

The business logic of Reactor can be configured by predefining rule types such as prerequisites, exclusion, minimum requirement, co-movement, and others. Rule types have been carefully tested both in terms of functionality and performance during development, so users have nothing else to do than to configure the appropriate rule parameters after performing service modelling (where the assessment of the portfolio and its translation to rules takes place). Creating parameters instantiates, for example, a prerequisite rule, where service "A" is a prerequisite for ordering "B", or that in the retail segment service "X" is not available.

Rule Segmentation (R)

In a complex business environment, it can easily happen that managing thousands or even millions of rules must be done in order for automated service manipulation to work. Examining several complex business situations has led to us to discover that rules and products can be designated into segments for Reactor, where only ten to one hundred rules are required for each segment.

Rule segmentation has several benefits:

• it helps avoid unwanted side-effects caused by new rules (such as when a new rule for a retail area causes problems in the field of business services, for example)
• the small number of rules drastically decreases the resources needed for business testing
• it can be easily determined what areas are affected during a modification; a new rule segment can be created in case of the modification of market segmentation, in a way that the operation of previous offers remains unchanged
• as a single transaction only deals with a single rule segment, both efficiency and high performance can be ensured.

Reactor basically ignores a number of business rules: if a few hundred rules can be handled easily, a few million can be handled easily as well. There is no significant difference in user experience.

Typically, the following keys are used in segmentation: business process, customer and subscription type, life cycle status, product portfolio identifier, loyalty time, and tariff package.

Customer Hierarchy Support (R)

Reactor manages Product Offering manipulations both on the subscription / contract level and any existing Customer-level by default. Customer-level operations may apply to customer-specific product offerings and to operations performed simultaneously on each customer subscription.

The Use of Points and Balances (R)(P)

Reactor is prepared to manage transactional balances of money or other currencies (such as loyalty points). In an environment where testing creditworthiness is a prerequisite for a new sale, Reactor can narrow down offers using special (minimum prerequisite) rules based on test results.

This same applies to balances, in the case of money or naturalia balances as well. Let’s take a look at loyalty points, for example. Reactor receives the amount of loyalty points for entities affected by the transaction from the Loyalty Management Application. Subsequently, our transaction will treat this amount as the opening balance; for example, it is possible to cover the price of a Product Offering from this balance. After each of these operators, Reactor decreases the balance available in the transaction, limiting the list of further offers available for the balance.

Paying in Instalments (P)

In the case of valuable hardware elements, there is often a need for payment in instalments. Reactor can calculate payment details based on predetermined business conditions, such as the starting amount or the minimum and maximum number of instalments.

Non-functional capabilities

High Availability

Reactor can run simultaneously, in multiple instances, in two different modes: stateful and stateless failover. In the case of stateful failover, certain instances share the details of transactions that they manage through a memory database, therefore any instance can continue any transaction. There is no such possibility for stateless failover, as each instance only manages its own transactions, therefore the so-called sticky mechanism is used to mark certain instances based on the identifications of the transactions.

Rapid Response Time

Reactor is designed to work with high-performance online environments, such as online stores, IVR or chatbot systems. A slow response is not acceptable in these environments. For Reactor, the maximum response time for certain extreme complicated operations does not exceed 1 second, while response time is expected to be less than 0.3 second.

High Performance

Reactor can manage a great number of transactions at the same time, which can contain thousands or millions or business rule instances.

Data Protection

The transactions can often process personal data or other sensitive business information. Therefore it is important that detailed logging mechanisms should monitor the dating of logs and that the logs should not contain sensitive data, such as providing a password when activating a service.

Multi-Channel Operation Based on Channel Identification

Reactor can be used by multiple business channels at the same time, which can be protected by authentication and authorization rules assigned to the channels. The authorization function ensures that unauthorized users cannot use Reactor, while it also prevents users from accessing each others’ transactions.

Multi-channel operation offers one other significant opportunity: channels can hand over a managed transaction to another channel for monitoring or finalization. For example, a chatbot sells a new service to a previously identified client, which can be checked in the back-office by the administrators before finalizing the order. In this case, the chatbot sends the transaction ID to the back-office application's task list, then the administrator can continue handling the order from where the bot stopped in the interactions with the client.

Transaction Aging (T)

One way of ensuring high performance is that Reactor automatically discards abandoned transactions. The expiration time can be set as an environmental parameter, which helps Reactor adapt to the expectations of different types of environments.

Specialisation of the Data Model

One way of ensuring high performance is that Reactor automatically discards abandoned transactions. The expiration time can be set as an environmental parameter, which helps Reactor adapt to the expectations of different types of environments.

Reference data

Reactor can be configured through a reference database, which contains all Product Offerings and their rule instances. Transactions read reference in advance; this way, the number of database accesses are reduced and the performance of operations is maximized.