Mendix Expert Developer: Integration and REST/SOAP/Web Services

Integration and REST/SOAP/Web Services

This domain tests whether you can build integrations that fail predictably: correct mapping, correct authentication, correct handling of every status code you can receive.

Core rules

• Consume REST offers a plain Send Request activity returning a string, or a mapping-based call that produces entities. Publishing REST (OData) and publishing SOAP expose your domain model as a contract - treat that contract as versioned API surface.
• Import mappings translate JSON/XML into entities; export mappings reverse it. Watch Force single (an array that may hold zero or one item) and missing-element handling, which silently produce empty attributes.
• Authentication is Basic, custom headers, or OAuth 2.0 client credentials. Secrets belong in environment constants, never in the model or in committed documents.
• Always inspect $latestHttpResponse/StatusCode before consuming a body. 4xx is a caller problem - do not retry; 5xx and timeouts may be retried with backoff and an idempotency key.
• SOAP integrations are WSDL-driven and raise faults rather than status codes; catch them and map them to a domain error.

Worked example

Consuming a customer API: the request maps a Customer entity out, the response maps back into a CustomerDTO. After the call the flow checks the status code - 200 and 404 are both valid outcomes, 429 means back off, 500 means retry once. The import mapping uses Force single on the address block because the API sometimes returns an object and sometimes an array of one. The API base URL and credentials are constants set per environment.

Traps

• Assuming a 200 means a valid body - validate required fields after mapping.
• Ignoring pagination and silently importing only the first page.
• Parsing JSON with string functions instead of an import mapping.
• Leaving the default timeout in place for a downstream system known to be slow.