Fluent Commerce Logo
Docs
Sign In
Essential knowledge

Author:

Fluent Commerce

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.
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.

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.

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.

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.

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]
Fluent Commerce

Fluent Commerce

Copyright © 2024 Fluent Retail Pty Ltd (trading as Fluent Commerce). All rights reserved. No materials on this docs.fluentcommerce.com site may be used in any way and/or for any purpose without prior written authorisation from Fluent Commerce. Current customers and partners shall use these materials strictly in accordance with the terms and conditions of their written agreements with Fluent Commerce or its affiliates.

Fluent Logo