Overview of Datahub approach and challenges:
DataHub supports the Commerce Cloud (SAP CCV2) integrations. However, product support is not releasing any new features or enhancements. The current DataHub package lacks a consolidated dashboard for monitoring transactional data and viewing end-system integration field mappings. The unavailability of transactional payload data hinders organizations from responding swiftly to data or integration issues.
Resolving Integration Challenges with SAP CPI
CPI is a strategic data integration solution for SAP Commerce Cloud. It offers a comprehensive set of pre-built connectors, robust mapping UI, and data payload monitoring capabilities tailored for seamless integration workflows. Its cloud-native architecture supports scalability, rapid deployment, and security features using SSL certificates. By leveraging CPI, businesses can streamline their integration processes, and improve efficiency without any downtime.
Datahub to CPI Migration Process
Let's understand how DataHub mappings and logic will be migrated in CPI for one source system.
Extensions Set for CPI
Add the following extensions to localextensions.xml to enable integration points and hooks:
<extension name='integrationbackofficetest' />
<extension name='integrationservices' />
<extension name='odata2services' />
<extension name='odata2webservicesfeaturetests' />
<extension name='outboundservices' />
<extension name='outboundsync' />
<extension name='webhookbackoffice' />
<extension name='inboundservices' />
<extension name='webhookservices' />
After adding these extensions and performing a system update, you will be able to see the Integrating UI perspective in the back-office.
Existing Datahub Mapping Resettling
Standard Datahub integration is achieved via Raw, Canonical, and Target mapping XMLs. These mapping will be migrated in CPI iFlows and commerce Integraion objects.
Raw Mapping Migration
Raw items mapping will be handled in CPI as the source system will directly interact with CPI. For example, MSTAV and MSTAE in the incoming MATMAS IDoc in RAW XML. This will be configured in the CPI iFlow as mentioned.
Canonical Mapping Migration
Similar to raw items, canonical transformation logic defined in canonical will also be configured in the CPI iFlow mapping. For example:
- E1MARAM-MSTAE > CanonicalProduct-crossPlantMaterialStatus
- E1MARAM-MSTAV > CanonicalProduct-crossDistributionChainMaterialStatus
Target Mapping Migration
Target mapping is typically associated with commerce items. Items in the target system will be directly mapped with the Commerce Integration Object. In the attribute section, export code and transformation expression manage the Integration Object attribute and value.
- Attribute.exportCode: This will be mapped with the direct property of the Integration Object. Once imported in CPI, it automatically creates the required EDMX file.
- Attribute.transformationExpression: This manages the value mapping of the item attribute. If transformation is required in the value received from ECC, it can be handled via a groovy script in ECC.
Sample iFlow configuration for the above scenario will look like this
Impex Translators
For complex types, we use Impex translators in DataHub. Here, we have different translators for each complex attribute where we write logic to set the value of the corresponding attribute. In CPI, translator logic will be handled by Pre/Post Persistence hooks.
Multiple Items/Headers Processing
In DataHub, multiple headers can be processed via a single canonicalItemSource. For example, CanonicalProduct can be used to create both base products and variant products. This mapping can be handled in CPI, where multiple payloads can be mapped from a single IDOC. Persistence hooks can also be used to create multiple objects.
Security
SSL Certificates
Commerce SSL certificates should be installed on CPI tenants to synchronize inbound/outbound data.
Authentication Type
Each Integration Object requires specific authentication, which can be either OAuth or Bearer Token. This information can be found under InboundChannelConfiguration.authenticationType.
Persistence Hooks
Persistence hooks allow the execution of business logic before or after a request to persist an item, similar to Interceptors used in Commerce. There are two types of persistence hooks: PrePersistHook and PostPersistHook. Several OOTB Persistence Hooks are available. For instance, the logic from the Impex translator classes used with DataHub has been replicated in these hooks. Depending upon the business needs one can create new persistence hooks.
The bean reference will be configured into CPI to invoke standard callback methods for these persistence hooks.
Monitoring
To enable payload monitoring and retention of CPI payloads in the Backoffice's Integration UI tools, add the following properties to local.properties or hcs-common:
properties
inboundservices.monitoring.success.payload.retention=true
inboundservices.monitoring.error.payload.retention=true
inboundservices.monitoring.enabled=true
outboundservices.monitoring.success.payload.retention=true
outboundservices.monitoring.error.payload.retention=true
outboundservices.monitoring.enabled=true
The CPI payload can then be monitored via the Backoffice Integration UI.
Help Site Reference: https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/9b7fba7fb23645fcb03d294ddee98752/ea15aabd47924c8...
