Skip to main content

Trigger chained rule runs

Chaining business rules can be useful in the following scenarios:

  • If a business rule that is run against one object needs to trigger processing related to another object.

  • If a business rule that is run against a new object needs access to its own database ID, which doesn’t yet exist when the rule is run.

Chaining rules to other objects

Chaining rules can be useful, for example, if you need to update portfolios based on the changes in the linked contact information. One particular case is changing the company's portfolio status as soon as the company's LEI code is updated in the contact information. This can be done with a scheduled process that regularly checks contacts’ LEI codes, but this approach would require frequent polling or suffer from delays.

Instead, you can record a business rule that reacts to an update in the contact LEI code by triggering business rules against all its underlying portfolios. The underlying portfolios could then have a business rule that checks their primary contact’s LEI code, and updates the portfolio’s status accordingly. With the rule chaining, the portfolios’ statuses get updated immediately after the contact’s LEI code is entered.

Chaining rules to the same object

Chaining rules to the same object can be useful if you need to trigger a rule whenever new data is added to FA system. Sometimes such business rules need access to the new object's database ID.

One example is OCR numbers – unique payment reference numbers that use portfolio database ID. Generating an OCR number for each newly created portfolio can be difficult because business rules typically run before data is saved to the database, meaning the database ID is not available for newly created objects.

With the rule chaining, you can address this issue by chaining a rule to run on the same object after it has been saved. This allows you to generate OCR numbers based on the database ID immediately after the portfolio is created.

How rule chaining works

The decision table below contains a simple example of how rule chaining works. It is triggered against any transaction or trade order with the “ChainToSelf” or “ChainToParentPortfolio” tag, and triggers a rule run against itself or its parent portfolio, respectively.

custom_tradeOrder_transaction_chained.xlsx

The decision table also contains two simple rules that write a row to the FA system logs whenever rules are run against a transaction, trade order or portfolio. The purpose of these additional rules is to confirm that the follow-up rules were run.

Below are the key points to understand when implementing rule chaining:

  • Import the fi.fasolutions.mod.portfoliomanagement.util.RuleUtils class. This is the class you will use to trigger the additional rule runs.

    • Use RuleUtils.addFollowUpRuleTrigger(messages, $1) to trigger rule runs against any object type that supports rule chaining. Rule chaining supports contacts, portfolios, securities, transactions, and trade orders. $1 should reference an object of one of those types.

    • Use RuleUtils.addRerunRequest(messages) to trigger a rule run against the object itself.

  • Chained rule runs happen after the original object has been saved.

  • Chained rule runs also save the objects that the rules were run against.

  • Chained rule runs have a built-in safeguard against loops: chained rule runs cannot trigger rules against the same object multiple times. Multiple separate objects can be chained, however.

In this section: