.png)
OpenText Business Network Integration Guide
Connect OpenText Business Network with enterprise applications through REST APIs, asynchronous document exchange, partner endpoints, files, and transaction workflows.
OpenText Business Network integration options at a glance
OpenText Business Network supports REST APIs for selected Trading Grid and Business Network capabilities, including document submission, retrieval, transaction status, and partner or exchange information. File and business-document exchange is central to the platform and may use EDI, XML, JSON, CSV, PDF, or partner-approved formats, depending on service and configuration. Processing is often asynchronous, while callbacks or event notifications are service-specific and should not be assumed for every lifecycle event. Martini can consume documented APIs, transform structured documents, submit files, poll status with stored watermarks, expose authenticated callback APIs, and coordinate retries, reconciliation, and partner-specific rules.
| Integration point | Supported by OpenText Business Network? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Selected Business Network and Trading Grid capabilities may include document submission, retrieval, transaction status, and partner or exchange queries. Availability varies by product, tenant, region, and contract. | Martini can consume documented OpenText REST APIs, configure authentication, map responses, and orchestrate downstream workflows. |
| Bulk, asynchronous, and batch processing | Limited | Business Network exchanges are commonly asynchronous, with documents moving through acceptance, validation, routing, delivery, acknowledgement, or rejection states. Exact bulk operations depend on the selected service. | Martini can implement controlled batching, queues, scheduled reconciliation, retry limits, and state tracking when a dedicated bulk endpoint is unavailable. |
| File and attachment APIs | Yes | Business-document exchange may involve EDI, XML, JSON, CSV, PDF, or other partner-approved files and transfer methods. | Martini can retrieve, submit, validate, transform, and route structured or file-based content, subject to the OpenText endpoint and partner agreement. |
| Webhooks and outbound callbacks | Limited | Callbacks or event notifications may be available for selected services and transaction events, but coverage is not universal. | Where documented, Martini can expose an authenticated API to receive notifications and then retrieve complete transaction details. Otherwise it can poll incrementally. |
| Authentication | Yes | Protected APIs may use OAuth-based authorization, client credentials, application keys, scopes, and authorization headers. Document exchange may additionally require partner, endpoint, protocol, or certificate credentials. | Martini can store credentials and certificates as environment secrets and apply the required authentication configuration to API and document workflows. |
| SOAP APIs | Legacy | Legacy OpenText or GXS services may expose web-service interfaces, but a current universal SOAP interface for Business Network capabilities was not confirmed. | Martini can consume a documented SOAP service when the customer’s provisioned OpenText environment still requires it. |
| Database and analytics access | Not confirmed | Direct access to OpenText-managed Business Network storage was not confirmed; APIs, exports, reporting interfaces, or managed files should be used instead. | Martini can connect to customer-owned staging or audit databases, but should not presume direct JDBC access to OpenText-managed data. |
How OpenText Business Network exposes data and business events
OpenText REST APIs
OpenText provides REST APIs for selected Business Network and Trading Grid capabilities. Depending on the service and tenant, these APIs may support document submission, retrieval, transaction status, and partner or exchange information.
Martini implementation pattern
Martini implementation pattern: Martini authenticates against the documented OpenText API, invokes the required resource from a workflow, validates the response, maps business data to internal models, and persists OpenText identifiers for later reconciliation.
Implementation sequence
OpenText asynchronous processing
Business Network exchanges are frequently asynchronous. A submission can be accepted for processing before it is validated, routed, delivered, acknowledged, rejected, or failed.
Martini implementation pattern
Martini implementation pattern: Martini separates submission from status reconciliation, stores a correlation key and watermark, and periodically retrieves status until a terminal state or an operational exception is reached.
Implementation sequence
OpenText files and business documents
File and document exchange is a core Business Network use case. Accepted formats and transfer protocols depend on the selected service, endpoint, and trading-partner agreement.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves files, parses supported structured formats, validates partner-specific requirements, transforms content, and submits or routes the resulting document through the configured OpenText mechanism.
Implementation sequence
OpenText callbacks and notifications
Callback and event-notification coverage is service-specific. OpenText should not be assumed to notify every document or transaction event.
Martini implementation pattern
Martini implementation pattern: where a callback is documented, Martini exposes an authenticated API endpoint, validates the notification, retrieves complete details from OpenText, and invokes the same reconciliation logic used by polling.
Implementation sequence
Legacy OpenText SOAP services
OpenText and legacy GXS products have historically exposed enterprise web services, but a current universal SOAP interface was not confirmed for all Business Network capabilities.
Martini implementation pattern
Martini implementation pattern: when a customer’s provisioned environment requires a documented SOAP service, Martini consumes the WSDL-defined operation, applies the required credentials, transforms XML payloads, and handles service-specific faults separately from business rejections.
Implementation sequence
Common OpenText Business Network integration patterns
Pattern 1: Exchange purchase orders and acknowledgements
When to use this pattern
Use this pattern when an ERP or procurement application needs to exchange purchase orders and order acknowledgements with suppliers through OpenText Business Network. The workflow should distinguish accepted submissions from final delivery or acknowledgement and avoid duplicate resubmission after an uncertain timeout.
Integration direction
Example Mapping
| OpenText Business Network Field | Canonical Field | Target Field |
|---|---|---|
| PurchaseOrderNumber | sourceDocumentId | PurchaseOrderNumber |
| SupplierIdentifier | tradingPartnerId | PartnerIdentifier |
| OrderLineItems | lines | PurchaseOrderLines |
| AcknowledgementStatus | exchangeStatus | OrderAcknowledgementStatus |
Martini implementation pattern
Martini retrieves or receives the purchase order, validates supplier and line data, maps the canonical model to the partner-specific EDI or XML structure, and submits it to OpenText. A separate workflow polls or receives a documented notification, correlates the acknowledgement, updates SAP, and routes rejected or delayed exchanges for review.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- scheduled processing
- error handling
Pattern 2: Process supplier invoices
When to use this pattern
Use this pattern when supplier invoices arrive through OpenText and must be validated and posted or staged in an ERP. Validation should cover supplier identity, purchase-order references, tax, currency, totals, and duplicate indicators before the invoice is accepted downstream.
Integration direction
Example Mapping
| OpenText Business Network Field | Canonical Field | Target Field |
|---|---|---|
| InvoiceNumber | supplierInvoiceId | InvoiceNumber |
| TradingPartnerIdentifier | supplierId | SupplierNumber |
| PurchaseOrderReference | purchaseOrderId | PurchaseOrderNumber |
| InvoiceTotal | grossAmount | InvoiceAmount |
Martini implementation pattern
Martini retrieves newly received invoices or processes a documented notification, parses the supported document format, validates business rules, and maps the invoice to the ERP model. It stores the OpenText transaction identifier, rejects or quarantines invalid documents, and retries only transient API or transport failures.
Martini capabilities used
- API consumption
- file processing
- data mapping
- validation
- business rules
- retry handling
Pattern 3: Synchronize shipments and advance shipping notices
When to use this pattern
Use this pattern when warehouse, logistics, or ERP systems must send shipment information and advance shipping notices through OpenText. It is useful when partner-specific versions, units, dates, identifiers, and acknowledgement requirements differ.
Integration direction
Example Mapping
| OpenText Business Network Field | Canonical Field | Target Field |
|---|---|---|
| ShipmentNumber | shipmentId | ShipmentIdentifier |
| OrderNumber | orderId | PurchaseOrderReference |
| ShipDate | shipmentDate | ShipDate |
| PackageLines | packages | ShipmentLines |
Martini implementation pattern
Martini receives shipment data, applies partner and document-version rules, converts dates, units, identifiers, and package lines, and submits the agreed advance shipping notice format. It records the OpenText transaction, reconciles acknowledgement or rejection, and sends operational exceptions to the responsible team.
Martini capabilities used
- workflows
- data mapping
- transformation
- business rules
- API consumption
- monitoring
Pattern 4: Reconcile transactions and exceptions
When to use this pattern
Use this pattern when the organization needs reliable monitoring of submitted, delivered, acknowledged, rejected, delayed, or failed documents. It is particularly useful where callbacks are unavailable or incomplete and status must be polled.
Integration direction
Example Mapping
| OpenText Business Network Field | Canonical Field | Target Field |
|---|---|---|
| TransactionIdentifier | externalTransactionId | CorrelationID |
| TransactionStatus | processingStatus | State |
| TradingPartnerIdentifier | partnerId | ConfigurationItem |
| ErrorMessage | failureReason | Description |
Martini implementation pattern
A scheduled Martini workflow retrieves incremental transaction statuses using a stored watermark and deterministic identifier, classifies transport versus business failures, and updates an audit ledger. It creates a deduplicated ServiceNow incident for non-retryable exceptions and retries eligible transient failures with bounded backoff.
Martini capabilities used
- scheduled workflows
- API consumption
- incremental retrieval
- correlation
- business rules
- error handling
Applications commonly integrated with OpenText Business Network
OpenText Business Network commonly sits between enterprise applications and external trading partners. The following are practical integration targets based on its B2B document-exchange role; exact document coverage depends on the customer’s applications, partner agreements, and provisioned OpenText services.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Exchange purchase orders, invoices, shipment notices, acknowledgements, and related transaction statuses with suppliers and customers. | SAP S/4HANA → Martini → OpenText Business Network | Martini consumes or receives SAP business documents, maps them to canonical and partner-specific EDI or XML structures, submits them through documented OpenText endpoints, and reconciles asynchronous transaction statuses back to SAP. |
| Oracle Fusion Cloud Applications | Synchronize procurement, order management, invoicing, fulfillment, and partner transaction information. | Oracle Fusion Cloud Applications → Martini → OpenText Business Network | A Martini workflow retrieves outbound documents from Oracle, validates partner and document rules, transforms the payload for OpenText, and writes acknowledgement or exception status back to Oracle. |
| NetSuite | Exchange sales orders, purchase orders, invoices, item receipts, and fulfillment information with trading partners. | NetSuite → Martini → OpenText Business Network | Martini orchestrates scheduled or API-triggered retrieval from NetSuite, applies partner-specific mappings and code conversions, submits documents to OpenText, and stores transaction identifiers for reconciliation. |
| Salesforce | Coordinate customer, account, order, and service-related transaction data with B2B exchanges where the Salesforce implementation requires it. | Salesforce → Martini → OpenText Business Network | Martini exposes or consumes APIs for Salesforce, normalizes relevant objects, applies document eligibility rules, and routes approved messages to OpenText while returning delivery or rejection outcomes. |
| ServiceNow | Create incidents or operational tasks for failed documents, partner errors, delayed transactions, and onboarding exceptions. | OpenText Business Network → Martini → ServiceNow | Martini polls or receives documented OpenText status notifications, correlates errors to trading partners and source documents, and creates ServiceNow incidents with controlled deduplication and escalation rules. |
| Workday | Exchange supplier, procurement, invoice, or other business documents where the customer’s Workday processes require it. | Workday → Martini → OpenText Business Network | Martini retrieves approved Workday payloads, validates required partner and document fields, transforms them into the configured OpenText format, and records acknowledgements for operational reporting. |
| Microsoft Dynamics 365 | Synchronize sales, purchasing, inventory, shipment, and invoice documents with trading partners. | Microsoft Dynamics 365 → Martini → OpenText Business Network | A Martini workflow maps Dynamics 365 documents into a canonical model and partner-specific format, submits them asynchronously, and performs status polling with retry and duplicate controls. |
| Jira | Create technical or partner-onboarding issues from transaction failures and route resolution status to operations. | OpenText Business Network → Martini → Jira | Martini classifies OpenText errors, suppresses duplicate issue creation using correlation keys, creates Jira issues for non-transient exceptions, and can update issue context when reconciliation changes the transaction state. |
How to build a OpenText Business Network integration in Martini
Objective
Confirm the exact OpenText Business Network service, tenant, API product, endpoint, partner configuration, and required credentials before implementation.
Instructions in Martini
- Register or obtain the required OpenText application credentials.
- Configure OAuth or other documented API authentication.
- Store client secrets, keys, partner credentials, and certificates as Martini environment secrets.
- Separate test and production endpoints and credentials.
Objective
Select an event-driven, API-led, file-based, or scheduled trigger based on the capabilities enabled in the OpenText environment.
Instructions in Martini
- Use a documented callback when the required event coverage exists.
- Use a Martini API for application-led submissions.
- Use a scheduler for status polling and incremental retrieval when callbacks are unavailable.
- Use a file or document trigger when the integration is configured around managed exchange.
Objective
Receive or retrieve the business document and establish stable source and OpenText correlation identifiers.
Instructions in Martini
- Retrieve the document or transaction details through the documented OpenText API.
- Capture source document IDs, partner IDs, document types, and transaction identifiers.
- Persist a watermark, page token, offset, or last processed identifier for incremental retrieval.
- Do not assume an unknown submission response means the document was rejected.
Objective
Coordinate document preparation, OpenText exchange, downstream updates, reconciliation, and exception handling in maintainable Martini workflows.
Instructions in Martini
- Separate document submission from asynchronous status reconciliation where required.
- Route documents using trading-partner and document-type rules.
- Use reusable workflow logic for correlation, status updates, and exception classification.
- Apply controlled concurrency and bounded retry behavior.
Objective
Convert partner-specific EDI, XML, JSON, CSV, PDF, or other agreed content into canonical and target-system models.
Instructions in Martini
- Validate document versions, identifiers, required fields, control numbers, dates, units, currency, and tax data.
- Keep partner-specific mappings separate from canonical models where practical.
- Transform payloads for the target ERP, operations system, or OpenText endpoint.
- Preserve source and target correlation values for reconciliation.
Objective
Ensure only valid and eligible documents are submitted or posted, while distinguishing transient technical failures from business rejections.
Instructions in Martini
- Check supplier, customer, partner, purchase-order, amount, and duplicate rules.
- Quarantine schema or business-rule failures rather than retrying them indefinitely.
- Use stable identifiers and a processing ledger to prevent duplicate submissions.
- Apply partner-specific acknowledgement and routing requirements.
Common OpenText Business Network data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Trading Partners | Represent organizations and counterparties that exchange documents through the network. | SAP S/4HANA, Oracle Fusion Cloud Applications, NetSuite, Microsoft Dynamics 365 | Martini maps partner identifiers, validates routing rules, and stores partner context with each workflow transaction. |
| Business Documents | Carry purchase orders, invoices, shipment notices, order acknowledgements, functional acknowledgements, and other structured messages. | ERP, procurement, warehouse, logistics, and finance applications | Martini parses, validates, transforms, and routes EDI, XML, JSON, CSV, PDF, or other supported content according to partner rules. |
| Transactions | Track submitted, received, delivered, rejected, or failed document exchanges. | ERP, ServiceNow, Jira, audit databases, monitoring platforms | Martini persists OpenText identifiers and statuses, performs reconciliation, applies retry rules, and correlates failures to source documents. |
| Connections or Endpoints | Define communication endpoints and protocols used to exchange documents with trading partners. | B2B gateways, ERP platforms, managed file services, partner systems | Martini uses the configured endpoint or protocol through documented APIs or file-exchange mechanisms and keeps environment-specific credentials in secrets. |
| Maps and Transformations | Convert partner-specific documents into canonical or destination-specific formats. | ERP, procurement, logistics, finance, and partner applications | Martini implements reusable mappings, validations, code conversions, and partner-specific business rules in workflows. |
| Communities or Partner Networks | Group organizations, relationships, document types, and exchange rules within a network structure. | Partner-management processes, ERP, procurement, operations applications | Martini uses community and relationship context to select mappings, routing decisions, validation rules, and exception paths. |
Authentication and security considerations
Authentication depends on the OpenText service
Protected OpenText developer APIs may use OAuth 2.0, client credentials, application keys, scopes, and HTTP authorization headers. Document exchange can additionally require trading-partner, endpoint, protocol, certificate, signing, or encryption credentials.
Protect credentials and certificates
- Store OAuth secrets, API keys, partner credentials, and certificates in Martini environment secrets.
- Use separate test and production credentials and endpoints.
- Apply least-privilege API permissions and service-account access.
- Plan certificate renewal, key rotation, TLS validation, and document-content redaction in logs.
Operational considerations for OpenText Business Network integrations
Plan for tenant and service variation
Confirm the exact OpenText Business Network product, tenant, region, API resources, document catalogue, partner configuration, and protocol requirements. API availability and resource names can vary by service and contract.
Control asynchronous processing
- Separate accepted-for-processing from delivered, acknowledged, rejected, or failed states.
- Use controlled concurrency, bounded retries, exponential backoff, and exception or dead-letter handling.
- Persist page tokens, timestamps, transaction identifiers, and deterministic secondary keys for incremental retrieval.
- Use stable source identifiers, OpenText transaction IDs, hashes, and a processing ledger to prevent duplicates.
Test and monitor document flows
Version partner mappings and API definitions, test representative documents, and preserve correlation data across Martini, OpenText, and source applications. Monitor rate limits, schema changes, routing errors, certificate expiry, processing delays, and business rejections.
Why use Martini instead of scripts or point-to-point integrations?
Coordinate the complete exchange lifecycle
Point-to-point scripts often combine authentication, document transformation, submission, polling, retries, and exception handling in fragile code. Martini separates these concerns into reusable workflows and APIs.
Support partner-specific variation
Martini can maintain canonical models alongside partner-specific mappings, validations, code conversions, routing rules, and document formats. This reduces duplication as communities and trading partners change.
Improve operational control
- Use scheduled and event-driven workflows for submission and reconciliation.
- Persist correlation identifiers and status history for auditability.
- Apply differentiated retry and exception rules for technical and business failures.
- Expose controlled APIs for internal applications without coupling them directly to OpenText service variation.
Frequently asked questions
OpenText Business Network can be integrated through documented REST APIs, asynchronous business-document exchange, managed files, partner endpoints, and selected callbacks or notifications. Depending on the service, documents may use EDI, XML, JSON, CSV, PDF, or other agreed formats. Scheduled polling is an alternative when callbacks are unavailable.
Yes. Martini can consume documented OpenText REST APIs, process and transform business documents, submit or retrieve files, receive documented callbacks, expose APIs for internal applications, and orchestrate polling, reconciliation, retries, and downstream updates. A native Martini connector was not confirmed and is not required.
No. A dedicated OpenText Business Network connector is not required when the necessary OpenText API, file-exchange mechanism, or configured partner endpoint is available. Martini can use the confirmed native integration mechanisms and standards-based protocols.
Lonti does not charge an additional per-connector or per-vendor fee to integrate OpenText Business Network. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from OpenText, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs are the primary method for documented API capabilities such as document submission, retrieval, and transaction status. File and business-document exchange is central to the platform. Asynchronous or batch processing should use the specific capabilities documented for the provisioned service. Legacy SOAP may be relevant only where a customer environment still exposes a documented service.
Callbacks and event notifications are service-specific and should not be assumed for every document or transaction event. Where documented, Martini can receive an authenticated callback and retrieve complete details. Otherwise, Martini can poll transaction or document status using a stored watermark or correlation identifier.
Synchronization commonly combines API-led document submission or retrieval with scheduled status reconciliation. Martini stores source IDs, OpenText transaction identifiers, partner identifiers, timestamps, and status watermarks, then maps terminal or intermediate states back to ERP, operations, or service-management applications.
Martini can maintain canonical and partner-specific mappings, validate business and document rules, and distinguish transport failures from authentication errors, schema failures, routing problems, and business rejections. Bounded retries with backoff are appropriate for transient failures, while stable source identifiers, correlation keys, and a processing ledger help prevent duplicates.
Related Martini documentation
Workflows
Transformation
Connect OpenText Business Network with Martini
Use Martini to build maintainable OpenText Business Network integrations for document exchange, partner synchronization, transaction reconciliation, and exception handling.