Table of Contents

Integration Intake: 3PL Dynamics and DataHub

This document describes the information and principles required to prepare a new or adjusted DataHub integration in a structured way. It serves as a guide for customers, partners, and the project team.

See also: DataHub overview.

1. Purpose of This Intake

To deliver integrations in a predictable and controllable way, relevant information must be complete and unambiguous before the project starts. This intake provides the basis for:

  • a realistic view of scope and complexity
  • insight into impact on existing processes and integrations
  • a well-founded plan and lead time
  • identifying technical and functional risks

2. Architecture: DataHub (Required)

All integrations in 3PL Dynamics are built exclusively on DataHub. DataHub connects to the EDI connector in 3PL Dynamics; we support the full configuration.

Point-to-point (direct) connections to the ERP are not supported. If you choose not to use DataHub, the customer is fully responsible for design, build, operation, and monitoring.

A DataHub subscription is required. Pricing is based in part on transaction volume (see the current pricing and product information / appendices in your offer).

2.1 Why This Approach?

DataHub is the central integration layer (ESB). Without it, the risk of fragmentation, tight coupling between systems, and operational disruption increases.

2.2 Guiding Principles

Principle Description
Decoupling Systems do not talk to each other directly, but through DataHub. Change stays local; the impact of changes is contained.
Central orchestration All message flows go through one platform: visibility, control, and a single place for monitoring and error handling.
Reusable patterns Standard patterns (e.g. routing, splitting, conditional processing) speed up delivery and limit custom work.
Transformation outside the ERP Mapping and translation (e.g. JSON, XML, EDIFACT) happen in DataHub so the ERP stays clean and business logic stays separate from integration logic.
Scalability New links and higher volumes can grow without rebuilding existing integrations.
Security and governance Centralized authentication, logging, auditing, and control over data flows.

3. Commercial and Setup Terms

  • Included startup period (per flow): for setting up the connection, mapping, testing, and go-live, Boltrics does not charge separate setup fees for 31 days from the start of each integration flow; this is covered by the DataHub bundle. After that period, any message-specific work is carried out by agreement (e.g. time and materials), as per contract.
  • System and configuration work outside the integration flow: changes to functional or technical configuration in 3PL Dynamics (e.g. new status templates, changes to scan screens) are not covered by the startup period and may be billed separately, depending on project agreements.

If information and test capacity are not provided clearly and on time, planning and the start of delivery may be delayed.

4. Information to Supply

4.1 General Project Context

For every request, at least:

  • customer and project phase (implementation, extension, or change)
  • type of request: new business, new integration, or change
  • functional and technical contacts
  • key users and stakeholders involved

4.2 Integration Scope and Message Flows

  • which messages are inbound to 3PL Dynamics
  • which messages are outbound from 3PL Dynamics

Typical areas: orders, inbound (ASN) and acknowledgments, inventory updates, transport/shipment, and billing. For each flow, specify the role in the process and dependencies (sequencing, upstream/downstream steps, and triggers).

Where available, provide mapping documentation for each message or mapping—often in the form of a MIG (Message Implementation Guide) from the trading partner or a Boltrics template.

4.3 Technical Principlesz

Protocol and connectivity
For example: REST API, SOAP, AS2, SFTP.

Not allowed: FTP (not supported for security reasons).

Authentication
For example: OAuth2, API keys, AS2, client certificates, basic authentication—whatever the chain allows.

Network and security
Any additional requirements, such as IP allowlisting, firewall rules, or VPN, where applicable.

Credentials (must be handled securely)
Never share passwords, tokens, certificates, or keys by email or chat. Use a password vault (e.g. Bitwarden, 1Password) to avoid leaks, keep usage auditable, and manage the lifecycle of secrets. Without correct, secure handover, the integration cannot start.

If the trading partner issues a connection or onboarding specification (naming, endpoints, certificates, AS2 IDs, and so on), include or forward it to the project team.

4.4 Data Characteristics

  • formats: JSON, XML, EDIFACT, CSV, …
  • volume: estimated messages per day per flow

4.5 Functional Context in Boltrics 3PL Dynamics

  • the end-to-end process the integration supports
  • process steps
  • relevant statuses
  • triggers for messages (e.g. status change, manual action)

Describe the real business process in 3PL Dynamics: how an order (or other object) moves through your operation, and which EDI or integration events are triggered at which step or status.

5. Intake Scenarios (What to Clarify)

5.1 New Business (ERP Implementation)

  • is an existing integration being migrated, or is it a greenfield build?
  • are there reference implementations or existing flow documentation?

5.2 New Integration (Existing Customer)

  • does the underlying process already exist in 3PL Dynamics, or does it still need to be set up (e.g. quality checks, picking, packing, cross-dock)?
  • what triggers the integration, and how does it fit with existing flows?

5.3 Change to an Existing Integration

Minimum:

  • customer
  • flow ID
  • message type

In addition:

  • a clear description of the change
  • reason (defect, change, enhancement)
  • preferably a concrete scenario or example (test case)

6. Governance, Monitoring, and Testing

  • Ownership: who is the functional owner, who is the technical owner?
  • Monitoring: who monitors the integration in day-to-day operation?
  • Testing: who supplies test data, who runs SIT, who runs UAT?

7. Preconditions for a Successful Delivery

  • sufficient test capacity and availability during the project phase
  • quick, concrete feedback from the customer and/or partner
  • documentation, examples, and agreements supplied on time

For scenario 1 (new business) and scenario 2 (new integration), we usually begin with a kick-off to align scope, agreements, and planning.

A successful go-live is at risk without enough test capacity and response from the organization, customer, or vendor during implementation; the client works with the supply chain to ensure this.

8. Quick Checklist: Minimum Handover

Use this to verify that nothing is missing (details are in the sections above).

  1. Which (EDI/integration) messages are inbound to the 3PL system?
  2. Which messages are outbound from 3PL Dynamics?
  3. Functional and technical contact (name, email, phone).
  4. Technical contact for the trading partner that sends/receives (company, name, email, phone) where applicable.
  5. Connection and security: protocol (not FTP), authentication, network requirements.
  6. Sample or test messages for validation, and a MIG or other mapping document per flow, if one exists.
  7. Agreement on who performs mapping: customer, partner, Boltrics, or split (document explicitly).
Edit this page