We’re integrating an external rule engine with Mendix decision-management module and hitting a wall. The external engine returns rule evaluation results as JSON, but our import mapping consistently fails.
The JSON payload structure from the rule engine looks fine when tested independently:
{
"ruleId": "CREDIT_001",
"decision": "APPROVED",
"score": 750
}
Our import mapping configuration references the Decision entity, but throws validation errors during runtime. The external rule engine connection works (we can ping it), but the decision-management module won’t process the response. Has anyone successfully integrated external rule engines with Mendix decision management? What’s the correct approach for mapping external JSON responses to decision entities?
We’re using the built-in connector. I didn’t realize the module had specific metadata requirements beyond the decision payload. Where can I find documentation on the required JSON structure for decision-management imports? The standard docs only show basic examples.
Are you using a custom microflow to handle the REST call or relying on the built-in decision service connector? I’ve found that custom microflows give you more control over JSON transformation before it hits the import mapping. You might need an intermediate transformation step to enrich the external engine’s response with Mendix-specific metadata fields that the decision-management module expects.
Another thing to check: is your import mapping set to create or update Decision entities? If you’re trying to update existing decisions, you need to ensure the external rule engine returns a valid decisionId that matches an existing record. Otherwise, set the mapping to create mode and let Mendix generate the IDs internally.
The decision-management module documentation doesn’t explicitly list all required fields, which is frustrating. Based on my implementation experience, you need: decisionId, timestamp, executionContext (object with userId and sessionId), rulesetVersion, and the actual decision payload. The module validates against this schema internally. If any of these are missing, you’ll get cryptic validation errors. I recommend creating a wrapper microflow that transforms your external engine response into the full structure before calling the import mapping.
I’ve seen this before. The issue is usually that the decision-management module expects a specific JSON structure that includes metadata fields beyond just the decision result. Check if your import mapping includes the required decision context fields like timestamp, version, and correlation ID. The module needs these for audit trail purposes.