Working with Semantic Groups


After completing this lesson, you will be able to Describe how to partition data using a Semantic Group.

Role of Semantic Groups in SAP BW/4HANA

Semantic Groups in SAP BW/4HANA is the successor of the Semantically Partitioned Object of SAP BW.

Unlike the Semantically Partitioned Object of SAP BW, the Semantic Group of SAA BW/4HANA is not an InfoProvider. This means you do not build a query on top of it. A Semantic Group is a tool used to generate multiple DataStore Objects (advanced) from a reference semantically-related DataStore Object (advanced). A optional CompositeProvider can be generated to simplify reporting and analysis over all of the DataStore Object (advanced) of a Semantic Group. Using semantically partitioned data models, Semantic Groups offer the following advantages when compared with an individual DataStore Object (advanced):

  • Better performance with mass data, because the data sets are distributed over several DataStore Objects (advanced).

  • Isolation of the data: Error handling is improved because only the data that was loaded with errors to one of the DataStore Object (advanced) of the Semantic Group is unavailable for data analysis.

  • Working with different time zones: Data loading and administrative tasks can be scheduled independently of the time zone.

SAP HANA simplifies the architecture compared to Semantically Partitioned Objects. The Semantic Group requires a smaller number of technical components.


The Semantic Group is not a transportable object. Only the generated objects of a Semantic Group can be transported.

You can easily generate new components from a Semantic Group at any time. The structure is copied from a DataStore Object (advanced) template. If common data exists, an existing DataStore Object (advanced) can also be added to the group. The DataStore Object (advanced) members of a Semantic Group remain independent objects and can be queried standalone.

Data Staging:

When loading data to a DataStore Object (advanced) that is part of a Semantic Group, a filter in the DTP ensures that only data that is suitable for the DataStore Object (advanced) as part of the Semantic Group is extracted. The DTP request is given the status "green", even if records have been filtered out. The partition criteria, using filters, are implemented in the transformation. This prevents that data from being posted to the DataStore Object (advanced) that does not match the partition criteria.


To avoid any misunderstanding, the function of Semantic Groups that was introduced in the DTP of SAP BW 7.x, has been renamed to Extraction Grouped By in SAP BW/4HANA. The meaning is still the same: Data records with the same values in the selected fields form a logical key and are processed together in one data package.


When you create the Semantic Group, you can generate a CompositeProvider that includes all DataStore Objects (advanced) in the Semantic Group. The CompositeProvider uses a union to combine them. The CompositeProvider is used for reporting and analysis. This CompositeProvider is overwritten every time a change is made to the Semantic Group. The CompositeProvider should therefore not be changed manually.


There is a no specific authorization for working with a Semantic Group. These authorizations are covered by the related objects (S_RS_DataStore Object (advanced), S_RS_HCPR). There is no authorization object (for example, S_RS_SEGR), for a Semantic Group as it is not a TLOGO object.

Transport Management:

The Semantic Group itself cannot be transported as it is not a TLOGO object. In the DEV system, objects are generated from the Semantic Group. These objects can be transported to the production system if all objects are in the same package and all objects are on the same request. There is no folder called "Semantic Groups" nor the Semantic Group itself is visible if you open the BW Modeling Tools of the QA/PROD system. Since the Semantic Group is a tool for generation of grouping of DataStore Objects (advanced) you cannot edit or even see the reference in the QA/PROD system. Any change has to be done in the DEV-system and then the changes can be transported (see also SAP Note 2622170). Please note in addition, that some restrictions apply for changing a Semantic Group.

Custom Development:

If customer code is refers to a DataStore Object (advanced) that is part of a Semantic Group, the table RSIPRORANGE (also in QA/PROD-system) manages the partition criteria of the DataStore Object (advanced). This table can be used to identify the suitable DataStore Object (advanced) for a customer look-up. In the meta data of a DataStore Object (advanced) which is stored in table RSODataStore Object (advanced), there are also fields which relate to the usage within a Semantic Group. However, the Semantic Group maintenance metadata is only available in the development system (tables RSOSEGR, RSOSEGRT, RSOSEGRLOC, RSOSEGR_MEMBER, RSOSEGR_RANGE).

Application Programming Interface (API):

To support on-going maintenance of Semantic Groups, an API is available. The API can be used to manage ‘homogeneous’ groups which consists of DataStore Objects (advanced) that are identical differing only in the Semantic Group criteria. Using the UPDATE method, it is possible to change the definition of all group members simultaneously as well as adding new or removing existing group members. The API does not provide all the functionality of the UI. For example, when working with ‘mixed’ groups, that is DataStore Objects (advanced) with different field-lists or ‘added’ DataStore Objects (advanced). These are not supported by the API. The API class is CL_RSO_SEGR_API and the related methods are CREATE, READ, UPDATE and DELETE.


Additional details about the creation and maintenance of Semantic Groups and its objects can be found in this documentation:

Launch the next demo to explore the settings of a Semantic Group in BW Modeling Tools:

Explore a Semantic Group with BW Modeling Tools

Log in to track your progress & complete quizzes