SAP Commerce Cloud Integration Roadmap Part II: Commerce Data Hub and SCPI

In the first part of this series, we took a look at the SAP Commerce Roadmap and integration implications for which SAP Commerce professionals and customers alike should be prepared.

As SAP continues to implement its cloud vision, with SAP Cloud Platform Integration (SCPI) at the center, SAP Commerce Data Hub is taking more of a back seat. Why? Below, we take a look at some Data Hub capabilities and limitations as well as the way teams will benefit from centralized Integration-as-a-Service (IaaS) in the cloud on the SCPI platform.

Comparison: Data Hub and SCPI

SAP Commerce Data Hub is squarely focused on ETL processing inbound and outbound data in SAP Commerce. SCPI, by comparison, is a fully-fledged cloud-based message broker, enabling the interconnectivity of many different types of systems and services running in the cloud or on-premise.

In Part I, we reviewed the SAP Commerce integration selection process put forth by SAP. Let’s now compare Commerce Data Hub’s features to those of SCPI, reflective of that selection process:

Aspect	Data Hub	SCPI
Extensibility	Data Hub is extensible, however less flexible Custom adapters, extensions, and development tools can be added to an installation Dynamic extensions can load metadata at runtime Higher complexity, challenging when manipulating existing items, such as target system export codes for ImpEx headers or column names	Highly extensible Can create custom Integration Objects, and make them available as part of Integration APIs Existing Integration APIs can be extended Roadmap Integration APIs in development Adapters based on Apache Camel components, enabling processing of any message payload via custom adapters, as needed, via ADK (adapter development kit)
Scalability	Some limitations Vertical scaling through additional pools Horizontal scaling requires a cluster Each instance has its own data partition Data loaded into a pool must be directed to the same node Only one node can be active for a given pool Concurrency only available when there are no dependencies between data items across pools or instances	Highly scalable Use of Integration Objects / APIs combined with SCPI allows for full scalable integration
Audit and Control	Complete transparency, within SAP Commerce instance The full history of data transformations, stored in a database and attached to Data Hub instance Pre-built XML configuration of what is logged, customizable Error analysis via BackOffice Data Hub perspective	Full monitoring capabilities Monitoring and control of services within SAP Commerce (Eg. Inbound) Logging of messages can be configured in SCPI
Testability	Fully testable, via unit tests Set of unit tests ships with Data Hub code, along with integration test sample, which can be extended	Fully testable flows, via SCPI and SAP Commerce Back Office Monitoring of inbound-outbound services via Integration Backoffice
Ease of Deployment	Rigid, build and deployments required for most customizations Requires planning and monitoring of active processing during deployment to ensure data integrity Additional manifest Commerce Data Hub considerations when deploying customizations to CCV2	SCPI configurations and processing can be deployed in runtime Integration Objects and Integration APIs are part of SAP Commerce, requiring platform deployment for changes
Reliability	Reliable, storefront and Commerce Data Hub nodes separate Asynchronous calls to Commerce Data Hub, storefront unaffected during Commerce Data Hub node failure	Highly reliable Integration decoupled from the storefront, so SCPI or processing instance downtime does not affect storefront
Stability	Stable at runtime, sensitive to configuration changes Reconfiguration of existing raw, canonical and target items can be done at runtime, with some caveats Extension modifications having dependencies cannot be dynamically loaded at runtime	Highly stable For recovery, dead letter queues and retry behaviors can be incorporated, depending on adapters in use Unexpected results are logged SAP Commerce Back Office Integration view can help with Integration monitoring and troubleshooting

Commerce-Specific Tooling

SAP Commerce Data Hub has served users well as an ETL processor of back-end data for integration with SAP Commerce. Ultimately, though, its rigid configuration, testing, redeployment and scalability limitations are too cumbersome for the needs of today’s delivery and improvement cycles for Commerce teams.

Domain-specific knowledge around Commerce Data Hub architecture was a must-have when making such integrations, also contributing to the maintenance complexity and overhead for organizations taking delivery. Now, this kind of specialized, expensive, and narrow expertise is no longer necessary to integration success.

A Flexible Future

As a centralized integration platform, SCPI will afford teams a more flexible medium for orchestrating and managing hybrid deployment landscapes. SAP Commerce architects can focus on Integration APIs (OData) on the Commerce side while collaborating with process integration architects and stakeholders as they manage the wider, hybrid integration landscape centered around SCPI.

What this results in is more flexible, manageable services, a lower total cost of ownership (TCO), and faster time to value for organizations modernizing their digital business.

So, thank you, Commerce Data Hub, for a job well done. SCPI can take it from here.