InfoProviders

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw73/helpdata/en/4c/a2275dbebd6642e10000000a15822b/content.htm
Created on October 09, 2014

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2014 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 1 of 9

Table of content
1 InfoProviders
1.1 Characteristic Relationships
1.2 Characteristic Relationships for Time Characteristics
1.3 Data Slices
1.4 Implementing Characteristic Relationships and Data Slices on the SAP HANA Database
1.4.1 SAP HANA-Specific Interfaces for Characteristic Relationships and Data Slices
1.4.2 Parameters for the SQLScript Procedures
1.4.3 Transport and Lifecycle Management of Required Objects

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 2 of 9

1 InfoProviders
Use
InfoProviders contain real-time InfoCubes and DataStore objects for direct updates in planning mode. As such, they provide the data basis for BW Integrated
Planning. Aggregation levels are a type of virtual InfoProvider. They are based on a planning-relevant InfoProvider or a MultiProvider that contains an InfoProvider
of this type. Aggregation levels are specifically designed so that you can plan data manually or change data using planning functions.
For more information about the types of InfoProvider, see:
Real-Time InfoCubes
Creating DataStore Objects for Direct Update
Creating MultiProviders
Characteristic Relationships and Data Slices
When planning, you can define the permitted combinations of characteristic values in the form of characteristic relationships and create data slices for the data
that you want to protect for a real-time InfoCube or a DataStore object for direct updates in planning mode.

Note
More information: Characteristic Relationships and Data Slices.
If the generic types of characteristic relationships (attribute, hierarchy, DataStore) and data slices (selection) do not meet specific customer requirements, you can
implement characteristic relationships and data slices of type Exit.

Note
For more information, see Implementing Characteristic Relationships and Data Slices on the SAP HANA Database
Default Key Date for Planning
You can create a default key date for a real-time InfoCube or a DataStore object for direct updates in planning mode. If time-dependent objects (such as attributes
or hierarchies) are used in objects in the planning model, you can always refer to the default key date for planning. This allows you to ensure that the same key
date is used throughout the planning model. The planning model objects that are relevant for this are characteristic relationships, data slices and parameters of
planning functions.
More information: Standard Key Date in Planning Functions.

Integration
Under Modeling in the Data Warehousing Workbench , you can create InfoProviders as the data basis for BW Integrated Planning. More information: Creating
InfoProviders.
In Planning Modeler , you can select InfoProviders that you want to use as the data basis for BW Integrated Planning. More information: Selecting InfoProviders.

1.1 Characteristic Relationships

Use
Characteristic relationships are used to define a relationship between characteristics with matching contents. You can use characteristic relationships to define
rules to check permitted combinations of characteristic values for each real-time InfoCube or each DataStore object for direct updates in planning mode. You can
also define rules for the system to use to derive values from one characteristic for another. This is useful for example if you want the derivable characteristics to be
available for further analysis.
You can define characteristic relationships for the master data of a characteristic (type attribute), a hierarchy (type hierarchy), a DataStore object (type
DataStore) or an exit class (type exit).
Unlike an InfoCube, a DataStore object for direct updates in planning mode has a key. Using BW-integrated planning, you can add or change data records. In
each case, the key needs to be filled. Characteristic relationships can be used to derive key fields from other characteristics; this avoids the need for every
aggregation level to always contain all the characteristics of the key.

Integration
If you define characteristic relationships for the attributes or hierarchies of characteristics, the system proposes the attributes or hierarchies that you created in the
BW system for a characteristic (see Tab Page: Attributes, Tab Page: Hierarchy and Hierarchy).
Characteristic relationships are created for a real-time InfoCube or a DataStore object for direct updates in planning mode. The system applies the characteristic
relationships to all planning-relevant InfoProviders that reference this InfoProvider.
Each input-ready query and planning function automatically takes the characteristic relationships into account:
In an input-ready query, cells for invalid characteristic combinations are not input ready, and new data records with invalid characteristic combinations
cannot be created.
Planning functions use the characteristic relationships to constantly check whether new characteristic combinations are valid. If it finds invalid combinations,
the system produces an error message.
The system derives the characteristics when it identifies the delta records in the delta buffer (for the InfoCube) or in the after image buffer (for the DataStore object).
Possible source characteristics include characteristics in the planning-relevant InfoProvider that are filled by characteristics from the relevant aggregation levels. If
characteristic relationships are changed, the data records in the planning-relevant InfoProvider might also have to be adapted to the new structure. You use the
Reposting Characteristic Relationships planning function for this purpose.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 3 of 9

Prerequisites
Before you can define characteristic relationships, the following prerequisites must be met:
The InfoProvider must be a real-time InfoCube or a DataStore object for direct updates in planning mode. The defined characteristic relationships also take
effect in MultiProviders where planning-relevant InfoProviders are used. More information: InfoProviders.
In characteristic relationships of type attribute, the target characteristic must be defined as an attribute of the basic characteristic and it must be contained
in the planning-relevant InfoProvider.
In characteristic relationships of type hierarchy, the target characteristic must be contained in the selected hierarchy and in the planning-relevant
InfoProvider. The hierarchy is mainly intended for modeling a derivation relationship; thus the hierarchy cannot contain a leaf or an inner node more than
once. Link nodes are also not permitted.
With characteristic relationships of type DataStore, only standard DataStore objects are permitted. You can use all the managing and monitoring methods
that are available in the Data Warehousing Workbench.

Features
Definition of a Characteristic Relationship
You can create characteristic relationships for a real-time InfoCube or a DataStore object for direct updates in planning mode. A characteristic relationship is made
up of a set of relations (steps) that link characteristics and are numbered sequentially. Each of these relations links a set of characteristics. These relations
represent the smallest units of a characteristic relationship.
Behavior of Combination Checks With and Without Derivation
You can only use relations to check characteristic combinations or derive characteristics. You specify this behavior when defining a relation. You can link several
relations of type Derivation if the targets of one relation are the sources of another relation. Redundancy should be avoided here so that the relations actually
represent the smallest unit of the characteristic relationships.
At runtime, the system determines the relationships in the planning-relevant InfoProviders that are used.
Combination check: A relation is only used in an aggregation level if every characteristic of the relation occurs in the aggregation level. With derivations,
these are the source and target characteristics. In this case, no characteristics are derived, and the system just performs a combination check.
Characteristic derivation: Derivation is not performed in an aggregation level. Derivation is only performed for records in the planning-relevant
InfoProvider. The system first determines the set (S) of characteristics that are filled by the relevant aggregation level. If all the source characteristics are in
set S, the system applies the derivation relations in the next step. The target characteristics of these derivations can then serve as sources in the steps that
follow. This means that the system performs the maximum possible derivation in the planning-relevant InfoProvider. If previously derived characteristic
values are changed again in subsequent steps, the derivation is incorrect. The system posts an error message.
Types of Characteristic Relationships
The following types of characteristic relationships exist:
Type

More information

Attribute

You can select an attribute of the basic characteristic as the target characteristic
(characteristic currency is an attribute of characteristic controlling area for example).
The existing combinations of characteristics and attribute values are always interpreted
as valid combinations.

Hierarchies

Characteristics are available as source or target characteristics if you marked them as

External Characteristics in Hierarchy in InfoObject maintenance. In addition to the
hierarchy basic characteristic, the hierarchy must include at least one other characteristic.
Only one characteristic is permitted as a source and/or target characteristic (higher-level
characteristics are not counted in compound characteristics).
The permitted combinations are taken from the hierarchy structure. A hierarchy can be
used in multiple relations: in step one, you derive a characteristic on the next level up
from the hierarchy basic characteristic; in the second step you take the derived
characteristic and derive the characteristic on the next level.
The hierarchies can be parameterized with suitable variables in accordance with the
property of the hierarchy.

DataStore

The data records located in the DataStore define the valid characteristic combinations and
are used for characteristic derivation.
Only combination check: You can select all InfoObjects from the DataStore object
(except for key figures).
With Derivation: You have to select the keys of the DataStore object as source
characteristics.
Target characteristics can be InfoObjects from the data part of the DataStore object (except
for key figures).
The keys for the DataStore objects can be restricted in any case; the restricted part is then
used for the combination check or derivation. The restrictions can be parameterized with
variables that must be replaceable without the dialog.
We recommend that you use only small DataStore objects (with few characteristics, few
records).

Exit

The valid characteristic combinations and derivable characteristic values are defined by
the customer-specific implementation of the specified exit class.
The exit class must implement interface IF_RSPLS_CR_EXIT. Only these types of
classes can be edited in maintenance. We recommend deriving your class from the
example class CL_RSPLS_CR_EXIT_BASE. You then only have to implement
methods 'CHECK', 'DERIVE' and 'CREATE'. Class 'CL_RSPLS_CR_EXIT_BASE' is
executable, but does not execute any actions.
Note the example source code given in the template class too: An infrastructure for
buffering can be provided here.

Note

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 4 of 9

As well as the characteristic relationships listed above, characteristic relationships for BW time characteristics are also permanently activated in the
system (see Characteristic Relationships for Time Characteristics).
The initial characteristic value # not assigned ) has a special role in a relation. Characteristics that do not occur in an aggregation level (and cannot be derived)
are updated with the initial value.

Example
Combination check without derivation:
There is a relation between the characteristics Product and Assortment ; usually there is no derivation relationship between the two. In aggregation levels
with Product but without Assortment , Assortment is therefore updated with the initial value. These types of combinations are always valid and they cannot
be forbidden. This also applies to combinations with the initial value for Product .
Combination check with derivation:
There is a relation between the characteristics Cost Center and Profit Center ; Profit Center can be derived from Cost Center . In an aggregation level that
contains Profit Center but not Cost Center , Cost Center is also updated with the initial value. Combinations of this sort cannot be forbidden. Since Profit
Center can be derived from Cost Center however, the reverse situation produces an invalid combination.

Activities
For more information on defining characteristic relationships in Planning Modeler, see Defining Characteristic Relationships.

1.2 Characteristic Relationships for Time Characteristics

Use
The BW system contains various time characteristics. When you create a planning model, you have to select an appropriate time characteristic for the planningrelevant InfoProvider. The choice of time characteristic depends on the planning application. You can use the Fiscal Year Period characteristic 0FISCPER
(12.2005 + 1 = 1.2006) for rolling planning, for example. However, if you want to build query views that contain Periods in the rows and the Fiscal Year in the
data columns, it makes more sense to use the Periods and Fiscal Year time characteristics. You should avoid using redundant time characteristics in a
planning-relevant InfoProvider. However in some cases, like the example given above, this may be useful.
If a planning-relevant InfoProvider contains redundant time characteristics, at runtime, the system uses the characteristic relationships that are required by the
input-ready queries or planning functions for the corresponding time characteristics. These characteristic relationships have type "derivation".

Caution
Note that the system only allows unique relationships. You can derive the calendar year (0CALYEAR) from time characteristic quarter (0CALQUARTER), but
not the calendar week (0CALWEEK).
If you want to model a relationship of this type, you require a customer-defined characteristic relationship of type exit that uses its own characteristics. These
characteristics must reference the appropriate standard time characteristics.
The system uses the derived characteristic relationships for the time characteristics (as with the other relations) for derivation purposes and combinations checks.

Caution
Note that for each time characteristic there is a maximum valid time interval. This can be set in the system. If you are using a time characteristic, the
maximum valid time interval has to cover the entire planning timeframe.
On the General Settings tab page, you specify the value on the F4 Help and Hierarchies for Time Characteristics screen (transaction
RSRHIERARCHYVIRT). Since this setting impacts on performance, you should keep the interval as small as possible.
You cannot create derivations that contain a time derivation that is used automatically in the system.
The following table offers an overview of the derivations that are automatically supported by the system:
Source characteristics

Target characteristics

0CALDAY

0CALWEEK

0CALDAY

0CALMONTH

0CALDAY

0CALQUARTER

0CALDAY

0CALYEAR

0CALDAY, 0FISCVARNT

0FISCPER

Fiscal year variant required due to compounding

0CALDAY, 0FISCVARNT

0FISCYEAR

Fiscal year variant required due to compounding

0CALDAY

0WEEKDAY1

0CALDAY

0CALMONTH2

0CALDAY

0CALQUART1

0CALDAY

0HALFYEAR1

0CALDAY, 0FISCVARNT

0FISCPER3

0CALMONTH

0CALQUARTER

0CALMONTH

0CALYEAR

0CALMONTH

0CALMONTH2

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Comment

Fiscal year variant required due to compounding

Page 5 of 9

0CALMONTH

0CALQUART1

0CALMONTH

0HALFYEAR1

0CALQUARTER

0CALYEAR

0CALQUARTER

0CALQUART1

0CALQUARTER

0HALFYEAR1

0CALMONTH2

0CALQUART1

0CALMONTH2

0HALFYEAR1

0CALQUART1

0HALFYEAR1

0FISCPER, 0FISCVARNT

0FISCYEAR

Fiscal year variant required due to compounding

0FISCPER, 0FISCVARNT

0FISCPER3

Fiscal year variant required due to compounding

0CALWEEK, 0WEEKDAY1

0CALDAY

0CALYEAR, 0CALQUART1

0CALQUARTER

0CALYEAR, 0CALMONTH2

0CALMONTH

0FISCYEAR, 0FISCVARNT, 0FISCPER3

0FISCPER

Fiscal year variant required due to compounding

1.3 Data Slices

Use
The data slice is a concept for protecting the main data of a planning-relevant InfoProvider against changes. This protection affects all input-ready queries and
planning functions that use this planning-relevant InfoProvider.

Example
If you want to ensure that certain plan versions cannot be changed after a certain point in time for example, and prevent current data from being overwritten,
you can use a data slice containing these plan versions.

Prerequisites
Data slices are created for a real-time InfoCube or a DataStore object for direct updates in planning mode. They affect all planning InfoProviders that contain this
planning-relevant InfoProvider. More information: InfoProviders.

Features
There are two types of data slice:
Data slices based on a selection. Here, you set the restrictions for the characteristics that you want to protect against changes.
Data slices based on an exit class. In the exit class, you can implement a customer-specific logic to protect data records.
The following basic rules apply for data slices:
If no data slice is defined for a planning-relevant InfoProvider, any valid characteristic combination can be posted to this planning-relevant InfoProvider (see
Characteristic Relationships).
Every data record in the selection in a data slice is protected against changes. The corresponding cells in input-ready queries cannot be changed. You
cannot use planning functions to change or save this kind of record. The data slices cumulate.
If a real-time enabled InfoProvider contains a data slice without any characteristic value restrictions, the data slice acts as a lock for postings of all types in
the entire real-time InfoProvider.
Once you have created a data slice it is activated automatically. The settings in the data slice definition have an immediate effect on the ability to update
data. You can deactivate an existing data slice at any time (status inactive ). This data slice is then ignored.

Activities
For more information on defining data slices in Planning Modeler, see Defining Data Slices.

1.4 Implementing Characteristic Relationships and Data Slices on

the SAP HANA Database
If the generic types of characteristic relationships (attribute, hierarchy, DataStore) and data slices (selection) do not meet specific customer requirements, you can
implement characteristic relationships and data slices of type Exit.
The following are two examples of requirements that can be met with an implementation of characteristic relationships or data slices of type Exit:
Example 1: Let us assume that two previously separate sales organizations are being merged. Some of the products offered by one organization are also
offered by the other, and these products originally had different product numbers in the two organizations. To allow standardized reporting over the entire
product range, the two independent product catalogs are mapped to a cross-organizational product catalog using a mapping table. The mapping table has
the following structure:
Table 1: Mapping Table Z_MAP_PRODUCT
Region

Regional_Prod_ID

Product_ID

R_01

RP_123

UP_123

R_02

RP_123

UP_321

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 6 of 9

...

...

In the different regional sales organizations, different products can have the same identification number. To ensure that there is a unique designation for a
cross-regional comparison, these RP numbers must be converted into unique UP numbers. In our example, product RP_123 from region R_02 is given
product ID UP_321.
Example 2: Let us assume that a company wants to implement a company-wide planning process for quarterly sales key figures at the product group level.
Note that some regional sales organizations fix their plan data (for certain planning versions at least) on a certain date, while others modify their plan data if
dictated by certain subsequent events.
This could mean for example that the plan data of Region A for the first quarter of the following year is fixed starting on 15th December of the current year,
while Region B is allowed to modify its plan right through to the end of January on the basis of an unforeseen opportunity to increase its sales. To make this
comprehensible, plan version V2 can be introduced, filled with the original plan data from plan version V1 and then opened for modifications from Region B
only.
To implement the requirement in example1, you can define a characteristic relationship of type Exit, containing two relations (steps) with derivation: The first
relation has the unique ID as its source characteristic and the original ID (in connection with the original sales organization) as its target characteristic, while the
second relation is the same but the other way round. The original ID is therefore derived if the unique ID is planned. The unique ID is derived if the fields are
reversed. The consistency of the two IDs is guaranteed if both characteristics are open for planning.
The requirement from example 2 is a typical case for a data slice of type Exit, defined on the characteristics Region, Plan Version and Quarter, with access to
data that is edited outside of the BWsystem in a tool for the planning process, which stores its data in a database. To make this requirement more individual still,
there should a number of administrators who are authorized to modify plan data at any time, in order to correct incorrect entries.

ABAP Exit Implementation

The typical ABAP exit implementation of these examples is direct, with the external data being read from the database using SQL commands from the ABAP
runtime and - taking into account further information such as user name (sy-uname) - checking, deriving or creating records in the corresponding structure.

Implementation on the SAP HANA Database

In BW, you can perform planning using internal database routines. In the SAP HANA database, you can perform SAP HANA-optimized planning. If you are using
the Planning Applications Kit, we recommend also implementing the customer-specific exist functionality for characteristic relationships directly in the SAP HANA
database using SQLScript. If you do not do this, you cannot take full advantage of the performance optimization possibilities: Plan data would then have to be
submitted to the ABAP runtime and processed in individual records. While this would not be problematic for displaying data from analytical queries, as the data is
available in the ABAP runtime anways, there can be a negative impact on performance if disaggregation (top-down distribution) or planning functions are
executed on mass data. The entire data processing then takes place in the SAP HANA database. An ABAP implementation of the exit functionality would then
prevent performance from being optimized.

Note
Note the following however: Even if you implement SQLScript procedures for all methods that are used in characteristic relationships and data slices, the
corresponding ABAP implementations must also be present, as the system triggers the ABAP equivalent in certain situations in order to avoid data transfer of
individual records between the BW system in the SAP NetWeaver stack and the SAP HANA database.

Note
If a SQLScript implementation is performed, the names of the implementing SQLScript procedures are determined in the ABAP runtime, and other
parameters that are only available in the SAP NetWeaver stack (such as the user name in the sy-uname system field) are determined for subsequent use in
the SQLScript implementation.
For ABAP processing of the exits, the following interfaces are required:
IF_RSPLS_CR_EXIT : ABAP implementation of the characteristic relationships
IF_RSPLS_DS_EXIT : ABAP implementation of the data slices
In addition to these interfaces, the following interfaces also have to be implemented in order to process the data in the SAP HANA database:
IF_RSPLS_CR_EXIT_HDB : SQLScript implementation of the characteristic relationships
IF_RSPLS_DS_EXIT_HDB : SQLScrip implementation of the data slices
The SAP HANA-specific interfaces have the following tasks:
1. They serve as marking interfaces which show that the data will be processed in the SAP HANA database, regardless of the existence of characteristic
relationships and data slices of type Exit.
2. By providing information about the corresponding SQLScript implementations, these implementation should be called up if the data is processed in the
SAP HANA database, and a data transfer to the ABAP runtime environment can be avoided.

Related Information
SAP HANA-Specific Interfaces for Characteristic Relationships and Data Slices
Parameters for the SQLScript Procedures
Transport and Lifecycle Management of Required Objects

1.4.1 SAP HANA-Specific Interfaces for Characteristic

Relationships and Data Slices
This section provides an overview of the implementation of SAP HANA-specific interfaces IF_RSPLS_CR_EXIT_HDB (for characteristic relationships) and
IF_RSPLS_DS_EXIT_HDB (for data slices). These contain two methods, GET_SQLSCRIPT_INFO and GET_SQLSCRIPT_ PARAMETERS.

Method GET_SQLSCRIPT_INFO
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 7 of 9

Method GET_SQLSCRIPT_INFO returns the name of the SQLScript procedures that are required for exit processing in the SAP HANA database.
Method GET_SQLSCRIPT_INFO of interface IF_RSPLS_CR_EXIT_HDB has the following export parameters:
Table 1: Export Parameters of Method GET_SQLSCRIPT_INFO of IF_RSPLS_CR_EXIT_HDB
Parameter

Description

E_DB_SCHEMA_NAME

Name of a database schema that contains the SQLScript procedures to be executed.

If the parameter of the method is not set, the DB schema of the SAP system is taken.

E_PROCEDURE_NAME_CHECK

Name of the SQLScript procedure that contains the implementation of the method to
check characteristic relationships.

E_PROCEDURE_NAME_DERIVE

Name of the SQLScript procedure that contains the implementation of the method to
derive characteristic relationships.

E_PROCEDURE_NAME_CREATE

Name of the SQLScript procedure that contains the implementation of the method to
create characteristic relationships.

E_PARAMETER_NAME

Name of a DDIC structure that describes additional parameters that are passed on to the
SQLScript procedures at runtime.
If the parameter of the method is not set, no additional information is sent by the
application server.

Method GET_SQLSCRIPT_INFO of interface IF_RSPLS_DS_EXIT_HDB has the following export parameters:

Table 2: Export Parameters of Method GET_SQLSCRIPT_INFO of IF_RSPLS_DS_EXIT_HDB
Parameter

Description

E_DB_SCHEMA_NAME

Name of a database schema that contains the SQLScript procedures to be executed.

If the parameter of the method is not set, the DB schema of the SAP system is taken.

E_PROCEDURE_NAME_PROTECTED

Name of the SQLScript procedure that contains the implementation of the data protection
check in data slices.

E_PARAMETER_NAME

Name of a DDIC structure that describes additional parameters that are passed on to the
SQLScript procedures at runtime.
If the parameter of the method is not set, no additional information is sent by the
application server.

Note
If method GET_SQLSCRIPT_INFO does not set one of the parameters with procedure names, the corresponding ABAP implementation is called at runtime
as a fallback.

Method GET_SQLSCRIPT_ PARAMETERS

When export parameter E_PARAMETER_NAME of method GET_SQLSCRIPT_INFO returns the name of the DDIC structure, method GET_SQLSCRIPT_
PARAMETERS is called. For both characteristic relationships and data slices, this method has the following export parameter:
Table 3: Export Parameter of Method GET_SQLSCRIPT_PARAMETERS
Parameter

Description

E_S_PARAMETER

Structure used to pass on additional parameters to the SQLScript procedures.

At runtime, this parameter has the type of the DDIC structure called
E_PARAMETER_NAME.

1.4.2 Parameters for the SQLScript Procedures

All SQLScript procedures for the implementation of methods to check and derive characteristic relationships or to protect data slices require an IN table parameter
and an OUT table parameter with the structure of the modeled characteristic relationship or data slice. The IN parameter table contains all data records to be
processed in the implementation. The OUT parameter table returns the processed data records.

Characteristic Relationships
CHECK
IN: All data records that should be processed by the procedure.
OUT: All data records in the IN parameter table, which are considered valid with regard to the characteristic relationship.
DERIVE
IN: All data records that should be processed by the procedure.
OUT: All data records in the IN parameter table, which are considered valid with regard to the characteristic relationshipm with derivation of target
charactersitic values from the source characteristics.
CREATE
OUT: For the CREATE procedure, there is an OUT table parameter with the structure of the modeled characteristic relationship, containing all
characteristic combinations that are valid according to the selection condition passed on to this method.

Data Slices
PROTECTED
IN: All data records that should be processed by the procedure.
OUT: All data records in the IN parameter table, which are protected against changes with regard to the data slice.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 8 of 9

For all methods, the following applies:

If a DDIC structure of method GET_SQLSCRIPT_INFO is returned in parameter E_PARAMETER_NAME, the SQLScript procedure must have additional scalar
parameters. The names of these parameters correspond to the component names of the DDIC structure.

1.4.3 Transport and Lifecycle Management of Required Objects

The ABAP classes that implement the SQLScript metadata rules can be transported with the SAP NetWeaver CTS (Change and Transport System). The
following section describes the software logistics options for the corresponding SQLScript procedures.

Creating SQLScript Procedures for Each System

You can create the procedures for each system in your system landscape using the SQL console in the SAP HANA studio or using transaction DBACOCKPIT in
the BW system as SAP HANA catalog objects. In the software, this option is only supported by syntax highlighting in the SAP HANA studio, but it is also very
simple and direct. Note however that every change to the implementation of a procedure must be replicated manually in all other systems in your system
landscape.

Creating the SQLScript Procedures as SAP HANA Repository Objects

You can create and activate the procedure as a SAP HANA repository object in the development system. (The activated object is then in the DB schema
_SYS_BIC.) This allows you to use the SAP HANA software logistics functions to provide data to downstream systems. This option involves a considerable
amount of configuration in order to set up a workable development environment in the SAP HANA studio. It is often worth the extra effort though, as you receive
better system support and can use Lifecycle Management for SQLScript procedure implementations in SAP HANA.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 9 of 9