Customizing of SAP BW

In a world of SAP, in general we use a term customization a lot. Normally the customization refers to adjusting an application to user specific needs. We say that the application gets customized to meet respective business needs. In case of multiple SAP modules (FI, CO, SD, MM, etc.) it means a process (usually an implementation project) thru which those modules are adjusted to fit an organization needs.

However, in SAP BW world this term is not much used. Reason is that the BW is rather technical module where the aim is to provide a user with a set of reports to help him to make a business decisions. Looking at the BW as a system to provide a business intelligence solution via frontend objects like reports/dashboards implementation of the BW is about delivering those BI objects. Therefore it cannot be just customized -  needs to be developed.

However, in my point of view there are two aspects that we possible can speak about customizing of the BW systems. One would be deploying of Business Content in order to deliver the reports. This includes an activation of it, setting it up, enhancing it (e.g. DataSources or reports via customer exits) etc. Second thing could be an initial technical configuration of the BW system right after its installation that can be viewed as the BW system customization. These are meant to be a steps that make the BW system usable and be ready for developing BI objects. This can involve steps like:

·        Defining Client Administration in the BW System (create a client copy (t-code SCCL), log sys (t-code SCCLN t-code SCCLN), etc.)

·        SAP Basis setup: profile parameters (t-codes: RZ10, ST02, etc.)

·        Create logical system (t-code: BD54)

·        Assign logical client (t-code: SCC4)

·        System Change Option (t-codes SE06)

·        OLAP cache settings (t-codes: SCUSTV14 or RSRCACHE)

·        Default processing settings (t-codes: RSODSO_SETTINGS)

·        Background settings (t-codes: RSBATCH)

·        Transfer parameters related to source systems (max kB, max lines, frequency, max. process, target system, t-codes: RSCUSTV6, SBIW)

·        Assign default logon group, default RFC group (t-codes: SMLG, RZ12)

·        Create default user, assign its authorization (t-codes: SM59, SU01)

·        Defining client administration in source systems

·        Check of IO 0OBJNM (t-code SNRO (Number Range Object Maintenance) object: BIM9999991)

·        Activate Technical Business Content (t-codes: RSTCO_ADMIN, RSTCT_INST_BIAC)

·        Check of what Business Function are in/active (t-code SFW5)

·        Configuring cold store

·        Configuring BW workspaces

·        Configuring SAP BW/4HANA Cockpit

·        Creating a Connection to a Back-End Systems (define users, logical systems names, ALE communication, RFC connections, customizing settings in source system, transfer global settings (e.g. exchange rates) from source to BW, activate DataSources, meta data upload)

·        Activate BEx history (t-codes: RSA1 or RS_PERS_ACTIVATE)

·        Activate relevant web services (t-code: SICF ->

RSO_META_DATA_REPOSITORY), web dynpros (t-code: SICF_INST)

·        Customizing of BEx/BW frontend version (t-code: RRMX_CUST)

·        Activate transport system STMS/CTS (t-code: STMS)

·        Create custom development package to be assigned to Transport Connection (t-code SE80)

·        Maintain permitted characters (t-code RSKC)

·        Check table RSADMINA

·        Check table RSADMIN

·        Activate background dispatching (t-code RZ11)

·        Assign default menu (t-code SSM2)

·        Setup trusted connection (e.g. for SSO)

·        Etc..

All of these is probably a reason why there is no a central t-code where the BW customization would take a place. Although through the history of SAP BW there were attempts to create such t-code. Actually, even in the newest BW/4HANA systems the below two t-codes are available. They both were created very long time ago as they started to appear in very old BW versions. They both call Function Module “DSYS_OUTLINE_BROWSE” but with different outline. What was meant by the outline is probably a subset of customizing entries. See below for the details.

 

t-code          program                 description                      outline

RSIMG           RSIMG_CALL           BW IMG                             SIMG_SBIW

SBIW            SBIWSHOW             BIW in IMG for OLTP           SIMG_SBIW or SIMG_SBIW

 

However, none of the above t-codes really provides big value. The RSIMG does not work at all. Attempt to run it ends up with the error message “Document not found”. In the case of SBIW t-code it runs but it provides just part of customizing related to source system.

The customization of the SAP BW as I described it in above just happens in SPRO t-code. See below pictures on how part of the SPRO t-code looks in BW 7.5 (or lower like BW 7.4, BW 7.3, BW 7.2) and BW/4HANA systems.

 

More information:

Customizing of BW4 systems

Configuration of BW system

BW Transformations: HANA runtime

In a BW system that runs on HANA (BW on Hana = BWoH or BW for HANA = BW/4HANA) a transformations can either be running directly in HANA database or in BW application server. In a former case the when the transformations is performed in SAP HANA all data processing happens in the database therefore it is considered as a faster because no data transfer from/to DB to app server is needed. In the latter case, there is an overhead of moving data from DB to app server then data is processed there and finally it need to be moved back to DB - which makes whole processing slower. Now let us have a closer look at processing BW’s transformation in HANA DB that was introduced as of SAP BW 7.4 SP04.

Within the BW transformation a routine called "SAP HANASQLScript" can be created. That is basically HANA SQL script. In BW’s view, the DB script is implemented as a method in AMDP (ABAP managed database procedure) class. Sometimes the script is called as "SAP HANA Expert Script" or "BW-generated Stored Procedure". To create this in SAP GUI (t-code RSTRANGUI) you can use menu Edit -> Routines -> Create SAP HANA Expert Script. This menu path is valid for BW 7.4 based systems. In case of BW 7.5 based systems the menu path was moved to Edit -> Routines -> Expert Routine -> AMDP Script.

To create the same in SAP HANA Studio particularly in "BW Modeling Tools" follow on General tab -> Start/End/Expert Routine  Create.

Creating/editing of code of the script takes place in SAP HANA Studio particularly in "ABAP Development tools for SAP NetWeaver (ADT)".

How does the processing of the TRFN in HANA DB it work technically? All business logic that is in TRFN is included in so called "CalculationScenario (CalcScenario)". Meta data of the CalculationScenario are stored in SAP HANA transformation. This object is identified by technical name TR_<ID_for_TRFN> (e.g. TR_00O2SPBEZ1RA5JRZTS4A17Z5O). The TR_* object is also sometimes called as "Analysis Process" or HAP – SAP HANA Analysis Process. It can be seen in t-code RSDHATR. The CalcScenario is embedded into a ColumnView. For data selection from the transformation source when DTP runs it creates SQL SELECT statement based on the ColumnView. Furthermore, during biz logic processing the CalcScenario applies all transformation rules on selected data. While the data is shifted from source to target it is done in single processing step by implementing as an INSERT AS SELECT statement that reads from the ColumnView and inserts into the target database object. While you would observe the HAP in the t-code RSDHATR notice that it is purely a runtime object. That means it can’t be created/modified in the t-code it-self. The CalcScenario can be seen in the t-code as well while switching Expert Mode on/Off in menu Extras. There are an XML representation and Script Definition tabs available.

It is also possible to jump from TRFN definition means t-code RSTRANGUI to HAP. While in the RSTRANGUI select menu Extras -> Display Generated HANA Transformation. This jumps to t-code RSDHATR.

More information:

HANA based BW Transformation

Differences Between ABAP and SAP HANARuntime

First Guidance... Using SAP HANA SQLScript in SAP BW Transformations

2057542 - Recommendation: Usage of HANA-based Transformations

BW’s InfoArea vs Application components

In BW we often hear terms like infoarea and application component. Let’s have a closer look on the two.

InfoArea (IA) as per its definition (on SAPterm - SAP Terminology) is an element for grouping meta-objects in the SAP BW systems. Each InfoProvider is assigned to the IA. Resulting hierarchy is displayed in BW’s Administrator Workbench. BW’s InfoObjects are also assigned to IAs. Table that holds data about the IA in BW is RSDAREA (Directory of InfoAreas).

Application component (APCO) has a relation to source system’s (OLTP) datasources. Historically when SAP started to deliver the datasources (within Business Content) for their EPR system they followed an application’s hierarchy of the ERP. In addition, that part had to reflect into BW as well. There are t-codes like RSA9 that can be used in ERP source system to transfer source system’s application component hierarchy to BW. Thus while speaking of the APCO think of hierarchy of applications in the source system.

However, relation between the application component hierarchy in the OLTP system and BW system are independed from each other. They are also stored in different tables. BW’s APCO is stored in the table RSAPPL (Application components directory). Whereas DataSource application component hier is stored in the table RODSAPPL DataSource Application Components.

More information:

onlinedocu

How to find out InfoArea for particular BW object type – in BW/4 systems?

How to find out InfoArea for particular BW object type – in BW/4 systems?

This blog post is continuation of my earlier blog - How to find out InfoArea for particular BW object type. That blog was focused on classic BW running on anyDB. In advent of BW/4 the tables for the BW objects have changed a little so I’m refurnishing the old blog post in here.

BW obj type	Table	Input field	Field which holds InfoArea’s name
InfoObject	RSDIOBJ	IOBJNM	MTINFOAREA
aDSO	RSOADSO	ADSONM	INFOAREA
Composite Provider	RSOHCPR	HCPRNM	INFOAREA
Open ODS View	RSFBP	FBPNAME	INFOAREA
OpenHub	RSBOHDEST	OHDEST	INFOAREA
DataSource	RSDS	DATASOURCE	APPLNM *
InfoSource	RSKSNEW	ISOURCE	INFOAREA
Data Flow	RSDFDMOD	DATAFLOW	INFOAREA
BW Query components	RSZCOMPDIR	COMPUID COMPID	INFOAREA
HANA Analysis Processes	RSDHAMAP	HAAPNM	INFOAREA *
Planning Sequence	RSPLS_SEQUENCE	SEQNM	INFOAREA *
Process Chain	RSPCCHAINATTR	CHAIN_ID	APPLNM *

 

* Field not populated (not used) in the table

* Instead of InfoArea an Application Component is used

 

More information:

How to find out InfoArea for particular BW object type.

SAP S/4HANA appliance

Normally when organization decides to implement SAP S/4HANA ERP system there is a implementation period during which the system is deployed to the organization reflecting its needs. This is a way in which the organization actually get engaged with SAP software.

Additionally SAP is offering for their customer and/or partner so called appliance, which has the S/4HANA software installed. This way there is no implementation period the software can be leveraged right away. They call it fully-activated appliance as it has already some demo scenarios preconfigured including a data. It can be useful for rapid prototyping, proof-of-concept work, demoing, testing etc. There are two way how the appliance can be consumed.

In cloud – appliance can be deployed from SAP CAL – Cloud Application Library.

On premise – SAP can send the software via set of blue-ray disks for installation on customer’s premises. And this option is actually an interesting one. It reminds me of some similar initiative that SAP was providing long time back. It was so called SAP IDES laptops. Even this time this is no physical hardware still there are similarities between the two. The software is preconfigured but this time you have to install it on your hardware. See below SAP Note for all the details about it.

 

More information:

2041140 - Order an SAP S/4HANA fully-activated appliance for on-premise deployment

SAP IDES laptops

Manipulating entries in OBJH table

While working on transporting a table maintenance entry recently I came across interesting issue. Normally systems that have a purpose of test/integration/pre-production/production or similar are closed for customizing changes. It is a setting on client level in t-code SCC4 like:

Client Role = "Productive"

Cross-Client Objects Changes = "No changes to Repository and cross-client Customizing objects"

That means that customizing is not allowed to be performed in these systems. Such a systems are called as "non-changeable" systems or "production clients". Change of the customizing is normally only done via transports.

However, a particular customizing (or parameter) table can be set in a way that changes are allowed even in productive clients. To setup the table in that way there is a checkbox called "Current Settings" available in t-code SOBJ (Maintenance Object Attributes). The value is saved in table OBJH (Object: Header) and column OBJTRANSP (Flag for Transport Interface of Maintenance Object). That mean that even changes to client specific objects are not allowed, current settings in the client can be changed. The column OBJTRANSP can have one of these entries:

             No transport

1          Manual transport

2          Automatic transport

3          Transport is not required

 

There has to be a blank value of the column in order to make the table customizable. Only way, how change the column OBJTRANSP is to regenerate the table maintenance view from t-code SE42 or from SE11.

 

Initially, I was not sure what makes the table or not maintained. Only once, I debugged table maintenance view (function group TABLEPROC_<table_name>) I realized that value OBJH- OBJTRANSP is being checked.

More information:

356483 - In test system, behavior of customizing objects which are editable in production i.e. Current Settings

77430 - Customizing: Current settings

Transporting table maintenance view

I have done an activity of generating a maintenance view for table many times. However, even after that I still have some issues while moving the view across the landscape. Issue lays with the transport request that need to be prepared for the move. Normally when the objects are automatically collected into the transport request while they are being created, it should be all fine – all objects should be collected automatically. In case some objects were not stored in to proper developer class but they went to temporary class then they need to be collected manually. As with any manual activity, also this one is prone to errors.

Therefore, I came up with a list of objects that I look for in my transport to make sure all objects are collected before I release it.

 

R3TR     FUGR     <Z_function_group_name>

R3TR     TABL     <Z_table_name>

R3TR     TABU     TDDAT -> table keys: <Z_table_name>

R3TR     TABU     TVDIR -> table keys: <Z_table_name>

R3TR     TOBJ     <Z_table_name>X*

 

Line no 1 FUGR <Z_function_group_name> represents the function group name specified in the table maintenance generator (t-code SE54).

Line no 2 TABL <Z_table_name> represents the table which the maintenance view is generated for.

Line no 3 TABU TDDAT represents Maintenance Areas for Tables means the table Authorization Group that is also specified in t-code SE54. Is can be specified in t-code SE11 -> Utilities -> Assign Authorization Group. Stored in column CCLASS of the TDDAT.

Line no 4 TABU TVDIR represents View Directory itself, all info info given in the t-code SE54 are stored here.

Line no 5 TOBJ represents Definition of a Maintenance and Transport Object of the table involved. X* - can be specified in t-code SOBJ. It depends on particular table type, it can be either:

C        View Cluster

L        Logical transport object

S        Table (with text table)

T        Individual transaction object

V        View

D        Dummy object