...

With the exception that complicated rules with many conditions containing more than 5 to 10 fields and many combinations are put in a separate rule sheets with their own descriptive name suffix.

Guidelines

• Place rules in the frame rule flow whenever you can and the window rule flow whenever you have to for the purpose of dividing the rules into many simple frame rule flows instead of one big and complicated window rule flow (see creating vocabularies).
  
  
• Divide the rules into the following rule sheets and rule sheet names (unless they have no rules. There's no need for empty rule sheets) -
  
  
  • <window or frame>_Fixed.ers - Fixed property settings.
  • <window or frame>_IsEnabled.ers - Rules for enabling form fields.
  • <window or frame>_IsVisible.ers - Form fields visibility rules.
  • <window or frame>_Pages.ers - Pages (tabs) visiblity rules and enabling or disabling pages.
  • <window or frame>_Messages.ers - Message rules (errors, warnings and info messages).
    
    
• Complicated rules with conditions containing more than 5 to 10 fields and many combinations should be put in a separate rule sheets with their own descriptive name suffix.
  For example: EntscheidDetailBasisFrame_IsUnUpdatable.ers
  
  
• A specific property (like a form field is enabled property or any other property) must be set in one place and one place only. The property must be set in one rule sheet covering all the combinations. In either the frame or window rules but never both. Setting the same property in different rule sheets increases the risk of conflicts.
  
  
• Use the default action column whenever possible to decrease the number of combinations and simplify rule sheets.
  For example: if you set the default for the is enabled property to false then you only need to specify the condition combination when it is true.
  
  
• Use an AND condition in combination with the default the column instead of an OR condition for setting properties to decrease the number of combinations and simplify rule sheets (because AND conditions use a single combination column while OR conditions use multiple combination columns). 
  
  
• The fixed rule sheet should only be used for properties that have a fixed or constant value and should not be used for default values.
  For example: if the specification says this form field is always enabled.
  
  
• The fixed rule sheet can also be used for setting custom properties by calling the custom JavaScript functions to fetch values (see incorporating code).
  
  
• In the _Message rule sheet, place the message text values in the cell action column and use the cellValue for the message parameter.
  For example: Message.new[type='info', entity='EntscheidDetailWindow', message=cellValue]
  

...

• 
  
• Every rule action should have a rule statement with a simple description (the descriptions will not be shown to the user) used internally for debugging and understanding what rules were triggered (see rule tests design).

Rule Test (Unit Tests)

Rule tests are the first and best way to debug and track down problems. Every rule sheet should have at least one ruletest rule test with the exception of the fixed rulesheet. In addition, rule statements should be filled with a description for every combination to help debug what rules were triggered when running ruletests or at runtimerule sheet.

Rule tests also show you the rule statements of the rules that were triggered when running the rule test to further help debug and understand rules output.

You cannot have multiple separate tests in a single rulesheet rule sheet and they must be separated to several ruletest files with the _Test<number>.ert suffixinto several rule tests. Alternatively, use a single ruletest that can combines or triggers multiple rule conditions and actions.When copying entities to the ruletest input column, remove rule test which triggers multiple rules.

Rule tests need to be incorporated and run as part of the build and pipeline unit tests.

Guidelines

• Every rule sheet should have at least one rule test (except for the fixed rule sheet) with the same name of their rule sheet and a _Test suffix.
  For example: EntscheidDetailWindow_IsEnabled_Test.ert
• If there are multiple rule tests for a rule sheet, the _Test<number> suffix should be used.
  For example: EntscheidDetailWindow_IsEnabled_Test3.ert

• Remove unused fields that have no conditions when copying entities to input column, to keep the

...

• rule tests simple and readable (keeping in mind that some forms and datasources can have tens or even hundreds of fields).

Ruletests need to be incorporated and run as part of the build and pipeline unittests.

Ruleflow Design

Image Removed

...

Rule Flows

Image Added

Even though the rulesheets rule sheets have no dependencies by default (except for special cases) and there is no need to connect them, the rulesheets should be connected it is still considered a best practice and you should always connect the rule sheets so the order of execution is clear.

Of course, there can be more complicated rule flows but there's currently no need or use case.

Guidelines

With the exception if there are special cases with a different dependency or a more complicated ruleflow.

• Make sure all the rule sheets are copied into the rule flow.
  
  
• Connect the rule sheets in the following order -

...

• 
  
  
  1. Fixed rule sheet.
  2. Is enabled rule sheet.
  3. Is visible rule sheet.
  4. Pages rule sheet.
  5. Messages rule sheet.
  6. or above; for any additional rule sheets (see rule sheet design).

Packaging Rules for Deployment (Generating JavaScript Files)

...

The window and frame names are unique so there is no risk of conflicts.

...

DynSelect Setting

Guidelines

• If there are any related fields that should be updated when a dynSelect value is changed in a form or calculated fields in business entities then they should be added to the dynSelect mapping so the correct values are available for to Corticon.
  
  This guideline is true when using Corticon as it is when writing TypeScript.

Incorporating Code (Advanced Cases)

Image Added

Using code should only be used as a last resort and if there is no other choice. Whenever possible backend data should be taken from the business entity. If the data does not exist in the business entity, consider adding the fields or even creating another business entity with the required fields.

To run simple synchronous code like fetching data from the UI, Corticon.js supports JavaScript functions calls in rulesheetsrule sheets. You can create custom properties and set their values with JavaScript functions in the fixed rulesheetrule sheet.

To run asynchronous code like backend calls, create a regular TypeScript event handler file that sets custom properties in the screen akEvent payload property and then calls the screen frame or window callRules() method to execute the screen rules (and the window rules).