Home

Use Cases

Training

Release Notes

Low-Code with UI Rules Engine

Low-Code with UI Rules Engine

1 Context

💡
In this task, we want to create a rules-based screen. We want to check something with low-code conditions in our screen. Here we are building an employee overview. If there is a leave request with a date for the employee, we want to display a button and the date. If there is no date, we want to hide the button and the empty date fields.

2 Result

image
image
image

3 Step by step guide

3.1 Create the screen

  1. 👋 Create a new screen using the ”TrainingDay5_Tempalte” and replace the following components and link them accordingly
    1. Screenname: “LowCodeRulesScreen_<yourName>”
    2. “EmployeeGrid ->Panel A
      1. “EmployeeDSO”
    3. “TrainingDay4_ExampleVacationForm” -> Panel B
      1. “VacationDSO”
  2. 👋 Join the VacationDSO and the EmployeeDSO with “EmpNum,EmpNum”
‣
Cheat result 🤭

3.2 Create the vocabulary and the rulesheet

  1. 👋 Navigate to “Logicalize” -> “Rules” and select the tab “Vocabularies”
  2. 👋 Generate a new vocabulary by clicking the two small gear wheel icon in the panel header menu (generate dialog)
  3. 👋 In the search field “Screen” search for your screen and generate the Vocabulary with the button “Confirm”
    1. 💡Depending on your point of view, a Vocabulary represents different things and serves different purposes. For the rule modeler, the Vocabulary provides the basic elements of the rule language – the building blocks with which business rules are implemented in Corticon.
    2. 💡For a systems analyst or programmer, a vocabulary is an abstracted version of a data model that contains the objects used in those business rules implemented in Corticon.
    3. 💡In Build.One, the vocabulary provides an abstraction of all objects and ids in the screen. This allows you to access different fields and attributes.
  4. 👋 Navigate back to the “Rulesheets” tab and click on the plus icon in the panel header menu (Launch Grid Create Dialog)
  5. 👋 Select your generated Vocabulary
  6. 👋 Select “Confirm”
  7. 👋 Open the rule designer by clicking the “Key” of your rulesheet

3.3 Create the rules with the rules designer

💡
Explanation of the Rule Designer

1. Use this button to save your work in the Rules Designer. 2. Use this button to undo your active changes. 3. This button allows you to delete your rules and conditions. 4. Validates the logic of your rules. 5. This button allows you to check the completeness of your rules. 6. This button allows you to check if there are logical conflicts in the rule. 7. Use this button to perform checks 4, 5 and 6 one after the other. 8. Use this button to create and deploy your rules for the screen. The corresponding TS files are created and the bundles are set up. 9. This opens an overview of all the objects in this screen and you can drag and drop them into your rule structure. 10. You can choose to add a condition, an action or a message to your rule tree. 11. Use this button to add your element from step 10 to the rule tree. 12. Top node for the rules 13. Check conditions for the rules. For example, the value of a field should match a certain rule. 14. Based on this condition, this action should then be true or false. 15. Based on this condition, an appropriate message is output. 16. Rule 1 to be checked and executed 17. Rule 1 to be checked and executed

image

3.3.1 Create the first check condition

  1. 👋 Click on the button “Vocabulary”
    1. 💡 When you first open the Vocabulary dialogue box, it covers the entire screen. Simply select the button in the top right-hand corner to minimise it.
  2. 💡 A dialog with the sturcture of the screen opens up
  3. 👋 Open up the tree grid with the following path
    1. Screenname → entities → Screenname → Forms → VacationForm_Training_Part4
  4. 👋 Drag and drop the TrainingDay4_ExampleVacationForm.StartDate_value on the conditions (Point 13 above picture)
    1. 💡 Open up the Conditions in the Tree grid → your condition was added here
    2. 💡 Rule 0 → Is always empty because it is a default condition
  5. 👋 Close the vocabulary dialog
  6. 👋 Add to Rule 1 the value “ click on it and select “Save”
    1. 💡 With the “ we check if the field is empty
  7. Add to Rule 2 the value >1998-01-01 click on it and select “Save”
    1. 💡 With the value we check if there is a valid date after the current year (We are working on the Progress SportsDB, the test data is a bit old 😀)

3.3.2 Create the actions for the check condition

💡
Now that we have created the two check conditions, we want to define the actions that should occur when the condition is met.

We defined the following actions

If the date is empty, as in rule 1 Then the start date, end date and button should not be displayed.

If the date is not blank as in rule 2 Then the start date, end date and button should be displayed.

  1. 👋 Click on the button “Vocabulary”
  2. 👋 Open up the tree grid with the following path
    1. Screenname → entities → Screenname → Forms → VacationForm_Training_Part4
  3. 👋 Drag and drop the following values to the Action in the tree grid
    1. TrainingDay4_ExampleVacationForm.SimpleSwatButton2__isVisible
    2. TrainingDay4_ExampleVacationForm.EndDate__isVisible
    3. TrainingDay4_ExampleVacationForm.StartDate__isVisible
  4. Add for all of the Actions in the Rule 1 field the Value F
  5. Add for all of the Actions in the Rule 2 field the Value T
💡
So we have indicated that if the condition from rule 1 is true, hide all values. → Visible = False

If the condition from rule 2 is true, show all values. → Visible = True

  1. 👋 Click on the button “CheckAll” to validate, check the completion and check for conflicts

3.4 Deploy and test the rules

💡
Now that we have created our rules, checked our conditions and actions, we need to deploy and export them.
  1. 👋 Click on the button “Browser” in the Deploy section
  2. 👋 Refresh your chrome/firefox browser without cache
  3. 👋 Launch your screen to see the result

4 Explanation

💡
It was quick and easy to create rule-based logic for our screen. These rules are persisted in TS files and bundles in the repository. As soon as we call the screen and the rule applies, the appropriate logic from the screens is applied. There is no need to connect to a server or anything. They just run as code in the background. Further down in this task there is linked documentation that explains all the rules, data types and operators.

4.1 Additional reading