Page 1 of 20

Greg or Dieckman n
October 21, 2014 26 mi nute read

Concepts compared: BPC standard and

BPC embedded
FollowRSS feedLike
55 Li kes 58,966 Views 21 C omments

1. Introduction
Following discussions and answering questions in this forum and also in the ‘Business Planning’
forum http://scn.sap.com/community/data-warehousing/business-planning I have the impression that
it is worth to explain concepts used in BW-IP/PAK as exposed in ‘BPC embedded’ and to compare
these concepts with ‘BPC standard’. This kind of information is usually not included in the
documentation.
This comparison is not a feature list and also tries to avoid judgments whether concepts used are
good or bad. The focus is on basic concepts, e.g. meta data concepts, data models, working with
transaction data, how the ‘engines’ work and transaction concepts. Only planning is treated here, no
consolidation.

I will also fix some notation since BW and BPC sometimes use the same terminology for different
things. This is usually causing a lot of confusion.
So let’s just start with terminology for the very basic BPC objects, namely ‘BPC
Environment’ and ‘BPC Model’. In my humble opinion (sorry, my first judgment) these names are
not good: ‘environment’ and ‘model’ are too generic and may cause misunderstandings.The old
names

 BPC Environment <-> Application Set

 BPC Model <-> Application

are much better, since a ‘BPC Model’ represents a planning application and a ‘BPC Environment’ is
a grouping of planning applications that share planning dimensions and are linked to each other. The
links e.g. may be represented by BPFs e.g. since the applications exchange planning data. Talking
about BPC objects I will always use the full term, e.g. ‘BPC Model’. But talking about general
concepts like in ‘data model’ I will use just ‘model’ (without ‘BPC’).
A glossary contains some definitions of the terminology used.

2. Why ‘BPC embedded’?

‘BPC standard’ is a planning (ok, also reporting and consolidation) solution based on BW technology
mainly designed to be used by LOB. The technical BW objects needed
(e.g. InfoObjects, InfoCubes) are generated and controlled by BPC and not directly exposed in
BPC. BPC introduces BPC-specific concepts different from BW concepts. Thus in ‘BPC standard’
one has to copy over all master data, hierarchies and transaction data from BW to BPC and to align
the copied data with the BPC concepts. In this sense ‘BPC standard’ is a data mart solution. To
support this ‘BPC standard’ implemented again a lot of existing functionality in BW (but in the BPC
way).
 Page 2 of 20

On the other hand there exists BW-IP (since BW 7.0). This is a planning solution in BW (by the way
this where the name Integrated Planning comes from), i.e. BW-IP directly uses BW objects. Only
very few new objects were added to BW to support Integrated Planning (e.g. the
InfoProvider ‘aggregation level’ and the planning functions). BW-IP objects are thus ‘native’ BW
objects. BW has a WHM and reporting part and thus the requirements were driven by IT scenarios
(cf. central data models, single point of truth …). This also applies to BW-IP. As a result, BW-IP is
completely generic in nature, ‘BPC standard’ concepts and data models come more from the
financial planning (and – of course – consolidation) area.
There are two solutions, optimized for either LOB or IT use cases.
One might have an issue with the ‘either or’ and the ‘price’ one has to pay for this.

 In a data mart solution one has to copy over and map/adjust master data/hierarchies and
transaction data, usually from existing high quality WHM data models. This forum is full of
examples how this can be achieved. This takes some effort (not only once) and is by nature
an ETL kind of problem. This is not an easy task for people from LOB. And all this has to be
done just to get the flexibility (in the sense of empowerment, not product features) that LOB
people are able to model and drive the planning process.
 One can just change the point of view, i.e. in IT scenarios LOB people need adjustments in
planning processes. These changes lead to changes in the data model, etc. To get these
changes from IT may take too long.

With respect to the required feature set there is no difference between IT and LOB scenarios. In both
cases there exists the full range of scenarios, from simple data entry to complex process driven
planning applications working on mass data. Complex requirements lead to some complexity in data
model and usually also have an impact on the way data and planning processes will be handled in
the application. One usually needs experts to design and maintain these data models and thus the
foundation of planning applications. This inherent complexity can be hidden to some extend making
design decisions based on the required feature set. So for the end user the application may still be
easy to use. But in the end there exists the ‘conservation law of complexity’. This means that there is
no such thing as a ‘one fits all’ solution. But this does not mean that LOB cannot be empowered to
adjust/extent and control planning processes (in fact that is part of their job, too). How is this
possible?

The ‘BPC embedded’ environment type was invented to solve the above kind of requirements by an
‘extension concept’, i.e. enhancing BW objects such that LOB-owned extensions of BW objects are
also possible. The guiding principle is: don’t copy the data! This means first of all, use the BW
objects and features. Thus one needs BW-IP/PAK data models and engines. Second, enhance
central BW objects by LOB-owned extensions. Here are some examples:

 BW master data can be extended by LOB-owned master (new values, new attributes; in
LOB-owned InfoProviders the LOB values ‘win’)
 Same for BW hierarchies
 LOB-owned InfoProviders
 Transaction data authorizations are granted by IT centrally (so to say a sandbox) and within
this IT controlled range LOB-controlled restrictions are possible
 … and many more BW objects hopefully will support such a LOB-extension concept in the
future …

Four of the above mentioned features already exist in BPC 10.1. In addition, also long established
BPC concepts will be reused in ‘BPC embedded’ if this fits conceptually, take work status and BPFs
 Page 3 of 20

as examples.
To summarize, ‘BPC embedded’ is designed to reuse BW data models as the foundation in a new
type of a ‘BPC Environment’. These data models can be enhanced by extensions of BW objects
owned by LOB. Technically these enhancements physically belong to ‘BPC environments’ or ‘BPC
models’. This concept allows using BPC in range of pure IT scenarios to pure LOB-owned scenarios
and anything in between.
But now it’s time to dig deeper and compare data models in ‘BPC standard’ and ‘BPC embedded’.

3. Data Models
Data models usually have a ‘visibility’. In a BW system all InfoObjects and InfoProvidershave a
global visibility. Please don’t confuse this with authorizations. With ‘visibility’ here I mean the
following: in BW there exists no ‘container’ other than the BW system itself where the BW objects
physically belong to.

3.1 Container
In ‘BPC standard’ there exist two physical container as mentioned in the introduction, the ‘BPC
Environment’ to group planning applications and another container for the objects specific to a
planning application (e.g. the generated BW InfoCube, work status table). The latter is the ‘BPC
Model’ (i.e. the planning application).
These containers are physical containers in the sense that an object X in ‘BPC Environment’ E1 is
‘compounded’ to E1. It does not make sense to talk about the object X in a different ‘BPC
Environment’ E2.
 Page 4 of 20

In ‘BPC embedded’ these two containers still exist, but BW objects will only be assignedto a ‘BPC
Model’ (and thus implicitly also to a ‘BPC Environment’). There is no physical dependency. Anyway,
this is clear since one wants to reuse the BW data model as a foundation (no copy!). By the way, this
assignment also is the technical way to make existing BW objects sensitive to BPC features like
work status. But the LOB-controlled extensions mentioned in section 2 belong physically to one of
the BPC containers.
 Page 5 of 20

3.2 Basic Objects

In planning (and reporting) one is interested in values (not only numbers) depending on a modeled
set of dimensions. Take ‘Revenue’ by ‘Fiscal Year’, ‘Version’, ‘Product’ and ‘Customer’ or
‘Classification A, B or C’ by ‘Fiscal Year’, ‘Version’ and ‘Customer’ based on ‘Revenue’.

In ‘BPC standard’ the objects representing the values are called ‘measures’, the dimensions are
called dimensions. BW uses the notions key figures and characteristics, respectively. In clients
(Admin-Client, EPM Add-In) ‘BPC embedded’ objects use the ‘BPC standard’ terminology for UI
consistency reasons.

‘BPC standard’
 Page 6 of 20

There are four special dimensions (in fact dimension types) in ‘BPC standard’, following
the CATE model

 Category (C) to model dimensions for versions

 Account (A); this special dimension represents the measures. There is only one technical
measure (key figure) in the BW layer for the numeric values.
 Time (T) to model the time dimension
 Entity is motivated to model parts of companies for consolidation

These dimensions and their attributes are mainly used to implement business logic needed e.g. for a
financial planning application or consolidation. The usage of the account dimension to represent the
measures is usually called ‘account model’. The other dimensions in ‘BPC standard’ are pure
generic in nature.
There exists no concept of compounded dimensions (characteristics). Hierarchies contain only
dimension members of the hierarchy base characteristic. This corresponds to BW hierarchies
with ‘postable’ nodes.

‘BPC embedded’

Since here 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.

Delta

Concept BPC standard BPC embedded

Representation of Dimensions, CATE model:
dimensions  Category (version)
 Account (to model the measures)
 Time (nothing to do with BW
time characteristics)
 Entity (mainly consolidation)
 plus generic dimensions
Representation of Measure,
values
Characteristics
 pure generic, except
 13 time characteristics
(calendar, fiscal)
 currency/unit
characteristics
Key Figures, of various types
 amounts linked to a
 Page 7 of 20

Concept BPC standard BPC embedded

only one techncial key figure in currency characteristic
 units linked to a unit
BPC generated BW InfoCube characteristic
 numbers of various
technical types,
 date, time
Hierarchies, parent- BPC hierarchies, BW hierarchies,
child relations
correspond to BW hierarchies with with different node types;
postable nodes
in addition display hierarchies in
BW queries

The most important and fundamental difference is that in ‘BPC standard’ one can have ‘base
members’ in a dimension and also calculated members, e.g. account C = account A + account B.
This is never ever possible in ‘BPC embedded’, by definition any dimension member is base
member and there don’t exist calculated dimension members. This comes from the design of the
reporting engines, in ‘BPC standard’ this is an MDX engine and in ‘BPC embedded’ the BW
Analytical Engine based on BW queries. In ‘BPC embedded’ this kind computations can be modeled
as part of the BW query using the BW Query Designer.

3.3 InfoProvider
InfoProviders are BW objects with persistence or compositions of BW objects with persistence.
InfoProviders can also be virtual so the real persistence may be ‘outside’ BW. Most prominent
InfoProviders are InfoCubes, DataStore-Objects and Multiproviders.
‘BPC standard’

This BPC environment type contains ‘BPC Models’ and per ‘BPC Model’ one BW InfoCube is
generated. In BPC this BW InfoCube is hidden, i.e. not exposed directly. From BW point of view this
InfoCube has no time and unit ‘BW dimensions’ (do not confuse this with dimension =
characteristic). The generated InfoCube has only one (technical) key figure of type number.

Internally BPC also uses a generated Multiprovider that just contains the generated BW InfoCube to
decouple from other objects in case the BW InfoCube has to be regenerated. This Multiprovider is
also not exposed in BPC. So per BPC model there is only one persistence object and no
composition concept.

Write-back technically writes delta records into the InfoCube, always to the lowest layer. The
concept of ‘unassigned value’ is not used.
 Page 8 of 20

‘BPC embedded’

This BPC environment type contains ‘BPC Models’. Any number of basic BW InfoProviders
(supporting write-back) can be assigned to a ‘BPC Model’. Local InfoProviders physically belong to
the ‘BPC Model’. Multiproviders are automatically assigned to a ‘BPC Model’ if at least one of the
part providers is assigned to the ‘BPC Model’. This is also true for aggregation levels.

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.

Delta

So the main difference is the usage of aggregation level together with the concept of ‘not assigned’
value. In addition ‘BPC standard’ uses the InfoCube as a pure storage: no build in BW concepts are
used e.g. ‘time consistency’ with respect to BW time characteristics or currency/unit characteristics
since these BW InfoObjects are simply don’t exist in BPC-generated InfoCubes. Time and currency
‘logic’ in BPC differs from BW built in concepts. Contrary, ‘BPC embedded’ uses build in BW
concepts and supports more BW InfoProviders.

3.4 Constraints
Reporting depends on consistent data, and this consistency is already ensured by applications
delivering the data or by ETL processes. Planning should not be bound to static data models (e.g.
from the actuals). This is why one can adjust and extent data models and build even new data
models for planning. When planning data is created and changed the system has to ensure data
consistency. To support these kinds of checks planning solutions provide some features to model
‘constraints’.

There exist (at least) two kinds of ‘constraints’:

 Page 9 of 20

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.

‘BPC standard’

For constraints of type 1 one can use ‘BPC Rules’; this is in fact a concept to validate data records
based some dimensions and measures (allowed values and/or ranges of values).
For constraints of type 2 one can use ‘BPC Work Status’ to protect data from being changed,
especially to control the planning process. To protect periods in rolling plans and to lock (protect) a
version are typical examples.

‘BPC embedded’

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.

Delta

Concept BPC standard BPC embedded

Constraints for BPC Rules (known as Characteristic Relationships
persistence ‘validations’
(methods CHECK, DERIVE,
in other products); CREATE);

validations can also be validations can also be implemented

implemented
using FOX or exit planning functions
using Script Logic
 Page 10 of 20

Concept BPC standard BPC embedded

Data protection BPC Work Status Data Slices,

BPC Work Status

(mapped to technical data slices at

run time)

4. Engines
Reporting and planning engines depend on design decisions made in the data model the engines
are based on. So the design and the way the engines work can be quite different. Traditionally in
planning solutions the reporting and planning engines are also quite different since reporting comes
first and planning was added later. Technically planning is often more complex since one needs a
reasonable transaction handling and one has to build ‘inversions’ of the reporting concepts (e.g.
reporting uses aggregation, planning uses disaggregation). In any case reporting and planning
engines have to support many types of calculations, here is where different kinds of data models
lead to very different engines.
Take MDX as the first example. MDX is a query language to support multidimensional data access
and computations (reporting). It does not work with just tables and views (the query language to be
used here is SQL) but it used ‘Cubes’ with contain ‘dimensions’ and ‘measures’, there are special
dimension like a ‘time’ dimension, and dimensions can have parent-child hierarchies. How to handle
all these objects is build in the very heart of MDX. That one is able to compute within a given
dimension is also a design decision of MDX, and the MDX engine is able to handle the
consequences of such a design decision (cf. ‘solve order’ when calculated members are used in
rows and columns).
MDX has a focus on reporting, planning features don’t really exist, with some exceptions e.g.
disaggregation. There one can also not find a real concept for transaction handling. The calculations
are mainly within the result set of an MDX statement. Thus calculations are modeled based on a grid
like model (rows, columns, and data cells). But in planning one also one has to copy, transform and
calculate ‘flat’ data records. To use a grid like format is not optimal in any case.

Summary

 Reporting and planning engines are based on design decisions of the data model; different
models often lead to different engines
 Calculations are needed both for flat data records and – of course – also to retrieve ‘data
cells’ in a grid like format (e.g. MDX result set)
 To support mass data handling (ETL like but also based on ‘business logic’) one also needs
build in algorithms and/or a script language
 Transaction handling like concurrency control is needed in planning applications

‘BPC standard’
 Page 11 of 20

Historically, main concepts in ‘BPC standard’ come from the MDX world. The SQE(shared query
engine) decides whether the data needed in a report are simple to read (only flat records to be read
and aggregated, no calculations) or whether besides aggregations, hierarchies and calculations are
needed. In the first case SQE can use a simple aggregation engine in the second case SQE will use
an MDX statement to read and calculate data.

For ETL like jobs ‘BPC standard’ is using the ‘BPC Data Manager’. Here one can also use batch
jobs; typical are data load scenarios, preparations of planning data or adjustments after manual
planning that are based on algorithms representing ‘business logic. The BPC generated real-time
InfoCube has not to be switched to the load-mode to use the ‘BPC Data Manager’. BPC also has a
script language to implement customer specific business logic.

In ‘BPC standard’ calculations are modeled in dimensions, so ‘formulas’ are dimension members. In
this sense ‘formulas’ are defined on the server. Of course there also exist calculations on the client
level, but we are talking here only about concepts used on the server. Calculations can also be used
in a script language; also MDX snippets are supported there. In addition ‘BPC standard’ has a lot
built in logic coming from data model. Take master data attributes as an example and here the sign
handling together with the usage of hierarchies and the account type (cf. AST, LEQ, INC and EXP
handling). As a result the SQE has to take all this information into account to create the ‘correct’
MDX statement to calculate values. To aggregate accounts without interpretation of the above
information will lead to result containing only ‘garbage’.

The persistence data model in ‘BPC standard’ is simple, namely the BPC generated BW InfoCubes
have one technical key figure. In simple reports or input forms thus there is a one-to-one
correspondence of a record in the fact table to a data cell in the result set of a report (or input-form).

‘BPC embedded’

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’ (cf.
glossary). 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).

The BW Analytic Engine prepares and optimizes the needed data read requests and delegates the
data access to the BW Data Manager (not to be confused with the BPC Data Manager; the latter is
something different). The BW Data Mangager then creates SQL queries to read and aggregate data.
 Page 12 of 20

Now we come to the fundamental difference of MDX compared with the BW Analytical Engine,
namely how calculations are modeled. Calculations are defined and modeled in the BW query. The
BW query definition contains so called ‘structures’. There is support for at most two structures, one
‘key figure structure’ and optional additional structure. One can consider a structure as an additional
dimension where one can define ‘restrictions’ and calculations. Thus restricted members or
calculated members in MDX or ‘BPC standard’ have to be modeled as restricted or calculated
structure elements in a BW query. Also complex ‘exception’ aggregation types are modeled in the
BW query e.g. where the order of aggregation and formula computation matters (take counting and
special handling of time aggregation as examples). Special computations based on the ‘sign’ of an
account can (and have to) be handled with formulas in BW queries. This also true for YTD reporting.
BW queries are needed for reports and input-forms.

Now to the algorithms based on flat data records. ‘BPC embedded’ uses the concept of planning
function types: the type represents the abstract algorithm, e.g. copy, revaluation, disaggregation,
FOX (the BW-IP script language). Since algorithms have parameters the concrete executable
instances of a planning function types are called planning functions. Here the parameters
(e.g. copy from, copy to) are specified (BW variables are supported) and also the filter to specify
data to be changed or reference data (read-only). A planning function is always assigned to an
aggregation level. The aggregation level defines the set of characteristics and key figures that are to
be changed.

The aggregation level is the concept to be able to ‘glue’ BW queries and planning functions together
and to have a well-defined ‘level’ where data will be changed. This is especially important when BW
queries and planning functions will be used together in Excel workbooks or web applications. The
aggregation level gives an additional structure to the multidimensional data model that allows
controlling data exchange (BW queries with planning functions in both directions).

Data exchange between BW queries and planning functions is also organized with some kind of
planning buffers to support planning and simulation without the need to save the data on the DB. Cf.
the next section for more details.

Delta

Concept BPC standard BPC embedded

Restrict values Special account BW structure element in a BW
query,
or
restricted key figure
Restricted measure
Restrict Restricted measure, dimension BW structure element in a BW query,
dimension
structure element of type selection
 Page 13 of 20

Concept BPC standard BPC embedded

Formulas Calculated measures, members BW structure element in a BW query,

structure element of type formula

Hierarchy, BPC hierarchy, BW hierarchy or display hierarchy,
parent-child
technical a special hierarchy the latter to display sub-totals in rows,
controlled by BPC columns

in a hierarchical way
Build in logic Build in account logic, e.g. sign, AST, No build in account logic, has to be
LEQ, INC and EXP modeled with restricted

Build in time logic, e.g. PERIODIC, key figures and formulas

QTD and YTD Predefined time hierarchies; but YTD
etc. has to be modeled via

restricted key figures

ETL BPC Data Manager, works also Real-time InfoCube in load mode:
in ‘planning mode’ WHM

Real-time InfoCube in planning mode:

planning functions
Planning Delivered BPC Script Logic or build Delivered planning function types or
algorithms in functionality build in functionality

like disaggregation like disaggregation and inverse

formulas
Script Language BPC Script Logic FOX, a planning function type
Write back On the lowest level of the BPC generated On level defined by the aggregation
BW InfoCube level for all

InfoProviders supported in BW-

IP/PAK

5. Transaction Concept

Using a client-server kind of architecture one has to decide whether one uses
a statelessor stateful programming model. Examples for stateless applications are most web
applications; stateful applications are useful when on the fly simulations are needed without storing
intermediate results on the DB. The transaction handling and enqueueconcept also depend on
design decision of a stateless or stateful application.
 Page 14 of 20

In a stateless planning application one usually retrieves only data needed for one ‘interaction step’ or
in the other extreme all data one might need in the application. Read data will usually be buffered on
the client (a flat client is the latter case). But the essence here is that the information available on the
client is sufficient to write back changed data to the DB only based on data known in the client and
persistent data available in the server. In other words no kinds of buffered data in the user session
(on the server) are required.

Stateful planning applications use ‘state’ in user session (on the server), i.e. in server roundtrips
information will be read, buffered and maybe changed. The changes are done only in the user
session not on the DB. This are simulation kind of scenarios but also performance may benefit from
such a design since resources can be required only once in the user session.

Stateless versus stateful applications usually also differ with respect to concurrency control. In any
case one has to have a transaction data lock concept (cf. SAP enqueueconcept) to avoid
inconsistent data when two different users change the same data region at the same time.
‘BPC standard’

‘BPC standard’ uses a stateless programming model. The data records read are notprotected by
SAP enqueues, i.e. in two user sessions the same data records can be changed. Only the time
interval needed to process ‘Submit’ (i.e. save on DB) will be protected by SAP enqueues (using the
BW planning enqueue server). The time interval is defined by the time to compute the delta records
to be saved plus the time to write the data records in the InfoCube. The implemented logic is: the
last one wins. Simulations are possible but one has to save ‘intermediate’ data on DB (‘submit’ and
‘refresh’).

Error handling

With respect to changed data the system filters out inconsistent records; consistent records can be
saved, inconsistent records cannot be saved on DB.
‘BPC embedded’

‘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.
 Page 15 of 20

Data in change mode will be protected by exclusive locks, reference data in a planning function will
be protected by shared locks (cf. 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’.
 Page 16 of 20

Remark

Don’t confuse ‘locked’ data with ‘BPC work status’ or ‘locked cells’. ‘Lock’ as used above means
transaction data locks (cf. SAP enqueue concept), i.e. the enqueue concept of the BW planning
enqueue server.

Delta

Concept BPC standard BPC embedded

Server state Stateless Stateful
SAP Enqueue Read: No Read: Yes

Save: Yes, exclusive in time Change mode: exclusive

interval
Read mode: shared
delta computation + save on
DB Save: No locks necessary; release locks,
relock still required resources
Locked data Only at ‘save on DB’, Based on filter and reference data (planning
region extracted from changed function)
records,
and filter and BW query definition
i.e. computed ‘selection table’
that contains all changed (input-ready property of structure elements in
a query).
records
Effect: Only one user can change data the
Effect: Last one wins specified data region
Lock server Enqueue server: BW planning Enqueue server: BW planning
Transaction data No Yes:
buffers
Planning buffer: Green requests (InfoCube)

Delta buffer: User session delta records

After-Image buffer: User session after-

image records

Simulation Via ‘save on DB’ Via ‘transfer’.

Session data will be taken into account in

planning functions and

BW queries, no ‘save on DB needed.

‘Reset to last saved state’ possible

 Page 17 of 20

Concept BPC standard BPC embedded

Error handling ‘Commit’ on DB for Write into delta or after-image buffer
consistent data records, contents using ‘everything or

inconsistent records will not nothing’ principle, i.e. all changed/new

be saved records have to be consistent

to be written into the delta or after-image

buffer.

Data in delta or after-image buffer is

considered to be consistent

and can be saved on DB.

Exception: Planning function before ‘save

on DB’

6. Links

Information about ‘BPC standard’ and ‘BPC embedded’ in general:

Unifying BPC NW and BW-IP

SAP Business Planning and Consolidation 10.1 NW FAQs

A small example how to use inverse formulas:

BW730: Input ready formulas in BW Integrated Planning

Information about the SAP Enqueue Server

Relationship Between SAP Locks and Database Locks – SAP Lock Concept – SAP Library
 Page 18 of 20

BW Enqueue Server (used in BW-IP and BPC), general information and sizing

http://service.sap.com/sap/support/notes/928044

7. Glossary
Terminology in bold setting is explained in this glossary.

 BPC embedded: The ‘BPC environment’ type used when BW-IP/PAK objects are exposed
in BPC
 BPC standard: The ‘BPC environment’ type used when no BW objects are exposed directly;
all BW objects are generated and controlled by BPC
 BPF: Business Process Flow; a concept to create task lists and to assign tasks to users;
allows to group planning tasks
 BW: Business Warehouse
 BW Analytic Engine: The analytic engine reads, aggregates and computes data based
on BW queries
 BW Aggregation Level: A subset of characteristics and key figures of the underlying
InfoProvider; is a concept to add structure to an InfoProvider. Is used in BW-IP to define the
fields to be changed in the underlying InfoProvider.
 BW Dimension: A set of characteristics in an InfoCube, usually semantically related; part of
the InfoCube definition
 BW Enqueue Server: Server infrastructure used to implement an enqueue concept for
transaction data records based on data regions defined on selection tables
 BW Hierarchy: Structure characteristics values in a hierarchical way (parent, child). Defined
with respect to a characteristic, the base characteristic. Inner hierarchy (nodes with children)
that are master data values of the base characteristic are called postable nodes
 BW-IP: BW Integrated Planning
 BW-IP Data Slice: A filter that defines a protected data region; records in this data region cannot
be changed
 BW Multiprovider: A union of BW basis InfoProviders
 BW query: A definition to read, aggregate data from InfoProviders and do computations with data;
has also a visual part, i.e. design of the initial result set (rows, columns). A rough analogy is to
consider a BW query as a ‘template’ for all ‘reasonable’ MDX statements one might create to get
result sets from a query cube. BW queries are the basis of the BW Analytic Engine
 CATE: Category, Account, Time, Entity
 Compounded characteristics: Characteristics may depend on other characteristics, so that only
the combination has a meaning, e.g. fiscal year depends on fiscal year variant
 Page 19 of 20

 Disaggregation: Also top-down distribution, i.e. taking aggregated values and to distribute
values down to lower levels using weight factors
 Fiscal Year Variant: Defines properties of fiscal years, e.g. the mapping of posting periods to
intervals of calendar days, number of posting periods, year shifts of posting periods, cf.
transaction GVAR
 ETL: Extract Transform Load
 FOX: BW-IP/PAK script language, technically a planning function type. FOX comes from formula
extension.
 Green request: A real-time InfoCube can have green and yellow requests; green requests
come from loaded data, e.g. using WHM, or from closed yellow requests. To avoid too many
requests, real-time InfoCubes have a yellow request which is closed after some ‘water mark’
of delta records contained in the request. Green requests can be contained in the planning
buffer; yellow requests are never (and cannot be) buffered in the planning buffer.
 InfoCube: A BW InfoProvider with persistence. Uses an ‘insert-only’ design and is optimized for
handling delta records.
 InfoCube, real-time: A BW InfoCube, optimized for write-back. In load-mode one can use WHM
to load data, in planning mode one can use BW-IP/PAK planning functions and input-ready
queries to write data into the InfoCube.
 InfoObject: Basic BW object, namely characteristics and key figures
 InfoProvider: BW abstraction of a BW data persistence or a composition of data persistence
 Inverse Formulas: Concept used in input-ready BW queries to make formulas input-ready and to
calculate back to operands of the formula
 LOB: Line of Business
 MDX: Multidimensional Expressions, a query language designed for multidimensional data
access and computations
 OLAP Cache: A cache containing persistent transaction data based on a BW query
definition and a data read request; contains usually aggregated data in an optimized form
needed by the BW Analytic Engine (also sometimes called BW OLAP)
 PAK: Planning Application Kit, i.e. the technology used to run BW-IP algorithms directly on SAP
HANA
 SAP Enqueue Server: Server infrastructure to implement the SAP enqueue concept. Supports
mainly ‘record based’ enqueues. The SAP enqueue server is used by BW enqueue server to
implement enqueue based on data regions, i.e. selection tables
 Script Logic: BPC script language used in ‘BPC standard’
 Stateful: ‘Server state’ is kept between client server roundtrips, e.g. meta data buffer, transaction
data and enqueues
 Stateless: No ‘server state’ is kept between client server roundtrips
 Structure element: This is an element in a structure of a BW query; can be of type selection or
formula
 Query Cube: ‘Virtual cube’ defined by the (static) filter of a BW query. This is a run-time object.
 Unassigned value: In BW all characteristics support the unassigned value (external
representation ‘#’); the unassigned value is always a valid master data value; this value
represents the ‘rest’ value; this design is very useful to work with ‘delta records’
 User session, also often called planning session: Server concept that represents ‘server state’
assigned to a user. On the ABAP server this is the so called ‘internal session’, cf. ABAP Keyword
Documentation (ABAP-Overview->ABAP Memory Organization – Overview -> General Memory
Organization).
 WHM: Warehouse Management
 YTD: Year to Date




 Page 20 of 20

 Alert Moderator

Assigned tags

 SAP Business Planning and Consolidation, version for SAP NetWeaver

 BW Planning
 #nw
 bpc embedded
 BPC Standard
View more...

Related Blog Posts

 SAP Business Planning and Consolidation 10.1 NW FAQs

By William Yu, Mar 20, 2014
 Collection of Interesting Resources Regarding Business Planning in BW
By Gerd Schoeffl, Jan 08, 2015
 Dummies for BPC NW Embedded system (1)
By Former Member, Aug 25, 2016

Related Questions

 SAP BPC 10.1 Standard on S4 HANA 1709

By Former Member, Apr 04, 2018
 Drill Through Configuration in AO
By RAM PATODIA, Feb 12, 2018
 BW Embedded+BPC Standard-Server installation
By Former Member, Apr 18, 2018