Designing for failure

Every integration flow fails sometimes. A receiver restarts, a certificate expires, a partner sends a part number nobody has mapped. The question is not whether your flow will meet an error but what it does next: retry quietly, stop and tell a person, or reject the message back to the sender. A flow without a deliberate answer still has one. It is just the default, and the default is rarely the right one for the business.

This course follows one Contoso Motor Co. interface from design to test. Great Lakes Fleet Services sends depot replenishment orders to Contoso as JSON over HTTPS (its headquarters purchase orders still arrive as X12 850 EDI, covered in sap-pim-206). Theo, the integration lead, has split the interface into two integration flows in SAP Cloud Integration, the integration service of SAP Integration Suite: CMC_GLFS_Order_Receive accepts the order, checks it and writes it to the JMS queue CMC_GLFS_ORDERS; CMC_GLFS_Order_Deliver reads the queue, maps the order to an ORDERS05 IDoc and posts it to the production system CMP through SAP Cloud Connector. The order that became sales order 1000473 travelled this path. The operations side (monitoring maps, ownership, reprocessing and reconciliation) is covered in sap-int-205; this course is the developer's half.

Three kinds of error

Before you draw an exception subprocess, sort the errors your flow can meet into classes, because each class needs a different response. The useful split is by what fixes the error.

The trap is treating every error the same way. A flow that retries a functional error retries it forever: the unknown part number will be unknown on the fortieth attempt too, and meanwhile the queue fills and the alert inbox drowns. A flow that sends every transient timeout to a person creates hundreds of tickets for problems that would have healed themselves in two minutes. sap-int-205 routes each error to the person who can fix it; here you build the flow so it can tell the classes apart in the first place.

Where the class is known

You can only classify an error where you have the information. Cloud Integration gives you three signals. The step that failed: the exchange property SAP_ErrorModelStepID holds the ID of the step where the error occurred, which you can see under Technical Information on a selected shape. The exception itself: its text and Java class. And for HTTP calls, the response code the receiver returned. A 503 or a timeout says "try later"; a 400 with a validation message says "this message is wrong".

Functional errors you detect yourself are the easiest to classify. In CMC_GLFS_Order_Deliver, a value mapping turns the customer's part number into a Contoso material. If no mapping exists, a Router sends the message to an Error End event in the main process with a clear reason. That deliberate error carries its own step ID, so the exception subprocess can recognize it and route it differently from a timeout. SAP's reference flow for this pattern (Pattern Content Based Routing, Raise Error) routes on ${property.SAP_ErrorModelStepID} in exactly this way.

Synchronous or asynchronous decides your options

Your design choices depend on who is waiting. If the sender waits for an answer (a synchronous HTTP or SOAP call), the flow cannot retry for an hour; it must answer within the caller's timeout, so the best you can do is a clean, meaningful error response and perhaps a short in-call retry. If nobody waits, persist the message first and process it asynchronously. That is why CMC_GLFS_Order_Receive does almost nothing: it validates the JSON, writes to the queue and answers Great Lakes with HTTP 202 Accepted. SAP's design guideline "Apply the Retry Pattern with JMS Queue" describes exactly this split.