Applies to: SAP BW3.5, BI7.0

For more information, visit the Business Intelligence homepage.

Summary

                         In some business process data loading will be conducted on hourly bases through Timestamp Field, are often required as delta criteria for generic delta extraction. However, in many tables such the timestamp field is not available; instead the creation/change date and time are available. Generic delta needs to function on one field. This article explains how exactly request are processed BW system to at OLPT server and what are the dependent fields are interlinked to fill the TIMESTAMP field on runtime extractor. 

Author(s):    VIJAY.G.M

Company:    Yash Technologies Private Limited

Created on:  3^rd October 2011

http://www.erphowtos.com/guides-a-tutorials/doc_view/534-generic-extraction-using-function-module-fm.html 

With respect to above like document, OLTP system pulls the delta records based on following ABAP code,

But in document not reflecting how extractor gets filled at OLPT system by BW system. This document elaborates the bag round technical debugging observation at extract checker.

( erdat >= startdate and ( erfzeit >= starttime OR ( erdat <= enddate and erfzeit <= endtime ) ) )

                                                                                 OR

( aedat >= startdate and ( aezeit >= starttime OR ( aedat <= enddate and aezeit <= endtime ) ) )

Some major observations from the above table:

1. During initialization, the lower limit value is blank. The higher limit is the current time.
2. During delta request, the lower limit value was 30 minutes, this value older than the higher limit value of the previous (i.e. init) delta request. This is due to the fact that we had given a safety lower interval of 1800. As a result, the lower interval was taken as the previous higher interval limit minus 30 minutes (i.e. 1800 seconds)
3. There is a time difference of +5:30 Hours (India) between the Time of extraction column (which shows the system time when the delta request was received in the source system) and the Low and High fields. This is due to the fact that the timestamp configured as a UTC timestamp, and the time zone of the system is UTC+5:30 (i.e. five hour thirty minutes ahead of UTC). The same difference exists between the Low and High fields and the Start/End Date & Time, which are the fields obtained when the low and high timestamps were split. The difference in this case is also due to the time zone.

What are SMQ1 and RSA7?

SMQ1 (Out bound Queue) is the physical storage for all transactions created in the source system.

Delta queue is a virtual store that displays open and unprocessed LUWS against active initialized data sources available in the source system and fetches data from SMQ1 physical storage. In addition to the default structure of data source, there will be five additional fields which will get populated on the fly in Delta Queue.

Following are the fields which get populated on the fly for all data sources irrespective of data source type whether it is application specific (standard) or generic data source, if Data sources are using delta queue for delta processing

• Host ID

• Process ID

• Time Stamp

• Counter

• Counter

As specified in the below screen shot, highlighted fields are populated on the fly when the delta created for the particular data sources.

If the Extractor is using a function module when data is requested from BI

In this case only repeat delta will be visible in RSA7 because delta queue able store last delta records unless and until next delta requested .For example if the data source delta type is AIE (after image via Extractor) and above specified fields will be filled while loading data into BW.

                                    When BW system request to load the initialization and delta update process, immediately two tables get updated at both system to maintain consistent extraction.

ROOSPRMSC ----------- OLTP System Table

RSSDLINIT     -----------BW System Table

BW System table ROOSPRMSC has following information.

BW System table RSSDLINIT has following information.

What is LUW and how it will process when we request delta data from BW?

LUW is logical unit of work

LUW Processing

LUW is logical unit of work, The qRFC outbound queue controlled using an Outbound Scheduler  (QOUT Scheduler). The QOUT Scheduler prompts the transfer of a LUW to a target system when all previous LUWs in this queue have been processed. When one LUW has been executed, the QOUT Scheduler automatically executes the next LUW in the queue.

In other words when we request delta load from BW, Source system will identify the last delta records which are in form of TID’s by using ROOSPRMSC table and it will delete previous confirmed LUWs(repeat delta table) and Process new LUWs(delta table)

How the source system will identify delta Records? What is GETID? What is GOTID?

ROOSPRMSC table will be used to identify last delta request and last delta LUW which has been loaded into BW

ROOSPRMSC: Control Parameter per Data Source Channel

This table stores all control parameters related to a data load.

Table fields and importance

INITRNR: This field provides the initialization request number

DELTARNR: This field provides the last delta request number

UTC Timestamp: This field provides the timestamp of the last delta request.

GETTID: This field refers to the last but one delta TID

GOTTID: This field refers to the last delta TID (that has reached to BW)

System will delete LUW’s greater than GETID and less than or equal to GOTID

For the next delta TID will be starting the succeeding TID of GOTTID, refer the above screen shots.

What is repeat delta and how it works?

                                  The data is stored in compressed form in the delta queue. It can be requested from several BI systems. The delta queue is also repeat enabled; it stores the data from the last extraction process. The repeat mode of the delta queue is specific to the target system.

In the above example screenshot refers repeat delta LUW which has been loaded into BW for the previous extraction and this repeat delta will be deleted in the time of next delta request

Delta steps:

1. Identify previous delta LUW’s (repeat delta)
2. Delete repeat delta LUW’s
3. confirm unprocessed delta LUW’s
4. Process unprocessed LUW’s

What is TID?

TID is concatenation of “IPADDRESS in which the record is created”, “Dialog Work Process used in creating service order”, “Timestamp at which the data is posted in SMQ1”, “Sequential number of record”.

In other words,

TID: ARFCIPID+ ARFCPID+ ARFCTIME+ ARFCTIDCNT

TID= Host ID (IP ID) +Process ID +Timestamp+ Transaction ID (LUW -> COMMIT WORK)

• Host ID= IP address of system
• Process ID= Process ID of LUW (hexadecimal format)
• Dialog process id which is available in decimal format in SM51 and hexadecimal format of Dialog work process will be saved
• Timestamp: The time stamp of delta record posted into outbound queue(SMQ1) and timestamp will be in UNIX hexadecimal timestamp
• Host ID, Process Id and Timestamp will be saved in below tables respectively.

ARFCSSTATE, ARFCSDATA, TRFCQOUT

The Delta Queue is constructed of three tables

1. ARFCSDATA: Raw Data, Based on the Extract Structure, but compressed.

1. ARFCSSTATE & TRFCQOUT: Pointer tables to Access and control the flow of                                          data to multiple BW systems.

UNIX hex decimal timestamp converter

http://dan.drydog.com/unixdatetime.html

Example: 4A4D8809 = Friday, July 03, 2009 4:24:41 AM UTC (GMT).

Extractor Debugging Process.

• When BW system request the data load, with help of last delta request, lower timestamp will filled (last extract date = start of next extract date) , for reference execute the extractor on debug mode with following steps.
• While debug mode concentrate on RSA2_SERV_GET_OLTP_SOURCE function module, on that extractor executes TIMESTAMP_CALCULATE Form (line Number 535).
• There some Incremental Conversion will calculated according to lower time stamp and upper time stamp on runtime and passes into extractor I_T_SELECT interface structure, based on this selection, function module logic will perform on records, 

In this way observed the time stamp filled by BW system.

SAP has delivered the standard ABAP program’RAC1_ DIAGNOSIS’ which will diagnosis consistence of delta extraction and loading.

Based on these observation, easily find out the delta missing records.

Refernce Doc : Note 583086 ‐ Diagnostic program for BW Delta Queue 

References: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40427814-376a-2c10-5589-bc1aaa6692c3?QuickLink=index&overridelayout=true

http://www.erphowtos.com/guides-a-tutorials/doc_view/534-generic-extraction-using-function-module-fm.html 

Business Intelligence homepage.

Assessing the Value of Performance Management:

Why traditional ROI methods aren’t always the answer

Enterprise performance management (EPM) is known to create a more intelligent enterprise – one that can access data and use information to drive better processes and make smarter decisions. As with any investment, stakeholders will be anxious to determine return on investment (ROI) – but since EPM, which includes strategic decision making, planning, and financial reporting, is not directly tied to revenue enhancement, calculating a precise ROI can be difficult.

An organization may spend time establishing the direct relationships between planning improvements and revenues. Making assumptions about drivers only to arrive at a questionable ROI analysis, some organizations miss the forest for the trees. EPM benefits an organization in many indirect ways, bringing together data and analytics to drive decisions, creating a framework to better manage the performance of suppliers, customers, profitability, and plans. On a global scale, EPM has a pervasive impact on the thinking and decision making that drives improved performance. This article helps recast your focus toward the intangible benefits of EPM, which very often prove to provide lasting and significant benefits to the organization.

The Pitfalls of Applying Traditional ROI Tactics to EPM

ROI is typically calculated in terms of dollar value – revenue or margin improvements or cost savings resulting directly from investment. It can be more difficult to measure the dollar value of EPM-related improvements such as better data, more timely reports, and a more efficient planning process, though that makes them no less valuable. If an organization uses a traditional planning approach – starting with last year’s budget and then adjusting revenue and costs by set percentages to create a forecast – how much better is a predictive, bottom-up planning approach enabled by EPM? While it can be tempting to equate a better plan with better decisions (and so greater margin improvements), asserting that adopting EPM will improve margins by 1%, for example, may be overly simplistic and unrealistic.

But could line-of-business managers’ ability to forecast in more detail improve an organization’s performance? Where traditional planning process might, for example, forecast only a flat 5% increase in sales, EPM techniques could offer analysis at the individual customer level. An organization might look at its largest accounts and begin to analyze how each will react to ads, promotions, and product innovation. How might various marketing and R&D activities affect the buying behavior of these customers? Business planning and consolidation can support such detailed budget rollups – and help create much more accurate three-to-five-year planning. So armed, an organization can better plan, staff, train, and support a wide range of sales, marketing, and R&D activities.

Another traditional ROI approach looks at process efficiencies. Employees can spend a lot of time producing reports and crunching data. If EPM automates these processes or makes them more efficient, how do the gains translate into time and dollar savings? While an organization can calculate time spent working with Excel spreadsheets, and time saved due to EPM – for example, one hour per week per employee – the real value lies in overall impact on the organization.

Intangible Benefits of EPM

The quest to put a hard number on the value and benefit of EPM shouldn’t overshadow its more intangible, but just as significant, benefits. For example, most organizations close their financial books once every month or quarter. The impact of a quick month end is significant. Take two hypothetical organizations with 500 employees and 20 accounting staff. If those 20 employees can reduce the month end close from 9 days down to 4 days, they now have nearly 40% more time to spend on proactive services and daily accounting routines. A fast close not only is more efficient, but also demonstrates to stakeholders that the organization can quickly produce an accurate representation of its performance. The result: The organization is seen by investors, banks, and partners as both effective and efficient.

Rather than looking solely for exact numbers, organizations must recognize that planning is a fluid process with both quantifiable and less easily measured benefits. Better plans help employees understand the drivers of performance, and so energize the company as a whole. A rich performance management and planning culture both attracts committed, self-motivated employees and encourages their global thinking about the implication of results. Such a culture permeates an organization, opens conversations, and drives results. Through EPM, SAP Services can enable this type of transformation and encourage organizations to re-examine their planning processes from the bottom up. As an example, a company could re-evaluate the use of variance commentary. When the monthly budget contains precise limits for an activity, such as sales, power, payroll, or cost of sales, monthly variance analysis helps explain unexpected changes to plan. However, if operational expenditures were simply educated guesses (for example, PR campaigns, travel, or consultancy fees) and are incurred as needed, monthly variance analysis on these items provides less insight and value.

Better Plans, Better Performance

Good planning can be identified in many ways: through traditional ROI calculation, but also through the recognition that the right strategic decisions and investments further both short- and long-term organizational goals. Better plans improve performance over time in a host of ways both concrete and intangible. They create actionable and realistic goals – and, through them, a more intelligent enterprise.

Every day, SAP Services helps companies identify and implement business planning and EPM improvements. To learn more about how we can help ensure that EPM delivers maximum benefits for your business, visit us at www.sap.com/services.

Edwin van Geel, EMEA practice manager for Enterprise Performance Management.

Francois Imberton, SAP Product Management, provided an ASUG Webcast on  SAP Dashboard BI 4.0 Feature Pack 3 Webcast.

The usual disclaimer applies that things are subject to change. 

Figure 1, Source: SAP

BI 4.0 offers a new panel to create queries inside the Dashboard Designer.  This panel is being enhanced for additional data sources such as BW.  Figure 1 shows that you can access BW via BEx queries from the Query Panel.  Also you can access third party OLAP via universes such SQL Server Analysis Services (SSAS) and Essbase.  The semantic layer will also offer access/connectivity to SAP ERP classic InfoSets and ABAP functions.

Figure 1 also shows there will be new ways to visualize hierarchies.  This is shown as part of the demo of this webcast.

Long term, Francois said they want to simplify authoring of design to  reduce dependency on Excel.  Excel (as part of the Dashboard) will never go away; it introduces an overhead in building and maintaining a solution, to be improved through better binding.

Figure 2, Source: SAP

Figure 2 shows the Query Panel in Feature Pack 3.  It enables you to access hierarchies defined in OLAP source.  You can select hierarchies as result objects or conditions – it can be level based member selection or value based.  Figure 2 shows how it looks in Design Time.

Figure 3, Source: SAP

Figure 3 shows the run time of how the hierarchies look using the tree view prompt selector or the hierarchical table.

In the hierarchical table, using BEx / ECC data sources, the component can act as a Report to Report Interface (RRI) sender  to a BEx Web report, an ECC transaction, or trigger another action, as long as the row select fits the context.  So you can jump from a dashboard table to a BEx web or an ERP transaction.

Francois said functionality like this allows BI to “close the loop” between BI and business processes.

DEMO of Dashboards 4.0 Feature Pack 3

Figure 4, Source SAP

Figure 4 shows a demo of Dashboards 4.0 FP3 in preview mode

This contains two query prompt components.  One is based on a hierarchy based on BEx/BW.

Figure 5, Source: SAP

Figure 5 shows the navigation of the hierarchy and the resulting change in the chart below.

Figure 6, Source: SAP Free Characteristics

Figure 6 shows the selection of Free Characteristics from the BEx Query inside the Dashboard Preview mode and the ability to select multiple values.

On the left of Figure 6 is the hierarchical table where the response time in navigating is fast due to multiple levels of caching. 

Figure 7: Source: SAP

Figure 7 shows how the hierarchical table acts like a spreadsheet and when you select a row, it acts as a selector and refreshes the information (chart) below.

Figure 8, Source: SAP

Figure 8 shows a hierarchy example against SQL Server Analysis Services (SSAS)

Figure 9, Design Time BI 4.0 Dashboard Feature Pack 3, Source: SAP

Figure 9 shows the design time of feature pack 3

On the left Query 1 and 2 are based on BEx Queries while Query 3 is based on SSAS.

Figure 10, Source: SAP

Figure 10 shows the Edit Query within Dashboards 4.0 FP3 based on a BEx query based on Flex.

Francois said that Figure 10 shows how similar this is to Web Intelligence on top of BEx.

Francois said they wanted to provide a “unified experience” dependent on the source

Figure 11, Source: SAP

Figure 11 shows the member selector that defines the levels you want to select from BW.  You can define selection based on values or go into levels and retrieve specific levels of the hierarchy.

Figure 12, Prompts

Figure 12 shows the Prompts; the first one comes from the BEx Query and the second one was defined within the Query Panel.  Also notice in the prompt summary there is a dependency (blue arrow).  First answer the root and then get a list of values for the dependent prompts.

Figure 13 Preview of Query Result, Source: SAP

Figure 13 shows the preview of query results to show how the results will look like – others in the past did not have these features (QaaWS).

Dashboards 4.0 Feature Pack 3 BW Connectivity in More Details

Figure 14, Source: SAP

Figure 14 covers BW Connectivity, comparing BEx Connector with Xcelsius 2008.

The new connector is to provide consistency across the clients.   Another area is consistency across the platform as with FP 3 you do not need BI Java.

“Interoperability” between dashboards and other clients, providing value.  The new infrastructure uses new dashboard services, platform services (including monitoring)

Before you had to publish to BW; this limitation is now gone.

Figure 15

To bind data/components to the data, you do not need to go to Excel anymore; you can bind to the query.  This simplifies the dashboard authoring and maintenance.

You still need to bind to Excel, however, to define the Chart title.

Figure 16, Source: SAP

Figure 16 shows limitations in BI 4.0 FP 3

BEx variable dependencies are handled at design time – and not at run time

Dashboard audience is casual; BEx variable dependency features work better in Analysis

Other Dashboard FP3 Enhancements

Figure 17, Source: SAP

The upgrade from Adobe Flex 2 to Flex 4 – for customers it has no impact unless you are using add-ons provided by partners

These partner add-ons need to be updated to Flex 4.

If you don’t upgrade add-ons these will not work with Dashboard FP 3.

The upgrade was done at the request of partners to take advantage of Flex 4 features.

Web Dynpro integration with NetWeaver Developer Studio to integrate flash files from Dashboards; in the past you had to build JavaScript wrappers, this is now simplified.

When Excel formulas are used over large range of data, performance data has been improved.

Combination charts will have the capability to define alerts with multiple series. 

New waterfall chart preview is shown in Figure 17.

Question & Answer

Q: What is the planned release of FP 3?

A: The plan is Q1 2012 – plans are subject to change

Q: Will hierarchical demo work with MSAS cubes?

A: Yes – shown in 3^rd tab of the demo

Q: Does the new version support bookmark functionality like Web Application Designer (WAD) does?  The user can drill down by hemisphere, region, and when they bookmark it, it saves those variables; they do not have go through drilldown/variable process again?

A:  Not offered out of the box; it is about personalization

Dashboard designer has a local scenario specific to a laptop – you can persist values / to retrieve view state but it will not be shareable between users. 

Alternative is to persist in XML file on server – but that is custom work

This request is on the list of the backlog; have not discussed post FP 3

Q: What is the minimum version of NW Portal that FP 3 support?

A: In FP 3, to integrate with NW Portal you use the Portal Integration Kit with BI Launchpad – you would need to follow up with that group

Q: Is there an XCelsius to Dashboard migration plan?

A: No migration – no feature being removed.

Q:  Does the hierarchy table support BPC hierarchies?

A: Post FP 3, there is a plan to provide universe connectivity on top of EPM cubes.  EPM suite, extended analytics package, does provide connectivity from Dashboards to EPM but not what was shown here with hierarchies

Q: Are SWF and XLF be combined?

A: They are, when you publish now you publish one entities – physically they are 2 but appear as one

Q: Does the FP 3 Dashboard come with BI 4.0 FP 3

A: Yes, it is part of the core release – it is the same release

Dashboard is in synch and included in that release 

I thank SAP's Francois Imberton for this ASUG webcast. We have two more upcoming BI 4.0 Feature Pack 3 webcasts for ASUG Members:

December 1st: SAP Integration in SAP BusinessObjects BI 4

December 7th: BusinessObjects Analysis Feature Pack 3 Updates

Check out these recent demos of BI on BIG data with SAP HANA. 

SAP BusinessObjects Explorer navigates 123 million records in seconds with SAP HANA.
 

Watch this search and business analytics on BIG data with SAP HANA.

Watch this customer demo with text analytics and BIG data with SAP HANA.

I do like Barry Manilow’s Grammy winning song, Cobacabana  and every time I hear CO-PA (Controlling Profitability Analysis) I hear that song.  Even more so now that I am hearing about the CO-PA HANA solution – it closely rhymes with Copacabana.  

Last week ASUG had a great webcast on High Performance Profitability Analysis with HANA CO-PA.  Carsten Hilker is the SAP Solution Manager for LOB Finance and this solution and was the primary presenter during this webcast.

As usual the legal disclaimer applies as solution is not available yet so everything is subject to change.  SAP is aiming for a Q4 release this year.

Agenda:

High performance profitability
HANA
HANA CO-PA Accelerator
Implementation Considerations
Business Transformation Services
Demo

High performance profitability

Figure 1 – Source, SAP

CO-PA has been around for several years, since R/2, and deals with large amounts of multi dimensional analysis data.  The technology constraints are now gone and we are now free to do what we want and process massive amounts of data.   “In memory databases have arrived” according to Carsten. All the data is at your hands.

SAP HANA

A HANA background was given; you want immediate answers.  We have been following 30 year old design principles, dependent on hard drives.  We have been designing around inefficiencies of hard drives.  As a result, we have a complex BI landscape today.

Figure 2, Source: SAP

We have a complex landscape today as shown in Figure 2.  To solve this they looked at running in main memory.  This has been covered in previous blogs.    A column-oriented database will have everything covered separately.  Today we only look at a few fields with Profitability Analysis but HANA will give you the ability to look at more data.

Figure 3 BI with HANA, Source: SAP

Figure 3 shows that we are operating with the lowest level of information we need, like our transactional ECC system.

Figure 4, Source SAP

Figure 4 lists the customers using HANA.

Figure 5, Source: SAP

Figure 5 shows HANA being used as an application platform.  SAP is creating content with HANA based on feedback from customers.   HANA CO-PA is the number one application that customers are using, to be used by both sales and finance.

HANA CO-PA Accelerator

IDC said “improved reporting drives better decisions”.  Today limitations are significant as we cannot get to the data fast enough.  We have a dependency on IT today as they control how much data you have access to and the levels. 

Figure 6, Source: SAP McKinsey’s Big Data

We can now process data, enrich it with data (such as CO-PA data with sales order data).  Big data can increase operating margin by 60%, per McKinsey.

Figure 7, How CO-PA looks today, Source: SAP

Figure 7 shows the traditional ERP stack, and CO-PA gets information from CO and SD.

Figure 8, CO-PA Today using Report Writer, Source: SAP

Figure 8 shows the old standby Report Writer, which has been around a long time.

Figure 9, CO-PA with BW, Source: SAP

Figure 9 shows data being transferred from ERP to BW with different data with different levels.

Figure 10, Source: SAP Summary of Challenges

Carsten reviewed the summary of challenges with the current CO-PA situation today as shown in Figure 10.

Solution is that we take data from traditional database and replicate to HANA.  Once loaded, it will allow archived data to be loaded to HANA.

Figure 11, Solution: Source: SAP

Figure 11 shows archived data being loaded to HANA, giving you the complete dataset of everything that has been posted, including archived data.

Figure 12, Improving Performance of CO-PA Allocations, Source: SAP

Figure 12 shows allocations from CO to CO-PA will run 50% faster as we are going to HANA as the read performance is improved.

Figure 13, Report Writer runs Faster with HANA

Report Writer can read information from HANA and run faster as shown in Figure 13

Figure 14, Ability to run CO-PA with BI 4.0 Tools

BusinessObjects Explorer, BusinessObjects Analysis Office can all be used against CO-PA HANA with all dimensions available as shown in Figure 14.  HANA will have line-item detail and aggregations are no longer a bottleneck.

Figure 15, Reporting Example

Figure 15 shows a reporting example with 120 million records that processed in less than one second.

Figure 16, Allocation Example, Source: SAP

Carsten then reviewed an allocation example where it took only 30 seconds to read the reference data.

Implementation Considerations

Figure 17, CO-PA HANA Implementation

Carsten said the CO-PA HANA implementation is comprised of consumable components, with ERP CO-PA ABAP add-ons to allow reporting from a connectivity perspective.  It has a CO-PA HANA model accelerator.  A program that reads the operating concern from CO-PA in ERP and creates an XML file with definition of operating concern and HANA will read that to create the data model. 

Installation is via a support package/note.  Implementation does not have to take 3 months, according to Carsten.

Figure 18, Data Replication, Source: SAP

A number of implementation scenarios are envisioned.  If you want HANA based reports you need to bring over line item and master data.  For this recommend use SLT (system landscape transformation) that allows both master data and transactions.  SLT is included in HANA depending on package you buy.

If you want accelerated ERP reporting you do not need master data replication and use the HANA CO-PA accelerator and SLT is not required. 

Carsten says replication is real-time.  Is that needed?    More than once a month is needed.  Closer to month-end you want to know what the profitability is. 

HANA CO-PA Accelerator is free for ERP/HANA customers.  Implementation Services offered will be the Rapid Deployment Solution including documentation, installation and business transformation workshop.

Figure 19 Implementation Components, Source: SAP

Figure 19  shows that you need hardware, and the SAP HANA standard or extended version (differentiated by the inclusion of SLT or not), the Accelerator which is free and the implementation services.

Figure 20, Software Requirements, Source: SAP

Carsten provided the information in Figure 20 so you can determine if your software requirements situation fits CO-PA HANA Accelerator.

Figure 21, Source: SAP

Business transformation  gives you instant access to all the data you already have.  Carsten said maybe there are fields you can use now and you can change allocations and look at your archiving strategy.  You can now consider doing shopping cart analysis – who bought what and when? SAP offers HANA CO-PA workshops and provides you with an assessment.

Demo

How do we get to the data?  The demo was with BusinessObjects Explorer, “google like” search and hands on ad hoc analysis.

Figure 22 – BusinessObjects Explorer Demo, Source: SAP

Figure 22 shows the front end with the CO-PA HANA data.  The left hand side is the measures which are the key figures you have.  The facets are on the right on how to select.  Lower half includes the visualizations.  The top right corner shows an active counter of records and will be continued to be filtered and how many records and how long it took.

Figure 23 – 3.2 Billion Records, Source: SAP

The response time with 3.2 billion was just as fast as going against 10 million records.

Question & Answer

Q: Financial closing and consolidation and consolidation is on BW; how will that work?

A: Financial close depends on company; in Europe CO-PA is part of the close
This solution is limited to CO-PA

Q: We do heavy CO-PA allocation on BW now and use realignment of master data
How will realignment work on reference data stored?

A: Maybe reason you brought CO-PA to BW is not there anymore.  Consider bringing allocations back to ECC. 

Q:  CO-PA data in BW is supplemented with sales data and not captured in core CO-PA information.  Will that work with HANA?

A: Carsten said this is an enrichment scenario and a join in HANA and reporting scenario

Q: Will HANA work with BPC?

A: It is separate, and now CO-PA is in HANA and bring it in to PCM and solutions will grow together.

Q: BPC on HANA, how will data be stored together?

A: BPC will come in 2 different flavors – BPC Netweaver on HANA
HANA is intended to be a multi-tenant environment, BW, BPC and operational data stores.  HANA CO-PA will be in the operational data store area.  The longer term plan – 2012/2013 – version of BPC that works natively on HANA without BW (similar to BPC on SQL Server today per Carsten.

Summary

This is an very interesting business use case for HANA and the possibilities.  It is nice to see that HANA will provide performance improvements to old tools such as Report Writer.  With the CO-PA HANA Accelerator is it interesting that you do not have to create the data models from scratch either; it is like providing BW content but customized to your own particular situation.

Upcoming HANA Webinars/Sessions This Week:

Wednesday, August 10, the SAP Customer Solution Adoption team will provide a Webinar on SAP HANA Operations.  Click here for more information.

Thursday, August 11, ASUG is having a webcast SAP High-Performance Analytic Appliance (SAP HANA) Software - What You Need to Know to Implement SAP HANA for Your Business - Register here (you must be an ASUG Member to register).

Friday, August 12, SAP Mentor John Appleby will provide "an overview of the HANA product, architecture and integration. Tips for project success and finding use cases for SAP in-Memory technologies" at SAP Inside Track Newtown Square, hashtag #SAPITNSQ.  Register here.

SAP Inside Track is a free event and open to all, but registration is limited so register soon.

Motivation

In SAP BW, usually there is no easy way of performing set operations (union, intersection, outer joins etc.) of two queries. This is usually a manual activity. Basically, post processing using two query results is difficult. Infosets can be used in some scenarios but these need additional modelling steps and not as flexible. This blog illustrates how we can fetch values from one query and then exclude these selected values from another query.

Business Example

Using technical content, you want to find out all infocubes that exists in the system but with no data being fetched from them over the last two years (via queries say).

Let X = {A1, A2, .. AN} be a query that delivers all the cubes in the system.

Let Y = {A1, A2, A3} be the query that delivers all the cubes in use over the last two years i.e. some data was fetched from them.

You want to find Z = X - Y = {A4, A5 .. AN}.

Steps

1) In query X, create a customer exit variable of type Selection option on characteristic A.

2) Write the customer exit coding in FUNCTION EXIT_SAPLRRS0_001 include ZXRSRU01. We calculate the variable values set at i_step=1. (How customer exit variables are processed is out of scope of this blog)

3) Code sample

Initialization of the request object (Every query execution is represented in BW via a request object).

DATA:

l_r_request TYPE REF TO cl_rsr_request,

l_s_compkey TYPE rszcompkey.

*** Initialization with query Y to be executed from within the ABAP code ***

l_s_compkey-objvers = rs_c_objvers-active.

l_s_compkey-infocube = 'INFOCUBE'.

l_s_compkey-compid = 'QUERY_Y'.   *** executing query Y

l_s_compkey-comptype = rzd1_c_comptp-report.

4) Get the internal query id for QUERY_Y

* Get the compkey

CALL FUNCTION 'RRI_REPDIR_READ'

CHANGING

c_s_repkey = l_s_compkey

EXCEPTIONS

entry_not_found = 1.

IF sy-subrc <> 0.

MESSAGE s792(brain) WITH l_s_compkey-compid.

EXIT.

ENDIF.

5) Create the Request object

CREATE OBJECT l_r_request

EXPORTING

i_genuniid = l_s_compkey-genuniid

EXCEPTIONS

OTHERS = 1.

 6) Call the query Y from within ABAP code

* get the query definition

CALL METHOD l_r_request->get_initial_state

IMPORTING

e_t_dim = l_t_dim

e_t_mem = l_t_mem

e_t_cel = l_t_cel

e_t_atr = l_t_atr

e_t_con = l_t_con

e_t_fac = l_t_fac

e_t_prptys = l_t_prptys

EXCEPTIONS

x_message = 8

OTHERS = 1.

* Set the request

CALL METHOD l_r_request->set_request

EXPORTING

i_t_dim = l_t_dim

i_t_mem = l_t_mem

i_t_cel = l_t_cel

i_t_atr = l_t_atr

i_t_con = l_t_con

i_t_fac = l_t_fac

i_t_prptys = l_t_prptys

EXCEPTIONS

no_processing = 1

x_message = 8.

* read data

CALL METHOD l_r_request->read_data

IMPORTING

e_warnings = l_warnings

EXCEPTIONS

no_processing = 1

x_message = 8.

*close the request

l_r_request->p_r_olap->FREE( ).

7) After fetching the results, assign the result set elements {A1, A2, A3} as exclude 'E' to the exit variable.

* Get the text table from the output handle of the request

ASSIGN l_r_request->n_sx_output-text->* TO <l_th_text>.

loop at <l_th_text> into l_s_txt_n.

clear l_s_range.

l_s_range-low = l_s_txt_n-CHAVL_EXT.

l_s_range-sign = 'E'. *** Excluding

l_s_range-opt = 'EQ'.

append l_s_range to e_t_range.

endloop.

......

e_t_range contains the variable values which will finally be submitted to OLAP to fetch the results of query X excluding values of Y i.e. X - Y.

Thus, in this way you can perform other set operations simply in the customer exit coding itself.

 P.S. For more details on executing BW queries from within ABAP, please refer: http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/43db5ee1-0701-0010-2d90-c3b991eb616c

So you’ve read about SAP BusinessObjects Analysis or even played with it. So what! you might say, OLAP analysis is not new after all… True, but SAP BusinessObjects Analysis differs from previous OLAP solutions. It’s the results of a significant software project (code name Pioneer) aimed at bringing together the best of SAP BEx and SAP BusinessObjects Voyager. The outcome: 1- a modern and compelling user experience leading to greater satisfaction and ultimately driving BI adoption among the business crowd. 2- Two different editions; the edition for MS Office for users of Excel and PowerPoint, and the edition for OLAP that provides self-service multidimensional analysis work spaces for personal or shared use over the Web.

Modern and compelling user experience

This is a major strength and value for our customers especially in comparison to legacy BEx front-ends. It enables fast business insights with intuitive drag-and-drop steps to analyze multiple dimensions and hierarchies. All of that in modern and familiar MS Office or web browser environments allowing pervasive deployments with much less dependency on IT.

MS Office ribbon-like toolbar in the edition for MS Office

Tabbed toolbar in the OLAP edition

And thanks to dedicated panels, workflows such as filtering, conditional formatting and adding calculations can now all be achieved without hiding your data (no more pop-up dialogs).

Analysis panel in the edition for MS Office                         

Data and Layout panels in the edition for OLAP

Light footprint and versatile deployment scenarios

SAP BusinessObjects Analysis is a superb fit for IT organizations wishing to bring innovation without disruption to their SAP NetWeaver BW deployment. First, it runs natively on top of current BW version 7 instances with existing BEx queries. Second, the edition for MS Office comes with a light footprint and versatile deployment scenarios that make it for an easy adoption. Third, it lays the groundwork for ongoing benefits as customers proceed along the business intelligence maturity curve at their own pace.

The edition for MS Office as a client/server application streamlines implementation and mitigates risks associated to the adoption of any new technology. Customers can start with the edition for MS Office for existing MS Office users (such as financial and business analysts) and set their “own pace” when it comes to deploying the SAP BusinessObjects BI platform and the edition for OLAP to more users across the organizations. Customers can even start with the edition for MS Office running with the successful and widely adopted version 3.1 of SAP BusinessObjects BI platform.

Benefits today, benefits tomorrow

While SAP BusinessObjects Analysis delivers tangible business benefits to our customers today, it is also a great investment for the future. As organizations grow more and more accustomed to SAP BusinessObjects Analysis, they have the ‘option’ move at their own pace, adopting other solutions of the SAP BusinessObjects BI suite.

Acknowledgement: I owe a great debt to my colleague and “Analysis expert” Thierry Audas for providing much of the material you just read in this post. Thanks for your contribution Thierry!

Other articles, posts, and links about SAP BusinessObjects 4.0 Innovations:

Innovations in 4.0 (summary)

Innovations in SAP BusinessObjects 4.0 Presentation

Innovation in 4.0: The New Semantic Layer

Innovation in 4.0: Unified User Experience

Innovation in 4.0: Personalized, Self-Service Access to Information

Knowledge Center for Analysis, edition for Microsoft Office 1.1

Knowledge Center for Analysis, edition for OLAP 4.0 

This might be my new favorite BIG data demo with SAP HANA and the Xbox Kinect. Ever wonder how you can analyze 3.2 billion rows of data with your own two hands?

Nic Smith   Insight on Business Intelligence at SAP

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/25389%3Futm_source%3Dtwitterfeed%26utm_medium%3Dtwitter%26utm_campaign%3DFeed%253A+SAPNetworkWeblogs+%2528SAP+Network+Weblogs%2529