Introduction to Fluent Rules

Basic steps to create a Rule Class

• Write a Java class that implements the com.fluentretail.rubix.v2.rule.Rule Interface.
•  Implement the 'run' method which receives the current event context as a parameter.
• Define the Rule metadata via the @RuleInfo annotation .
• Define additional Rule metadata via the @EventAttributes and @Param* annotations.

Rule Interface and Actions for Rules

Rule Interface

• Orchestrateable Entity e.g. context.getEntity()
• API Client  e.g. context.api()
• Source Event e.g. context.getEvent()
• Rule Parameters e.g. context.getProp()

Available Actions for Rules

• SendEventAction: SendEventAction produces an event, however that event could be for flow control, notification of other workflows, or future-dated events.
• WebhookAction: provides an integration ability, whereby data can be sent to an external endpoint.
• MutateAction: provides an action that mutates data (create or update an entity) within the Fluent Platform 
• LogAction: provides the ability to add a custom Orchestration Audit Event

Examples of Rule Actions

Flow control

Notify another workflow

Notify another retailer

Future-dated/Scheduled

Mutate action

Webhook action

Log action

Rule Annotations

RuleInfo Annotation 

• To validate the Rule for Workflow Execution.
• To provide data to display in the Workflow Builder and Rule Library.

• name - this is the Rule name. 
• description - this is a parameterised string used to describe the behaviour of the Rule, as well as indicate what and how the Rule Parameters are used.
• accepts - this is a list of EventInfo Annotations to describe the acceptable entity types
• produces - this uses an EventInfo Annotation to describe the Event that the rule outputs
• exceptions - this is a list of RuleExecutionException classes that this rule might throw( Exception Management)

EventInfo Annotation

• eventName - the Name of the Event produced by this Rule.
• entityType - the Entity Type of the Events accepted by this Rule, or the Entity Type of the Event produced by this Rule.
• entitySubType - the Sub Type of the Entity of the Event produced by this Rule.
• status - the Status of the Entity of the Event produced by this Rule.

Event Attributes and Rule Parameters

• name - the Name of the Event Attribute.
• type - the Type of the Event Attribute.

• name - The name of the Parameter. It is a required field
• description - The description of the Parameters. It is a required field
• defaultValue - This is the default value of the Parameter. It is an optional field

• Name - The name of the rule how it appears in the editor. *A combination of the accountId, plugin namespace and rule name will fully qualify a rule in the workflow. For example:  TESTACCOUNT.base.ForwardIfOrderAttributeExists
• Description - The description is how the Rule appears in the editor. Placeholders (like *"{" + PROP_EVENT_NAME + "}") represent parameters and are substituted with form fields in the editor. Every defined parameter must appear in the description and every placeholder in the description must have a corresponding @Param defined.
• Accepts - For this example we're restricting the Rule to apply only to Order actions. Accepts is an array, so we could add additional Entity types by adding more. If we are not using accepts  then  it means the rule will work on any orchestrateable entity. @EventInfo annotations. Accepts is used to validate workflows when they are updated and also to filter the Rule list in the editor. 
• Produces - The rule produces an event which is defined in the produces section. Since the event name is defined via a parameter the eventName is defined as "{" + PROP_EVENT_NAME + "}". The entity type/subtype/status defaults to the same value as the current event.
• Event attributes - The list of attributes which this rule expects to be present in the incoming event attributes. The event attribute annotations of all rules within a ruleset define the interface contract of the ruleset.
• ParamString - This annotation is used for Rule parameters. For example if the Rule takes 2 string parameters, one for attribute name and other for the outgoing event name. Parameterising allows the Rule to be re-usable in different ways.
• Slf4j - The @Slf4j annotation enables the logging which is currently visible only to Fluent SRE team, but in the future will be available to partners as well

Run Method

• Validation stage
• Retrieve data/query stage 
• Write conditional logic stage
• Build action data stage 
• Produce action stage