Two Design Choices for Your MarkLogic Decision Services

In our first blog post, No-Code Business Logic Development for MarkLogic Database, we saw the benefits of using Corticon.js as a no-code platform to enable business specialists to develop, maintain and test rules-driven business logic for Progress MarkLogic servers.

In this blog, we will explore two main design patterns we commonly see in use by our customers.

MarkLogic Integration

Both patterns use the same MarkLogic integration solution. In this section, we will briefly cover how the integration works.

In Corticon Studio, we can generate decision services with just two clicks by using the MarkLogic target platform as shown below:

Note: The decision service generation can be done as part of a CI/CD pipeline with command line tools. Where, for example, generating decision services is done after business specialists commit changes to a source-control system and after all Corticon-driven tests have passed.

On the MarkLogic side, we can leverage triggers. For example, we can execute a decision service every time a document is updated in a database collection. The integration is straightforward as it leverages MarkLogic server-side JavaScript (for details, see the JavaScript Reference Guide).

While a MarkLogic trigger executes in-process very close to the data, Corticon.js decision services perform extremely fast. This enables real-time decision-making processes.

Trigger Implementation

From an implementation point of view, the main actions executed by the trigger can be summarized as:

1. Reading the document as JSON from the collection:
   const data = cts.doc(uri).toObject();
   
2. Executing the Corticon decision service:
   const result = decisionService.execute(data, configuration);
   
3. Writing the business-rules results in MarkLogic database
   xdmp.documentInsert("/insurancePricing/result.json", result, insertConfig });

First Design Pattern – All Data In

All the data that the business rules need is passed in as part of the decision service input payload.

This is illustrated in the following diagram:

The yellow box in the middle of the diagram shows the trigger code which is under the integrator’s control. The blue box to the right shows the decision service, which is under the control of the modeler.

This is the simplest way to use a Corticon decision service. In step 1 in the diagram above, the trigger executes when the file is updated and calls the decision service (step 2). In step 3, upon completion, the decision service returns the results which are inserted into the MarkLogic database in step 4.

This design pattern is the easiest to understand as the MarkLogic document is the complete input to the decision service.

There is a variant to this pattern where the trigger code (the yellow box in the previous image) can read additional documents and merge them into a single input to the Corticon decision service.

From the business rules point of view, all the data is passed in.

Second Pattern – On-Demand Data Retrieval in Rules

Business processes are complex, and for many decision services, it is not desirable or practically feasible to pass all the data required for all conditions as part of the input payload. This would result in a very inefficient process as the input data would be too large and could take too long to gather.

In this second pattern, we let the rules drive what additional data they require to proceed with the decisioning process.

This is illustrated in the following diagram:

This pattern is similar to the first one. The main difference is that the decision service, in this example, retrieves the risk of the zone driven for this specific driver by reading an additional document in MarkLogic database.

We commonly see this pattern applied in complex business processes that contain conditional flows requiring specific data sets.

Conclusion

In MarkLogic, the rules execute “in-process.” This brings many benefits, including:

• The decisioning is fast and scales well, enabling real-time decision processes.
  

• The total cost of ownership is minimized as you do not need to provision, scale and deploy separate servers to execute the decision services.
  

• The security posture is easier to understand and manage (no need to open additional ports, run separate servers or leverage different stacks).

Progress Corticon provides a rich environment to model complex decisions and access only the data required based on business rules enabling more efficient and scalable services.

We see two typical design patterns used by many of our customers who leverage business rules-driven decision services. To explore these patterns in more detail, reference this GitHub example.

What’s more, you can enroll in free training for Corticon.js.

LEARN MORE ABOUT CORTICON