DSL (Domain Specific Language) Builder and Validator is a feature designed to simplify the creation, modification, and testing of DSL rules across the Moveworks Environment. These rules are integral to mapping and executing customer-specific business use cases through tailored logic that interfaces with various system contexts. The feature is heavily used in the below customer phases :

1. Implementation Phase: DSLs are initially created during the implementation of the customer environment in Moveworks. DSLs are very important in this phase as it allows phased or controlled rollout of plugins to the user base.
2. Post-Go-Live Phase: DSLs are not static and can be authored or modified from scratch based on evolving enterprise needs or feedback. This includes updates to the Rules to act on context from attributes like user, ticketing etc.

DSL fields can vary in complexity:

• Simple Expressions: Some fields take basic logical values like True or False.

• Context-Dependent Expressions: More complex DSL fields reference dynamic data contexts, allowing them to evaluate conditions based on specific inputs.

  • For example, user.email_addr in ['[email protected]'] requires the user context to evaluate correctly. This means the user must ensure the email_addr attribute is being ingested via Identity Ingestion.

    

  • Another example, is chaining multiple user attributes together in a single rule to create a Complex one like below. Here we are checking across two conditions - If the user has the state Contractor & If the user email is present in the list defined.

    

What Challenges does it Solve ?

• Field Reference Uncertainty: Users would be unsure which fields can be referenced in their DSL expressions, leading to expressions that fail evaluation due to invalid or missing attributes or contexts.
• Lack of Feedback: There was no mechanism to provide users with immediate feedback on the correctness of their DSL expressions, reducing productivity and accuracy.
• Testing Complexity: Complex DSL rules are hard to build and validate due to a lack of integrated evaluation contexts.
• Self-Troubleshooting Deficiency: Administrators lack features to independently validate or troubleshoot DSL rule errors.

How to Use it?

To address these challenges, the DSL Builder and Evaluator aims to provide:

Autocomplete

• The Builder now offers users autocomplete suggestions for valid fields within a given data context. For instance, typing user. prompts suggestions like email_addr, name, etc.

📘

If you are ever unsure about what contexts a DSL Field supports in a Config, just click on the DSL Rule Box and it will list on the contexts supported.

• The Builder also takes nested attributes into consideration and auto completes the suggestions under the parent. For instance, here the attribute employment_info has other fields under it which can be selected like role, department, etc. which are also suggested.

  

Validate Syntax

• Every DSL builder has a button labelled “Validate Syntax” which evaluates the DSL expressions to ensure their correctness before evaluation. It is a requirement to Validate all DSLs before submitting changed.

  • Validation ensures the right attributes are being utilised in the DSL rule. It will throw and error regarding the problematic attribute if it is invalid.

    

  • Validation ensures the Syntax, indentation, structuring of IF ELSE Conditions are done appropriately.

    

  • When there is a Validation Error being throw, please reference the Errors Section which explains what the could be.

Run

• Allows real-time testing of DSL rules by including the context of the resource users are trying to test against. For instance we are testing the rule present in the Preview on top against the user selected from the Dropdown.
  Note : Only ingested users will list this dropdown.

  

• There are some DSLs Fields which support ticket context as well and are tested in the same way. In the tester here, you need to select the Connector for your ITSM system and enter a Ticket Number which will be polled to evaluate the rule against.

  

Best Practices to Follow

• When writing or editing an existing DSL rule ensure you understand the objective of, what the Rule will achieve on evaluation. This helps identify which context this rule will be written under as Moveworks has the below data contexts :
  • User
  • Ticket
  • Resource
  • Approval
• If the DSL Rule being written leverages custom attributes from a specific data context. We should ensure these custom attributes are suggested by the autocomplete feature.
  • In order for this to be possible the user must ensure these Customer Attributes have been defined under the appropriate context in the Moveworks Attribute Registry.
  • Learn more about Custom Attributes and how to Register them here.
• Before finalizing a DSL rule and submitting it, click on Validate Syntax feature to check for potential errors with the syntax or attributes being used.
  • Use the Error returned by the Builder to understand what the cause is and what resolution steps can be leveraged.
  • Here is a list of Errors which are returned by the DSL Tester that can be used to understand the root cause of the issue.
• It is always recommended to test individual parts of a complex DSL rule incrementally to ensure each component functions correctly before combining them and testing against the final rule.

Usage of Customer Attributes

DSL fields across different Plugins with the below contexts support Custom attributes which can be defined in the Moveworks Attribute Registry. These are attributed which are specific to the customer environment.

1. User Management
2. Ticket Processing
3. Approvals
4. Knowledge Management

This is a required pre-requisite if you plan to use custom attributes across DSLs Rules. In order to learn more about Custom Attributes and How to create them please visit this Guide.