Rule Actions

Essential knowledge

Author:

Fluent Commerce staff

Changed on:

30 June 2024

Overview

Rule Actions are the single output of a Rule.

Rules do not perform actions directly. Rather, they inform the Workflow Engine what it should do as a result of the rule execution. The Workflow Engine interprets the specific Action produced by the Rule and handles it appropriately.

Most Actions are queued internally within the Workflow Engine and executed at the end of the current process.

Key points

There are 4 types of Actions available to produce from a Rule:
- ```
`SendEventAction`
```
- ```
`MutateAction`
```
- ```
`WebhookAction`
```
- ```
`LogAction`
```

SendEventAction

The

`SendEventAction`

provides the mechanism for sending new events.

A common use case for this is to control flow, and trigger a new Ruleset for execution after completing the current one. These types of events are typically queued and executed within the same execution thread, as long as they are for the same context.

Another common scenario for this action is to trigger a Ruleset in a different Workflow. These events cannot be executed on the same execution thread, and should be sent out of Rubix, to be processed on a separate execution context.

Using the

`SendEventAction`

There are various purposes for sending an Event:

Flow control - move the current workflow execution onto the next ruleset.
Notify another workflow - trigger a ruleset within a different related workflow.
Notify another retailer - trigger a ruleset within a different retailer's workflow.
Future-dated - schedule an event execution for a later date.

Max Payload Size

It’s essential to ensure the total payload size is less than 25kb, including any attached attributes.

As a general rule, events should contain the minimal viable information to run the next section of the workflow. Anything beyond that can either be recorded in a

`LogAction`

or stored as an attribute of the entity.

Flow Control

In order to move your process to the next Ruleset, you will need a rule to send an event for the same context as the current event, and name the Ruleset to be triggered.

The best way to do this is to build the Event off the current execution event:

1public class MyCustomRule {
2
3    //...
4
5    public void run(C context) {
6
7        //...
8
9        Event currentEvent = context.getEvent();
10        Event flowControlEvent = currentEvent.toBuilder().name("MyNextRuleset").build();
11        context.action().sendEvent(flowControlEvent);
12    }
13}

Language: java

Name: Example

Description:

[Warning: empty required content area]

Notify Another Workflow

When required to send an event to a different workflow, it is recommended to build the new Event from scratch, but including the relevant details from the current Event.

Important Note

You will also need to add a

`scheduledOn(new Date())`

to ensure that the event will be processed successfully.

In the following example, let's assume that the current Event if for an Order, and it needs to notify the Inventory Catalogue:

1public class MyCustomRule {
2
3    //...
4
5    public void run(C context) {
6
7        //...
8
9        Event newWorkflowEvent = Event.builder()
10                .rootEntityRef("IC_123")
11                .rootEntityType("INVENTORY_CATALOGUE")
12                .entityRef("IP_321")
13                .entityType("INVENTORY_POSITION")
14                .entitySubtype("DEFAULT")
15                .scheduledOn(new Date())
16                .retailerId(context.getEvent().getRetailerId())
17                .source(context.getEvent().getId().toString())
18                .name("RulesetName")
19                .attributes(myEventAttributes)
20                .build();
21
22        context.action().sendEvent(newWorkflowEvent);
23    }
24}

Language: java

Name: Example

Description:

[Warning: empty required content area]

Notify Another Retailer

When sending an event to another retailer, you need to ensure you set the new Event Retailer Id to a value different to the current Event, as well as any other differences in context:

1public class MyCustomRule {
2
3    //...
4
5    public void run(C context) {
6
7        //...
8
9        Event currentEvent = context.getEvent();
10
11        Event newRetailerEvent = currentEvent.builder()
12                .retailerId(context.getEvent().getRetailerId())
13                .source(context.getEvent().getId().toString())
14                .name("RulesetName")
15                .attributes(myEventAttributes)
16                .build();
17
18        context.action().sendEvent(newWorkflowEvent);
19    }
20}

Language: java

Name: Example

Description:

[Warning: empty required content area]

Schedule an Event for Later

Should you require some behaviour to trigger at a later time, you can schedule an event like this:

1public class MyCustomRule {
2
3    //...
4
5    public void run(C context) {
6
7        //...
8
9        Event currentEvent = context.getEvent();
10
11        Date anHourFromNow = DateUtils.addHours(new Date(), 1);
12
13        Event newRetailerEvent = currentEvent.builder()
14                .name("RulesetName")
15                .scheduledOn(anHourFromNow)
16                .source(context.getEvent().getId().toString())
17                .build();
18
19        context.action().sendEvent(newWorkflowEvent);
20    }
21}

Language: java

Name: Example

Description:

[Warning: empty required content area]

MutateAction

The

`MutateAction`

provides the mechanism for calling GraphQL Mutations as per the Fluent GraphQL Schema. Mutations provide a way to create or update data within the platform.

Important Note

`MutateAction`

behaves slightly differently from other Actions in that they are executed directly after the current Rule.

Using the

`MutateAction`

When you want to create or update an entity within the Fluent Platform, you will need to use a

`MutateAction`

from a Rule to execute against the GraphQL API.

First, you will need to construct a Mutation object. You should add your mutation query GraphQL file to the

`graphql`

folder in your plugin project, and perform a Maven build to generate the relevant mutation object.

Once you have the Mutation object generated for use within your Rule, you simply need to build it with the relevant data, and pass it as a parameter to the Mutation Action:

1public class MyCustomRule {
2
3    //...
4
5    public void run(C context) {
6
7        //...
8
9        UpdateOrderInput updateOrderInput = UpdateOrderInput.builder()
10                .id(context.getEntity().getId())
11                .attributes(attributeInputList)
12                .build();
13
14        UpdateOrderAttributesMutation updateOrderAttributesMutation = UpdateOrderAttributesMutation.builder()
15                .input(updateOrderInput)
16                .build();
17
18        context.action().mutation(updateOrderAttributesMutation);
19    }
20}

Language: java

Name: Example

Description:

[Warning: empty required content area]

WebhookAction

The

`WebhookAction`

provides an integration ability, whereby data can be sent to an external endpoint.

Read more on Webhooks, and how to build the Webhook receiver in the Integration section.

Important Note

By default, when a Webhook in a custom Rule fails it reverts back to the default Webhook action logic. To prevent this and use the logic set up in the custom Rule, you need to add a setting to the Workflow that contains your Rule. Read more here.

Using the

`WebhookAction`

The example below demonstrates sending the current event to an endpoint:

1public class MyCustomRule {
2
3    //...
4
5    public void run(C context) {
6
7        //...
8
9        context.action().postWebhook(url, context.getEvent());
10    }
11}

Language: java

Name: Example

Description:

[Warning: empty required content area]

LogAction

The

`LogAction`

provides the ability to add a custom Orchestration Audit Event.

The additional orchestration audit event will be associated to the same context as the parent event, making it a useful approach to adding additional information about the current execution.

Note

Please note that only a single LogAction per rule is actioned. This is to minimise abuse of this feature which may result in performance issues.

Using the

`LogAction`

To log additional information to the Audit log for the current Event context, simply use the Log Action as follows:

1public class MyCustomRule {
2
3    //...
4
5    public void run(C context) {
6
7        //...
8
9        context.action().log(message, detailedMessage, attributes);
10    }
11}

Language: java

Name: Example

Description:

[Warning: empty required content area]

Rule Actions

Overview

Key points

SendEventAction

Using the
`SendEventAction`

Flow Control

Notify Another Workflow

Notify Another Retailer

Schedule an Event for Later

MutateAction

Using the
`MutateAction`

WebhookAction

Using the
`WebhookAction`

LogAction

Using the
`LogAction`

Fluent Commerce staff

Building Blocks

By Type

Legal Resources