Planning and Designing Integration Solutions
Planning and designing integration solutions
This domain tests whether you can turn a business interface into an ACE solution: choosing an integration node versus an independent integration server, structuring applications and libraries, selecting message-flow nodes, and deciding between ESQL, mapping, REST, SOAP, MQ, and file transport. The exam favors designs that keep environment-specific values outside the flow.
Core rules
- Model a message flow around the smallest unit of work that must succeed or fail together; set transactional scope deliberately.
- Use MQ for assured delivery, HTTP for synchronous request/reply, and file or FTP where the partner contract requires it.
- Put reusable subflows, maps, and Java in libraries; put deploy-time values in policies, configurable properties, or server.conf.yaml rather than hardcoded Compute nodes.
- Prefer ESQL for procedural message-tree manipulation and complex loops; prefer Graphical Data Mapping for declarative, schema-aware transforms.
- Design error handling as a first-class path: failure terminals, ESQL or Java try/catch, and a common error subflow.
Worked example
An order request arrives on IBM MQ and must be validated, enriched from a database, and sent to a SOAP service. A sound design uses MQInput with transactional scope covering the database and SOAPRequest, a Compute node for validation, a database or mapping step for enrichment, and SOAPRequest with SOAPReply. If the SOAP call fails, roll back the MQ get so the message is retried; send persistent failures to a backout queue. Keep the endpoint in a policy so test and production BARs differ only by configuration.
Traps
Do not choose a synchronous HTTP pattern for a batch process that must survive outages. Do not put credentials in ESQL literals. Do not create one giant flow with no error terminal. Do not assume a mapping node can replace every procedural ESQL loop.