What Can Nexus Extract from SAP?

dab Nexus is a flexible SAP data extraction platform that supports multiple SAP source types, ranging from physical database tables to semantic data models and SAP reports. The exact extraction scope depends on SAP system architecture, available interfaces, authorizations, and customer-specific implementations.

SAP DDIC Database Tables

Overview

SAP stores application data using objects defined in the ABAP Dictionary (DDIC). Depending on the SAP release and database platform, data can be stored in different table types. From a Nexus perspective, data can be extracted from SAP tables and views that are exposed through the ABAP Dictionary and are accessible via the SAP interface used for extraction.

The primary DDIC database object types are:

DDIC Object Type	Description	Typical Usage
Transparent Table	1:1 mapping between the DDIC definition and a physical database table	Business application data
Pooled Table	Multiple logical tables stored in a common table pool	SAP system/control data (legacy)
Cluster Table	Multiple logical tables stored together in a data cluster	SAP application data (legacy)
View	Virtual object based on one or more tables	Reporting and data access

Note Although SAP S/4HANA has largely replaced pooled and cluster tables with transparent tables, Nexus can still extract pooled and cluster tables where they are available, including in older SAP ECC systems.

---

Transparent Tables

Overview

A Transparent Table is a database table that has a 1:1 relationship with the underlying database table. The table name, field names, and structure defined in the ABAP Dictionary correspond directly to the physical table in the database.

Transparent tables are the most common SAP table type and contain the majority of business application data.

Key Characteristics

• Direct mapping: One SAP table = One database table
• Same structure in DDIC and database
• Supports primary and secondary indexes
• Accessible using Open SQL and Native SQL
• Contains transactional, master, and organizational data
• Fully supported in SAP ECC and SAP S/4HANA

Common Examples

Category	Table	Description
Finance	BKPF	Accounting Document Header
	BSEG	Accounting Document Line Items
	ACDOCA	Universal Journal
Sales & Distribution	VBAK	Sales Order Header
	VBAP	Sales Order Items
Materials Management	EKKO	Purchase Order Header
	EKPO	Purchase Order Items
Master Data	MARA	Material Master
	KNA1	Customer Master
	LFA1	Vendor Master

Pooled Tables

Overview

Pooled tables are logical DDIC tables that are stored physically within a shared table pool. Multiple pooled tables share the same underlying database table. These tables were primarily used to save database resources in older SAP releases.

Key Characteristics

• Multiple SAP tables share a single physical database table
• Mainly used for system configuration and control data
• Accessed through the ABAP Dictionary
• Considered a legacy concept
• Not used in SAP S/4HANA

Typical Examples

Table	Description
A003	Pricing Conditions (older ECC systems)
Various SAP system tables	Configuration and control data

Cluster Tables

Overview

Cluster tables are logical DDIC tables whose records are stored together in a compressed data cluster within a single physical database table.

Several cluster tables can share the same physical storage area.

Key Characteristics

• Multiple logical tables stored in a single database cluster
• Data is stored in compressed format
• Historically used for performance optimization
• Access typically performed through ABAP Open SQL
• Legacy concept; replaced by transparent tables in SAP S/4HANA

Typical Examples

Table	Description
BSEG	Accounting Document Line Items (ECC)
KONV	Pricing Conditions (ECC)

Note In SAP ECC, some well-known tables such as BSEG were implemented as cluster tables. In SAP S/4HANA, these structures have been redesigned and stored as transparent tables.

Views

Overview

A View is a virtual DDIC object based on one or more underlying tables. Views do not necessarily store data themselves but provide a logical representation of data.

Views are commonly used for reporting, analytics, and simplified data access.

Key Characteristics

• Based on one or more tables
• No duplicate data storage
• Supports joins and filtering
• Frequently used for reporting and integrations
• Common in ECC and S/4HANA environments

Common Examples

View Type	Description
Database View	Join of database tables
Projection View	Subset of fields from a table
Maintenance View	Used for table maintenance
CDS View	Modern semantic data model in S/4HANA

CDS Views

Overview

Core Data Services (CDS) Views are SAP's strategic data modeling technology for defining semantic data models at the database layer. CDS Views enable developers and consumers to access business data through reusable, performance-optimized, and semantically rich views. CDS Views are a fundamental part of the Virtual Data Model (VDM) in SAP S/4HANA and can be consumed by SAP Fiori applications, analytics, OData services, external integrations, and reporting tools. For Nexus, CDS Views provide a business-oriented alternative to direct table extraction, allowing data consumption through SAP-delivered or custom semantic models.

Key Characteristics

• Semantic Data Modeling – Business-friendly representation of underlying database tables.
• Database Pushdown – Processing is executed directly in SAP HANA, improving performance.
• Reusable Logic – Business logic, joins, calculations, and filters are defined once and reused across applications.
• Annotations – Metadata annotations support analytics, OData exposure, UI generation, and authorization.
• Security Integration – Supports role-based access control using DCL (Data Control Language).
• Virtual Data Models (VDM) – Forms the foundation of SAP's modern data access architecture.

CDS Views in SAP ECC

CDS technology is available in newer SAP ECC releases running on SAP HANA. Typical use cases include:

• Reporting and analytics
• OData service generation
• SAP Fiori applications
• Simplification of complex SQL joins
• Data extraction for external systems However, CDS adoption in ECC is generally more limited compared to SAP S/4HANA.

CDS Views in SAP S/4HANA

In SAP S/4HANA, CDS Views are a core component of the application architecture. SAP delivers thousands of standard CDS Views covering business domains such as:

Domain	CDS View / API Entity	ABAP CDS View Name
Finance	I_GLAccountLineItem	I_GLAccountLineItem
	I_JournalEntry	I_JournalEntry
	I_ProfitCenter	I_ProfitCenter
Sales	I_SalesOrder	I_SalesOrder
	I_SalesOrderItem	I_SalesOrderItem
	I_Customer	I_Customer
Procurement	I_PurchaseOrderAPI01	I_PurchaseOrderAPI01
	I_Supplier	I_Supplier
Materials & Inventory	I_Product	I_Product
	I_MaterialStock	I_MaterialStock

These views provide standardized access to business data while abstracting the underlying table structures.

CDS DDIC-Based Views vs. CDS View Entities

SAP provides two implementations for CDS views: CDS DDIC-based Views and CDS View Entities. While both expose data through Core Data Services (CDS), SAP recommends using CDS View Entities for new developments due to technical improvements and a simplified architecture.

Finding the ABAP CDS View Name

Option 1: Check the CDS View in SE11

1. Open transaction SE11.
2. Enter the CDS View name (for example, I_GLAccountLineItem).
3. Display the definition.
4. Look for the annotation:

@AbapCatalog.sqlViewName: '...'

Example:

@AbapCatalog.sqlViewName: 'IFIGLACCTLNITM'
define view I_GLAccountLineItem as ...

The value of @AbapCatalog.sqlViewName is the ABAP SQL View Name associated with the CDS View.

Note: Newer CDS View Entities may not have a generated SQL View Name. In such cases, use Option 2 to determine the technical name exposed through Operational Data Provisioning (ODP).

Option 2: Check Table RSODPABAPCDSVIEW in SE16

SAP maintains a mapping between CDS Views and their ODP-exposed technical names in table RSODPABAPCDSVIEW.

1. Open transaction SE16 or SE16N.
2. Enter table RSODPABAPCDSVIEW.
3. Filter by the CDS View name (for example, I_GLAccountLineItem).
4. Execute the query.

The results show the corresponding CDS View metadata and technical names used by ODP extraction frameworks.

Example

CDS View	Where to Find the ABAP Name
I_GLAccountLineItem	@AbapCatalog.sqlViewName in SE11 or lookup in RSODPABAPCDSVIEW
I_JournalEntry	@AbapCatalog.sqlViewName in SE11 or lookup in RSODPABAPCDSVIEW
I_SalesOrder	@AbapCatalog.sqlViewName in SE11 or lookup in RSODPABAPCDSVIEW
I_PurchaseOrderAPI01	@AbapCatalog.sqlViewName in SE11 or lookup in RSODPABAPCDSVIEW

Recommendation: For SAP S/4HANA systems, especially newer releases, checking RSODPABAPCDSVIEW is often the most reliable method for identifying the technical CDS name available for extraction

Overview

Feature	CDS DDIC-Based View	CDS View Entity
Definition Statement	DEFINE VIEW	DEFINE VIEW ENTITY
ABAP Dictionary Object	Creates an additional CDS-managed DDIC View	No additional DDIC view generated
Architecture	CDS Entity + DDIC View	CDS Entity only
Activation Performance	Slower due to additional DDIC object generation	Improved activation performance
SAP Recommendation	Obsolete for new developments	Recommended for new developments
Availability	Supported for compatibility and existing systems	Preferred option in modern ABAP development

CDS DDIC-Based Views

A CDS DDIC-based view is technically based on a CDS-managed DDIC view in the ABAP Dictionary and is defined using the DEFINE VIEW statement. During activation, SAP creates:

• The CDS entity
• A corresponding CDS-managed DDIC view

This additional Dictionary object increases complexity and activation effort.

Example:

define view Z_SalesOrder
  as select from vbak
{
    key vbeln,
        erdat
}

CDS View Entities

CDS View Entities are the successor to CDS DDIC-based views. They are defined using the DEFINE VIEW ENTITY statement and do not generate an additional DDIC view. This leads to a leaner architecture and improved activation performance. SAP recommends using CDS View Entities for new developments.

Example:

define view entity ZI_SalesOrder
  as select from vbak
{
    key vbeln,
        erdat
}

For existing SAP systems, CDS DDIC-based views remain widely used and can be extracted by Nexus.

Virtual Data Model (VDM)

The Virtual Data Model (VDM) is a structured collection of SAP CDS (Core Data Services) views that provides a semantically rich and reusable data layer on top of database tables. The VDM organizes CDS views into different layers to separate data access, business logic, and consumption scenarios.

The VDM consists of:

• Basic Views – Directly access database tables and expose business-friendly data models.
• Composite Views – Combine multiple Basic Views and add business semantics.
• Consumption Views – Provide application-specific models for analytics, reporting, APIs, and SAP Fiori applications

Stability Contracts

SAP classifies many CDS views using Stability Contracts, which indicate the level of compatibility SAP guarantees across future releases. Stability contracts help customers and partners determine whether a CDS view can be safely reused in custom developments and integrations. The most important contract for external consumption is:

Contract	Description
C1	Released for customer and partner consumption. SAP guarantees a stable public interface and backward-compatible changes within the contract scope.

According to SAP, only specific CDS views that follow the C1 stability contract are officially released for customer and partner reuse. These released views are intended for long-term consumption scenarios and are the recommended objects for integrations, reporting solutions, and custom applications. Nexus can extract data from SAP CDS Views regardless of their VDM layer or Stability Contract classification

Official SAP References

For more information about the SAP Virtual Data Model (VDM) and CDS view architecture, refer to the official SAP documentation:

• Virtual Data Model and CDS Views (SAP Help Portal)

• VDM Layers and View Types (SAP Help Portal)

Basic Views (Interface Views)

Basic views are built directly on top of database tables and are the only CDS views that access database tables directly. They provide business-friendly field names and enrich the data model with metadata and associations.

Examples

Database Table	Basic CDS View	Business Object
KNA1	I_Customer	Customer Master
MARA	I_Product	Material/Product Master
VBAK	I_SalesOrder	Sales Order Header
VBAP	I_SalesOrderItem	Sales Order Item
BKPF	I_JournalEntry	Accounting Document Header
BSEG	I_OperationalAcctgDocItem	Accounting Document Item

Example Relationship

KNA1
  ↓
I_Customer

Annotated with:

@VDM.viewType: #BASIC

Composite Views (Interface Views)

Composite views are based on basic views and/or other composite views. They combine data from multiple sources and add business semantics and logic without directly accessing database tables.

Examples

Composite CDS View	Description
I_SalesOrderCube	Sales Orders combined with items and customer information
I_BillingDocumentCube	Billing header and item information
I_InventoryCube	Product and inventory information
I_ProfitCenterPlanActualCube	Financial actual and plan data

Example Relationship

I_SalesOrder
       +
I_SalesOrderItem
       +
I_Customer
       ↓
I_SalesOrderCube

Annotated with:

@VDM.viewType: #COMPOSITE

Consumption Views

Consumption views form the top layer of the VDM. They are built on reuse views (basic and composite views) and are designed for specific business use cases such as reporting, analytics, APIs, and applications. They access database tables only indirectly through the reuse layer.

Examples:

• SAP Fiori applications
• OData services
• KPI dashboards
• Analytical queries

Examples

Consumption CDS View	Usage
C_SalesOrderQry	Sales Order analytics
C_BillingDocumentQry	Billing analytics
C_ProfitCenterPlanActualQry	Financial reporting
C_GLLineItemsQ0001	General Ledger reporting
C_ProductSalesPerformanceQry	Sales performance analysis

Example Relationship

I_SalesOrderCube
        ↓
C_SalesOrderQry
        ↓
Fiori App / OData Service / KPI Dashboard

Annotated with:

@VDM.viewType: #CONSUMPTION

SAP Reports

Nexus can extract data from an SAP report if the report can be executed automatically and its results can be exported from SAP GUI. In practice, this means the report must:

• Be implemented as an ABAP program.
• Provide an initial selection screen for entering parameters and filters.
• Produce its results in a tabular format after execution.
• Allow the table output to be exported to a file using standard SAP GUI functionality.

Nexus follows the same process as a user in SAP GUI: it executes the report, populates the selection parameters, and exports the resulting table output. Nexus does not extract the report itself—it extracts the exported table data. Therefore, as a rule of thumb, if a user can run the report, enter selection parameters, view the results in a table, and export that table to a file, the report can generally be extracted by Nexus.

ECC vs. SAP S/4HANA Data Model Considerations

Overview

When extracting data from SAP systems, it is important to understand that SAP S/4HANA introduced significant data model changes compared to SAP ECC. Many traditional tables still appear to exist in S/4HANA, but in reality they may be implemented as Compatibility Views rather than physical database tables. SAP introduced these views to preserve backward compatibility for existing reports, custom developments, extractors, and integrations.

As a result, data extraction tools such as Nexus can often continue to access familiar ECC objects while customers transition to S/4HANA.

Compatibility Views

Compatibility Views are SAP-delivered CDS-based views that map legacy ECC table structures to the new S/4HANA data model. They act as an abstraction layer between old application logic and new physical tables.

For example:

ECC Object	S/4HANA Replacement
MSEG	MATDOC (via compatibility view)
COEP	Universal Journal (ACDOCA) via compatibility view
COSP / COSS	Universal Journal structures via compatibility views
Various FI/CO tables	Consolidated into ACDOCA

SAP's goal is to allow existing custom code and integrations to continue functioning with minimal changes after a system conversion.

---

Important Extraction Guidance

Compatibility Views Are Supported

Nexus can extract from compatibility views just as it can from regular SAP tables because SAP exposes them through standard interfaces. This allows existing extraction packages to continue operating after many ECC-to-S/4HANA migrations.

Prefer Native S/4HANA Objects When Possible

While compatibility views are convenient, SAP recommends using the new S/4HANA data model where possible. Compatibility views exist primarily for backward compatibility and may introduce additional joins, unions, or business logic layers.

For new projects, consider using:

• CDS Views
• CDS View Entities
• Business Partner objects
• Universal Journal (ACDOCA)
• Material Document table (MATDOC)
• Released SAP APIs and OData services

rather than relying solely on legacy ECC structures.

Performance Considerations

Some compatibility views can be significantly more complex than the original ECC tables they emulate. In certain cases SAP compatibility views perform joins and transformations across multiple underlying objects. Large-scale extractions should therefore be validated for performance during implementation.

Key SAP ECC vs. SAP S/4HANA Data Model Changes

Area	SAP ECC	SAP S/4HANA
Financial Accounting & Controlling	FI and CO data distributed across multiple tables such as BKPF, BSEG, COEP, COSP, and COSS	Financial and controlling data consolidated into the Universal Journal (ACDOCA). Legacy tables are often implemented as compatibility views.
Inventory Management	Material document and inventory information stored across tables such as MKPF and MSEG	Inventory transactions are primarily stored in MATDOC. Legacy objects such as MSEG are exposed through compatibility views.
Customer & Vendor Master Data	Separate master data objects for customers (KNA1) and vendors (LFA1)	Unified Business Partner (BP) model replaces separate customer and vendor master concepts.
Data Access Layer	Physical ECC tables used directly by reports, custom developments, and integrations	Many legacy tables are implemented as Compatibility Views that map old structures to the new S/4HANA data model.
Reporting Model	Data often spread across multiple application-specific tables requiring reconciliation	Simplified and harmonized data model enabling real-time analytics and reporting directly on consolidated structures

Extraction Recommendation

For SAP S/4HANA systems:

• Existing ECC-based extraction scenarios frequently continue to work through SAP compatibility views.
• For new implementations, prefer CDS Views, CDS View Entities, Business Partner objects, ACDOCA, and MATDOC where feasible.
• Validate extraction performance when compatibility views are involved, as some views can be significantly more complex than the underlying S/4HANA tables.

Finding Whether an Object Is a Compatibility View

In SAP GUI:

1. Open transaction SE16N
2. Enter the table name
3. If SAP displays a Proxy Object, the object is likely backed by a compatibility view
4. Navigate to SE11 to inspect the underlying CDS definition and physical tables involved

This can help determine whether an extraction is accessing a physical table or a virtual compatibility layer.

SAP References

For customers planning SAP ECC to SAP S/4HANA migrations, SAP provides extensive documentation covering compatibility objects and data model simplifications:

• SAP Note 2595627 – Compatibility Views in SAP S/4HANA – Compatibility views in S/4HANA.
• SAP S/4HANA Simplification List (SIMPL_OP2023) – Complete overview of S/4HANA data model changes.
• SAP S/4HANA Migration and Conversion Guides – Official migration and conversion guidance.

These documents provide detailed mappings of obsolete ECC tables, replacement structures, and functional changes introduced in SAP S/4HANA.