IBM Sterling B2B Integrator (C8060-218) key terms

A Sterling B2B Integrator workflow defined in XML that chains services, adapters, and decisions to move or transform data. It is the unit that the process engine executes, schedules, and monitors.

The Eclipse-based desktop tool used to draw, validate, and deploy business processes. It presents services as nodes on a canvas, supports on-failure links, and produces the BPML that the engine runs.

The XML dialect in which Sterling B2B Integrator business processes are stored and exchanged. Understanding its element structure helps troubleshoot processes that fail to deploy or behave differently than the model suggests.

A reusable processing step inside a business process, such as a translation, a document extraction, or a database query. Each service has configurable parameters and can be reused across many processes.

A link in a business process that runs only when the preceding service raises an error. It typically logs the exception, sends notification, or routes the document to an error queue for later reprocessing.

The runtime component that instantiates and executes business processes, tracks instance state, persists it to the database, and resumes work after a restart. It also enforces timeouts and concurrency limits on running instances.

A configurable connector that lets a business process talk to an external system or protocol, such as FTP, SFTP, AS2, HTTP, MQ, or the local file system. Adapters are configured once and referenced by name in processes.

The named set of connection settings (host, port, credentials, security options, retry behavior) that an adapter uses at runtime. Multiple business processes can share one configuration, and changes apply without redeploying processes.

An adapter that transfers files over SSH, supporting key-based or password authentication, known-host verification, and remote directory operations. It is preferred over plain FTP where confidentiality and integrity of exchanged files matter.

An adapter that performs file transfers over the FTP protocol, including passive mode, remote listing, get, and put operations. Because FTP sends credentials in clear text, many partners require FTPS or SFTP instead.

An HTTP-based protocol for exchanging EDI with trading partners using signed and encrypted MIME payloads plus Message Disposition Notifications. It provides non-repudiation through receipts and is configured per partner with certificates and URLs.

The receipt returned by an AS2 receiver confirming that a message arrived and, if requested, that its signature and decryption succeeded. MDNs can be synchronous or asynchronous and are essential evidence for non-repudiation.

A record representing an external organization you exchange documents with, holding identifiers, contacts, and links to agreements. Partners are onboarded once and then referenced by agreements, envelopes, and delivery channels.

A configuration object that binds a partner to specific business processes, delivery channels, and document formats. It determines which inbound documents are accepted and how outbound documents are enveloped and routed.

The end-to-end process of bringing a new trading partner live: collecting identifiers and certificates, creating partner and agreement records, building or selecting maps, testing with sample documents, and moving to production.

A named inbound endpoint that combines a listening adapter, a document format, and the business process to invoke. It is the entry point that decides how received data is picked up and which process handles it.

A mapping definition that converts data between formats, such as X12 to XML or a flat file to a database layout. Maps define source-to-target field rules, loops, and default values used during translation.

The tool used to build and test translation maps, linking source and target structures, defining extended rules, and validating output against sample input. It also supports linking to code lists and cross-reference tables.

Electronic Data Interchange: the structured, standards-based exchange of business documents such as purchase orders and invoices between trading partners. In this product it is typically X12 or EDIFACT carried inside envelopes and processed by translation maps.

The control structure wrapping EDI documents: interchange, group, and transaction set headers and trailers that carry sender, receiver, control numbers, and counts. Correct envelopes are required for partners to accept and acknowledge documents.

The ANSI ASC X12 family of EDI standards used mainly in North America, organized into transaction sets such as 850 purchase orders and 810 invoices. Documents are wrapped in ISA/IEA interchange and GS/GE group envelopes.

The United Nations EDI standard widely used outside North America, with messages such as ORDERS and INVOIC wrapped in UNB/UNZ interchange and UNG/UNE group envelopes. Its syntax and segment naming differ from X12.

An X12 transaction set that reports acceptance or rejection of a received interchange, group, or transaction set, including error codes. Partners often require it within a defined window after receipt.

A short X12 segment-level acknowledgment confirming receipt of an interchange and reporting whether its control structure was accepted. It addresses envelope-level errors rather than the content of individual transaction sets.

The EDIFACT message used to acknowledge receipt and report syntax errors for an interchange, group, or message. It plays the role that the 997 plays in X12.

A lookup table that maps a partner's codes to your internal values, such as part numbers or unit-of-measure codes. Maps consult these tables during translation so partner-specific values resolve correctly.

An X.509 credential containing a public key, identity information, validity dates, and a CA signature. It is used for signing, encryption, and TLS in partner communications and must be trusted by both sides.

An entity that issues and signs digital certificates, either publicly trusted or internal to an organization. Partners must trust the issuing CA chain for certificate-based signing and TLS handshakes to succeed.

The repository of trusted CA certificates and partner certificates used when validating signatures and TLS connections. Missing or expired entries are a common cause of handshake and signature-verification failures.

The protected repository holding private keys and the certificates that pair with them, used when signing or decrypting data. Access is controlled so that private key material is never exposed to unauthorized users.

A cryptographic value computed over a document with a private key so a receiver can verify origin and integrity. In EDI exchange it underpins non-repudiation, especially when paired with signed receipts.

A public and private key combination used for SFTP authentication in place of a password. The public key is installed on the remote server and the private key is held securely by the client configuration.

An individual login plus the role-like group that grants it access to specific menus, services, and administrative functions. Assigning the minimum group needed follows least-privilege practice and limits operational risk.

The model in which permissions are attached to groups rather than to individual users, and users inherit them by membership. It simplifies administration and auditing when staff change responsibilities.

The administrative console for the platform, where you manage users, adapters, certificates, schedules, and system health. It is also where you inspect running processes, logs, and queue depth during troubleshooting.

A time-based trigger that starts a business process on a defined interval or calendar, such as polling a mailbox every five minutes. Schedules can be enabled, paused, and monitored from the administrative console.

The design pattern of catching errors in a process, recording context, and routing work to retry or manual review instead of losing it. Good handling keeps failed documents visible and recoverable.

Re-running a failed process or document after correcting the cause, such as a bad map, an expired certificate, or an unreachable partner. The platform retains the original payload so reprocessing does not require the sender to resend.

The scheduled cleanup of old process instances, documents, and logs to control database growth, with retention rules that preserve what audit or legal requirements demand. Tuning purge intervals is a routine performance task.

Adjusting process concurrency, adapter timeouts, database indexes, and purge settings so throughput and response times meet service levels. It usually starts with measuring queue depth and identifying the slowest service in a process.