How to allow for "dynamic" inputs and/or fetching data

[machty]

I am working on building a decision graph to determine whether a transaction requires additional review before approval. Our clients want the ability to create rules based on recent purchase statistics. For instance, one client has requested the ability to calculate the median transaction amount from the last 5 purchases and use that "dynamic" value as an input in a Decision Table. While we can compute this request for them and input it into the decision graph, they may later want to adjust the number of purchases considered to 10 or another figure.

Are there effective ways to achieve this? Could this be a use case for Custom Nodes, and if so, how would that function?

One approach I’m considering is to provide the transaction history, limited to the last 50 transactions. Then, for any complex logic, clients could use a JavaScript function to perform statistical calculations. Does this seem like a viable plan?

[hatbrox]

hi,
I was going to ask the same question. Did you find a solution?
I think gorules cannot fetch any data. The service that requests gorule to do a rule evaluation is also responsible for providing all the necessary data.
But like your example, it's difficult to know what data is needed by the rule.
At this point, I feel obliged to implement the same solution you suggested: provide more data in the request.
This is also an very ineffective approach, because we bloat the request payload with data that are not (always) necessary.

[machty]

I never found a solution to this and the project to implement this got deferred. Perhaps there is a solution to writing a custom parser of the graph to tease out all of the dynamic inputs, or to scan/regex for a set of known variable types to filter out the possible data that needs to be queried to provide as input. Been a while since I've looked at this though.

[ivanmiletic]

Hi @machty @hatbrox GoRules can fetch the data but it is not yet nice, you can use http module in the function node.

We have on our roadmap to implement a new version of a built in HTTP API node (drag and drop - similar to table, functions etc), however we didn't have strong use case / requests from our enterprise customers... until yesterday. As soon as we complete some internal BRMS features, rollout upgraded Expression Node and finish compliance stuff we will revisit prioritization of the HTTP API node.

Is this what you are looking for?

[hatbrox]

hi @ivanmiletic,
Maybe I can provide a use case, hopefully, this is what machty also wanted.

🎯 Business Rule: German Newspaper Discount

Rule: If the customer has 5 or more active or pending subscriptions to eligible German newspaper products — across subscription inventory, shopping cart, and open orders — then apply a 10% discount code; otherwise, return '0'.

if we decompose the above rule, I get this:

🧾 Inputs

• customerId
• Eligible product codes: ["DEU_NEWS_1", "DEU_NEWS_2", "DEU_NEWS_3", "DEU_NEWS_6", "DEU_NEWS_11"]

📦 Data Sources & Conditions

Data Source	Field	Status Condition
Subscription Inventory	status	Active
Shopping Cart	itemStatus	In Progress
Open Orders	orderItemStatus	In Fulfilment or Open

✅ Output

• If total matching count across all sources ≥ 5 → discountCode = "DISCOUNT10"
• Else → discountCode = "0"

Ideally I wanted to store the entire rule definition in gorules, and by rule definition, I means full details of what data to fetch (data source, product code, status) plus the conditions and the action (output)

I understand it is not the responsibility of GoRules to gather and structure the necessary input data:

• Gorules expects that the data is already prepared upfront and provided in the request payload.
• Gorules is doing the "easy" part of the business rule: just check if the variable GermanSubscriptions is less/greater or equal to 5

this gives us 2 options:

1. the calling service (in this case, it's our "Product Configurator service") takes full responsibility for gathering the input data before asking Gorules to determine the discount code. This means Product Configurator must know all the details about the business rule: where to look, what product code and what status. How can Product Configurator know that?
   Gorules would not have much to do, really, just decide if cusotmer is eligible for a discount.

+----+-----------------------------+------------------+
| #  | Input: GermanSubscriptions  | Output: discount |
+----+-----------------------------+------------------+
| 1  | GermanSubscriptions < 5     | 0                |
| 2  | GermanSubscriptions >= 5    | 10PCENT          |
+----+-----------------------------+------------------+

2. Product Configurator is "dumb", it just fetches all the product data that exist for this customer id, whatever the product code or status. Then I use gorules to filter, count etc and finally asset the discount eligibility. or define a big decision table with all the product codes, data source, status.
   there is much more logic happening in gorules, which is good, but the issue is that the Product Configurator would provide a rather large data set, which is not best practices from a performance point of view. I believe the average customer have 80 products (mostly historic data stored in the subscription inventory)

I guess I would like gorules to have 3 distinct components:

• a business rule catalogue (with full details)
• an workflow engine that can both orchestrate the evaluation engine (test conditions) but read the business rule to determine what what input data it needs to collect, and make the API requests towards various backends (as defined in the rule definition).
• an evaluation engine that tests conditions and generates output.

I'm not a developer, so I hope I haven't lost you on the way :-)

are there better patterns to manage design time and runtime tasks?

notes:
business users would like a single application to manage the entire business rule definition.
we're currently looking at the Zen engine as a proof of concept, but the full BRMS solution (low/no code, maybe MCP server later) should be a natural evolution of the solution if we want to empower business users to maintain the rules.

[hatbrox]

@ivanmiletic , can you tell me if you're going to provide feedback? we need to know if we wait any further for your input or explore other options.