Outlining the Architecture Behind SAP S/4HANA Service

The main principles behind the architecture of S/4HANA Service when comparing it with SAP CRM 7.0 are as follows:

• Harmonized master data:
  • Use of the SAP S/4HANA material master, not the SAP CRM product
  • Use of the business partner (customer) master record for sales area dependent data instead of SAP CRM specific tables
  • Use of technical objects (such as equipment) instead of IObjects
• Engine harmonization:
  • Use of SAP S/4HANA Sales Pricing instead of IPC (SAP CRM 7.0)
  • Use of SAP S/4HANA Sales Billing instead of SAP CRM Billing
  • Integration of the configuration engine Advanced Variant Configuration (from SAP S/4HANA)
• Customizing harmonization (use of original SAP S/4HANA tables, not SAP CRM mirror tables)
• No use of SAP CRM middleware for internal processes, such as the creation of follow-up documents or data exchange with external (SAP or non-SAP) systems
• UI principles:
  • Web Client UI is continued, SAP Fiori apps are available
  • Visual harmonization (Belize theme)
• No more obsolete technology stacks (IPC/VMC, TREX, JAVA Stack)

Concerning the harmonization of product master data (material masters): the SAP CRM product master is not used. Product categories and hierarchies are no longer available. The only grouping criteria are the material group and the (Sales and Distribution) product hierarchy.

The set type technology for extending the product master is no longer available. All use of APIs to the (SAP_ABA) product master have been replaced by new APIs in SAP S/4HANA. The central class for access is CL_CRMS4_PRODUCT_API. Search for products is still available as a WebClient UI search application, but this now uses Core Data Services (CDS) views of the SAP S/4HANA material master. The BOL model is retained, but has been simplified considerably.

For customers working with SAP CRM 7.0, a migration path is available from SAP CRM products to SAP S/4HANA material masters for service products.

The figure shows possible reference objects in service transactions.

Individual Objects (also referred to as IObjects or simply Objects) are no longer supported because they belong to the SAP_ABA product master.

Concerning the business partner: SAP S/4HANA uses the business partner as its primary object: synchronization with (SAP ERP) customer/vendor master records is performed using Customer/Vendor Integration (CVI). Maintenance of accounts is still possible using the WebClient UI application. The SAP CRM database tables of the sales area-dependent data (shipping, billing, and so on) are no longer used. Instead, the tables from the customer master are used (KNV* tables). In particular, partner functions are no longer assigned to a relation, but maintained on sales area level (table KNVP).

The following functionality is no longer supported:

• Group hierarchy
• Marketing attributes
• Marketing permissions
• Template framework

Concerning organization management and employees: SAP GUI transaction PPOMA_CRM is not working any longer for the assignment of employees, because relationship type 008 for the CP – S assignment (central person to position) has been replaced by a new type called 771. Assignment must be performed through, for example, the WebClient UI application. The new relationship type allows a co-existence with the HR organizational model, without side effects such as over-employment by assigning an employee to two positions. Employees themselves can only be maintained in HCM (transaction PA30), no longer in the Web Client UI application.

Concerning Customizing harmonization: SAP CRM Customizing tables that are replicas of an SAP S/4HANA Customizing table are no longer used. An example is as follows: terms of payment: CRMC_PMNTTRMS is replaced by T052.

Concerning Pricing, the following functions are not supported:

• Condition exclusion using exclusion indicator KZNEP
• Tracking cumulative values with condition update
• Data sources
• Quantity adjustments
• Agreed conversion factors
• Configurable parameters and formulas in pricing (CPF)
• Commodity pricing

For supported fields, see the following option in Customizing: SAP Customizing Implementation Guide→Service→Basic Functions→Pricing→Display Supported Price-Relevant Fields (Standard Delivery).

Concerning data exchange:

• Thanks to the harmonized master data and Customizing in SAP S/4HANA, replication of master data or Customizing is no longer necessary.
• In SAP CRM 7.0, the SAP CRM middleware was also used to generate follow-up documents in SAP ERP from an SAP CRM transaction, for example, a sales order or a purchase requisition. In SAP S/4HANA Service, the SAP CRM middleware is completely eliminated from these processes. All follow-up documents are created upon saving using a synchronous call of the corresponding APIs:
  • SD sales order (containing the sales items of a service order)
  • Internal order (CO)
  • Billing Document Request (BDR)
  • Reservation, Purchase requisition, Purchase order (Logistics integration)
• Triggering the follow-up processes is controlled by system table CRMS4S_EXCH_FCTR. There is a corresponding Customizing table CRMS4C_EXCH_FCTR that SAP customers can use to integrate their own processes.

Business transactions (service order, opportunity, activity, and so on) are based on the so-called One Order data model, which was developed in the late 1990s. This data model is very disadvantageous for analytical applications because of the distribution of data across many tables, GUID pointers, and name/value type tables. For this reason, a redesign of the data model was introduced with SAP S/4HANA Service. The goal of this is that transactional and analytical applications can run on the same primary persistence of the data.

The following are the basic principles of the data model and its redesign:

• One flat header and item table for each group of business objects
• Semantic keys instead of GUIDs
• Complex extensions and sets:
  • Important records are extracted as individual fields into the header/item tables. Examples: Partner: sold-to party, ship-to party, contact; Status: open, completed, billed; Dates: valid from, valid to.
  • All records are kept in a separate table, but the key structure is simplified in order to allow direct JOINs (avoiding the link handler)
• Repetition of header fields at item level
• Order APIs remain stable (also the lower level APIs)
• Advanced searches, interactive reports, enterprise search, and analytical applications are implemented using Core Data Services (CDS) views
• No more use of index tables
• Every business object type (for example, a service transaction) is assigned an acronym (for example, SERV), and the corresponding database table has the name CRMS4D_<acronym>_H (header) or CRMS4D_<acronym>_I (item), respectively. The acronyms are stored in table CRMS4C_ACRONYM.
• The (new) tables for the complex components are named CRMS4D_<component>, for example, CRMS4D_PARTNER, CRMS4D_SCHEDLIN.
• In order to connect the previous GUID based approach to the design used now, "reduced versions" of CRMD_ORDERADM_H/I were retained, which are called CRMS4D_BTX_H/I.

The above figure shows some examples of converted SELECT statements based on the One Order redesign.

AET is the Application Enhancement Tool. In SAP CRM 7.0, a WEB UI-based development tool was introduced by SAP called the Application Enhancement Tool (AET) for the creation of fields for business objects.

Concerning field extensibility: fields can be appended to header and item tables, through a so-called persistence include. This persistence include is also included in the One Order segment CUSTOMER_H/I, which is the link to the API and the UI, and in the search and search result structures.

Concerning integration:

• In SAP CRM 7.0, integration to other systems (SAP and non-SAP) was always implemented using the SAP CRM middleware (exception: SAP Supply Chain Management (SAP SCM)).
• The standard interface to external systems was the so-called XIF adapter, which allowed SAP customers to exchange objects in a generic IDOC format (asynchronous). In addition, SOAP services (synchronous and asynchronous) and BAPIs were available.
• With SAP S/4HANA Service, all these interfaces have been deprecated: the XIF adapter uses the middleware, IDOCs are not allowed in the Cloud, the interface contains many unsupported segments, the SOAP services contain unsupported functionality, and they do not comply with the SAP S/4HANA services architecture. Similarly, the BAPIs contain unsupported parameters.
• Therefore, the current integration paradigm is: for each business object synchronous CRUD services (OData) are provided. Asynchronous SOAP services are also provided. Prioritization of which services are shipped with which release depends on the business cases that are included in the respective release scope.

Concerning the Readiness Check and Migration tools:

• There is no system conversion from SAP CRM 7.0 to SAP S/4HANA Service like the SAP ERP to SAP S/4HANA conversion. This is always a migration because the SAP S/4HANA Service add-on has to be installed upfront and, in a second step, data has to be migrated.
• Readiness Check: SAP has published Simplification Items that describe the delta between SAP CRM 7.0 and SAP S/4HANA Service in detail. Each simplification item can have a check assigned that can be executed in a customer system in order to automatically determine areas where functionality is not supported, or adaptations need to be made.
• Migration tools: SAP provides migration tools to migrate objects to the SAP S/4HANA data model. Examples of this are the following:
  • Migration of SAP CRM service products to SAP S/4HANA material masters
  • Migration of business transactions

Customers who are willing to migrate from an SAP CRM 7.0 installation to SAP S/4HANA Service might not want to this in one step. They might prefer to transition smoothly over time. This reduces risks, allows for a more flexible adaptation to business needs, and minimizes impact for the business.

For this reason, a hybrid deployment model as shown in the figure, Hybrid Deployment: System Landscape, is supported.

If a customer is considering or planning a migration of an SAP CRM 7.0 or an SAP CRM 7.0 EhP installation to SAP S/4HANA (on premise) release 1909 or a higher, the information maintained in SAP Note 2691605 - Persistency of business transactions optimized for HANA is relevant, regarding the way data is persisted in the system.

The persistence of the data of SAP S/4HANA Service business transactions has been redesigned completely, in order to support fast queries and analytical activities. Every business object in SAP S/4HANA is represented using a flat table (header and item level) which absorbs all flat sets and extensions. Complex components, such as partners or reference objects, are still held in a separate table, but the key structure of this table has been simplified.

• The main principles behind the architecture of S/4HANA Service when comparing it with SAP CRM 7.0 are as follows: harmonized master data, engine harmonization, Customizing harmonization, no usage of SAP CRM middleware, modern UI, and no more usage of obsolete technologies.
• Customers who are willing to migrate from an SAP CRM 7.0 installation to SAP S/4HANA Service might not want to this in one step. They might prefer to transition smoothly over time. This reduces risks, allows for a more flexible adaptation to business needs, and minimizes impact for the business. For this reason, a hybrid deployment model is supported.
• The persistence of the data of SAP S/4HANA Service business transactions has been redesigned completely, in order to support fast queries and analytical activities.