IBM Sterling B2B Integrator (C8060-218) common mistakes
IBM Sterling B2B Integrator (C8060-218) · Understand the traps and how to avoid them.
Treating the graphical process modeler as a diagramming tool: building a business process that looks correct but never sets the service's on-fault behavior, so when a translation or communication service throws an exception the process simply stops with no notification and no cleanup.
Candidates focus on the happy-path sequence of services and overlook that each service node has fault handling and that the process itself needs an explicit error path or a default fault handler. The modeler validates structure, not error routing, so nothing warns them.
What to do instead
For every service that can fail (translation, adapters, database), attach a fault link or configure the default fault behavior. Model an explicit error branch that logs the failure, rolls back or releases the document, and sends a notification via an alert or email service. Test by forcing a failure (bad input document, unreachable host) and confirm the error branch executes.
Confusing the roles of the trading partner agreement, the envelope, and the translation map: expecting the agreement alone to transform data, or expecting the map alone to route documents to the correct partner.
The three artifacts work together and the exam tests whether the candidate knows which component does what. New users often think a partner agreement performs EDI-to-XML conversion, or that a map handles delivery.
What to do instead
Learn the division of labor: the partner/agreement configuration governs identification, envelope overrides, delivery channel selection, and security; the envelope (system or partner-specific) defines ISA/GS/ST and similar wrapping; the translation map performs content transformation between formats. Be able to state, for a given scenario, which artifact must change.
Mixing up inbound and outbound direction when configuring a trading partner delivery channel or agreement, so documents are extracted from the wrong mailbox or delivered to the wrong protocol endpoint.
The same partner may have both inbound and outbound channels, and the configuration screens look similar. Candidates memorize field names without mapping them to document flow direction.
What to do instead
Before configuring, draw the document lifecycle: where it enters, which mailbox or protocol, which business process picks it up, and where it exits. Verify by running a test document end to end and checking the mailbox and the partner's received file, not just the process status.
Assuming an EDI document that passes structural validation is business-valid: not checking that segment counts, control numbers, and functional acknowledgments (997/999) are actually generated and correlated.
Candidates equate a successful translation with a correct interchange. Envelope validation, control-number sequencing, and acknowledgment generation are separate steps that can silently fail or be skipped.
What to do instead
Know the acknowledgment flow: which process generates the 997/999, how control numbers are stored and incremented, and where to verify the outbound acknowledgment. Test with a deliberately malformed interchange and confirm the expected reject acknowledgment is produced.
Configuring an SFTP or FTP communication adapter without accounting for host key verification, passive versus active mode, or the remote directory path, then blaming the business process when transfers fail.
Adapter errors surface as process failures, so candidates troubleshoot the process instead of the adapter. Passive/active mode and key trust are classic real-world pitfalls that the exam probes.
What to do instead
Isolate the adapter: test the connection from the adapter configuration or a standalone test, confirm host key or certificate trust, choose the correct transfer mode for the firewall topology, and verify the remote path exists and is writable. Only then re-run the process.
Confusing AS2 concepts: treating the signing certificate, the encryption certificate, and the MDN (receipt) as interchangeable, or expecting synchronous and asynchronous MDNs to behave the same.
AS2 combines signing, encryption, and non-repudiation receipt in one exchange, and the partner configuration has separate fields for each. Candidates who have not configured AS2 in practice guess which certificate does what.
What to do instead
Map each certificate to its function: your private key signs outbound, the partner's public key encrypts outbound, and the reverse applies inbound. Know that synchronous MDN returns on the same HTTP connection while asynchronous MDN arrives later on a separate call, and know where to look for MDN status.
Granting broad administrative or all-permission roles to a service account or integration user because the process 'works' that way, without understanding permission groups, user groups, and resource-level access.
Candidates hit an authorization failure during setup and solve it by escalating privileges rather than diagnosing the missing permission. The exam tests least-privilege design.
What to do instead
Identify the specific permission or resource the process needs (mailbox access, adapter use, map execution) and grant only that through the appropriate permission group and user group membership. Re-test with the restricted account and document the minimum set required.
Scheduling a business process without considering overlap, time zone, or what happens on a missed run: setting a short interval on a long-running process and creating concurrent executions that contend for the same documents.
The scheduler configuration looks simple, so candidates set an interval and move on. They do not reason about execution duration versus interval, or about catch-up behavior after downtime.
What to do instead
Size the interval against realistic run time, use a schedule that prevents concurrent runs of the same process where documents would conflict, confirm the server time zone assumption, and decide explicitly whether missed runs should be skipped or caught up. Verify by observing two cycles in the schedule log.
Troubleshooting only at the business process level: reading the process status, seeing 'completed', and concluding success, without checking the document's mailbox state, the adapter log, or the translation report.
A process can complete while a document is left in an unexpected state, an acknowledgment was never sent, or an adapter logged a warning. Candidates stop at the first green indicator.
What to do instead
Adopt a layered troubleshooting routine: process status, then document/mailbox state, then the specific service's log or report, then the adapter or partner-side evidence. For each failure, state which layer revealed the cause before proposing a fix.
Treating performance and maintenance as after-the-fact: ignoring purge/archive of old documents and logs, and never tuning queue or thread settings, then misdiagnosing slow throughput as a network problem.
These topics are less hands-on during a first implementation, so candidates skip them and answer from intuition. Accumulated data and default concurrency settings are common real causes of degradation.
What to do instead
Know the maintenance levers: document and log purge/archive policies, database growth, and the tunable concurrency/queue settings. When given a slow-throughput scenario, check data accumulation and configuration limits before blaming the adapter or network.