The most common misunderstanding in an architecture meeting comes down to a name. The screen says “incoming service”, everyone pictures an external system calling us, and the discussion runs from the wrong end for half an hour.
Why the incoming service name misleads
The flow runs the other way: iDataEngine initiates the call and processes the response that comes back. Reading the name that way shortens half of the architecture discussions. The opposite direction, calls arriving from outside, lives on the outbound service side.
Once that is clear, the real decision shows up. Should an external service call sit inside a piece of development, or as a stored definition?
The settings that live in an external call definition
On the definition route, the following end up in one record:
- URL, HTTP method, content type and headers.
- Authentication: header generation in Basic, Bearer token or API key form.
- A body template built with variables, plus query parameters.
- Client settings such as timeout, redirect following and certificate verification.
- How the response is read: JSON, XML, HTML or plain text.
On the response side XML is converted to JSON with Jackson XmlMapper, and HTML bodies and tables are parsed with Jsoup. So pulling data out of an older service with no proper API is possible, as long as you build it knowing the path is fragile. When the markup of the source page changes, the integration breaks quietly.
The cost of a call that lives in code shows up somewhere else: how many files hold the credential, how many seconds is the timeout, and who knows the answer once the person who wrote it three years ago has left? Keeping the definition in one place means you fix a changed contract in one place. It does not stop the contract from changing.
Event actions are processed in sequence
A stored external service can also be called as the REST action of an event. The variables in the body template are then fed from event data: row fields, metadata and event context are placed into the template. Notifying an external order service when a status field changes in a SAP table is built exactly this way.
One behaviour is worth knowing here: the dispatcher reads active triggers in order and actions are processed sequentially. If one action depends on a slow service, the work behind it waits. That is why the setting for continuing or stopping the chain on error matters.
Testing the timeout and the error response together
Most teams test only the successful response. With external services the real information is in the failure: does it return 401, a 200 with an error body, or does it time out? Writing the expected behaviour down first and testing both paths decides what you look at during the first production incident.
Let us be plain about one thing as well: the availability and contract stability of the external service are dependencies outside iDataEngine. A definition makes that dependency visible; it does not remove it.
Pick the most fragile of your external integrations, usually the one nobody wants to touch. Let us move its URL, credential, timeout and error behaviour into a single definition, then break it on purpose and watch what happens.