Compare Integration Interfaces and Data Patterns
Learning Objectives
After completing this unit, you’ll be able to:
- List the interfaces you can use for integration.
- Explain how you can push or pull data.
- Explain the need for real-time versus batch integration.
Integration Interfaces
B2C Commerce connects to payment processors, analytics platforms, social advertising networks, and inventory services. Before you build an integration, you need to identify which interface to use, which side initiates the data transfer, and how quickly data flows.
B2C Commerce provides seven interface types. Each suits a different kind of external system.
REST APIs: Makes HTTP calls to external endpoints and uses cartridge code to process responses. For example, Apple Pay PSP API for authorization, Facebook Conversions API for shopper events, and Google Merchant API via service records.
LINK cartridges: Provides self-contained integration units on the cartridge path isolated from app_storefront_base. For example, Apple Pay LINK cartridges, as well as int_google and int_socialfeeds for Google Channels feeds.
Client-side JavaScript and ISML tags: Runs logic in the shopper’s browser. For example, the Facebook Pixel for tracking events, and the Apple Pay button via the <isapplepay> ISML tag.
B2C Commerce Script API: Runs server-side calls without external HTTP round-trips. For example, shopper IP geolocation resolution via dw.system.Request.getGeolocation(), and default ratings overrides via the ratings.js decorator.
dw.system.Request.getGeolocation() returns null when the IP address can’t be found. Handle this case in your code.
Business Manager job framework: Schedules recurring data-export tasks. For example, Google-ExportFullFeeds steps for catalogs, inventory, price books, and stores, and daily Facebook catalog feed exports.
WebDAV file exchange: Delivers export files to WebDAV paths for external systems to poll. For example, Google Channels read catalog, inventory, pricing, and store files.
Hooks: Intercepts platform behavior using custom cartridges without modifying core platform code. For example, transformation hooks customize attributes when generating the Facebook product catalog feed.
Push and Pull Integration
Understanding who initiates a data transfer helps you select the right interface and anticipate failure points.
Push
In a push integration, B2C Commerce initiates the transfer. The external system is a passive receiver.
- The Facebook Conversions API receives shopper events that Einstein tracking collects, transforms to the Facebook format, and pushes to the API in real time.
- After a shopper authorizes payment on their Apple Pay device, B2C Commerce pushes the authorization request to the PSP and stores the returned transaction ID.
- The Google-ExportFullFeeds job writes catalog, inventory, pricing, and store files to WebDAV on a schedule that B2C Commerce controls.
Pull
In a pull integration, a system requests data from a source on demand. The source provides data only when asked.
- Google Merchant Center pulls feed files from WebDAV after B2C Commerce writes them. Google controls the polling schedule.
- On each storefront request, B2C Commerce calls dw.system.Request.getGeolocation() to pull the geolocation for the shopper’s IP—fresh per request, not prestored.
- The ratings.js decorator pulls a product rating from a third-party review service when the product model is constructed.
The Google Channels integration combines both: B2C Commerce pushes files to WebDAV. Google pulls them on its own schedule. Because the operations are decoupled in time, a delayed Google poll doesn't affect the export, and a failed export doesn't prevent Google from reading the files.
Real-Time Versus Batch Integration
Real-Time
Real-time integrations transmit data immediately as events occur within the commerce platform. When a shopper performs an action—viewing a page, adding an item to cart, or completing checkout—the platform captures that event through its tracking mechanism, transforms it into the third-party service's format, and sends it via API in real-time. This approach ensures that external systems have up-to-the-moment visibility into customer behavior and can respond accordingly. Real-time transmission is particularly valuable for event-driven scenarios where timing matters, such as triggering immediate actions based on shopper activity. The trade-off is that real-time integrations require constant connectivity and can generate high API call volumes during peak traffic periods.
Batch
Batch integrations operate on scheduled intervals, collecting and processing data in bulk before transmitting it to third-party systems. The platform runs scheduled jobs that extract data—such as product catalogs, categories, orders, promotions, or shipping profiles—and generates feed files in a specified format (such as tab-delimited text). These files are placed in a designated location where the third-party service retrieves them using credentials and protocols like WebDAV.
Batch processing is efficient for large data sets that don’t require immediate synchronization, such as complete product catalogs or daily order summaries. This approach reduces API overhead and allows for data validation and transformation before transmission.
However, there’s an inherent delay between when data changes in the commerce platform and when it becomes available to the third-party service. The choice between real-time and batch integration often depends on the use case. Event tracking and behavioral data typically benefit from real-time transmission, while comprehensive data sets like product catalogs work well with scheduled batch feeds. Many integrations use a hybrid approach, combining real-time event streaming for shopper activity with batch feeds for catalog updates to balance immediacy with efficiency.
Factor | Favors real-time integration | Favors batch integration |
|---|---|---|
Data freshness | Shopper-facing, transaction-critical | Back-office, latency-tolerant |
Volume | Low, per event | High, full catalog |
Failure impact | Failure contained in the request cycle | Recoverable on next scheduled run |
Next Steps
In this unit, you learned which interfaces B2C Commerce provides, how push and pull patterns move data, and when timing requirements favor real-time over batch. In the next unit, you examine the tradeoffs between client-side and server-side implementations, and see how loose coupling protects integrations from single-point failures.