To be able to make decisions based on lists of data or to return one or multiple maps as one or multiple different form of maps, the current YARD functionality is not enough.
As a solution to this I propose adding a rule element and input import types Map and List.
Rule element will start with simple goal of returning a Map or a List. A Ticket or a Person object for example would be a Map, List of Tickets is a List of Maps and then of course there can be a Map of Maps of Maps and so on.
Conditional elements will include simple rule setup. To filter collections or change the form.
specVersion: alpha
kind: YaRD
name: 'Merge'
inputs:
- name: Jira 1
type: List
- name: Jira 2
type: List
elements:
- name: Merged data from two ticket streams
type: Decision
logic:
type: Rules
rules:
- when:
- given: $ticket
from: Jira 1
having:
- status == "Blocking"
then:
list:
- add: $ticket
- when:
given: $ticket
from: Jira 1
having:
- status == "Blocking"
then:
list:
- add: $ticket
As well as grouping functionality with the same approach. Making the YAML format act as a DSL for the RuleUnit DSL.
This should also work in the then part, but easier and cleaner way to access and edit maps will help with editing and readability.
Since the element return type is always a list, a primitive data type or a map. This would also help with any editor work, since the list and map manipulation is easy to detect.
- when:
given: $ticket
from: Jira 1
having:
- status == "Blocking"
then: "Merged data from two ticket streams".add($ticket)
Or when like in the other elements, you could return JSON.
This approach mimics the YAML DRL Rules without using the type as a restriction. This is since in our current use cases there is no type detection in an easy way. Also this would require either a type declaration in the YARD file or importing a Java class. Alternative would be to use a schema import, but that then again requires us to add another step for creating schemas.
More of a YARD ticket, but let's track it here.
To be able to make decisions based on lists of data or to return one or multiple maps as one or multiple different form of maps, the current YARD functionality is not enough.
As a solution to this I propose adding a rule element and input import types Map and List. Rule element will start with simple goal of returning a Map or a List. A Ticket or a Person object for example would be a Map, List of Tickets is a List of Maps and then of course there can be a Map of Maps of Maps and so on.
Conditional elements will include simple rule setup. To filter collections or change the form.
As well as grouping functionality with the same approach. Making the YAML format act as a DSL for the RuleUnit DSL.
This should also work in the then part, but easier and cleaner way to access and edit maps will help with editing and readability. Since the element return type is always a list, a primitive data type or a map. This would also help with any editor work, since the list and map manipulation is easy to detect.
Or when like in the other elements, you could return JSON.
This approach mimics the YAML DRL Rules without using the type as a restriction. This is since in our current use cases there is no type detection in an easy way. Also this would require either a type declaration in the YARD file or importing a Java class. Alternative would be to use a schema import, but that then again requires us to add another step for creating schemas.