SAP BW 7.3- New Additions (Futures/Functionality)

Glimpse about the SAP BW 7.3- New Additions (Futures/Functionality)

I was very excited about the new futures in BW 7.0 when it was announced; release includes many features, such as BW Accelerator, DTP, Different types of DSO and many more …..Now the turn come for BW 7.3, most of us would interested to know what’s new BW 7.3, now I am trying to describes the new functions/ future in SAP BW 7.3 in Part 1.

New functions/ future in SAP BW and Bex

Data Warehousing

Hybrid Providers:

· A new type of Info provider has been introduced in SAP BW 7.3 it can be created based on DSO and Hybrid provider based on direct access.

Semantically partitioned Info provider/ object:

· New Kind of Info provider can have same structured several DSO or Info cubes, with this we can divide the info provider into many small, equally sized partitions

In-Memory Optimized Info Cube (From SP5):

· A standard Info Cube (IMOIC) that is optimized for use with SAP HANA

In-Memory Optimized DSO (From SP5):

· Now we can create standard DSO that is optimized for use with the SAP HANA database.

Version Management:

· It creates and manages historical versions of each existing BW object (TLOGO object).

Graphical Data Flow Modeling:

· GUI enables us to easily create data flow/dataflow templates

Copying a Data Flow:

· By using Wizard we can copy process and DW Objects in A dataflow or in a process chain

Dataflow creation:

· Based on Dataflow generation Wizard we can model a dataflow from a data source/file

Migration a Data Flow:

· For automated migration we can use Transaction RSMIGRATE

Generic BW delta for NON-SAP System Data source:

· Now we can do the Delta extraction Based on Generic data source for object type R3TR RSDS from non-SAP source systems (DB Connect, UD Connect, file interface, Web Service and Staging BAPI)

New Authorization Objects

Authorization objects for working with the DW Workbench:

· S_RS_HYBR: Authorizations for working with Hybrid Providers

· S_RS_LPOA: Authorization for working with semantically partitioned objects

· S_RS_HIST: Authorization for Version Management

· S_RS_CPRO: Authorization for working with Composite Providers

· S_RS_WSPAC: Authorizations for Working with BW Workspaces (From SP5)

· S_RS_AI : Authorization for working with analytic indexes (APD)

· S_RS_XCLS: Frontend Integration - Xcelsius Dashboard (BOBJ/Xcelsius)

New Role Templates:

The Below role templates have been added

· BW Workspace Administrator (S_RS_TWSPA)-From SP5

· Display, maintain, or extract Data Source (OSOA)( S_RO_OSOA_TMPL)

· BW Workspace Designer (S_RS_TWSPD)-From SP5

· BW Workspace Query User (S_RS_TWSPQ)-From SP5

New Roles:

· For the business user, role SAP_BW_WORKSPACE_DESIGNER (From SP5)

Archiving Object:

· Now we can archive the change log of analysis authorizations by using the archiving object RSEC_CHLOG

Teradata Foundation:

· Teradata as a DBMS for SAP BW is now supported.

Analytic Index:

· An analytic index is a data container whose data is stored in the BWA

Composite Provider:

· Its Info provider that fetches together data from one or more Analytic indexes and it can be use for reporting and Analysis.

Delete statistical data for WHM (Warehouse Management):

· By using RSDDSTAT_DATA_DELETE program we can schedule the deletion of WHM statistical data (table RSDDSTATWHM).

SAP HANA DATABASE:

· From SAP Net weaver BW 7.3 SPS05, SAP HANA Data base is available as the Database for SAP BW

· By using transaction code RSDD_HM_PUBLISH we can create and publish the SAP HANA Model.

New futures in Bex

· Now we can Remove References in Reusable Structures

· Now we can Remove References in Reusable Filters

· In BEx Query Designer We can display the documents for a query and reusable query components (filters, variables, structures, and calculated and restricted key figures)

· All non-reusable Query components (like Attributes, Structure elements, Condition, exception and cells...etc) are now switchable in the switch Framework

· Read Near-Line Storage and the Data Integrity settings option are Available in Bex Query designer under Query properties on the Enhanced tab

· Now we can use Classic-Info Sets of an application system for operational reporting with BI tools that access BEx queries on Info Providers, without needing to create a data model in the SAP BW or replicate the data.

· By Using the Command wizard in WAD, we can include commands for Variables in Web templates

· BEx Web applications can now be displayed flicker-free

· By Using Custom Extension Web item in Bex WAD, We can insert our own Java script or HTML into our Web application. you create your own ABAP classes for this (see SAP Note 1110636)

· By Using the Web item Page Break, we can specify where to insert a page break in your Web applications, when the Web application is exported in PDF format.

· We can now change the drilldown of charts by drag and drop. Same procedure as when navigating in the data of an analysis grid.

· For easy Navigation : The value lists in Web dialog boxes now contain vertical and horizontal scroll bars

· Now we can use a formula to make an ad hoc recalculation of key figures in a structure for Bex Web application

· We can exclude values from the selection (in the input help dialog in BEx Web).

· We can change the sequence of the selected values by using arrow icons (in the input help dialog in BEx Web).

· For time characteristics, we can now select calendar days from a calendar rather than from a list of values in the input help dialog in BEx Web).

· Analysis in BEx Web applications in Firefox is now fully supported

· By Using ABAP report SAP_RSADMIN_MAINTAIN we can define the size of the result set in Web applications

· Now we can create user specific variants by using variable the variable screen (Bex Web)

· Export Library for SAP Business Explorer

· We can personalize variables in BEx Web applications and display them in the variables screen

· By using BADI (RSR_VARIABLE_F4_RESTRICT_BADI) can now restrict the input help of input-ready variables in the Variables screen.

· In Bex Report designer, we can format hierarchy and generate corresponding row patterns

· We can now display multiple Web items side by side in the print version of a Web application by using the EXPORT_LAYOUT Web template parameter

· In analysis mode, you can select a query view from the dropdown box (BEx Analyzer)

· In Bex Broadcaster, we can distribute online links to Workbooks

· Also we can make a setting so that BEx Analyzer starts when the user clicks the online link, and the query displayed there

· We can now use BEx queries/query views as data sources for dashboards that we create with SAP Business Objects Dashboard Design

· A bucket is a precalculated value set that is stored in a database table or in an index on SAP BW Accelerator and can be used as a filter in a query

· By using BWA index maintenance (transaction RSDDB), you can display, edit and create BWA indexes for the following BW object types: Info Cubes (including semantically partitioned objects), Virtual Providers, hierarchies and master data (for the input help).

· SAP Business Objects Explorer (accelerated version) allows you to display data from a SAP BW Accelerator index (BWA index).

· We can also send the results of the BW Accelerator consistency checks by e-mail

In this blog I have covered the New functions in brief, respective to the data warehousing and Bex

My Subsequent blogs would cover more about the individual objects and elaboration/creation on the same (SAP BW 7.3 new futures)

Part-2: What are the changes/enhancements and deletion in SAP BW 7.3

Delta methods In LO

Queued Delta

In this mode, extraction data is collected from document postings in an extraction queue from which the data is transferred into the BW delta queue using a periodic collective run. The transfer sequence is the same as the sequence in which the data was created ,

When a document is posted it is saved to application table, and also saved to the Extraction Queue ( here is the different to direct delta) and you have to schedule a V3 job to move the data to the delta queue periodically and from their it is moved to BW.

Direct delta.

When a Document is posted it first saved to the application table and also directly saved to the RSA7 (delta queue) from here it is being moved to BW.

So you can understand that for Delta flow in R/3 Delta queue is the exit point.

Un serialized V3 Update

This method is largely identical to the serialized V3 update. The difference lies in the fact that the sequence of document data in the BW delta queue does not have to agree with the posting sequence. It is recommended only when the sequence that data is transferred into BW does not matter (due to the design of the data targets in BW).

You can use it for Inventory Management, because once a Material Document is created, it is not edited. The sequence of records matters when a document can be edited multiple times. But again, if you are using an ODS in your inventory design, you should switch to the serialized V3 update.

LO Cockpit (LO Extraction )Delta Mechanism

For extracting logistic transactional data from R/3, a new generation of datasources and extractors, no longer based on LIS (Logistic Information System) information structures, was developed starting from BW Release 2.0B and PI 2000.1 or PI-A 2000.1 (valid from R/3-Release 4.0B ).
The tools for the logistics extract structures can be found in the IMG for BW (transaction SBIW): access into your OLTP system, choose Customer-Defined DataSources -> Logistics -> Managing Extract Structures.
The Logistics Extract Structures Customizing Cockpit (you can directly see it by transaction LBWE) represents the central tool for the administration of extract structures.



Ok...but, in other words, what is this the Logistic Cockpit (LC)?
We can say that it’s a new technique to extract logistics information and consists of a series of a standard extract structures (that is, from a more BW perspective, standard datasources), delivered in the business content thanks to a given plug-in.
But, what is the logic behind these datasources that allows to manage the logistic flows towards BW in delta mode after an initial load of the historical data (done with update mode ‘Delta Initialization’, by retrieving data from the setup tables, which are assigned to each extract structure, and are filled using special setup transactions in OLTP) ?
Following from many questions posted until now in SDN BW Forums, in this weblog we will focus only on the delta mechanism of the LC and not on the other tasks we can manage inside it, like the necessary steps for activating and carrying out successful data extraction or the maintenance of extract structures and datasources (but, don’t worry, it will arrive also a summary weblog dedicated to these important procedures in the next days !).

The V3 Update

Unlike the LIS update (well, I know that you are asking ‘but how does this old LIS update work ???’...my dear, another weblog will arrive very soon also for this topic...sorry for the waiting, but I have a lot of things to do !), data is transferred from the LIS communication structure, using extract structures (e.g. MC02M_0HDR for the header purchase documents), into a central delta management area.
This transfer takes place thanks to the V3 update with a specific (scheduled) job and is therefore temporally detached from the daily application operations; the main consideration is that the delta management acts as a buffer (not depending from the application business) containing data that can be requested from BW via infopackage with update mode ‘delta’.
The following picture shows (with an high-level view) the interaction between the LIS communication structure and the V3 extraction technology.

We said that for updating the extraction of transactional data from the different logistics applications (MM, PP, SD and so on), the technology for collective updates (‘V3 updates’) is used (until PI 2003.1).
This means that the data is collected in the R/3 update tables before the transfer to the interface: the data is retrieved there by means of a periodic update process that needs to be started in order to transfer delta records to the the BW system delta queue.
During this V3 collective run (that you can start and schedule from LBWE for each application component), the data is transferred to the BW delta queue (that you can see from RSA7 (see the picture below) or LBWQ transactions), from which they are retrieved by means of (delta) requests from the BW system.

V1, V2, V3...
When scheduling what

Normally in R/3 there are three types of update available:

 Synchronous update (V1 update)

Statistics update is carried out at the same time (synchronous) as the document update (in the application tables).

 Asynchronous update (V2 update)

Document update and the statistics update take place in different tasks.

So, V1 and V2 updates don’t require any scheduling activity.

 Collective update (V3 update)

As for the previous point (V2), document update is managed in a separate moment from the statistics update one, but, unlike the V2 update, the V3 collective update must be scheduled as a job (via LBWE).
Remember that the V3 update only processes the update data that is successfully processed with the V2 update.



This is a key task in order to properly manage the right working of the BW logistic flows.
In fact, scheduling timing process is very important and it should be based on the basis of
1) the amount of activities on a particular OLTP system and on
2) the particular requirements related to the updating needs of data displayed in BW reports.

For example (relating to the first point), a development system with a relatively low/medium of new/modified/deleted documents may only need to run the V3 update on a weekly/daily basis.
Instead, a full production environment, with really many thousands of transactions everyday, may have to be updated hourly, otherwise postings will queue and can affect performance heavily.
About the second point: if, for example, the reporting timing refers to a monthly periodic view, successfully monthly scheduling the V3 update will ensure that all the necessary information structures are properly updated when new or existing documents are processed in the meanwhile.
Finally, the right choice will be the result of all these considerations; by doing so, the information structures in BW will be current and overall performance will be improved.
It’s possible to verify that all V3 updates are successfully completed via transaction SM13.
SM13 transaction will take you to the Update Records: Main Menu screen:



On this screen, enter asterisk as your user (for all users), flag the radio button ‘V2 executed’, select a range date and hit enter.
Any outstanding V3 updates will be listed.

At this point, it’s clear that, considering the V3 update mechanism, the main requirement is that the delta info have to be transferred in the same sequence to the BW system as it occurred in the OLTP system.
Just a consideration...if we had to load our delta records only in a cube, there would be no problem: everything goes in append and, in the end, we’ll find the final situation right displayed thanks to the OLAP processor!
But since updating in ODS objects is permitted in the logistics extraction for almost all DataSources, we have to consider any effects that can derive from the ‘overwrite’ update mode (specific of the ODS object).
For example, the consistent storage of a status field (e.g. delivery status) in ODS objects can only be ensured only with a right (serialized) delta sequence: if the record with ‘open delivery’ status (created as first record in R/3) arrives later than the record with ‘closed delivery’ one (created as second one in R/3), we would have a false representation of the reality.

Considering that, the sequence of the existing data records is recognized by and taken into account when reading and processing the update data (step A of the picture), as well as when transferring data to the BW system (step B).
Since the normal existing update methods actually does not recognize the serialized processing of update data, the Serialized V3 Update function was created (also thanks to subsequent several corrections in SAP Basis) in order to be able to serialize step A.