Application Development and Automation Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Ravikumar_H1
Explorer
2,464

In this blog, we'll dive into multi-origin in CDS views, understand its use cases, and explore how to implement it with practical examples. By the end, you’ll have a clear understanding of why this feature is valuable and how to leverage it for your SAP S/4HANA applications.

What is Multi-Origin in CDS Views?

Multi-origin in CDS views refers to the ability to handle data originating from multiple sources or tenants in a single data model. This is especially relevant for scenarios like:

  • Multi-tenancy: Managing data for multiple tenants in a shared SAP system.
  • Cross-system reporting: Combining data from multiple systems (e.g., SAP and non-SAP).
  • Consolidated views: Aggregating data from various tables or partitions while maintaining source traceability.

The multi-origin feature uses a special field, typically referred to as the $session.client, or custom fields such as MANDT, to identify the data's origin.

Use Cases for Multi-Origin in CDS

  1. Multi-Tenancy in S/4HANA:

    • A shared S/4HANA system serving multiple tenants where each tenant's data is segregated logically but stored in the same database.
    • CDS views can dynamically filter data based on the current tenant or client.
  2. Consolidated Reporting Across Clients:

    • Reporting across multiple SAP clients (e.g., Client 100, Client 200), where you want to show aggregated or tenant-specific data.
  3. Data Integration from Different Sources:

    • Merging data from different systems (e.g., SAP ECC and non-SAP) into a unified CDS view.

How Multi-Origin Works in CDS Views

Multi-origin functionality is enabled using:

  1. Session Variables: For example, $session.client dynamically filters data based on the user's client session.
  2. Annotation @Environment.systemField: This annotation marks fields (like MANDT) as automatically filtered by the system.

Step-by-Step Implementation

1. Defining a Basic Multi-Origin CDS View

Below is a simple example of a CDS view for handling data from multiple clients

@AbapCatalog.sqlViewName: 'ZMULTIORIG'
@EndUserText.label: 'CDS View with Multi-Origin Support'
@AccessControl.authorizationCheck: #CHECK
define view ZMulti_Origin_Sales
  as select from zsales_data
{
  key SalesID          as Sales_ID,
      Client           as Origin_Client, -- Represents the origin (MANDT)
      CustomerID       as Customer_ID,
      SalesDate        as Sales_Date,
      ProductID        as Product_ID,
      Quantity         as Quantity,
      Amount           as Amount
}
where Client = $session.client

 

How it Works:

  • The field Client (or MANDT) identifies the origin of the data.
  • The filter Client = $session.client ensures that users see only the data corresponding to their current session's client.

2. Multi-Origin with Aggregations

Suppose you want to aggregate sales data across multiple origins (clients). Here's how you can extend the basic CDS view

@AbapCatalog.sqlViewName: 'ZMULTIORIGAGG'
@EndUserText.label: 'Aggregated Multi-Origin CDS View'
@AccessControl.authorizationCheck: #NOT_REQUIRED
define view ZMulti_Origin_Aggregated
  as select from ZMulti_Origin_Sales
{
  Origin_Client,
  Product_ID,
  sum(Amount) as Total_Sales
}
group by Origin_Client, Product_ID

 

Explanation:

  • This view aggregates the Amount field by Origin_Client and Product_ID.
  • It allows consolidated reporting while preserving the ability to differentiate between data origins.

3. Multi-Origin with Tenant Identification

For multi-tenant systems, you can use annotations like @Environment.systemField to simplify client filtering

@AbapCatalog.sqlViewName: 'ZMULTIORIGTEN'
@EndUserText.label: 'Multi-Tenant CDS View'
@AccessControl.authorizationCheck: #CHECK
define view ZMulti_Tenant_Sales
  as select from zsales_data
{
  key SalesID          as Sales_ID,
      CustomerID       as Customer_ID,
      SalesDate        as Sales_Date,
      ProductID        as Product_ID,
      Quantity         as Quantity,
      Amount           as Amount
}
where Client = @Environment.systemField: client

 

Here, the annotation @Environment.systemField: client automatically handles the client filtering, reducing the need for explicit $session.client usage.

4. Cross-Client Reporting Without Filters

In some cases, you may want to disable client-based filtering to create a global view that includes all data from all origins

@AbapCatalog.sqlViewName: 'ZGLOBALVIEW'
@EndUserText.label: 'Global View Without Client Filtering'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@ClientHandling.type: #NONE
define view ZGlobal_Sales_View
  as select from zsales_data
{
  key Client           as Origin_Client,
      SalesID          as Sales_ID,
      CustomerID       as Customer_ID,
      SalesDate        as Sales_Date,
      ProductID        as Product_ID,
      Quantity         as Quantity,
      Amount           as Amount
}

 

Here, the annotation @ClientHandling.type: #NONE disables client-specific filtering, making the view cross-client.

Sample Output

Here’s what the output might look like for the above views:

Scenario 1: Data for Single Origin

Sales_ID  Origin_Client  Customer_ID  Sales_Date  Product_ID  Quantity  Amount
1001      100	         CUST01	      2024-01-05  PROD001     10        500.00
1002	  100	         CUST02	      2024-01-15  PROD002     5	        250.00

 

Scenario 2: Aggregated Data Across Origins

Origin_Client     Product_ID       Total_Sales
100               PROD001          500.00
200               PROD002          1000.00

 

Scenario 3: Global Cross-Origin View

Origin_Client  Sales_ID  Customer_ID  Sales_Date  Product_ID  Quantity  Amount
100            1001      CUST01       2024-01-05  PROD001     10        500.00
200            1002      CUST02       2024-01-15  PROD002     5         250.00

 

Best Practices for Multi-Origin CDS Views

  1. Use Annotations:

    • Use @Environment.systemField: client for tenant-specific views.
    • Use @ClientHandling.type: #NONE for cross-origin views.
  2. Test for Performance:

    • Multi-origin queries can be resource-intensive. Optimize with proper indexes and aggregations.
  3. Combine with AMDP or CDS Hierarchies:

    • Extend multi-origin views with hierarchies or AMDP for complex scenarios like forecasting or migrations.

Conclusion

Multi-origin in CDS views is a powerful feature that simplifies handling data from multiple sources or tenants. Whether you're building tenant-specific models, cross-client reports, or global views, understanding and leveraging this feature can enhance your SAP applications’ efficiency and scalability.

1 Comment