SAP ABAP System (using RFC to generated extractor)

Run Mode: BACKGROUND AND DIALOG Aggregation: NATIVE Iteration: SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: REQUIRED Please check here

Generates an extractor function module in the managed system, extracts data via RFC to the generated function module, compares data in SAP Solution Manager.

You choose this for an ABAP-based system. The data is read using a function module, which needs to be individually generated for each comparison object. The generation creates an own function module per each data model in the customer namespace. It allows enhancements in the generated code, for example to code some additional application logic, but requires transport from the development system to the production system.

Parameters

The following data must be entered:

SAP ABAP System (using RFC to generic extractor)

Run Mode: BACKGROUND AND DIALOG Aggregation: NATIVE Iteration: SUPPORTED Duplicate Check: SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: REQUIRED Please check here

You choose this for an ABAP system. The data is read using a generic extractor function module. It is not necessary to generate individual extractor function modules but you generate SQL statements that are used by a generic extractor function module to extract the data. The generic extractor function module is delivered with the add-on ST-PI as standard code, thus does not allow extensions. You can find more details about the generic extractor function module in SAP note 1819794 - CDC: Generic extractor function module.

Parameters

Enter the following data:

Business Intelligence (MDX Query) 

Run Mode: BACKGROUND AND DIALOG Aggregation: NOT AVAILABLE Iteration: SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: REQUIRED Please check here

Generates MDX queries for BW info objects, extracts data via query execution in the managed BW system, compares data in SAP Solution Manager.

You can use this source type to extract data from SAP BW info objects. The metadata is presented in the following way, info objects are table names while key figures are field names.

Parameters

The following parameters are required:

BW Read Interface (BWRI) 

Run Mode: BACKGROUND AND DIALOG Aggregation: GENERIC AFTER EXTRACTION Iteration: NOT SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: NONE

This source type uses an RFC connection to the BW system to call the BW Data Manager Read Interface to read the data. In the data model an InfoCube is entered as table and the characteristics and key figures as table columns. There is no generation, but the information in the data model is used to call the BW Data Manager Read Interface. 

Currently the new source type BWRI supports the comparison of data from BW InfoCubes only. It is possible to use characteristics as key or data fields, but key figures can be used as data fields only. Both characteristics and key figures can be used as context fields.

Parameters

The following information is required

Remote Database (using ADBC)

Run Mode: BACKGROUND AND DIALOG Aggregation: NATIVE Iteration: SUPPORTED Duplicate Check: SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: REQUIRED Please check here

You choose this for a non-ABAP system where you can establish a direct remote database access. The data is read via a secondary database connection using a native SQL statement with ADBC (ABAP Database Connectivity). This works for all SAP-supported RDBMS including HANA.

Parameters

Direct remote database access 

In addition to its own local database, the Solution Manager can also create secondary database connections to “remote” (external) databases of other non-ABAP or non-SAP systems. The connection to a remote database uses ADBC (ABAP Database Connectivity), which is an ABAP/OO-based API and supports all official SAP-supported Database Management Systems (DBMS). It allows running native SQL queries from the ABAP stack. CDC can generate such native SQL extraction queries to read and compare the data with other data sources. The corresponding secondary database connection must be maintained with transaction DBACOCKPIT. The old method of using transaction DBCO is still supported but less user-friendly.

From a technical point of view, you need an installation of an appropriate Database Client and Database Shared Library (DBSL), for each type of SAP-supported DBMS, if not already installed. For example, if the Solution Manager runs on a MaxDB database, and you want to connect to some external application using also a MaxDB database, there is no additional installation necessary. However, if this external application runs on MS-SQL, you would need to install an additional DBSL and DB-Client from Microsoft.

The following SAP Notes provide additional information on how to setup the secondary database connections (also known as database multiconnect) for the different supported DBMS.

Using SAP HANA SDA (Smart Data Access) you can connect to further remote sources not listed here, such as Hadoop, Teradata, etc. The HANA DB exposes them as virtual tables, and CDC can consume them with the source type ADBC or HANA as well. So the access path from CDC point-of-view would be SolMan/CDC => ADBC => HANA => SDA => RemoteDB.

Please see here for further information: https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.01/en-US/a07c7ff25997460bbcb73099fb59007d.html

Comparison in one SAP HANA Database

Run Mode: BACKGROUND AND DIALOG Aggregation: NATIVE Iteration: SUPPORTED Duplicate Check: NOT SUPPORTED Metadata retrieval: SUPPORTED 

Extraction Strategy: EXTRACT COMPARISON IN ONE DATABASE Special Permissions: NONE

This source type enables comparisons directly in an SAP HANA database. You can compare data from the SAP HANA database with data from a second database (SAP HANA or a different database). For this purpose, the tables of the second database must be available as virtual tables in the SAP HANA database. This is realized using SAP HANA Smart Data Access:

SAP HANA Smart Data Access

The SAP Hana Smart Data access is based on virtual tables that maps to an existing object at the remote data source site.

 For information about how to create virtual tables using SAP HANA Smart Data Access, please see the corresponding chapter in the SAP HANA Administration Guide: SAP HANA Smart Data Access.

For most source types, CDC extracts data from both data sources and compares them in SAP Solution Manager. To compare data directly in an SAP HANA database, you first change the extraction strategy from Default: Individual Data Selection in Each Source System to Execute Comparison in One System. After this, instead of selecting two source types, you select only one source type Comparison in One SAP HANA Database.

Parameters

The following information is required:

During comparison, data is compared in the SAP HANA database and only the comparison result is returned to the CDC application in SAP Solution Manager:

This source type determines row hashes and uses them for comparison. Where available, only the key values and row hashes are transfered from the second database to the SAP HANA database. After the inconsistencies are determined, only the requested information like inconsistency details and context fields for the inconsistent objects is determined from the two databases.

This source type offers improved performance because the comparison is moved from the application server of SAP Solution Manager to the more powerful SAP HANA database. In addition to data comparison within one SAP HANA database or between two SAP HANA databases, this approach is also suitable for various other databases like TERADATA, SAP Sybase ASE, SAP Sybase IQ, Oracle and MS SQL Server. Currently the source type does not support comparison in blocks of configurable block size, so we recommend to split very large comparisons first, see Mass Activities for more information.

OData Service

Run Mode: BACKGROUND AND DIALOG Aggregation: GENERIC AFTER EXTRACTION  Iteration: SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: NONE

Use this source type for data from cloud systems which offer an accessible OData services.

Parameters

The following information is required:

For connecting to Cloud systems, for example SuccessFactors, only basic authentication is supported over a secure HTTP connection.

CDC supports all versions of OData, version 2.0+. Upto Service pack 6, only the ATOM format is supported and from SP07, the JSON response is supported.

The following functions must be accessible and working for CDC to function with the OData service:

• Metadata  ($metadata)
• Count ($count and/or $inlinecount)
• Querying, filtering and expand operations ($select,$filter,$expand)
• Paging operations ($top and $skip)

Metadata interpretation

General display

Each OData Entity set is considered as a table. So after entering the RFC destination, add a table to the OData source. The Entities are equivalent to tables in CDC. On selecting the entity set, the properties and associations, if any, are displayed in the form of columns. CDC supports only one primary OData entity at a given time. Each entity set is linked to an Entity type. An entity type has properties and navigation properties to other entities.

For fields of the given entity having a standard EDM type (like Edm.Int32, Edm.String etc.), the field followed by an equivalent ABAP DDIC type is shown. 

Special properties

Supported and equivalent data types

The table below enumerates the equivalent OData and DDIC data types for comparison. As before stated, these types are only for information. All OData responses are treated as strings.

 Ariba Networks (Using Transaction Monitoring API V2)

Run Mode: BACKGROUND AND DIALOG Aggregation: NOT SUPPORTED Iteration: SUPPORTED FOR SELECT FIELDS Duplicate Check: NOT SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: NONE

This source type generates an openAPI query, extracts data via Transaction management API, compares data in SAP Solution Manager. 

The SAP Ariba Transaction Monitoring REST API gives users of SAP Ariba cloud solutions a fast and reliable mechanism to track business documents as they flow between applications. This allows a high degree of visibility and traceability into business processes and documents.

Parameters

The following parameters must be entered:

Requirements for Ariba Networks

Follow the steps for enabling the Transaction monitoring API as detailed in the SAP Ariba Transaction monitoring REST API guide available here.

The following steps are required to use the Transaction Monitoring API with Ariba Network:

• Provision TM OpenAPI and BPM integration (Client-ID to ANID mapping).
  To create the client-ID mapping, contact your SAP Ariba Customer Success Manager or Account Manager

Documents supported

Metadata provided

Iteration support

The Ariba source type for CDC supports iteration and key-based selection for the following fields (Only one can be selected at a given time):

• document_id
• correlation_id
• transaction_id

Limitations

Due to the CDC Source type making use of the API, it is limited in a few ways. These are:

• When the ARIBA source type is a primary source type, the date_happened filter is mandatory and must be between two time frames and cannot be more than 30 days in the past. Relative time filters are advised.
• Filters can only be applied to the fields as detailed in the filters section. Other combinations are not possible.

 Ariba P2P/P2O (Using Operational Reporting API)

Run Mode: BACKGROUND AND DIALOG Aggregation: NOT SUPPORTED Iteration: NOT SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: NONE

This source type generates an openAPI query, extracts data via the Operational Reporting API, compares data in SAP Solution Manager. 

The Operational reporting API for procurement enables you to extract and report on the transactional procurement data that you need to make operational decisions, such as invoices to pay or purchase requisitions that need approval. 

Parameters

The following parameters must be entered:

Metadata

The CDC Source type for P2P/P2O provides the following tables.

The tables are:

• CDC_CopyOrder
• CDC_DirectOrder
• CDC_ERPOrder
• CDC_Invoice
• CDC_InvoiceRequisition
• CDC_Recipt
• CDC_Requisition

Each table has custom fields pertaining to the type and all tables have few fields in common:

• createDate
• updateDate
• status

Only one date field can be selected at a given time. By default, all statuses are selected

Filters

The following fields are filterable using CDC:

Supported filter Values for status

Limitations

Due to the CDC Source type making use of the API, it is limited in a few ways. These are:

• When the ARIBA source type is a primary source type, the createDate/updateDate filter is mandatory and must be between two time frames and cannot be more than 30 days in the past. Relative time filters are advised.
• Filters can only be applied to the fields as detailed in the filters section. Other combinations are not possible.

View creation on Ariba P2P/P2O

The cross-database comparison for Ariba P2P/P2O works with views provided from the Operational Reporting API. Not all views are supported however. We make use of few custom views for each document type. When the comparison is run, the tool tries to create a view using the reporting API, this view is created depending on the date field selected. For example, if you select the view CDC_Requisitions and select the date filter as create_date, a custom view will be created with the CDC_Requisitions_CR. This view will then be used for extracting data. Please note that the view will be created only once when the comparison is successfully run for the first time.

XML File on Application Server

Run Mode: BACKGROUND AND DIALOG Aggregation: GENERIC AFTER EXTRACTION Iteration: SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: NOT SUPPORTED  Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: NONE

No generation, extracts data from XML files on application server of SAP Solution Manager, compares data in SAP Solution Manager.

You choose this for data that is stored in a XML file on an SAP Solution Manager application server. The source type is able to process single and multiple XML files.

Parameters

The following data is required:

Requirements

The CDC source type FIXS for XML files on application server requires either XML files directly in asXML format or XML files in any different format and a corresponding transformation to bring the required data from these files into asXML format.

asXML is the format that you get if you use transformation ID for an internal ABAP table. The following is an example for one item with columns PARTNER, NAME_LAST and NAME_FIRST. (For a table with multiple items, you would see multiple <item> tags.)

The XML declaration at the beginning of the file is optional, whereas the namespace definition needs to refer to ABAP XML. The part of the XML file containing the data to be compared needs to be included in tag <asx:values> (and </asx:values> respectively).

Beyond this level a tag <TABLE> marks the start of the data table, whereas several tags opening and closing with <item> (and </item> respectively) mark the beginning and the end of a line item in the table to be compared.

Within the <item> tags the names of the respective table fields need to be used as tag names. These tags contain the actual item data.

Furthermore it is important that the tags in the XML file in asXML format must correspond to the tags in the mapping connection of the CDC data model.

Example

ABAP Table:

Converted into asXML this table would look like this:

<?xml version="1.0" encoding="UTF-8"?>
<asx:abap xmlns:asx=" http://www.sap.com/abapxml" version="1.0">
<asx:values>
<TABLE>
<ITEM>
 <FIRST_NAME>Jason</FIRST_NAME>
 <LAST_NAME>Li</LAST_NAME>
 <CITY>Shanghai</CITY>
</ITEM>
<ITEM>
 <FIRST_NAME>Peter</FIRST_NAME>
 <LAST_NAME>Meier</LAST_NAME>
 <CITY>Berlin</CITY>
</ITEM>
<ITEM>
 <FIRST_NAME>Michael</FIRST_NAME>
 <LAST_NAME>Smith</LAST_NAME>
 <CITY>Washington</CITY>
</ITEM>
</TABLE>
</asx:values>
</asx:abap>

In the definition of the data model it should like this:

(Here “TEST_TABLE” is used as table name.)

XML File on local PC

Run Mode: DIALOG Aggregation: GENERIC AFTER EXTRACTION Iteration: NOT SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: NOT SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: NONE

You choose this for data that is stored in an XML file on the local PC. 

Parameters

The following data must be entered:

Requirements

The CDC source type FIXL for XML files on local PC requires XML files in asXML format.

asXML is the format that you get if you use transformation ID for an internal ABAP table. The following is an example for one item with columns PARTNER, NAME_LAST and NAME_FIRST. (For a table with multiple items, you would see multiple <item> tags.)

The XML declaration at the beginning of the file is optional, whereas the namespace definition needs to refer to ABAP XML. The part of the XML file containing the data to be compared needs to be included in tag <asx:values> (and </asx:values> respectively).

Beyond this level a tag <TABLE> marks the start of the data table, whereas several tags opening and closing with <item> (and </item> respectively) mark the beginning and the end of a line item in the table to be compared.

Within the <item> tags the names of the respective table fields need to be used as tag names. These tags contain the actual item data.

Furthermore it is important that the tags in the XML file in asXML format must correspond to the tags in the mapping connection of the CDC data model.

Example

ABAP Table:

Converted into asXML this table would look like this:

<?xml version="1.0" encoding="UTF-8"?>
<asx:abap xmlns:asx=" http://www.sap.com/abapxml" version="1.0">
<asx:values>
<TABLE>
<ITEM>
 <FIRST_NAME>Jason</FIRST_NAME>
 <LAST_NAME>Li</LAST_NAME>
 <CITY>Shanghai</CITY>
</ITEM>
<ITEM>
 <FIRST_NAME>Peter</FIRST_NAME>
 <LAST_NAME>Meier</LAST_NAME>
 <CITY>Berlin</CITY>
</ITEM>
<ITEM>
 <FIRST_NAME>Michael</FIRST_NAME>
 <LAST_NAME>Smith</LAST_NAME>
 <CITY>Washington</CITY>
</ITEM>
</TABLE>
</asx:values>
</asx:abap>

In the definition of the data model it should like this:

(Here “TEST_TABLE” is used as table name.)

CSV File on Application Server

Run Mode: BACKGROUND AND DIALOG Aggregation: SUPPORTED Iteration: SUPPORTED Duplicate Check: NOT SUPPORTED 

Metadata retrieval: SUPPORTED Extraction Strategy: INDUVIDUAL SELECTION AND KEY BASED SELECTION Special Permissions: NONE

This source type was introduced with Solution Manager 7.2. You use it for data stored in comma separated files (CSV).

Parameters

The following data is required:

Metadata

Enter any table name and the field names from the header line or any field names in case of no header line. There is no value help for table and field names, but you have to enter them manually.

CSV files supported

The source type supports different kinds of CSV files:

• CSV files with or without header lines: The header line is not compared but determines the order how the fields are mapped.

• CSV files with different field separators: A comma is used as default field separator, but it is possible to enter different field separators.

• CSV files in different formats: The source type checks automatically if the file is in UTF-8 format. In UTF-8 format, a possible byte order mark (BOM) is skipped and not included in the comparison. In a non-Unicode system, the file is read without being converted. In a Unicode system, if the file is not in UTF-8 format, the characters of the file are handled in accordance with the non-Unicode code page that would be assigned at read time in a non-Unicode system, in accordance with the entry in the database table TCP0C of the current text entvironment.