SAP BPC 10.1 ( Embedded model )Implementation Consideration on Project

Embedded Model - New Features

 

·       Business Planning and Consolidation embedded is part of the SAP BW installation. If we want to use Business Planning and Consolidation embedded we only need to install and configure SAP BW.

 

·       The models in Business Planning and Consolidation embedded refer to Info Providers that exist in SAP BW. Each model can include several Info Providers of the following types: Real-time Info Cubes Input-enabled Data Store Objects, Virtual Providers with write interface

 

·       New Environments are created from scratch and not copied from existing environments.

 

·       Model Management, To create a new model, need to set references to Info Providers that exist in SAP Business Warehouse (BW),can choose an arbitrary number of Info Providers to include in the model.

·       There are no reporting models and non-reporting (drivers and rates) models

·       Reports and input forms are based on BW queries created with the BEx Query Designer.

 

·       Variables – We can use variables that are defined in the BW query.

 

·       Page axis - In the data grid of the report/input form, can include dimensions in the page axis. We can select specific members of these dimensions and display their aggregated values.

 

·       Disaggregation – we must define disaggregation in the queries that you use for reports/input forms.

 

·       Input forms only: Planning session - A planning session buffers the data before sending it to the database.

 

·       Input forms only: Locking – we can lock certain cells so that their values cannot be changed

 

·       System Report could be created on the following: Business process flows, Data changes, Work status,

 

·       Identity dimensions - When creating a new process template, the Time dimension is no longer a mandatory identity dimension.

 

·       Internal and external driving dimensions - Some of the InfoObjects provided by SAP BW may not have performer and reviewer properties. In these cases we can use external driving dimensions that have these properties.

 

·       Workspaces - When we create workspaces for the performer and reviewer, we set hyperlinks to existing elements like reports or input forms. We cannot create new elements directly in the workspace.

 

·       The BW data models are used; all dimensions (characteristics) are generic in nature except the 13 time dimensions and the unit/currency dimensions. Time dimensions know about the calendar and also about fiscal years. These concepts come from the Business Suite (cf. fiscal year variant).

 

·       Measures (key figures) are of type amount (refer a currency characteristic), quantity (refer a unit characteristic), of type number, date or time.

 

·       There is no special characteristic like the 'account dimension', So BW data models may be based on a key figure model, an account model or a mixture of both models. This depends how characteristics are used and interpreted in the data model and in BW queries.

 

·       Compounded characteristics are supported. Hierarchies can contain members of the hierarchy base characteristic, foreign characteristics values and text nodes.

  

·       Supported basic BW Infoproviders with write-back (planning provider for short) are: real-time InfoCubes, DataStore-Objects (direct update, planning), local BW providers and virtual InfoProvider implementing a write interface.

 

·       Write-back technically writes delta records into the InfoCube (local InfoProvider, virtual provider) and 'after-image' records into the DataStore-Object. In any case there is an aggregation level involved here and only fields (characteristics, key figures) from the aggregation level are filled. The other fields have the 'unassigned' value (characteristics) or the neutral element (key figure) with respect to the standard aggregation SUM, MIN, MAX. Using the BW-IP concept of characteristic relationships characteristics outside the aggregation can be derived from characteristics in the aggregation level.

 

·       The BW Analytic Engine is based on the definition of a BW query. The BW query definition can be considered as a 'template' of all 'reasonable' MDX statements one can use for the 'query cube'. The BW query also contains the definition of a default query view, i.e. how to use characteristics: the free characteristics (correspond to the 'page axis' in MDX), which characteristics are drilled-down on rows, columns and where BW hierarchies are used. This is quite similar to the corresponding parts of an MDX statement. On the other hand this analogy might be misleading since the BW query is no such thing as a concrete 'query' (like an SQL query or an MDX query).

 

·       'BPC embedded' uses a stateful programming model. From the context of planning objects the system always knows that the data regions to be used in change mode or in display mode.

 

·       Data region in change mode: defined by the (static) filter of a BW query and input-ready structure elements; in a planning function the filter used to run the planning function.

 

·       Data region in read mode: defined by the (static) filter of a BW query and the display-only structure elements; in a planning function this is the filter used to run the planning function merged with the reference data. Reference data come from planning function parameters, take 'copy from' as an example.

 

·       Data in change mode will be protected by exclusive locks, reference data in a planning function will be protected by shared locks (SAP enqueue concept). The locked data region is described by filters (technically 'selection tables), i.e. 'BPC embedded' does not use DB like locks on DB records but a description of data regions to be locked. This mechanism protects existing records as well as records to be created in the planning session.

 

 

·        This concept allows to buffer already read data and changed data in the user session. 'BPC embedded' uses the following 'buffers'

 

·        Planning buffer: buffers green requests of an InfoCube, technically the buffer is the OLAP cache; this is a buffer for persistent data

 

·        Delta buffer: buffers changed records in form of 'delta records' for all basic InfoProviders supporting a 'delta handling', e.g. InfoCubes

 

·        After-Image buffer: buffers changed records logically in the form of after-image records for planning enabled DataStore-Objects

 

 

·        As a result, in 'BPC embedded' the clients provide two buttons to process changed data: 'Transfer' and 'Submit':

 

·        'Transfer': Check the changed data and run the algorithm to process changed data; write changes to the delta or after-image buffers. All BW queries (input-ready or not) or planning functions in the same user session will display/use the most-recent session data automatically. One can also return to the last saved data on the DB via'Reset'.

 

·        'Submit', i.e. save data to DB. Technically the delta records will be taken from the delta or after-image buffer and saved on DB. Locks will be released and set new for the BW queries still used in change mode in the planning application.

 

 

·        Assume user U1 has acquired an exclusive lock for data region F1 (filter). A user U2 working on overlapping data regions F2 protected by exclusive locks (data in change mode) will get a lock conflict. So the first user U1 acquires the resource and can change/create data in the date region defined by the filter F1. The second user U2 cannot change data for all filters F overlapping with filter F1: a query will be switched to display mode, a planning function will send an error message.

 

Error handling

 

With respect to write to the delta or after-image buffer the design is an 'everything or nothing' concept. This is also true for 'save to DB'. What is in the delta or after-image buffer is considered 'consistent'. Exception: A planning function the runs before 'save to DB'.

 

There exist two kinds of 'constraints':

 

1.    Constraints for persistent data, e.g. the dimension members used have to exist, combinations of dimension members have to be valid, values for some measures have to be in some range (e.g. balance is 0 for some accounts).

 

2.    Constraints of more temporary nature; in most cases this is a data protection concept. Typical examples: in a rolling plan one should not be able to change data in previous planning periods; a planning version is closed, no changes are allowed any more.

 

Often there exist also client features to model 'constraints' e.g. to protect data cells. This section is only about server side constraints.

 

For constraints of type 1 one can use compounded characteristics e.g. to model valid combinations of characteristics values. Example: Fiscal Year Variant and Fiscal Year; another may be Country and City. Compounding cannot be changed easily. Thus one can use characteristic relationships to model admissible combinations of characteristics values. In a retail assortment planning application one may create a relation for characteristics Product and Assortment. One can also derive characteristic values from other characteristic values.

 

For constraints of type 2 one can use data slices. Technically this is a filter that describes data regions that cannot be changed. Also „BPC Work Status‟ can be used

 

Removed Components and Functionality

 

The following list shows the components and functionality that are not present in Business Planning and Consolidation embedded:

 

Documents view

Consolidation

 

Journals

Ownership management

EvDRE functionality

Dimension management

 

Legal consolidation

Business rules

Script logic

Drill-through

Content Lifecycle Management

Management of document types and subtypes

 

Do you have an experience of running FOX functions and planning sequences on HANA? What are the limitations?

 

Yes, I do have experience of running the FOX functions and planning sequences in HANA.. The limitation is we need to develop the ABAP code to call database procedures in SAP HANA, check to push data-intensive calculations to SAP HANA, resulting in less data transfer between the application server and the database layer

 

 

 

Do you have an experience of using EPM addin over BEx queries? How do you manage to call filters of planning functions via EPM addin? How do you call user-exit/ABAP variables of BEx query via EPM addin?

 

Yes, I do have extensive experience of using EPM Add-in for BEX Queries, calling filters of planning functions & the Exit variables in EPM Add-in

·        When using the new connection, get the EPM – Query Selection screen, search for either queries or workbooks. ( To run a plannable query, we can enter a character string such as prod” under Query Selection, and the system will return with a hit list of available queries to pick from. If we want to use a query more than once, you can make it a favorite by clicking the star icon under the Favorite column.

 

·        Select the Create Report From Query option on the lower left .This will automatically create an EPM report based on the default query view. Choose OK, and the EPM-Set Variable prompt for fiscal year pops up. After you select 2015, the EPM report is displayed in Sheet1; you can then enter prices for B1, for example, and use the EPM Save Data button to store the data in memory

 

 

·        After logging in EPM and searching for the BEX Query (Example: PRODUCTPLANQUERY), select the option to Create Report From Query choose OK, the default query view is used to create an EPM Report and the several planning functions have been added into the Data Processing tab. As planning functions are added, the system assigns an assigns an alias that is referred to in macros. Using the alias is to run functions with pushbuttons; the first function added will be DP_1, for example.

 

·        To use a planning function, select the Data Processing tab on the lower right, right-click the EPM connection, and select a planning function. In this first pass, select the Copy function, and add it to the EPM connection

 

·        Then choose Execute to copy the Key Figure (prices) from version B1 to B2. ( Example.

 

 

 

 

 

 

 

 

The planning scenario will start by copying B1 prices to B2 and then marking up the B2 prices. Before revalue the prices in version B2, change the variable value to 15%. To do that, just go to the Variable tab for the Revalue B2 function, and input “15” (as shown in Picture) If want to provide the markup value from the Excel sheet, just select Cell, and add the cell location to the right. If only want to revalue 2015, just go to the planning function on the Filters tab (on the right side of the figure) and enter “2015” next to Fiscal Year

 

After revaluing B2, copy B2 to B. Because the source version in the Copy to B function is supplied via a variable, manually input version “B2” in the Variable tab, and then execute the function.