IBM Sterling B2B Integrator (C8060-218) cheat sheet

Sterling B2B Integrator runs as a Java application on a J2EE servlet container (WebSphere or JBoss depending on release); the core engine, adapters, and services execute inside that container.

Key install-time components: the application server, a supported JDK, a database (DB2, Oracle, or SQL Server), and a shared file system directory for documents and configuration.

The perimeter server (formerly called the perimeter) is a separate process that fronts inbound/outbound network traffic; adapters can run inside the JVM or be offloaded to perimeter servers for isolation and scale.

Cluster topology: a node is one JVM instance; multiple nodes share one database and one shared file system. Session affinity is required at the HTTP load balancer so a user stays on one node.

The database stores business process definitions, schedules, system properties, and transaction state; the file system stores large payloads and adapter artifacts. Both must be backed up consistently.

Install order: database and schema creation, then application server, then the product installer (GUI or silent response file), then configuration/deployment of the EAR, then property tuning.

System properties (Customer_overrides.properties and the admin console) control adapter behavior, timeouts, and thread pools; overrides in customer_overrides take precedence over shipped properties.

Version upgrades require a supported source-to-target path; check the upgrade matrix and run the database schema upgrade scripts before deploying the new EAR.

A business process (BP) is an XML document composed of services; the Graphical Process Modeler (GPM) is an Eclipse-based editor that renders and edits that XML.

Core service types: business process services (BPML), adapters (FTP, File System, AS2, MQ, HTTP), translation services, and utility services (assign, choice, onFault, wait, timer).

The BPML element has a name and a start flag; only one BP can be marked as the starting process for an execution context.

Data flows through the process context as primary documents and named documents; XPath expressions address them, e.g. /ProcessData/PrimaryDocument or a named document by ID.

provides branching on XPath conditions; catches exceptions from any child service and exposes error details for recovery or notification.

The service sets context variables and can copy, concatenate, or transform values using XPath and XSLT-style expressions.

Service configuration is stored as elements; on the GPM canvas each service node exposes typed parameters (host, port, directory, document ID).

Business processes can be invoked directly from the admin console, from a schedule, from a service (BP invocation), or from an inbound adapter triggering a named process.

A trading partner profile holds identifiers (DUNS, EDI ID/qualifier, AS2 ID, email) and is linked to a partner group; the group supplies defaults such as envelope and communication settings.

Envelope and translation are configured per partner: inbound/outbound EDI envelopes, delimiters, version, and the translation map used for that partner.

Onboarding sequence: create partner profile, assign to a partner group, configure delivery channel (FTP/SFTP/AS2), configure EDI envelope and translation, then test with a sample interchange.

Partner groups inherit settings to members; overrides at the partner level take precedence over group-level defaults for envelope and communication parameters.

AS2 partner configuration requires the partner's AS2 ID, URL, signing/encryption certificates, and MDN (receipt) settings; both sides must agree on signing and encryption algorithms.

The trading partner agreement (TPA) or partner configuration binds inbound identification (e.g. ISA sender ID) to a specific partner and business process.

Use the partner setup wizard or admin console to validate; a common failure is a mismatch between the ISA qualifier/ID and the configured partner identifier.

Translation converts between EDI and XML (or flat file) using maps; the map defines source-to-target field mappings and is executed by the translation service in a BP.

EDI envelope layers: interchange (ISA/IEA), functional group (GS/GE), and transaction set (ST/SE). Enveloping services add or strip these layers.

ISA defines delimiters (element separator, segment terminator, sub-element separator) and the repetition separator in ISA11 for versions 00401 and later.

The ISA control number and GS/ST control numbers must be unique per partner and per interchange; duplicate control numbers are a frequent source of rejected interchanges.

Translation map types include EDI-to-XML, XML-to-EDI, flat file-to-XML, and positional/delimited flat file maps; map selection is configured per partner and document type.

Validation levels: envelope validation (structure and control numbers), map validation (field-level rules), and business validation (codes and cross-field rules) can each be enabled or bypassed.

Functional acknowledgment (997/999) generation is configured per partner; the 999 carries implementation-level acceptance/rejection detail for HIPAA and similar sets.

XML translation uses XSLT or the product's map editor; namespaces in source XML must be declared in the map or XPath selection fails.

FTP adapter uses host, port, user, password, and directory; passive mode is required when the client sits behind a firewall that blocks inbound data connections.

SFTP adapter uses SSH, key-based or password authentication, and a known-hosts check; the host key must be trusted or the connection is refused.

AS2 adapter sends over HTTP(S) with signing and/or encryption, requests a synchronous or asynchronous MDN, and supports retry with duplicate-message detection via Message-ID.

HTTP adapter supports GET/POST, proxy settings, SSL, and configurable timeouts; response codes outside the expected set raise a fault in the BP.

MQ adapter connects to IBM MQ queue managers using queue name, channel, host, port, and credentials; it can get, put, or browse messages and supports transactional get.

File System adapter reads/writes local or mounted directories; polling intervals and file-name patterns control which files are picked up, and duplicate pickup is avoided by rename or delete.

Adapter retry and timeout settings are per adapter instance; a failed send typically raises an exception caught by in the BP for retry or alerting.

Outbound adapters are often offloaded to perimeter servers so network I/O does not consume the core engine's threads.

Users are assigned to groups (roles); permissions on services, business processes, and admin functions are granted through group membership, not directly to users.

Key stores and trust stores hold private keys/certificates and trusted CA certificates respectively; SSL and AS2 signing/encryption reference these stores by name.

Certificate validity, key usage, and the full chain to a trusted CA must be verified; an expired or untrusted certificate causes handshake or signature failures.

AS2 signing uses the sender's private key and the receiver verifies with the sender's public certificate; encryption uses the receiver's public certificate and the receiver decrypts with its private key.

Password and key-store policies (length, expiry, lockout) are configurable system properties; enforce them for compliance audits.

Audit logging records administrative changes and user actions; enable it and retain logs per your compliance requirement.

Use the certificate manager to import, export, and view certificates and to check expiration; rotate certificates before expiry to avoid outages.

Schedules are defined in the admin console with a start time, recurrence (once, interval, cron-like), and the BP to invoke; a schedule can be enabled or disabled without deletion.

The process monitor shows running, completed, and failed BP instances with status, start time, and duration; drill into an instance to see each service's input/output.

Troubleshooting order: check the BP instance status, then the failing service's error message, then adapter logs, then the database or file system for the payload.

Common faults: connection refused/timeout (adapter), document not found (wrong document ID or XPath), map error (field mismatch), and duplicate control number (envelope).

Use the document viewer to inspect primary and named documents at each step; enable debug logging for a specific service or adapter to capture detail.

Failed instances can be resubmitted or terminated from the monitor; terminate only when the instance is stuck, since it leaves partial state.

Alerts and notifications can be configured on BP faults or schedule failures so operations staff are notified without manual polling.

Tune thread pools and adapter concurrency against database connection pool size; a common bottleneck is too few DB connections relative to BP concurrency.

Purge old BP instances and documents on a schedule; unbounded growth of transaction tables and the file system degrades performance and backup time.

Monitor JVM heap, garbage collection, database wait times, and adapter queue depth; heap exhaustion often presents as slow BPs rather than a crash.

The database is the shared state for a cluster; ensure all nodes point to the same schema and that the file system is shared and consistent across nodes.

Back up the database and shared file system together; restoring one without the other leaves orphaned document references.

Apply fix packs through the supported installer; review release notes for schema changes and required property updates before deploying.

Log levels are set per component; raise to debug only temporarily because verbose logging fills disks and slows the engine.

Capacity planning should account for peak EDI volume, document size, and adapter retry storms after partner outages.

The core engine is a J2EE application; the perimeter server is a separate process that handles network I/O in front of the engine.

A cluster shares one database and one shared file system; the HTTP load balancer must use session affinity.

Install order: database schema, application server, product installer, EAR deployment, then property tuning.

System properties can be overridden in customer_overrides.properties, which takes precedence over shipped defaults.

Large payloads live on the shared file system while metadata and process state live in the database; back up both together.

A business process is an XML document of services; the GPM is an Eclipse-based editor for that XML.

branches on XPath conditions and catches exceptions from child services.

Primary and named documents are addressed by XPath such as /ProcessData/PrimaryDocument.

A BP can be started from the admin console, a schedule, a service invocation, or an inbound adapter.

Partner profiles hold identifiers such as DUNS, EDI ID/qualifier, and AS2 ID and are linked to a partner group.

Partner-level settings override group-level defaults for envelope and communication parameters.

AS2 onboarding requires the partner's AS2 ID, URL, certificates, and MDN settings.

Inbound partner identification often matches the ISA sender ID and qualifier to a configured profile.

EDI layers: interchange (ISA/IEA), functional group (GS/GE), and transaction set (ST/SE).

ISA defines element, sub-element, repetition, and segment delimiters for the interchange.

Control numbers must be unique per partner; duplicates cause rejected interchanges.

997/999 acknowledgments are configured per partner; the 999 carries implementation-level detail.

FTP passive mode is required when a firewall blocks inbound data connections.

SFTP requires the host key to be trusted or the connection is refused.

AS2 signs and/or encrypts over HTTP(S) and requests a synchronous or asynchronous MDN.

MQ adapter uses queue name, channel, host, port, and credentials to connect to a queue manager.

Permissions are granted to groups; users inherit access through group membership.

Key stores hold private keys and certificates; trust stores hold trusted CA certificates.

AS2 signing uses the sender's private key; encryption uses the receiver's public certificate.

Check certificate expiry and full chain validity before handshake or signature failures occur.

Schedules define a start time, recurrence, and target BP and can be disabled without deletion.

The process monitor shows running, completed, and failed instances with per-service detail.

Troubleshoot in order: instance status, failing service error, adapter log, then payload location.

Duplicate control numbers and wrong XPath document references are common fault causes.

Match adapter concurrency and BP threads to the database connection pool size.

Purge old process instances and documents on a schedule to control table and disk growth.

Monitor JVM heap, GC, DB waits, and adapter queue depth for performance issues.

Back up the database and shared file system together to avoid orphaned document references.