5.4    SAP BW/4HANA InfoProviders

SAP BW/4HANA InfoProviders are modeling objects comprised of measures and contextual elements that represent a specific view of the data. Previous releases of SAP BW restricted the modeling of InfoProviders to be based solely on InfoObjects. Inbound data first was associated to InfoObjects during data provisioning before being made available in InfoProviders and queries. Data integration was a prerequisite for reporting functionality.

Any modeling activity started by making sure that all required InfoObjects, the smallest building blocks for an InfoProvider, were already available in SAP BW. If that wasn’t the case, then the first step was to create the necessary InfoObjects. This could represent undesired overhead, especially for cases such as prototyping, one-time data loads, or ad hoc reporting requirements.

However, SAP BW/4HANA InfoProviders can be modeled based on InfoObjects or directly with fields that follow specifications from external sources. This new modeling option available for SAP BW/4HANA InfoProviders is known as field-based modeling; we’ll discuss it next.

5.4.1    Field-Based Modeling

SAP BW/4HANA allows for field-based modeling in addition to InfoObject-based modeling when defining InfoProviders. With field-based modeling, InfoProviders can be defined with generic fields that follow the specifications of external data sources, such as for data type and length. Queries can be created on top of field-based InfoProviders the same way as with InfoObject-based ones. Reporting functionality in SAP BW/4HANA thus can be provided with or without associations with InfoObjects.

Choosing between field-based or InfoObject-based modeling depends on reporting requirements. If you want external content enhanced with attributes, hierarchies, and descriptions already stored in SAP BW/4HANA, then you should associate external fields with InfoObjects.

However, if your objective is more aligned with punctual analysis, prototyping, or even isolated data analysis, then the field-based approach could be effective. In this case, to allow queries on field-based InfoProviders the system will automatically convert the external fields into internal, temporary InfoObjects at the query level, with a naming convention following the pattern 2F<InfoProvider>-<field name>.

Certain reporting restrictions are applicable to field-based InfoProviders, however (described in SAP Note 2185212, ADSO: Recommendations and restrictions regarding reporting). Only field names not longer than 20 characters are visible directly in reporting. Table 5.10 shows the required lengths for various fields for both characteristics and key figures.

Field Length
Characteristics
CHAR 1–250
NUMC 1–250
CUKY 5
UNIT 3
LANG 1
DATS 8
TIMS 6
Key Figures
INT4
FLOAT
DEC 16–31; decimal places 0–14
CURR Length 1–31; decimal places 1–14 (there must be an assignment to a CUKY characteristic, and the length must be greater than or equal to the number of decimal places)
QUAN Length 1–31; decimal places 0 –14 (there must be an assignment to a UNIT characteristic, and the length must be greater than or equal to the number of decimal places)

Table 5.10    Required Field Lengths for Characteristics and Key Figures

5.4.2    Open ODS Views

Open ODS views are SAP BW/4HANA metadata objects that represent the structure of an external data source. Open ODS views, as the name suggests, are nonpersistent. They’re mainly used for data virtualization and association of external data source fields with existing InfoObjects.

Data sources for an Open ODS view can vary, from SAP HANA tables to third-party tables located in external databases or data pools. Creating a new open ODS view follows similar steps as those for any other InfoProvider: Right-click an InfoArea and select the option to create a new Open ODS view. Basic parameters include technical ID and a meaningful description. Unique to Open ODS views, however, are the Semantics and Source Type parameters, as shown in Figure 5.12; these must be specified when defining such an InfoProvider.

Defining Open ODS View InfoProvider

Figure 5.12    Defining Open ODS View InfoProvider

These parameters can have the following effects:

After providing the general specifications the next step for creating an Open ODS view is to complete the modeling of its structure. As an example, assume that table SALES_DATA was created directly in the SAP HANA database with sales data originating from a non-SAP system. The fields of such a table follow the naming conventions and definitions of the source system and differ from SAP terminology.

The goal here is to have this data reported alongside similar data coming from SAP sources. An Open ODS view can be created easily, allowing for the virtualization and consumption of this non-SAP sales data by the SAP BW/4HANA application.

To accomplish this, Open ODS view ZODSV1 is defined with Semantics set to Facts and Source Type set to Database Table and View. The system looks for the definition of the data source—in this case, the details of the table or view to supply data to the Open ODS view. It’s necessary to indicate the SAP schema and table name for setting up the connection. Open ODS view ZODSV1 is then assigned to table SALES_DATA within the SAP HANA database.

To model the Open ODS view, we drag the fields of interest from table SALES_DATA, available under Source Field, and drop them into the corresponding folders of the Open ODS view, under View Field, as shown in Figure 5.13.

Modeling Open ODS View Structure

Figure 5.13    Modeling Open ODS View Structure

After completing the modeling, the Open ODS view can be activated and queries can be built directly on top of it. In such a scenario, SAP BW/4HANA queries would rely on field modeling, because associations with InfoObjects have been made during the Open ODS view definition.

Right-clicking the Open ODS view opens a context menu containing the option to create a new SAP BW/4HANA query (see Figure 5.14).

Creating SAP BW/4HANA Query on Field-Based Open ODS View

Figure 5.14    Creating SAP BW/4HANA Query on Field-Based Open ODS View

Because the Open ODS view ZODSV1 is based on field modeling, any query created on top of it will contain elements with the naming convention 2FZODSV1-<field name> (for example, 2FZODSV1-ORDER_DATE; see Figure 5.15).

Field-Based Query Definition Following Naming Convention 2<InfoProvider>-<field name>

Figure 5.15    Field-Based Query Definition Following Naming Convention 2<InfoProvider>-<field name>

It’s also possible to enrich the external content view via an association feature available in the Open ODS view definition screen. Association refers to assigning the fields of an Open ODS view to existing SAP BW/4HANA elements such as an InfoObject, thus inheriting the InfoObject’s master data content, including attributes, text, and hierarchies.

To demonstrate the association feature, the definition of Open ODS view ZODSV1 can be modified. The CUSTOMER_NAM field can be associated with InfoObject ZCUSTOMER, as shown in Figure 5.16. This InfoObject is of type characteristic and contains language and forecast strategy attributes.

Modified Open ODS View Definition

Figure 5.16    Modified Open ODS View Definition

The Direct Usage of Associated Object by Name property can also be set to ZCUSTOMER. By doing so, the CUSTOMER_NAM field will be presented as InfoObject ZCUSTOMER to subsequent SAP BW procedures and queries.

After this, the CUSTOMER_NAM field will act and feel like InfoObject ZCUSTOMER. The attributes of ZCUSTOMER will be made available during query definition, and any display property will, by default, follow the InfoObject definition. The field-based modeling is thus superseded by the associated SAP BW data model. Figure 5.17 shows the Open ODS view ZODSV1 fields during query creation after association has been set. As shown, ZCUSTOMER and its related attributes are now available for selection instead of the CUSTOMER_NAM field.

ZCUSTOMER InfoObject and Related Attributes Made Available for Query Definition after Association at Open ODS View Level

Figure 5.17    ZCUSTOMER InfoObject and Related Attributes Made Available for Query Definition after Association at Open ODS View Level

5.4.3    Advanced DataStore Objects

Advanced DSOs are the central objects for data persistency in SAP BW/4HANA. These are very flexible modeling objects that can be configured to address different data retention scenarios, including data overwriting, additive behavior, and change log-based delta processes.

Advanced DSOs are comprised of three tables: the inbound table, active table, and change log. The modeling properties of an Advanced DSO are set according to data-retention requirements and determine which of these three tables are to be generated.

The options available for modeling Advanced DSOs are centered on data-writing procedures and how existing data content is to be updated against potential changes triggered by inbound data.

Inbound data is commonly written to the inbound table of an Advanced DSO. From there, it can be transferred to the active table following a process known as activation/compression. The activation can generate change logs that may then be stored in the change log table.

As shown in Figure 5.18, the general definition screen of an Advanced DSO contains the modeling options available in the left panel and predefined model templates on the right panel. Model templates cover the most typical data architectural requirements. After selecting a model template, the corresponding modeling properties are set automatically.

The modeling properties can also be set manually by flagging the options related to activation needs and special types of data input. The system validates the options as they’re selected by inactivating certain property combinations. The modeling properties available to be set manually are as follows:

Modeling Options Available When Defining Advanced DSOs

Figure 5.18    Modeling Options Available When Defining Advanced DSOs

Let’s dive into each of these modeling options with the assistance of diagrams depicting the three Advanced DSO tables:

As noted earlier, SAP offers model templates that consist of predefined Advanced DSO property settings. These settings create Advanced DSOs to address the most common data warehousing modeling scenarios.

Some of these model templates use a naming convention that refers explicitly to classic SAP BW metadata modeling objects, such as InfoCubes or standard DSOs. Table 5.11 lists each model template and its corresponding modeling properties set in the Advanced DSO configuration.

Model Template Group Model Template Name Advanced DSO Modeling Properties
Enterprise data warehouse architecture Data-acquisition layer (including corporate memory)
  • None
Enterprise data warehouse architecture Corporate memory— compression capabilities
  • Activate Data
Enterprise data warehouse architecture Corporate memory— reporting capabilities
  • Activate Data
  • Keep Inbound Data, Extract from Inbound Table
Enterprise data warehouse architecture Data warehouse layer— delta calculation
  • Activate Data
  • Write Change Log
Enterprise data warehouse architecture Data warehouse layer— data mart
  • Activate Data
  • All Characteristics are Key, Reporting on Union of Inbound and Active Table
Planning Planning in InfoCube-like manner
  • All Characteristics are Key, Reporting on Union of Inbound and Active Table
  • Planning Mode
Planning Planning on direct update
  • Direct Update
  • Planning Mode
Classic objects Standard DSO
  • Activate Data
  • Write Change Log
Classic objects Write-optimized DSO
  • None
Classic objects InfoCube
  • Activate Data
  • All Characteristics are Key, Reporting on Union of Inbound and Active Table

Table 5.11    Model Templates and Related Advanced DSO Properties

5.4.4    CompositeProvider

CompositeProviders are metadata objects of a nonpersistent nature. Their primary purpose is to act as a logical layer that combines the content of different datasets for reporting and analysis. CompositeProviders make use of union and join SQL operations to harmonize data from SAP BW/4HANA InfoProviders and SAP HANA views, forming an output structure for query consumption. The modeling complexity is thus transparent for the report user.

A CompositeProvider is created like any other SAP BW/4HANA InfoProvider: Select an InfoArea within the SAP BW/4HANA application, right-click, and choose New • CompositeProvider. After providing a technical name and a description, the next step is to select the datasets (i.e., InfoProviders) and SQL operation types (union or join) required for the desired modeling output.

For example, let’s imagine a modeling scenario in which three objects must be combined in a report. The first is InfoObject type characteristic ZCUSTOMER and stores the customer master data, which includes, in addition to customer IDs, the language and forecast strategy attributes.

The other two objects are transactional repositories containing sales transaction data. One is an Advanced DSO, ZADVDSO, storing sales data originating from SAP sources and persisted in the SAP HANA database. The other is Open ODS view ZODSV1, which allows for visualization of sales data from external sources. The reporting requirement is to have the sales revenue combined and summarized by customer in one dataset enriched with attributes for reporting purposes. A possible solution could be to create a union combining the two sets of sales transactions first, followed by a join of the resulting data set with the master data attributes.

For this, a CompositeProvider using a SQL union operation can be created to combine the contents of Advanced DSO ZADVDSO and Open ODS view ZODSV1. This CompositeProvider will then be joined subsequently to master data ZCUSTOMER. The first step is to provide a technical name (ZCP_U1) and a description (Composite Provider Union 1) for our union-based CompositeProvider, as shown in Figure 5.31.

CompositeProvider Union Initial ScreenCompositeProviderunion

Figure 5.31    CompositeProvider Union Initial Screen

Click Next at the bottom of the composite initial screen. On the next screen, select the SQL operation and InfoProviders that should be part of the model. For this example, these parameters define a union between Advanced DSO ZADVDSO and Open ODS view ZODSV1. This is done by adding these two InfoProviders under Union Providers (see Figure 5.32). Click Finish to proceed to the CompositeProvider definition screen.

Selecting Union of InfoProviders for CompositeProvider ZCP_U1

Figure 5.32    Selecting Union of InfoProviders for CompositeProvider ZCP_U1

The CompositeProvider definition screen contains three tabs: General, Scenario, and Output. On the General tab, runtime properties can be set that cover many aspects, such as parallel processing, access to near-line storage data, data integrity checks, and caching, among others.

In our example the CompositeProvider union ZCP_U1 will be used in a subsequent join with customer master data, so the property This CompositeProvider Can Be Added to Another CompositeProvider is selected in the General tab (see Figure 5.33).

Allowing CompositeProvider Union to be Used by Other CompositeProviders

Figure 5.33    Allowing CompositeProvider Union to be Used by Other CompositeProviders

The modeling of the output structure is defined in the Scenario tab by dragging and dropping the fields from each InfoProvider within the Source section into the output structure within the Target section of the CompositeProvider. The union procedure is established automatically if the same InfoObjects are dragged from different InfoProviders, as shown in Figure 5.34.

Defining Output Structure and Union Operation of CompositeProvider via Scenario Tab

Figure 5.34    Defining Output Structure and Union Operation of CompositeProvider via Scenario Tab

The semantics of a CompositeProvider output structure can be further enhanced in the Output tab. This could include updates to the descriptions of the structural elements and association with InfoObjects, pertinent when field-based modeling objects are being combined under a CompositeProvider but should be reported based on InfoObjects at the query level.

When modeling is complete, the ZCP_U1 CompositeProvider union can be activated. The next step is to create a second CompositeProvider to perform the join operation between ZCP_U1 and InfoObject ZCUSTOMER. This is done by defining a new CompositeProvider, ZCP_J1 (CompositeProvider join 1), combining both InfoProviders using a SQL union operation. The steps are very much like those we used to create the first CompositeProvider, ZCP_U1.

After providing a technical ID (ZCP_J1) and description (CompositeProvider Join 1) for the new CompositeProvider, click Next to add ZCP_U1 and ZCUSTOMER to the Join Providers section (see Figure 5.35).

Selecting Join Operation PartProviders for CompositeProvider ZCP_J1PartProvider

Figure 5.35    Selecting Join Operation PartProviders for CompositeProvider ZCP_J1

The join type can be inner or left outer. For CompositeProviders with left-outer joins, the sequence in which the InfoProviders are added to the Join Providers section is important. If a left outer join is chosen, then the first InfoProvider added to this section will drive the join.

The sequence of providers and the join type can be changed in the CompositeProvider screen during modeling, however, under the Scenario tab. To do so, right-click on top of the join element and select an option from the context menu (see Figure 5.36):

In our example, CompositeProvider ZCP_J1 will use an inner join type. The next step is to drag and drop the elements from the source section to the target section, thus defining the output structure of CompositeProvider Join 1. Because this is a join instead of a union, the customer ID available in both InfoProviders only needs to be dragged over once to be available in the output structure.

The Customer ID and related Language and Forecast Strategy attributes are dragged from the source area represented by ZCUSTOMER InfoObject into the target structure. The key figure Amount USD is dragged from the CompositeProvider ZCP_U1 which reflects the union of sales transactions from SAP sources (Advanced DSO ZADVDSO) and external sources (Open ODS view ZODSV1).

Now, it’s time to define the join condition. Right-click ZCUSTOMER under Source and choose Create Join Condition Field from the context menu. Now, you can define the join between the two InfoProviders. The join in this case will be based on InfoObject ZCUSTOMER, available in both InfoProviders (see Figure 5.37).

Defining Join Condition Field between InfoProviders

Figure 5.37    Defining Join Condition Field between InfoProviders

Now, the join condition is integrated into the output structure, as shown in Figure 5.38. CompositeProvider ZCP_J1 can now be activated and made available for reporting and analysis.

Join Condition Defined within Output Structure of CompositeProvider ZCP_J1

Figure 5.38    Join Condition Defined within Output Structure of CompositeProvider ZCP_J1