Recovering deleted web templates in development from quality – reverse transport

By Manohar 

Objective:

It is human to err, but some errors unfortunately involve high price tags. This post is to explore the options of recovering a deleted web template in SAP BW development system. I have not tried this for other objects so I’m unaware of the possibilities that lie ahead. It is always a best practice to avoid any types of deletion of objects or data without proper confirmations.

Requirement: Recovering a web template in development, which got deleted by mistake.

Pre-requisite: This web template’s latest version has been transported to quality and other target systems previously.

Procedure: Let us first create a scenario by deleting an existing web template:

Stock Overview report as shown below has been deleted from the development system BAD.

After choosing YES the template ceases to exist in the development system which is reconfirmed by the below checks:

Running the URL:

Landscape and direction of transport movement:

Step 1: Login to Quality - BAQ

Step 2: Identify the transport request containing the latest version of the required web template.

In transaction SE03 choose “Search for objects in Requests/Tasks” under “Objects in Requests” folder.

Enter the object type as TMPL in case of web templates and the name of the web template that was deleted and execute.

The result would display all the requests that contained the web template; it is wiser to choose the latest one as that would be the working latest version of the web template. Make a note of the transport request.

Step 3: Create a Transport Request in Quality of request type “Transport of copies” and target as DEVELOPMENT.

In transaction SE10 create a transport request of type “Transport of copies” checked.

Under create request choose the radio button “Transport of copies”.

Make sure to choose the TARGET as DEVELOPMENT system, use possible entries help here. If you choose only workbench request then the possible entries help would not display the Development system in the list.

Step 4: Insert the web template into the request from the transport request identified in step 2.

Choose to “Include Objects” into the selected request.

Select the radio button “Object List from Request” and specify the request number which holds the latest version of the required web template.

The message bar should indicate that the objects are inserted from one request to another; this could also be confirmed by checking the objects in the new request.

Step 5: Release the request from Quality so that it could be imported in Development.

Step 6: Login to development system and import the released request containing the web template from Quality:

Go to transaction STMS_IMPORT in development.

You should be able to see the request released from Quality here, provided you did not miss to mention the target as Development during creation of the request in Step 3.

Choose the required options and the import should start.

Step 7: Moment of Truth.

Post successful import of the transport run the development relevant URL and you should be able to find the web template opening up.

Also you should be able to find the deleted web template upon searching:

Even though we know the cure, prevention is always better. Please be extremely cautious before deleting objects from any system.

All About.... Infocube Dimension design: A different perspective

By: Manohar Delampadi          scn.sap.com

Objective: The objective of this post is to simplify the understanding on dimension designs of an infocube and to decide upon the dimensions based on the repetition of the data held in the dimension tables.

Pre-requisites: An infocube is already created and active, and filled will data, which will be used for analysis of dimension tables.

Dimension to Fact Ratio Computation: This ratio is a percentage figure of the number of records that exists in the dimension table to the number of records in fact table or what percentage of fact table size is a dimension table. Mathematically putting it down, the equation would be as below:

          Ratio = No of rows in Dimension table X 100 / No of rows in Fact Table

Dimension Table Design Concept: We have been reading and hearing over and over again that the characteristics should be added into a dimension if there exists a 1:1 or 1:M relation and they should be in separate dimension if there exists a M:M relation. What is this 1:1 or 1: M? This is the relation which the characteristics share among each other.

For instance if one Plant can have only one Storage Location and one storage location can belong to only one plant at any given point of time, then the relation shared among them is 1:1.

If 1 Functional Location can have many equipment but one equipment can belong to only one functional location then the relation shared between the functional location and Equipment is 1:M.

If 1 sales order can have many materials and one material can exist in different sales orders then there absolutely is no dependence among these two and the relation between these two is many to many or M: M.

Challenges in understanding the relationship: Often we SAP BI consultants depend on the Functional consultants to help us out with the relationship shared between these characteristics / fields. Due to time constraint we generally cannot dedicate time to educate the functional consultants on the purpose of this exercise, and it takes a lot of time to understand this relationship thoroughly.

Scenario: An infocube ZPFANALYSIS had few dimensions which were way larger than the preferred 20% ratio. This had to be redesigned such that the performance was under 20% ratio.

This ratio could be either manually derived by checking the number of entries in the desired dimension table (/BIC/D<infocube name><dimension number>) to the fact table (/BIC/F<Infocube Name> or /BIC/E<Infocube name>) or a program SAP_INFOCUBE_DESIGNS can be executed in SE38 which reports this ratio for all the dimensions, for all the infocubes in the system.

SAP_INFOCUBE_DESIGNS:

We can find from the report that the total number of rows in the fact table is 643850. Dimension 2 (/BIC/DZPFANLSYS2) has around 640430 rows, which is 99% (99.49%)of the fact table rows and Dimension 4(/BIC/DZPFANLSYS4) has around 196250 rows, which is 30%  (30.48%)of the fact table rows.

Infocube ZPFANLSYS:

Approach:

Step 1: Analysis of the dimension table /BIC/DZPFANALSYS2 to plan on reducing the number of records.

/BIC/DZPFANLSYS2

Fact table:

Dimension table holds 1 record more than the fact table.

View the data in the table /BIC/DZPFANLSYS2 (Table related to Dimension 2) in SE12 and sort all the fields. This sorting will help us spot the rows which have repeated values for many columns, which will eventually lead to understanding the relationship between the characteristics (columns in dimension table).

Identifying the relationships:

Once the sorting is done we need to look out for the number of values that repeat across the columns. All the records which repeat could have been displayed in a single row with one dimension id assigned if all the columns had same data. The repetition is a result of one or more columns which contribute a unique value to each row. Such columns if removed from the table then the number of rows in the table will come down.

In the below screenshot I’ve highlighted the rows in green that were repeating themselves with new dimension IDs, as only 2 columns SID_ZABNUM and SID_0NPLDA have new values for every row. These two columns having new values for every row have resulted in rest of the columns repeating themselves and in turn increasing the data size in the dimension table. Hence it can be easily said that these two columns do not belong in this dimension tables, so the related characteristics (ZABNUM and 0NPLDA) need to be removed out of this dimension.
Few rows could be found which repeat themselves for most of the columns, but have a new value once in a while for some columns, as highlighted in yellow in the below screenshot. This indicates that these columns share a 1:M relation with the rest of the columns with repeated rows and these could be left in the same dimension.

Conclusion: The columns marked in green belong to this dimension tables and the columns marked in red needs to be in other dimension tables.

Step 2: Create a copy infocube C_ZPFAN and create new dimensions to accommodate ZABNUM and 0NPLDA.

ZABNUM was added to dimension C_ZPFAN8 and 0NPLDA was added to C_ZPFAN7. These were marked as line item dimensions as they have only one characteristic under them.

Analysed the issue with dimension 4 in the similar way and changed other dimensions to help the situation.

Post changes, loaded the data into the copy infocube C_ZPFAN and found the number of records in the dimension table /BIC/DC_ZPFAN2 to be 40286.

Ratio: 40286 / 657400 * 100 = 6.12 %

SAP_INFOCUBE_DESIGNS:

Dimension2 of the copy infocube: /BIC/DC_ZPFAN2

Even now there a few repeated rows and columns, but the ratio is within 20%. We can create up to 13 dimensions, but it is always better to keep a dimension or two free for future enhancements.

Hope this was helpful.

All about Process Chains.... Tips

By: Chandiraban singu

Process chain:

A Process chain is a sequence of processes that wait in the background for an event. Some of these processes trigger a separate event that can start other processes in turn.

If you use Process chains, you can

Automate

the complex schedules in BW with the help of the event-controlled processing,

Visualize

the schedule by using network applications, and

Centrally control and monitor

the processes. This article will provide you a few (Seven) tips in the management of Process chain.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00a1f389-ec7c-2c10-04bc-9d81b3084171?overridelayout=true