There are a few points why SCPI will replace Datahub in future as we already wrote in our blog:
- More use-cases: Datahub is an integration middleware only for SAP Commerce. The SCPI is a middleware for multiple SAP applications and non-SAP applications.
- Native Cloud-Solution: More and more SAP provides its products as cloud solutions which all benefit by common processes like e.g., provisioning and security management.
- ncreasing amount of pre-built integrations: SAP implements common integrations like ERP, S/4HANA, Cloud for Customer, Marketing Cloud and others with best practices, which help to reduce integration costs, and which can be used as base for own customizations. The integrations can be easily searched via SAP API Business Hub and there is a simple mechanism for transferring into the own working area.
- Unknown ongoing support of Datahub: Now no fix end-of-maintenance date exists but it’s clear that SAP pushes the SCPI as strategic way forward and will get rid of unnecessary ballast.
For these reasons as CX Commerce developers we need to get in touch with SCPI and understand what the main differences to Datahub are.
From a high-level view both Datahub and SCPI move data from source to target via sender adapter, message transformation and receiver adapter. Datahub is a simple Java web application. The SCPI is based on Apache Camel – an open-source integration framework for routing and mediation of messages of any format and any kind of transport.
In so-called Integration Flows you declare how messages are going to be processed.
Sender and receiver adapter specify the technical connectivity. Many technologies like IDoc, SFTP, SOAP, LDAP, OData, HTTPS and third-party connectors like for ELSTER, Facebook, Twitter, Mail receivers are supported out-of-the-box. Also, there are versatile options to secure the connection and the message content.
Between sender and receiver adapter message processing steps are defined by flow elements. The source message is transformed into a target message. For example, a MATMAS IDoc is transformed into an OData object that the Commerce webservice can understand. Typical message transformer steps are mapping, filtering, converting formats, encoding/decoding, content modification and scripting. You can find more details in SAP Help Portal.
Development and Deployment
The SCPI comes with an online graphical editor for Integration Flow development.
When you are familiar with the Java development there are some points you will miss or must get used to:
- Complex Flows become chaotic. There is no feature like advanced search.
- Tracing changes is not supported. You could download the Flows and commit to a version control system, but this is time-consuming and not safe.
On the other hand, there are some big advantages. Changes can be quickly implemented and deployed. Long and risky restarts just because of a small configuration change are a thing of the past. The message-based and stateless approach makes it easier to reason about logic. No database like in datahub is accessed by multiple processes, which could cause side-effects and unclear behavior.
Logging is very comfortable. For each message you easily find the executed Integration Flow with its input message and the generated messages. You could even debug every step by activating a tracing mode.
On Commerce’s side there is a new Backoffice Cockpit for Integration modelling and inbound and outbound monitoring. You can dynamically customize integration models without the need of code changes.
To summarize the SCPI requires familiarization with the Integration Flow’s business process modelling which is a demanding challenge. On the other side you will profit on the broad range of use-cases and the accelerated release process. As the SCPI is a subscription-based cloud service you don’t care for infrastructure and application management. You can concentrate on developing business integrations.