With SAP NetWeaver BW 7.3 SAP has provided improvements to existing InfoProviders and more importantly introduced some brand-new ones. These new ones include CompositeProviders, HybridProviders, semantically partitioned objects (SPOs), a query itself, and TransientProviders. Add these new ones to the existing different types of InfoCubes, three kinds of DataStore objects (DSOs), MultiProviders, and InfoObjects and confusion may result. I review the basics, introduce you to the new ones, and explain why you would use them. First here are some caveats about InfoProviders:

• InfoProviders do not have to be physical tables. They can just be run-time objects.
• Some reporting applications let you access an InfoProvider directly, without first writing a query on it. Basically when this happens the system is writing a query for you with all the characteristics and key figures initially available.
• Just because you could write a query against an object does not mean you have to (see the note above).
• Some InfoProviders are not exposed to reporting tools via authorizations. In these cases you may not be allowed to create a query.
• Although the word “info” as part of InfoProvider implies that the data being queried has had a cleansing transformation already performed on it, this is no longer true for all InfoProviders. For example, in the case of TransientProviders, no such cleansing has occurred.

Following is a list of all the varieties of 7.3 InfoProviders with a descriptive overview. For each InfoProvider I bullet the benefits and when to use them and identify the improvements that are specific to HANA.

Physical InfoProviders

Physical InfoProviders are based on physical tables under the control of the SAP NetWeaver  BW schema on the HANA database. Users are actually querying these underlying tables when they are executed against the objects below, known as InfoProviders. InfoObjects (as InfoProviders): Business evaluation objects are known in BW as InfoObjects. They are divided into characteristics (for example, customers), key figures (revenue), units (currency or amount unit), time characteristics (fiscal year), and technical characteristics (request number). Only characteristic InfoObjects are used for InfoProviders. When InfoObjects are permitted as InfoProviders the BW Modeler allows the use of the master data attributes and text of a characteristic InfoObject for direct query access. An example is a query producing a list of the employees of a company, including their names and email addresses. InfoObject features and when to use them:

• Use features when you want master data in a report but do not need any transaction data. InfoObjects must be enabled as InfoProviders via the context menu of the InfoProvider tree.
• HANA specific: Activation of newly loaded master data can be enabled on the Data Transfer Process (DTP) that loads it. The hierarchy attribute change run is not needed anymore.
• HANA specific: Virtual master data can be sourced from special HANA-specific views called attribute views.

DSOs

DSOs have existed since nearly the beginning of BW under the name Operational Data Stores. They are objects primarily designed to store data on the transactional level. An example is an object to store the cost center transactions in detail for a company. There are three DSOs (write optimized, direct update, and standard), each with different table structures and purposes within the Layered, Scalable Architecture++ (LSA++). Standard DSOs consist of three tables, as shown in Figure 1. These standard DSOs provide a technical function to generate a clean record-level delta image when the source cannot. This process is called activation of the requests. All three types of DSOs in general provide detailed data that can be used for reporting or propagation to follow on InfoProviders for aggregated reporting. DSO features and when to use them:

• Use standard DSOs when you want detailed data stored in a cleaned-up homogenized way. They are required in some situations (like the situation depicted in Figure 1), when the DataSource sends the after image (the current) state of the record (20 as shown in Figure 1) when a record in the source changes.
• HANA-specific standard DSO feature: The activation process (the most time-consuming step in the extraction, transformation and loading [ETL] process) is drastically improved because the activation logic is executed on the HANA database, not on the application server.

Write-Optimized DSOs

Write-optimized DSOs are single table objects designed with a technical key (request, package, or record) that makes every record unique by default. They are used primarily to maintain detailed homogenized versions of the state of source system records and the changes to these records just as they occur in the source. Their big difference versus standard DSOs is that they do not provide the generated delta image at the record level. Write-optimized features and when to use them:

• Use them when you want detailed data stored in a cleaned-up homogenized way but do not need the feature discussed above (record-level delta) that the standard DSOs provide. Use them to store an audit of all changes to the source system transactions’ corporate memory. Because they do not have an activation step, they are very fast to load. Finally, one feature worth noting is that these objects are partitioned automatically by request for performance improvements.

Direct Update DSOs

Not much has changed with direct update DSOs. These DSOs are basically a single table with a business-based key. They were and still are used behind the scenes in Financials consolidations, as targets in the Analysis Process Designer (APD), and as direct updates via BAPIs. Like a write-optimized DSO, they are a single table, but unlike all other physical InfoProviders they get their data using a BAPI or via the APD, not via DTPs and transformations. An example of an analysis process using the APD transaction code RSANWB is shown in Figure 2. The Analytical Index shown in Figure 2 is discussed later. For now focus on the top right corner of this figure, which is the direct update DSO.

InfoCubes

These original BW objects are SAP’s version of an industry standard term called a star schema.   They consist of collections of tables designed to store transactional data at a summarized level. A sales cube would store sales by customer, part number, sales organization, and month. Cubes link to the characteristic InfoObject’s master data through a technical table called SID for a robust collection of fields to analyze a business process. Figure 3 is a graphical representation of a cube. InfoCube features and when to use them:

• Use them when you want summarized data for many years, yet still want fast reporting performance. For non-HANA BW systems further aggregation can be accomplished with the use of another BW object called an aggregate cube, sometimes called baby cubes.
• HANA specific: Major improvements come to cubes in HANA. The E table is eliminated. The dim tables (except package) are eliminated. No aggregates are needed and compression is normally not needed.

Non-Physical InfoProviders

Non-physical InfoProviders are InfoProviders in which the data is not stored in BW schemas or run-time collections of physical InfoProviders. The persistence to the data is not in BW. Rather, at run time the query is executed and the underlying data is gathered from the physical place where it is stored and assembled on the fly.

Virtual Cubes

A virtual cube is a run-time-based object used to gather source data and present this data to the user after the execution of a real-time transformation. Figure 4 shows the concept. Virtual cube features and when to use them:

• Use them when you need real-time data from a source system. Because the data must be moved across systems and transformed, this type of object has performs poorly.
• HANA specific: With HANA there is a new option for virtual providers that supports a simple user interface (UI) for field mapping to InfoObjects versus having to use a transformation. This new HANA-based virtual provider allows access to special HANA views (analytic and calculation), but only from the HANA that is running BW.

InfoSets

InfoSets are run-time collections of other BW InfoProviders. InfoSets provide for the linking of these objects by way of a join. With InfoSets you can join multiple other InfoProviders with different join types. The resulting object is similar to using an access database. In addition, InfoSets have a special join type allowing you to link time dependent master data to transactional data. You can reproduce a result that approximates the master data at the time of the transaction record. For example, you could link a DSO with the order date, customer, and quantity sold with a customer master (InfoObject) with a time-dependent country attribute. By temporal joining on the order date you could produce a report showing the quantity sold by the country of the customer on the date of the order. InfoSet features and when to use them:

• Use them when you need a query against a join between InfoProviders and do not want to persist the joined data – for example, orders or deliveries. Because they are not efficient, use them when a union does not produce the correct results or for other reasons if you absolutely need to. You should note that when temporal joins are needed they are the only possible answer.
• New in 7.3, InfoSets can be a virtual source of data for a transformation and DTP.
• HANA specific: With HANA or SAP NetWeaver BW Accelerator (BWA) you should attempt to replace the InfoSet by a CompositeProvider because the CompositeProvider join logic is executed on HANA or BWA and thus is much faster than processing the join on the SAP NetWeaver BW application server.

MultiProviders

A MultiProvider is a run-time collection of other BW InfoProviders. MultiProviders provide for the linking of these objects by way of a union. MultiProviders are used in a BW system for many reasons. MultiProvider features and when to use them:

• To improve performance through parallel processing of the sub-queries of the part providers that make up the MultiProvider.
• To isolate queries from the real source of data allowing technical changes that do not affect the query targets to be made easily. Internal business reasons to keep data separate yet easily combinable.
• Situations such as different divisions, or plan and actual, are some examples of this. The examples with divisions are sometimes called domains of data. With SAP NetWeaver BW 7.3 refer to the section “Semantically Partitioned Objects (SPOs),” which might be a better way to model domains, time-based collections, or part providers.

HybridProviders

A HybridProvider is a sophisticated new 7.3 object (similar to a MultiProvider) that links real-time or near-real-time providers with data physically stored in a cube. There are two options to build hybrids. One uses a hybrid with a cube and a real-time data acquisition (RDA) fed DSO, while the other uses a normal cube with a virtual cube. The query written against a MultiProvider that wraps a hybrid would access the current (maybe one day or one hour old) data from the real-time object and the remaining data from a cube. HybridProvider features and when to use them:

• To improve performance to the access of real-time or near-real-time data.
• HANA specific: With HANA it is possible to use a special database-level trigger to push data to the RDA-enabled part of a hybrid using SAP Landscape Transformation (SLT).

TransientProviders

A TransientProvider is not a normal BW provider, as it can be loosely defined as a provider that is not created using transaction code RSA1 (BW’s Data Warehouse Workbench). Also it is not based on the providers listed above nor does it get data cleansed via a transformation. A TransientProvider is basically an object existing outside of these more normal BW objects against which you are allowed to directly query. The four ways to make transients are shown in Figure 5. They include the APD (the transient is called an analytical index), BW Workspaces  (the loading of a file or snapshot query is the transient), direct access to HANA Analytic/Calc. views, or Business Suite-based transients. These ERP Business Suite-based transients are based on classic InfoSets or the Operational Data Provisioning (ODP) framework. You should be aware that these transients require a BW system to be installed on the ERP suite’s application server so you can access the Query Designer.

• Use TransientProviders to allow quick access to raw data without the need to process it in BW to cleanse the data.
• As an alternative to real-time access with a virtual cube, you can use the BEx query designer on top of the ERP Business Suite.
• HANA specific: Transients based on HANA views can only be built on BW on HANA.
• HANA or BWA specific: Transients built with the APD can only be built on BW running HANA or enabled with BWA.

CompositeProviders

CompositeProviders are collections (joins or unions) of TransientProviders or other InfoProviders created in transaction code RSA1 or as part of a BW workspace. Creating Composite InfoProviders is only possible with in-memory-supported BW, which means BWA or HANA. CompositeProviders are built using a menu path in the Windows UI or via the Workspace Tool set. Figure 6 shows a CompositeProvider. CompositeProvider features and when to use them:

• To allow quick flexible modeling from data in coming from transients in combination with other InfoProviders (such as cubes or DSOs).

• Note: CompositeProviders are only for use with HANA or BWA.

Semantically Partitioned Objects (SPOs)

SPOs are a wizardly incarnation of a MultiProvider. Like the normal variety it allows the union of multiple DSOs or cubes, but now an SPO wizard assists the modeler in building all underlying objects required to support the scenario. The wizard helps build the part providers as well as the DTPs and transformations. SPOs as defined above are basically an automated wizard-based way to create the objects and ETL needed for what used to be a MultiProvider and the MultiProviders’ part providers (the underlying objects that form the MultiProvider). The ideas and implementation of SPOs have not changed relative to BW 7.3 in a non-HANA world, as shown in Figure 7. The purpose of an SPO to semantically isolate business-related data into part providers has not changed as well. As I mentioned before, this is sometimes called separating data into domains.  One benefit of isolating the part providers using domains by division is that poor data quality from one division resulting in failed loads would not affect the others. SPO features and when to use them:

• SPOs should replace MultiProviders that were built for splitting data by domain or by time. They are easier to maintain and build. More information about SPOs can be found at: https://help.sap.com/saphelp_nw73/helpdata/en/d1/468956248e4d9ca351896d54ab3a78/content.htm.

• In addition, for details on how SPOs efficiently prune queries refer to: https://help.sap.com/saphelp_nw73/helpdata/en/e3/1fd9b36cf2407f93fd2fc3c367c0d8/frameset.htm.

The following SAP training sessions provide more information on BW on HANA and delta training in general: SAP Training for BW on HANA (BW362): https://training.sap.com/v2/course/bw362-sap-bw-73-on-sap-hana-10-classroom-098-us-en/. SAP Training for DELTA BW3.X  >>>>  BW7.3 (DBW73): https://training.sap.com/v2/course/dbw73-delta-bw-70-to-bw-73-classroom-096-us-en/.