A web service on the enterprise service bus adds two new mandatory fields. What breaks, and what must change in the integration?
A web service integrated through the enterprise service bus (ESB) has added two new mandatory fields — taxId and consentGiven — to its request contract. It now rejects any request that omits them.
Constraints:
- The upstream systems still publish the message below and know nothing about the new fields.
- The bus performs message translation and content-based routing between the two sides.
- The two new fields are required — a request without them is rejected by the service.
{
"customerId": "C-1001",
"fullName": "Ivan Petrov",
"email": "ivan@example.com"
}Determine what breaks in this integration and describe exactly what must change, and where.
Every message now fails at the target: the service rejects requests missing the two mandatory fields, though senders are unchanged. Fix it by updating the bus mapping to supply the fields, bumping the contract version, and updating consumers and tests. Roll out with backward compatibility.
- ✗Assuming the bus auto-fills missing mandatory fields
- ✗Changing only the sender and skipping the bus mapping
- ✗Rolling out with no version bump or backward compatibility
- →Where could the bus source the new field values from?
- →How do you avoid losing in-flight messages during the change?
What happens: a mandatory field that the message does not carry is a validation failure at the receiving service. It is not the sender that breaks but the exchange: taxId and consentGiven are absent, so the service rejects every request even though the source systems are unchanged.
What must change, and where:
- On the bus — update the mapping and message translator so the new fields are populated: from the sender if it knows the value, or enriched from a reference system if it does not.
- Bump the contract and schema version (WSDL/XSD or JSON Schema) and document the new fields as mandatory.
- Update validation, consumers, and tests; agree the source of
consentGivenwith the business. - Roll out with backward compatibility and handling for in-flight messages so none are lost.
{
"customerId": "C-1001",
"fullName": "Ivan Petrov",
"email": "ivan@example.com",
"taxId": "7701234567",
"consentGiven": true
}
