Introduction

The SAP C/4HANA suite includes a variety of cloud-based products that will enable key parts of your business. To automate your complete end to end business scenarios, you will need to integrate products in the suite along with other SAP products, such as SAP S/4HANA, along with third-party solutions. This article provides some guidelines to choose the ideal integration strategy for various scenarios.

Integration & Extension Approaches

Integration and extension approaches fall into these general categories:

Asynchronous or Point to Point

This category includes file-based solutions that must be configured for a specific source and destination system. Examples are ImpEx andHot Folders for SAP Commerce, or direct OData calls to Marketing, Sales, Service or Commerce Clouds.

Cloud Integration

This category includes cloud-based integration solutions such as SAP Cloud Platform Integration (CPI) and Third Party solutions available in the SAP App Center.

Cloud Extension

This category includes cloud-based extension platforms such as the soon to be released SAP Cloud Platform Extension Factory powered by the Kyma open source project and other SAP Cloud Platform services. SAP Cloud Platform Extension Factory provides a cloud-native platform for building services. This includes serverless functions with a services catalog that handles all the security and connectivity to both custom built and SAP Cloud Platform services as well as third-party services. It also provides a standard Application Connector model to connect SAP C/4HANA applications with a standard event model and API management.

Data & Non-Functional Requirements

Transactional Data

Integrations can be required for maintaining consistent data across multiple systems (see "Master Data" below), but they could also be needed for transactional data. Examples of these types of integration include quote, order, invoice, payment, fraud, tax, social, and email.

SAP App Center: The SAP App Center provides pre-built, certified extensions built by partners and service providers for easily integrating services into the SAP C/4HANA applications.

Writing your own custom integration: If the integration you want to use is not provided through an available integration API (see http://api.sap.com/) or in the App Center, then you're going to have to build the integration yourself. For common transactional integrations, you can integrate with your service provider quicker by using certain APIs.

Master Data

With any integration, there will be shared data. Master data ensures that there is only a single source of truth for the data. The requirements will define which system will hold this data. Any other system that needs this data will need to either replicate the data or have a way to access it. Examples of master data can include one or more of the following:

Customer

Product

Suppliers

Stock Level

Price

Changes to this data need to be replicated in both systems. For example, if a customer's name has a source of truth in System A, and it is changed in System A, then there will need to be an integration to update the field in System B or enable System B to read the field in System A. It is very important during Foundation and Exploration phases that the master data be defined, as it is a driver for what integrations will be required.

Data Format

Asynchronous integrations can be difficult because the data being interchanged will typically be in different formats. The data itself may also be structured (row-column data model) or unstructured. Examples include web pages, word documents, social feeds, and more). It may be in a common format (for example, comma-separated values) or it could be stored in a proprietary format known only to you. If you are transferring data in or out of SAP C/4HANA applications, a transformation will need to be performed between the source and target systems you're calling. Alternatively, you could build code to make a direct call to or from the target system.

Additionally, the data may require enrichment before it's made visible to the end user. This enrichment can happen during import/export, or it can be completed at a later time as part of other business processes. The level of enrichment should be defined as part of the requirements for each integration.

Non-Functional Requirements

The following topics should be considered for any integration or extension approach:

Extensibility - How easy it to extend and customize a solution if whatever is provided out of the box is not exactly what is needed?

Scalability - If the amount of data coming in or going out grows or you need more processing power, how easy is it to grow the solution?

Audit and Control - What level of audit and control are provided for the integration? Can it log individual changes? Can you prevent specific users/groups from executing an import or export?

Testability - How easy is it to write new tests? What level of testing is provided? Are there included test frameworks that are automated or is testing manual?

Ease of Deployment - How quickly can you set up an integration and start import/export processes? Is it configuration only? Are there any additional applications/hardware required?

Reliability - Does the integration provide any options for fail-over?

Stability - How does it handle unexpected errors/exceptions?

Conclusion

This article outlines the high-level categories of integrations and major topics to consider.