Rules SDK Usage Guide

Prerequisites

• Install JDK 8.  Currently, Rules SDK (Fluent SDK) supports Java 8. You can download Java 8 from the Oracle link —> JDK 8 Installation.  Once installed, verify that JDK 8 is active on your system path.
• Install Maven 3.6. We recommend to use Maven 3.6 which can be downloaded from Apache Maven —> Download Apache Maven. Once installed, verify that Maven is active on your system path.

• Install IntelliJ IDE. Use IntelliJ IDE (either CE or Ultimate edition).

• Install GraphQL Plugin. Install the GraphQL plugin for IntelliJ by using: IntelliJ > Preference > Plugins > search for GraphQL, and install it.
• Install Postman. You can install Postman from this link -> Download Postman.

Rules SDK Setup & Plugin Creation

Introduction to Rules SDK

What is the Rules SDK?

• • Build plugins containing custom-developed Rules for deployment into OMX Platform.
• • Easily install plugins on the OMX Platform for use in the client workflows.
• • Remain unique and competitive within their own market space.
• • Have control over the optimisation and processing of their omni-channel orchestrations.

Key Features of Rules SDK

• Ready to use Java Maven Archetype for creating a new Fluent Plugin Project.
• Easy to use Install Scripts for Windows, Linux, and Mac OS.
• Java API Clients for both Fluent REST and GraphQL API.
• Ready to execute Postman, Insomnia, and GraphiQL Scripts for both Fluent REST and GraphQL API.
• Sample Rules which are ready to deploy and run in a Workflow.

Rules SDK Installation Guide

• IntelliJ (Java IDE) has a JDK path set to 1.8 and Maven 3.6 is configured within IntelliJ.
• If you are using Maven version > 3.6, add a mirror (a dependency provided in the Prerequisites  Section) in your Maven directory .m2 >repository > settings.xml

Step 1. Download and install Rules SDK

• Name and version of Rules SDK being downloaded. This folder contains lib folder, installation scripts and Readme file
• Installation Script based on your operating system
  • For Mac/unix: Install.sh
  • For Windows: Install.bat
• Readme File is the text file which provides the Installation and configuration steps
• Archetype jar file containing all the Archetype required for setting up a new project
• Foundation sources jar file containing all source code of all the rules that are being provided in an account. All the rules provided are part of Foundation Plugin

Step 2. Run the Installation Command

• Open up a Terminal / Command prompt and navigate to your extracted SDK folder.
• The installation script for your environment is in the SDK Folder.  Refer to the table below — run the installation script for your specific environment (Mac/Linux or Windows):

Step 3. Configure your Plugin Project

• 'groupId'. This is your Maven group id. Typically made up of a reverse of your primary root domain e.g. com.acme
• 'artifactId'. This is a descriptive unique Maven Java module name in kebab case format (I.e. hyphens between each word in lower case). Follow the naming convention `rubix-plugin-<fluentaccountId>-<pluginshortname>`.  For training purposes, you may use your name as the <pluginShortName>. For e.g. rubix-plugin-training-manav   

• 'fluentAccountId'.  This is your Fluent Account ID. You can get the value from Postman.
• 'fluentApiHost': https://<fluentAccountId>.sandbox.api.fluentretail.com. This value is pre-populated with your sandbox url. Press Enter to accept the value
• 'fluentApiPassword'.  This is your Fluent Account password. You can get the value from Postman.
• 'fluentApiPort' = 443'.  This value is pre-populated for SSL. Press Enter to accept the value
• 'fluentApiUserName'.  This is your Fluent Account  Name. You can get the value from Postman.
• 'fluentApiClientSecret'.  This is your Fluent Account Secret Key. You can get the value from Postman.
• 'fluentPluginName'.  Use the same name you have used in your artifactid eg. manav
• 'fluentVendorName'.  This is your company name. e.g. Training  Ltd (opens in a new tab)
• Confirm your parameters by entering the letter Y.   If you need to change any of the values , then enter the letter N followed by Enter key, and repeat the above steps.  

View an example of a successful build

• This is the same extracted Rules SDK folder(discussed above ),from where you have run the installation script for your system.
• This is the installed and configured plugin rubix-plugim-fctrainau543- manav which is created as a result of successful build.

Plugin Structure & JS GraphQL

GraphQL within Plugin Project

Plugin Project Folder Structure

• insomnia - This folder contains all the required API Requests and workflows to set up a new retailer with sample data and workflows for each of the Fluent Apps.
• postman - The postman folder contains the current API Collection for setting up a retailer, and installing and running the sample plugin rules.
• src - This folder will contain all the java source code. You will write your custom Rules in this folder.
• graphql  - This folder will contain all the queries and mutation . Java class are  auto generated for each query and mutation.
• java - You will write the JUnit / unit test cases/classes in this folder.
• pom.xml - It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects.

GraphQL within IntelliJ

• graphql - This folder contains all the GraphQL queries and mutations. 
• GetOrderById.graphql - This is an example GraphQL query which we will be using in our demonstrations later in the course.
• schema.json - This is the JSON version of Fluent's schema.
• apollo-client:generate - This plugin generates a Java class/code for the GraphQL queries/mutations written in the GraphQL folder.

Step 1. Create a  GraphQLConfig file

Step 2. Replace the code in the graphqlconfig file with the code below

1{
2"projects": {
3"<YOUR_PROJECT_NAME>": {
4"schemaPath": "src/main/graphql/<YOUR_PROJECT_GROUP_PATH>/schema.json",
5"extensions": {
6"endpoints": {
7"sandbox": {
8"url": "https://<YOUR_FLUENT_ACCOUNT_ID>.sandbox.api.fluentretail.com/graphql",
9"headers": {
10"Authorization": "Bearer ${env:AUTH_TOKEN_ENV}"
11}
12}
13}
14}
15}
16}
17}

Step 3. Fill the placeholders with your Fluent Account values in your graphqlconfig  file 

• grahqlConfig - This is the generated graphqlConfig file 
• <YOUR_PROJECT_NAME>- This is your project name. Add a short unique Project name, mostly your accountID for eg "FCTRAINAU543"
• <YOUR_PROJECT_GROUP_PATH> - This is the path of the  schema.json file in your project. In our plugin project, schema.json is under com. training folder so  this  <YOUR_PROJECT_GROUP_PATH> value is replaced with "com. training" so it will be  "src/main/graphql/com.training/schema.json"
• url - You should replace < Your_Fluent_Account_ID>  with your accountID . For eg "https://FCTRAINAU543.sandbox.api.fluentretail.com/graphql"
• Authoriszation - This is an environment variable. It is an authorisation token generated after an account is authorised in Postman. This value is filled at the run time.

Modify and run a GraphQL query

Step 1. Modify Query

• In your plugin project's src/main/graphql/com.training/queries folder, open the "GetOrderById.graphql" file.  Add the total price field to the query as per the query given below.  

1query GetOrderById($id: ID!) {
2    orderById(id: $id) {
3        id
4        ref
5        type
6        status
7        totalPrice
8        attributes {
9          name
10          type
11          value
12        }
13    }
14}

Step 2. Run the Query

• Fill the AUTH_TOKEN_ENV environment variable: AUTH_TOKEN_ENV is the environment variable that gets the value of access_token, which you get after authentication of the retailer from POSTMAN collection.
• Enter any valid order ID (Note: the query needs this ID as a variable) and run the query. 

Step 3. Generate the Java class using the Apollo GraphQL plugin for IntelliJ 

Introduction to Fluent Rules

Prerequisite Knowledge

• OMX Workflow -  Understand the Workflow Engine (previously 'Rubix Orchestration Engine'), Workflow Design Patterns, Workflow Builder
• Workflow Framework - Understand the Workflow Framework, Events, and Triggers.

Rule Interface and Actions

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

Case scenario - Implement Fraud Check

Client Scenario

• Our Client has experienced a high number of fraud cases in the past 6 months. 
• In order to resolve the problem, our client has decided to implement fraud protection into their Order Fulfilment Workflow. 
• Instead of manually verifying incoming orders, the client now wishes to implement an automated mechanism to check.

🔎 Requirements Analysis 

⚙️ Solution Design

• Define a parameter for the Order Total Price Threshold: HighValueThreshold
• Add a Boolean Attribute to the Order named IS_HIGH_VALUE, and set it to TRUE if the Order's Total Price is above the value defined in the HighValueThreshold parameter.
• If the Order Total Price is less than (or equal to) the HighValueThreshold, then the rule will not do anything.

Designing your Rule

• 1 Be simplified
• 2 Be generic
• 3 Be flexible
• 4 Be re-usable
• 5 Be part of multiple compositions.

Writing the Rule

Create a Rule Class

 Step 1. Create a Rule Class

• Using any Java IDE (we are using IntelliJ) open the Plugin Project created in the previous section.
• Create a new class named MarkOrderHighValueRule — Right-click on the src/main/java/com.training/rule folder of your plugin project to create a new java class. Name the class as MarkOrderHighValueRule 
• Implement the v2 Rule Interface — Make your class 'MarkOrderHighValueRule', and  implement Rule Interface com.fluentretail.rubix.v2.rule.Rule
• Override the run method and use the context in the run method.  Please note, the v2 Rule interface is the one that supports GraphQL.

Step 2. Create a HighValueThreshold Constant (solution design specification)

Step 3. Add @RuleInfo and @ParamString annotations

• RuleInfo: Name will include the name of the Rule class (which will be the class you have created) 
• description in @RuleInfo: It is a brief description that what is rule doing and what parameters it is using
• accepts: In the case scenario , the Rule accepts only ORDER entity
• @ParamInteger: Shows the name, description and default value of parameter.

1package com.training.rule;
2
3import com.fluentretail.rubix.event.Event;
4import com.fluentretail.rubix.foundation.graphql.type.UpdateOrderInput;
5import com.fluentretail.rubix.rule.meta.EventInfo;
6import com.fluentretail.rubix.rule.meta.ParamInteger;
7import com.fluentretail.rubix.rule.meta.RuleInfo;
8import com.fluentretail.rubix.v2.context.Context;
9import com.fluentretail.rubix.v2.rule.Rule;
10import com.training.util.Constants;
11
12@RuleInfo(name = "MarkOrderHighValueRule"
13        , description = "Mark the Order as HIGH_VALUE when the Order " +
14        "Total Price is greater than {" + Constants.PARAM_NAME_HIGH_VALUE_THRESHOLD + "}"
15        , accepts = {
16        @EventInfo(entityType = "ORDER")
17                    }
18        )
19@ParamInteger(name = Constants.PARAM_NAME_HIGH_VALUE_THRESHOLD, description = "The value " +
20        "threshold of which Orders should be marked as High Value", defaultValue = 1000)
21
22
23public class MarkOrderHighValueRule implements Rule
24{
25    @Override
26    public <C extends Context> void run(C context)
27    {
28
29    }
30}

Configure the run method

Run method — Validation

• Use a return statement to exit immediately but continue processing the Ruleset, or
• Throw an Exception, and stop processing the Ruleset.

Steps to validate your Rule

• context.getProp (Constants. CONSTANT NAME, TYPE.class) is used to get the local constant — save the retrieved constant in a variable.
• Validate the value retrieved and throw the exception if 'not valid' or 'null'.

Run method — Retrieve data/query

Steps to execute your Rule

• Use  context.getEvent().getEntityId() to retrieve the Order ID from the context
• In the pervious section "PLUGIN STRUCTURE & JS GRAPHQL" you have run a query "GetOrderByIdQuery " and have created a query Object . Now use  GetOrderByIdQuery.builder().id(orderId).build( )  method to create an instance of the created "GetOrderByIdQuery "GraphQl Query Object.
• Execute the GraphQL Query using the GraphQL API Client provided by the context by using  context.api().query() 
• Create a method that validates the retrieved data by asserting it with expected data. The code snippet for this method is provided below.
• Call the above method in the run method to validate the retrieved data.

1 /*
2     * Query Result Validation Code extracted into Private method, but should be a Util method.    
3     */
4    private void validateQueryResult(GetOrderByIdQuery.Data data, String orderId, Context context) {
5
6        if (data.orderById() == null) {
7            throw new RuleExecutionException(String.format("Unable to process Rule: %s - No Order Found for Id: %s, Order Ref: %s",this.getName(),orderId, context.getEntity().getRef()), context.getEvent());
8        }
9
10        if (data.orderById().totalPrice() == null) {
11            throw new RuleExecutionException(String.format("Unable to process Rule: %s - No TotalPrice Found for Order Id: %s, Order Ref: %s",this.getName(),orderId, context.getEntity().getRef()), context.getEvent());
12        }  
13    }

Run method — Write conditional logic

1// Simple Logic:
2if (data.orderById().totalPrice() <= threshold) {
3return;
4}

Run method — Build action data

• Mutation (update or save some new or changed data) 
• SendEvent (send an event to trigger workflow)
• SendWebhook (send an event to an external system)

Steps to build an action

• Define your GraphQL Mutation query in the src/main/graphql/mutations folder.
• Run a maven build to generate the Mutation Java Object.

1mutation updateOrderAttributes($input: UpdateOrderInput) {
2 updateOrder(input: $input) {
3     ref
4 }
5}

•  Add a constant to hold the Attribute key in the Constants class. i.e create a new boolean AttributeInput named IS_HIGH_VALUE with a value of TRUE.
• Write a method that creates and returns a List <AttributeInput>. This attribute list is passed to the instance of UpdateOrderInput.  

1/*
2     * Extracted to private method, but should be a Util method.
3     */
4    private List<AttributeInput> createNewAttributeInputAsList(String attrName, Class type, Object attrValue) {
5
6        AttributeInput attrInput = AttributeInput.builder().name(attrName).type(type.getSimpleName().toUpperCase()).value(attrValue).build();
7        List<AttributeInput> attributeInputList = new ArrayList<>();
8        attributeInputList.add(attrInput);
9        return attributeInputList;
10    }

• Build the mutation query Object in preparation for producing a Mutation Action as below:

1// Prepare for Action:
2        List<AttributeInput> attributeInputList = createNewAttributeInputAsList(IS_HIGH_VALUE_ORDER_ATTRIBUTE_NAME, Attribute.Type.BOOLEAN.getValueClass(), Boolean.TRUE);
3
4        UpdateOrderInput updateOrderInput =  UpdateOrderInput.builder()
5                                                                .id(orderId)
6                                                                .attributes(attributeInputList)
7                                                                .build();
8        UpdateOrderAttributesMutation updateOrderAttributesMutation = UpdateOrderAttributesMutation.builder().input(updateOrderInput).build();

Run method — Produce action

Exception Management, Debugging and Logging Events

Fluent's Platform Exception Handling

• Special handling for exceptions of type RuleExecutionException
• Default handling for all other Exceptions

The RuleExecutionException Class

• Rubix engine will stop the execution of the current Ruleset, but continue processing previously queued inline events
• Rubix will not process any queued actions
• Rubix will log the exception in an orchestration audit Event, without a stack trace
• Rubix will mark the Event as a success
• Rubix will return a successful response to the UI if the execution was triggered by a User Action
• Rubix will create and attempt to execute a Ruleset Exception Event
  • The name of this new Ruleset Exception Event is the same as the Ruleset that threw the exception and the eventType is set to EXCEPTION
  • The RuleExecutionEvent message and the cause throwable (if it exists), will be available as part of the Exception Event for use within your rules

Default handling for other Exceptions

• Rubix will stop the current execution
• Rubix will not process any queued actions
• Rubix will log the exception in an orchestration audit Event, including a stack trace
• Rubix will mark the Event as failed
• Rubix will return an error response to the UI if the execution was triggered by a User Action
• Rubix will not create and attempt to execute a Ruleset Exception Event

Types of Debugging

IDE Debugging

Sandbox Debugging

• Avoid Trial & Error debugging and testing
• Always try to reproduce the issue locally, either with Unit Tests or with the TestExecutor
• Use the Events (Activities) to see what happened during the execution
• Ensure your Rules are as atomic (small single-purpose) as possible - the more granular your rules, the more useful information will be provided by the Audit Events, making problem identification much simpler.

Logging & Audit Events

• Snapshot - A snapshot of the Entity at the time the Orchestration Event is received into the workflow.
• Ruleset - An audit of the ruleset executed as a result of an Orchestration Event
• Rule - An audit of a Rule executed within a ruleset as a result of an Orchestration Event
• Action - An audit of an Action executed as a result of an output of a Rule
• Exception - An audit of an Exception that has occurred during the execution of an Orchestration Event
• Custom Logs (LogAction) - The context.action().log() can be used to log custom Orchestration Audit Events.

Custom Log Examples

• Custom Log - Create a class for logger. A maximum of 1 log is allowed per rule for performance reasons. This provides accessible information for debugging purposes.
• LogLevels constants - Create an enum representing different Log Levels.
• Create a list for collecting logs - You can collect logs throughout the execution of your class, and write them as attributes to the log.

• Logs are internal only - System logs ( log.debug) are internal to our SRE teams. Heavy logs in rule code can impact our support and maintenance procedures, as well as performance.

Test your rule

Unit Testing

• Create a fully Mocked Unit Test (using IDE's Unit Testing capabilities) for your custom Rule. In the Mocked unit test perform one (1) assertion per test case and test both positive and negative paths.
• Test your Rule in the TestExecutor.  The TestExecuter can be viewed as a mini Workflow Engine simulator that runs on your local machine to assert additional behavior.
• Deploy your plugin to your Sandbox account.

Mocked Unit Testing

Create a Mocked Unit Test class for your custom Rule

• Open your plugin project in which you have written the MarkOrderHighValueRule class.
• In the src/test/java/com.training/rule folder of your plugin project, create a new class named MarkOrderHighValueRuleTest.
• Write a setup method to initiate the mocks. This setup method will run before every test in the class. The setup method uses MockitoAnnotations class to initiate Mocks(initMocks). Mockito is the Fluent mocking framework.
• Define a mock on Context, which is a required parameter of the run method in the Rule class.

• Make sure you import the v2 version of Context i.e use this package com.fluentretail.rubix.v2.context.Context
• The org.mockito package can mock all classes except final classes. 

1
2    package com.training.rule;
3
4    public class MarkOrderHighValueRuleTest 
5    {
6
7        private MarkOrderHighValueRule rule = new MarkOrderHighValueRule();
8
9        @Mock
10
11        private Context context;
12
13        @Before
14
15        public void setup() 
16        {
17
18            MockitoAnnotations.initMocks(this);
19
20        }
21
22    }

Use Mockito to write test cases

1/**
2 * NOTE: This is a snippet from `MarkOrderHighValueRule class from 'Writing the Rules' section
3 **/
4
5// Validation:
6Integer threshold = context.getProp(Constants.PARAM_NAME_HIGH_VALUE_THRESHOLD, Integer.class);
7if (null == threshold) 
8{
9    throw new PropertyNotFoundException(400,String.format("Required Parameter not provided: %s", Constants.PARAM_NAME_HIGH_VALUE_THRESHOLD));
10}

• Create a test method named run_withMissingThresholdParam_ThrowsPropertyNotFoundException ( ).
• The run method throws a PropertyNotFoundException, so we don't need any assertion in the Test case.  The Test expected behaviour will manage the exception with the following line of code: @Test(expected = PropertyNotFoundException.class)
• Use a negative path test: In the arrange section of the Test,  get the property. If the property returned is null, then it throws an exception.  
• Run the test case: On IntelliJ use control+shift+R key code. Or, right-click inside the method, and select run_withMissingThresholdParam_ThrowsPropertyNotFoundException method. 

1<dependency>
2        <groupId>org.powermock</groupId>
3        <artifactId>powermock-module-junit4</artifactId>
4        <version>1.6.6</version>
5        <scope>test</scope>
6    </dependency>
7    <dependency>
8        <groupId>org.powermock</groupId>
9        <artifactId>powermock-api-mockito</artifactId>
10        <version>1.6.6</version>
11        <scope>test</scope>
12    </dependency>

Include PowerMock and prepare to write the test case

• Open the pom.xml file in your project. 
• Copy the dependencies ( provided below) under the existing Mockito dependency
•  Check the scope is set to test
•  Clean the Maven project.

• As we are using PowerMock, we need to define a different test runner for PowerMock. Refer to the table below to define and prepare the test runner class for PowerMock

• Define the following Mocks in your testing class 

1// Required Mocks
2@Mock
3private Event event;
4@Mock
5private ReadOnlyFluentApiClient apiClient;
6@Mock
7private GetOrderByIdQuery.Data data;
8@Mock
9private GetOrderByIdQuery.OrderById orderById;
10@Mock
11private ActionFactory actionFactory;

• Define/Write the default behaviour of above defined Mocks in the setup ( ) method.

• PARAM_NAME_HIGH_VALUE_THRESHOLD value - returns the default value of $1000  
• (context.getEvent()) - it will return the mocked event value
• event.getEntityId()) - will return the default String value of  "123"
• Other context values - context.api() , apiClient.query(any(), data.orderById() will return respective mocked values

Create a test case using PowerMock

• Create a test method named as     run_withValueGreaterThanThreshold_queuesUpdateOrderAttributesMutation()
• The "arrange, act and assert" approach of the test method is explained in the given below interaction (See diagram below).
• Run the test case: On IntelliJ use  control+shift+R key code. Or, right-click inside the method, and select run run_withValueGreaterThanThreshold_queuesUpdateOrderAttributesMutation() method. 

• Arrange - if the order's totalprice value is greater than the default value set in the setup() method then it will return value greater than default value for totalPrice. It also returns mocked actionFactory.

• Act - it will make the rule run on the mocked context.
• Assert - It will verify that the mutation is called only one time and is of any UpdateOrder type.

Write another test case using PowerMock

• Prepare PowerMockRunner by updating @PrepareForTest annotation to include AttributeInput.class . Your annotation should look like:

• Define a Mock of AttributeInput.Builder by using the below code. This will allow us to verify that the Attribute Name is set correctly.

• Create a test method named  run_withValueGreaterThanThreshold_addsAttributeWithNameIsHighValue() which throws Exception
• Use the given below code for this test case.
• Run the test case.

1@Test
2    public void run_withValueGreaterThanThreshold_addsAttributeWithNameIsHighValue() throws Exception {
3
4        //arrange:
5        when(orderById.totalPrice()).thenReturn(1001.00);
6        when(context.action()).thenReturn(actionFactory);
7
8        AttributeInput attributeInput = AttributeInput.builder().name("test-name").type("test-type").value("test-value").build();
9        PowerMockito.whenNew(AttributeInput.Builder.class).withNoArguments().thenReturn(mockedAttributeInputBuilder);
10        when(mockedAttributeInputBuilder.name(anyString())).thenReturn(mockedAttributeInputBuilder);
11        when(mockedAttributeInputBuilder.type(anyString())).thenReturn(mockedAttributeInputBuilder);
12        when(mockedAttributeInputBuilder.value(any())).thenReturn(mockedAttributeInputBuilder);
13        when(mockedAttributeInputBuilder.build()).thenReturn(attributeInput);
14
15        //act:
16        rule.run(context);
17
18        //assert:
19        verify(mockedAttributeInputBuilder, times(1)).name(Constants.IS_HIGH_VALUE_ORDER_ATTRIBUTE_NAME);
20    }

Practice Exercises

• run_withValueGreaterThanThreshold_addsAttributeWithTypeBoolean
• run_withValueGreaterThanThreshold_addsAttributeWithValueTrue
• run_withValueLessThanThreshold_doesNotQueueAnyMutation
• run_withValueLessThanThreshold_doesNotBuildAnyAttribute
• run_withValueEqualThanThreshold_doesNotQueueAnyMutation
• run_withValueEqualThanThreshold_doesNotBuildAnyAttribute

Testing on the TestExecutor

• rule(Class.class): load a rule
• ruleset(RuleSet ruleSet): adds a ruleset to the workflow
• entity(Entity entity): adds an entity to the workflow
• validateWorkflow(Event event): validates the workflow with the given event
• execute(Event event): executes the workflow with the given event

• count*(): Provides access to the number of events or actions that have been executed in the context.
• get*(): Provides access to the entities, rules, events, and properties.

• run_withTotalPriceGreaterThanThreshold_callsMutateAction
• run_withTotalPriceLessThanThreshold_doesNotCallMutateAction
• run_withTotalPriceGreaterThanThreshold_doesNotCallMutateAction

Step 1 - Create a test class

1public class MarkOrderHighValueRuleExecutorTest {
2
3    private static final Integer HIGH_VALUE_THRESHOLD = 1000;
4    private static final String ORDER_ID = "123";
5
6    private TestExecutor executor;
7
8    private Event event;
9
10    @Mock
11    private ReadOnlyFluentApiClient apiClient;
12
13    @Mock
14    private GetOrderByIdQuery.Data data;
15
16    @Before
17    public void setup() {
18
19        MockitoAnnotations.initMocks(this);
20
21        when(apiClient.query(any())).thenReturn(data);
22    }
23}

Step 2 - Create an Event entity

1@Before
2    public void setup() {
3
4        MockitoAnnotations.initMocks(this);
5
6        when(apiClient.query(any())).thenReturn(data);
7
8        // Setup up an instance of a Rubix Entity
9        RubixEntity entity = RubixEntity.builder()
10            .status("BOOKED")
11            .entityType("ORDER")
12            .flexType("flexType")
13            .flexVersion(1)
14            .ref(ORDER_ID)
15            .id(UUID.randomUUID().toString())
16            .build();
17
18    }

Step 3 - Create an Event to trigger the Ruleset

• Event.builder on declared Event instance - Use Event builder to build the event with the attributes of retailerID, entityID, rootEntityRef, etc.
• Event.builder.build  - Once the event is built, it will be used to trigger the workflow.

Step 4 - Create the Rule instance and Ruleset

• The Rule we are going to test. 
• Setup the Ruleset- ruleset configured with an instance of the Rule, an Entity, and an Event.

• Create a map in the setup() method to show how the Rule is configured with Rule parameters in the Ruleset.
• Create an instance of a Ruleset in the setup() method to hold an instance of the Rule that is configured with the parameters as shown in the interaction below

• map of rule parameters - ImmutableMap will map required parameters of the Rule.
• event paramater of ruleset - It is the event that is triggering the ruleset.
• name of the rule  - MarkOrderHighValueRule.class.getSimpleName() is the name of the Rule class
• map builder - propertyBuilder.build() is the map builder that states how the rule is configured

Step 5 - Setup the TestExecutor

1// Set up a TestExecutor to simulate Orchestration Engine
2        executor = TestExecutor.builder()
3            .rule(MarkOrderHighValueRule.class)
4            .ruleset(ruleSet)
5            .entity(entity)
6            .testApiClient(apiClient)
7            .build();

Step 6 - Create a test case to run on TestExecutor

• Create a test method named run_withTotalPriceGreaterThanThreshold_callsMutateAction
• The test method "arrange, act and assert" approach is in the below-given code snippet. 
• Run the test case.

1@Test
2    public void run_withTotalPriceGreaterThanThreshold_callsMutateAction() {
3
4        // arrange:
5        GetOrderByIdQuery.OrderById orderById = GetOrderByIdQuery.OrderById.builder().id(ORDER_ID).totalPrice(1001.00).type("type").__typename("type-name").build();
6
7        when(data.orderById()).thenReturn(orderById);
8
9        executor.validateWorkflow(event);
10
11        // act:
12        TestContext context = executor.execute(event);
13
14        // assert:
15        assertEquals(1, context.countActionsOfType(TestContext.MutateAction.class));
16    }

Practice Exercises

• run_withTotalPriceLessThanThreshold_doesNotCallMutateAction
• run_withTotalPriceEqualToThreshold_doesNotCallMutateA

Testing on Sandbox

Deploy your Rule

• Prepare your plugin for deployment
• Upload and install your plugin on your account
• Add your new rule to a ruleset within a workflow
• Execute your new rule
• Complete your new Workflow
• View the audit events for your rule execution

Step 1 - Prepare your plugin for deployment

Compile & Package

• A particular plugin version can only be uploaded once.
• Inside pom.xml version tag ,  SNAPSHOT is possible but can be confusing since “-“ gets replaced with “." which can impact on GET. We recommend  replacing SNAPSHOT with version like 0.0.1
• All the test cases need to Pass else the maven built will fail and won't generate .jar file.

Step 2 - Upload & Activate

Postman & Account Authentication

• Navigate to the DV-RS-01 Deploy a Custom Plugin > Authenticate Account Super User in the Fluent Learning - DV-RS1 Labs Postman collection.
• Select the Fluent Auth request, and click Send. This will authenticate the Super User who has the right to deploy on the account.

Upload Plugin

• Navigate to the DV-RS-01 Deploy a Custom Plugin > Deploy & Validate > Upload plugin and POST the request.
• Set the file parameter in the body of the request by selecting your plugin jar file.  On the Body tab,  click on Select Files, then browse to locate your plugin jar file.
• Click Send to upload your plugin.  Confirm that you receive a successful response, HTTP Status Code 200 OK.

Activate Plugin

• Navigate to Deploy a Custom Plugin > Deploy & Validate > Activate plugin and POST request. 
• Click Send and confirm that the response is 200 OK.
  Note: This request does not contain a response body.
• Inside Deploy & Validate run Plugin Status & Account Rules GET Requests. These requests will give you details of all the active Rules in your account (e.g. event, parameters,  event attributes) which are used as the environment variables. 
• Use the Get Plugin Status request to confirm that you have successfully uploaded and activated the plugin. The response should contain a field called bundleStatus with a value of ACTIVE.
• Now that your plugin is successfully activated, use the Get Account Rules request to see all the rules active in the account. Search the response for the name of your rule MarkOrderHighValueRule.

• Upload Plugin - It's a Post request where you will upload your plugin and send the request.
• Plugin Status & Account Rules - These GET request will provide you with your details of your active Rule like parameters, events , event's attributes. These details are used as environment variables.
• Activate Plugin - This Post request Activate your uploaded plugin.
• File - Use File as the Key value. 
• Upload's plugin request - Body - You will upload the plugin in the Body of Upload Plugin Request.
• Successful upload - On successful upload you should get status 200 OK response.
• Choose jar file - Browse to location of your plugin project. It is a Jar file which you have created in the Step1 - Prepare your plugin.
• Send request - Once you have uploaded the plugin , Send the request.

Step 3 - Add your New Rule in the Workflow

• Login to your Fluent Console using your FC_Fashion retailer credentials.
• Authenticate FC_Fashion Retailer in Postman. A successful request will generate a valid access_token and status 200 OK response.
• In Postman, navigate to DV-RS-02 Apply Simple ORDER: CC Workflow and execute the Simple ORDER:: CC Workflow PUT request.  A Click and Collect (CC) Workflow will now appear on your Console.

• Open the newly updated Order CC Workflow in the Modeller.
• Click ADD RULESET, create a new RULESET and name it AnnotateOrder. *See table below for an e.g. of a short and meaningful description of a Rule.
• Save your RULESET.  This will open the RULESET editor drawer that will prompt you for details of the Rule. Refer to the below table to fill in the required details for the Rule:

• Commit changes.

• Active Rules  - This list is displayed when you pick Rules. The list shows all the Active Rules in your Account. You can search and select the Rule.
• Description - Write a short and meaningful description of the Ruleset.
• Available from - Select the state on which the Ruleset will be available. MarkOrderHighValueRule is available  when the order is in Received  state
• Rules  - Add the Rules required for the RULESET.  Clicking on Rules will list all the active Rules in your account.

Step 4 - Execute your new Rule

• Click on CREATE Ruleset and revise the current Workflow by changing the Send a MockBookOrder event for the (current entity) Rule to Send an AnnotateOrder event for the (current entity).  

• Create RULESET - Click on Create to modify the current Workflow to call the added Rule
• Send an event for current entity - Call the  Rule in "Send an ______event for the current entity. 

• An Order with a total price greater than the threshold value 
• An Order with a total price less than the threshold value

Order Creation Steps

• Create Customer POST request — this request will create a Customer.
• Create CC Order with Price 105.00  POST request — This request will create an Order with a total Price of 105.00 which is less than the Rule's Threshold value.
• Create CC Order with Price 205.00  POST request — This request will create an Order with a total Price of 105.00 which is greater than the Rule's Threshold value.

• Check if the attribute IS_HIGH_VALUE, has a value of True for the Order with Price 205.00
• Check there should be no Attribute called IS_HIGH_VALUE  for the Order with Price 105.00.  But the Order should still be progressing through the workflow.

Step 5 - Complete the fraud workflow

Execution Context

Complete the Fraud Workflow

• Description of Validate if the Order can be automatically booked or need manual intervention
• Add three (3) Rules to complete the Workflow.  Refer to the table below for the details of the Rules required in the RULESET:

• Mody AnnotateOrder RULESET - Once the ValidateOrder RULESET is created , then modify AnnotateOrder RULESET to add SendEventGQL Rule
• SendEventGQL Rule - In the SendEventGQL Rule , call the ValidateOrder event .

Complete the Modified Workflow

• Create CC Order with Price 105.00  POST request - This request will create an Order with total Price of 105.00 which is less than the Rule's Threshold value.
• Create CC Order with Price 205.00  POST request - This request will create an Order with total Price of 105.00 which is more than the Rule's Threshold value
• On the console, navigate to the Orders section and locate your created Order. The Order with price of 205.00  should be in FraudCheck  state and Order with price of 205.00  should be in Completed state . Click on Order to view the order details.

Step 6 - View the Audit events for your Rule execution

• Activity section within Fluent Console —  Here, you will see the high-level state lifecycle that the Order went through.
• Fluent Console Events screen —Here, you can search for your Order ID, Reference, or other available filter and view the raw event data associated with the Order.
• Postman — Here, you can retrieve all the events associated with the Order in JSON format. You can execute the 'Get Order' Audit Logs GET request in DV-RS-03, create Orders for FraudCheck logic and see the details of all events associated with the Order.