次の方法で共有

Schema design: do include support for Errors and Warnings

  • [アーティクル]

Abstract: Schema designs usually contain some boolean Error-or-Success code to handle the result of the process. In an EAI scenario, schemas should contain at least support for a new result type: Warning.

EAI communicates different applications. In a one-to-one integration, the result can be just categorized Success or Failure. But if we have more than two applications, there can be a wider range of situations. So we need to categorize the results.

The following is a simple example the common error situation:
Let’s suppose that we are calling a web service and sending back its response to the initial caller (ala message router). What if the web service is down? --> We compose an empty response and put an error in the header. Something like this:

<Response>
<Header>
<Result type=”error”>
<Errors>
<Error code=”1” source=”WebService1”>A timeout happened!</Error>
</Errors>
</Result>
</Header>
<Body/>
</Response>

See the body is empty.

But what if we must create one aggregated response from two or more web services and only one them fails? We cannot say it’s an error (there is valid data), but we cannot say it’s a success.

So let’s use a warning:
The process that aggregates many responses into a unique big response can convert the error into a warning. Some way like this:

<Response>
<Header>
<Result type=”warning”>
<Warnings>
<Warning code=”2” source=”MessageRouter”>Some services did not responded as expected</Warning>
</Warnings>
</Result>
</Header>
<Body>

    <!-- data from WebService 2 -->
    <!-- data from WebService 3 -->
<!-- data from WebService N -->
</Body>
</Response>

And the initial caller is happy because it has a valid response, but it’s aware that it’s not a full success. We can also have a severity weight of the warning (low, medium, severe, catastrophic, etc).

Note that in the aggregated response I’ve removed references to which Web Service failed and its original message --> the Message Router & Aggregator hides the integration logic to the caller, of course, but this is another chapter…

Comments