Lesson Learnt from Business Release

Part of the datawarehouse governance in a corporate company is to have quarterly business release (BR) for the enhancements and new project to be transported into Production system. Thus there is a need to set up a regression environment to ensure thorough testing was done before the the cutover took place. The regression environment has to be the exact copy of Production system in terms of data and configuration.

During this time cutover for BR1 to Regression and Production environment, I encountered numerous issues which I can relate them to the nature of the change request, shared objects, transports,data loading and design.

Change Request
There were two particular change requests that causes impact to multiple objects (including the queries, web template, infoobjects, function modules, class, IP aggregates) in the system.The first one being the reverse sign for data which is supposed to be reported both in P&L and Overhead. The data is entered in Overhead manual entry layout. It'd be entered in positive sign. The data saved needs to be in reversed sign as P&L report for these particular account is supposed to be shown in negative. We can't make changes to the frontend P&L report as the reversal sign in frontend will cause all other non Overhead account to be reversed as well. So the only way is to change the layout for Overhead report to flip the sign and ensure the backend data is saved in negative value. This change involves changes in all the Overhead and P&L manual entries and actual reports; both queries and web template.

The second one refers to the inclusion of additional level in cost center hierarchy for manual entry input and reporting. If the relationship of data is defined through the navigation/display attributes, then it is important to ensure the master data is correctly updated. If the new level needs to be open for manual entries, a new infoobject for that level has to be created and included in all the aggregates level and cubes. Thus there's a need to recreate a new aggregate level and perform cube remodeling. New aggrgates level means new manual entry layout. So we can see changes involve all the way from infoobject attributes, aggregates level, queries (both manual entry and output) and web templates.

Shared Objects
Removal of an obsolete attribute in an infoobjects can cause some of the transformation to fail as those infoojects are still in used. Thus the governance of infoobjects is very important to ensure the changes to any infobject (especially those shared in APO and Finance like material and material group) are carefully assessed on the impact of change.

Transport
Transport order and its prerequisite are important so that no old changes overwrites the new ones. It is a good practice to keep one change in one transport request or to collect only necessary objects. There'd bound to be incident where the objects which are not related to the change or fix are collected together with the transport request and caused the object to be inactive when moved to production environment.

Data loading
Whenever there is a logic change in the transformation level that requires the historical data to be transformed again causes the need to reload data to reporting level cube. There are different ways to approach this scenario but previous steps done on the reporting level data such as selective deletion has to be considered. Below are some steps that can be taken:
1) Selective deletion (in this case we can see the importance of including the source module character as well in that level although the objective at reporting level is to minimize the data granularity for performance purpose)

2) Deletion by request (in this case we can see the importance of loading data by request to reporting layer). The only setback is the load can take a long time as the previous requests were loaded in on daily basis.

3) Offset data through self-loop. This step is quite safe as offset data is added (nothing is deleted).

Design
Usually there's a need to report from the reconciliation level(data that had gone through all the transformation) for data checking purposes. This means the data in transformation level and reporting level has to be the same. In order to ensure the data is the same in reconciliation reports and actual reports ,the best practice is not to allow any transformation to happen between the transformation level and reporting level.

SAP Authorization Tables

Authorization Objects Tables

Table Name	Description
TOBJ	Authorization Objects
TACT	Activities which can be Protected (Standard activities authorization fields in the system)
TACTZ	Valid activities for each authorization object
TDDAT	Maintenance Areas for Tables
TSTC	SAP Transaction Codes
TPGP	ABAP/4 Authorization Groups
USOBT	Relation transaction > authorization object
USOBX	Check table for table USOBT
USOBT_C	Relation Transaction > Auth. Object (Customer)
USOBX_C	Check Table for Table USOBT_C

User Tables

Table	Description
USR01	User master record (runtime data)
USR02	Logon data
USR03	User address data
USR04	User master authorizations
USR05	User Master Parameter ID
USR06	Additional Data per User
USR07	Object/values of last authorization check that failed
USR08	Table for user menu entries
USR09	Entries for user menus (work areas)
USR10	User master authorization profiles
USR11	User Master Texts for Profiles (USR10)
USR12	User master authorization values
USR13	Short Texts for Authorizations
USR14	Surchargeable Language Versions per User
USR30	Additional Information for User Menu
USH02	Change history for logon data
USH04	Change history for authorizations
USH10	Change history for authorization profiles
USH12	Change history for authorization values
UST04	User masters
UST10C	User master: Composite profiles
UST10S	User master: Single profiles
UST12	User master: Authorizations