Integration planning and patterns

The core strength of Composable Commerce lies in its flexibility and composability. However, real-world enterprise commerce solutions rarely rely on a single platform. A robust commerce architecture requires seamless integration with a surrounding ecosystem of specialized services like:

• Enterprise resource planning (ERPs): used to centralize and automate back-office commerce processes like inventory, purchasing, accounting, and fulfillment so orders and stock stay in sync across channels.
• Product information management (PIMs): used to maintain, enrich, and distribute consistent, customer-ready product data (texts, images, attributes) to websites, marketplaces, and other sales channels.
• Order management system (OMS): used to capture, route, and track commerce orders across warehouses and carriers, managing inventory allocation, shipping, and returns from a single hub.
• Customer relationship management (CRMs): used to store customer profiles and interaction history so commerce teams can segment audiences, personalize marketing, and support customers more effectively.
• Payment providers: used to securely process online card, wallet, and alternative payments at checkout, handling authorization, settlement, and often fraud checks and Buy Now, Pay Later (BNPL) options.
• Tax engines: used to automate the calculation of the correct sales/VAT tax per jurisdiction at checkout and on invoices, based on customer location and product tax rules.
• Search: used to let shoppers quickly find relevant products on the digital commerce site with features like autocomplete, filters, and ranking tuned for conversions.

Determine what integrations are necessary for your commerce solution early in the planning phase. This will help you choose the right architecture, tools, and patterns to ensure a smooth and efficient integration process.

Plan integrations

Effective data integration in Composable Commerce relies on thorough planning and a detailed understanding of the requirements and technical possibilities. Determine what integrations are required to complete your solution, and for each integration, define:

• The key data domains involved: common integration points are Customer, Order, Pricing, Inventory, Catalog, Taxes, Payment, Search, and Email.
  Each integration point has its own requirements for data mapping, synchronization frequency, latency, and security, which will influence your choice of integration patterns and tools.

  For example, Price and Inventory updates are more frequent and time-critical than updates to core Product information.

• The source of truth or master data version, for each data domain—for example:
  • Customer data can be mastered in a CRM or Composable Commerce.
  • Order data can be mastered in an OMS or ERP.
  • Inventory data can be mastered in a WMS, ERP, or OMS.
  • Pricing and promotions can be mastered in a pricing engine or Composable Commerce.
• The direction of data flow—for example, one-way or bi-directional.
• The frequency and latency requirements—for example, real-time, near-real-time, or batch.
• The volume of data to be transferred.
• The integration points and touchpoints—for example, events, APIs, or webhooks.

Plan data migration

A data migration plan maps out the data types, the source of truth for the data, and what needs to be migrated manually from other systems.

Customer Data

Customer profiles are usually the main focus and take the most amount of effort during data migrations.

A Composable Commerce Customer only requires an email address as a unique identifier upon creation. It is highly recommended to also provide the Customer's addresses; they are used by Composable Commerce to determine shipping costs and taxes.

Product Data

Product data mapping aligns data from your primary sources with Composable Commerce. You should prioritize essential attributes, especially those crucial for search functionalities for specific features:

• Establish a clear mapping strategy for essential attributes.
• Consolidate supplementary information, for instance, as a JSON text attribute.

As a best practice, you should:

• Only transfer essential product data.
• Ensure structure compatibility.
• Consider that a 1-to-1 relationship between Product types across systems may not be necessary.

Order Data

Order management is essential for commerce applications. Composable Commerce focuses on capturing Orders, which are then typically passed on to other systems, like the OMS or ERP, for further handling.

The Order Master Record generally lives in a downstream system from Composable Commerce; typically, the downstream system is either an OMS or ERP. These systems are designed to be a centralized system for orders coming from all channels and provides robust reporting mechanisms.

For organizations without an OMS or ERP, Composable Commerce can be the source of truth for Orders.

Inventory Data

Inventory generally comes from the system that has the Order Master Record. This is due to the fact that orders directly influence inventory, therefore a close relationship between them is important.

To avoid overselling items, it is recommended to establish threshold levels for Inventory tracked with Composable Commerce. This allows the Inventory to become depleted in Composable Commerce without making a call to the master inventory for each Order. Once the threshold is reached, Composable Commerce can make real-time calls to the master inventory to confirm stock availability before Orders are created.

Tax, Payment, and Search data

• Tax: If you do business in the United States and Canada, it is recommended to integrate a third-party tax calculation service to comply with the highly complex tax regulations.
• Payment: As Composable Commerce only tracks the status of Payments, you must integrate an external payment service provider to offer payment methods for your customers.
• Search: If you have an external search service in place for product discovery, you can integrate it with Composable Commerce to provide consolidated catalog data.

You don't need to manually migrate types of data where the source of truth is not Composable Commerce—for example, if you have a PIM, you can use an integration with Composable Commerce to sync the Product data initially. The same goes for other integration points like Orders, Inventory, and Pricing.

Separate initial migration from ongoing integrations

Initial data migration and ongoing synchronization often use different approaches.

Initial migration

As a best practice, migrate only active or relevant records—for example, Products that are live or planned to be sold, or Orders still within a return or warranty period.

At this stage, it is important to cleanse your data (especially Customer records), align data mapping to Composable Commerce's model, and avoid redundant or historical attributes.

Ongoing integrations

Ongoing integrations should focus on delta changes, such as new or updated records. This minimizes data transfer and processing load in scenarios such as Customer updates, Product catalog updates, Orders creation or updates, Inventory changes, or Price changes.

At this stage, it is important to choose integration patterns and options (tools) that support your required latency, volume, and frequency.

Integration patterns

Integration patterns provide standardized architectural blueprints for connecting different systems and data sources based on business and technical requirements. When selecting a pattern, consider factors like volume, frequency, required latency, and business tolerance for temporary non-synchronized state.

Batch processing

Batch processing involves transferring bulk data at scheduled intervals. This pattern is suitable for scenarios where real-time synchronization is not critical, such as:

• Nightly product catalog syncs from a PIM or ERP.
• Bulk price updates for seasonal campaigns.
• Regular inventory snapshots from a WMS.

For example, a retailer might use batch processing to update thousands of product listings overnight, ensuring the storefront is refreshed without impacting the customer experience during peak hours.

Broadcasting events

Changes from Composable Commerce are sent as messages to multiple subscribers, enabling event-driven workflows. This pattern is ideal for scenarios requiring near-real-time updates, such as:

• When an Order is created (OrderCreated event), trigger a shipment creation in the OMS, an inventory decrement in ERP/WMS, and send an order confirmation email via a marketing platform.
• When a Customer registers (CustomerCreated event), create a profile in the CRM.
• When a Product is published (ProductPublished event), update search indexes and recommendation engines.

Aggregation

Aggregation involves collecting data from multiple sources into a single system for unified processing or analysis. This pattern is useful for scenarios like managing multiple sources of product information when creating a Product in Composable Commerce.

You can achieve this pattern through two approaches:

• (Recommended) A single integration that consolidates the resource data, such as Product, from all sources. The consolidation is done at the integration level.
• Multiple integrations with each providing different pieces of the resource information.

Bi-directional syncs

Bi-directional syncs constantly keep two sources of data updated with each other's information. This pattern is generally discouraged due to the risk of data conflicts and increased complexity—for example, synchronizing customer data between Composable Commerce and an external CRM in both directions could lead to conflicting updates if not managed carefully.

For cases where the source of truth might be split between several systems (for example, Composable Commerce is the source of truth for specific attributes while an external system is the source of truth for others), a bi-directional integration might be required. If those situations can't be avoided, a careful synchronization of the integration processes is required.

Real-time data transfer

Real-time data transfer involves immediate propagation of changes from one system to another using an active connection between the two points to make data accessible—for example, direct database replication. This integration pattern is not supported by Composable Commerce. Real-time interactions should be handled via the HTTP API.

Key takeaways

• Plan integrations early by identifying data domains, sources of truth, data flow direction, latency requirements, and volume expectations.
• Migrate only essential data during initial migration and cleanse Customer records before transfer.
• Use gradual migration strategies for Customer passwords and leverage the externalId field for external system references.
• Separate initial migration from ongoing integrations as they often require different approaches and tools.
• Choose integration patterns based on volume, frequency, latency requirements, and business tolerance for temporary data inconsistency.
• Batch processing works well for non-critical bulk updates, while broadcasting events supports near-real-time reactive workflows.
• Set external data attributes as read-only in Composable Commerce and consolidate data at the integration level when using aggregation patterns.
• Avoid bi-directional syncs whenever possible due to increased complexity and conflict risks.

Test your knowledge