Wednesday, 29 January 2014

SAP BW Production Support Issues with Resolutions


1. DTP Failure

Select the step-> right click and select “Display Message”-> there we will get the message which gives the reason for ABEND.
A DTP can failure due to following reasons, in such case we can go for restarting the job.
  • System Exception Error
  • Request Locked
  • ABAP Run time error.
  • Duplicate records
  • Erroneous Records from PSA.
Duplicate records:
            In case of duplication in the records, we can find it in the error message along with the Info Provider’s name. Before restarting the job after deleting the bad DTP request, we have to handle the duplicate records. Go to the info provider -> DTP step -> Update tab -> check handle duplicate records -> activate -> Execute DTP. After successful competition of the job uncheck the Handle Duplicate records option and activate. 

DTP Log Run:
  • If a DTP is taking log time than the regular run time without having the back ground job, then we have to turn the status of the DTP into Red and then delete the DTP bad request (If any), repeat the step or restart the job.
  • Before restarting the Job/ repeating the DTP step, make sure about the reason for failure.
  • If the failure is due to “Space Issue” in the F fact table, engage the DBA team and also BASIS team and explain them the issue. Table size needs to be increased before performing any action in BW. It’ll be done by DBA Team. After increasing the space in the F fact table we can restart the job. 
Erroneous Records from PSA: 
When ever a DTP fails because of erroneous records, while fetching the data from PSA to Data Target, in such cases data needs to be changed in the ECC. If it is not possible, then after getting the approval from the business, we can edit the Erroneous records in PSA and then we have to run the DTP.
Go to PSA -> select request -> select error records -> edit the records and save.
Then run the DTP. 

2.      INFO PACKAGE FAILURE: 

The following are the reasons for Info Pack failure.
  • Source System Connection failure
  • tRFC/IDOC failure
  • Communication Issues
  • Processing the IDOC Manually in BI
  • Check the source system connection with the help of SAP BASIS, if it is not fine ask them to rebuild the connection. After that restart the job (Info Pack).
Go to RSA1 -> select source system -> System -> Connection check.
  • In case of any failed tRFC’s/IDOC’s, the error message will be like “Error in writing the partition number DP2” or “Caller 01, 02 errors”. In such case reprocess the tRFC/IDOC with the help of SAP BASIS, and then job will finish successfully.
  • If the data is loading from the source system to DSO directly, then delete the bad request in the PSA table, then restart the job
  • Info Pack Long Run: If an info pack is running long, then check whether the job is finished at source system or not. If it is finished, then check whether any tRFC/IDOC struck/Failed with the help of SAP BASIS. Even after reprocessing the tRFC, if the job is in yellow status then turn the status into “Red”. Now restart / repeat the step. After completion of the job force complete.
  • Before turning the status to Red/Green, make sure whether the load is of Full/Delta and also the time stamp is properly verified.
  • Time Stamp Verification:
Select Info Package-> Process Monitor -> Header -> Select Request -> Go to source System (Header->Source System) -> Sm37-> give the request and check the status of the request in the source system -> If it is in active, then we have to check whether there any struck/failed tRFC’s/IDOC’s 

If the request is in Cancelled status in Source system -> Check the Info Pack status in BW system -> If IP status is also in failed state/cancelled state -> Check the data load type (FULL or DELTA) -> if the status is full then we can turn the Info Package status red and then we can repeat/restart the Info package/job. -> If the load is of Delta type then we have to go RSA7 in source system-> (Compare the last updated time in Source System SM37 back ground job)) Check the time stamp -> If the time stamp in RSA7 is matching then turn the Info Package status to Red -> Restart the job. It’ll fetch the data in the next iteration

If the time stamp is not updated in RSA7 -> Turn the status into Green -> Restart the job. It’ll fetch the data in the next iteration.

Source System
BW System
Source System RSA7
Source System SM37
Action
I/P Status RED(Cancelled)
I/P Status (Active)
Time stamp matching with SM37 last updated time
Time stamp matching with RSA7 time stamp
Turn the I/P Status into Red and Restart the Job
I/P Status RED(Cancelled)
I/P Status (Cancelled)
Time stamp matching with SM37 last updated time
Time stamp matching with RSA7 time stamp
Turn the I/P Status into Red and Restart the Job
I/P Status RED(Cancelled)
I/P Status (Active)
Time stamp is not  matching with SM37 last updated time
Time stamp is not matching with RSA7 time stamp
Turn the I/P status into Green and Restart the job
I/P Status RED(Cancelled)
I/P Status (Cancelled)
Time stamp is not  matching with SM37 last updated time
Time stamp is not matching with RSA7 time stamp
Turn the I/P status into Green and Restart the job

  • Processing the IDOC Manually in BI:
When there is an IDOC which is stuck in the BW and successfully completed the background job in the source system, in such cases we can process the IDOC manually in the BW.
Go to Info Package -> Process Monitor -> Details -> select the IDOC which is in yellow status(stuck) -> Right click -> Process the IDOC manually -> it’ll take some time to get processed.

Note: Make sure that we can process the IDOC in BW only when the back ground job is completed in the source system and stuck in the BW only.

3.      DSO Activation Failure:

When there is a failure in DSO activation step, check whether the data is loading to DSO from PSA or from the source system directly. If the data is loading to DSO from PSA, then activate the DSO manually as follows
  • Right click DSO Activation Step -> Target Administration -> Select the latest request in DSO -> select Activate -> after request turned to green status, Restart the job.
  • If the data is loading directly from the source system to DSO, then delete the bad request in the PSA table, then restart the job
4.      Failure in Drop Index/ Compression step:

When there is a failure in Drop Index/ compression step, check the Error Message. If it is failed due to “Lock Issue”, it means job failed because of the parallel process or action which we have performed on that particular cube or object. Before restarting the job, make sure whether the object is unlocked or not
There is a chance of failure in Index step in case of TREX server issues. In such cases engage BASIS team and get the info reg TREX server and repeat/ Restart the job once the server is fixed.
Compression Job may fail when there is any other job which is trying to load the data or accessing from the Cube. In such case job fails with the error message as “Locked by ......” Before restarting the job, make sure whether the object is unlocked or not.

5. Roll Up failure:

“Roll Up” fails due to Contention Issue. When there is Master Data load is in progress, there is a chance of Roll up failure due to resource contention. In such case before restarting the job/ step, make sure whether the master data load is completed or not. Once the master data load finishes restart the job.  

6. Change Run – Job finishes with error RSM 756

When there is a failure in the attribute change run due to Contention, we have to wait for the other job (Attribute change run) completion. Only one ACR can run in BW at a time. Once the other ACR job is completed, then we can restart/repeat the job.
            We can also run the ACR manually in case of nay failures.
Go to RSA1-> Tool -> Apply Hierarchy/Change Run -> select the appropriate Request in the list for which we have to run ACR -> Execute.

7. Transformation In-active:

In case of any changes in the production/moved to the production without saving properly or any modification done in the transformation without changing, in such cases there is a possibility of Load failure with the error message as “ Failure due to Transformation In active”.

In such cases, we will have to activate the Transformation which is inactive. 
Go to RSA1 -> select the transformation -> Activate
In case of no authorization for activating the transformation in production system, we can do it by using the program - RSDG_TRFN_ACTIVATE
Try the following steps to use the program "RSDG_TRFN_ACTIVATE” here you will need to enter certain details:
Transformation ID: Transformation’s Tech Name (ID)
Object Status: ACT
Type of Source: “Source Name”
Source name: “Source Tech Name”
Type of Target: Target Name
Target name: “Target Tech Name”
  1. Execute. The Transformation status will be turned into Active.
Then we can restart the job. Job will be completed successfully. 

8. Process Chain Started from the yesterday’s failed step:

In few instances, process chain starts from the step which was failed in the previous iteration instead of starting from the “Start” step.
In such cases we will have to delete the previous day’s process chain log, to start the chain form the beginning (from Start variant).
Go To ST13-> Select the Process Chain -> Log -> Delete.
Or we can use Function Module for Process Chain Log Deletion: RSPROCESS_LOG_DELETE.
Give the log id of the process chain, which we can get from the ST13 screen.
Then we can restart the chain.

Turning the Process Chain Status using Function Module:

At times, when there is no progress in any of the process chains which is running for a long time without any progress, we will have to turn the status of the entire chain/Particular step by using the Function Module.

Function Module: RSPC_PROCESS_FINISH

The program "RSPC_PROCESS_FINISH" for making the status of a particular process as finished.
To turn any DTP load which was running long, so please try the following steps to use the program "RSPC_PROCESS_FINISH" here you need to enter the following details:
LOG ID: this id will be the id of the parent chain.
CHAIN: here you will need to enter the chain name which has failed process.
TYPE: Type of failed step can be found out by checking the table "RSPCPROCESSLOG" via "SE16" or "ZSE16" by entering the Variant & Instance of the failed step. The table "RSPCPROCESSLOG" can be used to find out various details regarding a particular process.
INSTANCE & VARIANT: Instance & Variant name can be found out by right clicking on the failed step and then by checking the "Displaying Messages Options" of the failed step & then checking the chain tab.
STATE: State is used to identify the overall state of the process. Below given are the various states for a step.
R Ended with errors
G Successfully completed
F Completed
A Active
X Canceled
P Planned
S Skipped at restart
Q Released
Y Ready
Undefined
J Framework Error upon Completion (e.g. follow-on job missing)

9. Hierarchy save Failure:

When there a failure in Hierarchy Save, then we have to follow the below process. 

If there is issues with Hierarchy save, we will have to schedule the Info packages associated with the Hierarchies manually. Then we have to run Attribute Change Run to update the changes to the associated Targets. Please find the below mentioned the step by step process.

ST13-> Select Failed Process Chain -> Select Hierarchy Save Step -> Right click Display Variant -> Select the info package in the hierarchy -> Go to RSA1 -> Run the Info Package Manually -> Tools -> Run Hierarchy/Attribute Change Run -> Select Hierarchy List (Here you can find the List of Hierarchies) -> Execute.

Monday, 13 May 2013

Full/Delta/Initialize delta update methods

Introduction

Update method is used to get the updated data coming from the source system to BI system at Info package level. We can set update methods in the update tab of the info package.

The update methods in the info package are:

1. Full Update
2. Delta Update
3. Initialize Delta Process
    (I) Initialize with data transfer
    (II) Initialize without data transfer
    (III) Early Delta Initialization

1.Full Update

Full update extracts the full data from source system to PSA in BI7 every time. 

2. Delta Update

Delta update extracts delta records only from the BW delta queue in the source system to BI system.

We must initialize the delta in order to get delta records, otherwise it is not possible to load delta records.

The following are the 4 delta types for the data source in the system.

F: Flat file provides the delta
E: Extractor determines the delta, Ex: LIS, COPA
D: Application determines the delta, Ex: LO, FI-AR/AP
A: Use ALE change log delta

Note: We can know the delta properties from ROOSOURCE table in the source system with SE16 transaction code.

3.Initialize Delta Process

To get the delta records, one must initialize the delta process. While initializing the delta process, the system will generate a flag: Initialize option for the source system in (scheduler menu of info package) BI and BW delta queue per the data source in the source system (RSA7). This enables the time stamp mechanism.

Initialize with data transfer

If you select this option, It extracts the init data from source system to BI system and allows delta functionality.

Steps for initialize with data transfer

Lock the users in the source system 
Delete the contents of the setup tables for the specific application component in source system(T code: LBWG). 
Fill the setup tables (SBIW or OLI*BW, use 1,2,3...in place of * according to the application ). 
Run the info package with initialize with data transfer. 
unlock the users in the system 

Note: This is very time consuming process, because we need to lock the users until data reaches to the BI system.This effects the client business.

Initialize without data transfer

In some cases, init is successful but someone has deleted the init flag. In order to set the flag again to perform the delta load without disturbing the data, we execute IP with this option.

Steps for initialize without data transfer

Lock the users in the source system 
Delete the setup tables content for the specific application component. 
Fill the setup tables 
Run the IP with the option: Initialize without data transfer. 
Unlock the users in the source system 
Load data to BI system using repair full request info package 

Note: In this method, after data is loaded to setup tables we can unlock the users in source system. this is better option than initialize with data transfer option.

Early Delta Initialization

In this option, we can do the delta initialization before filling the setup tables.So that users can post the documents when we are filling the setup tables.We will get the posted records in the next delta run

Steps for early delta initialization

Run the Info package with early delta initialization option.This will enable the BW delta queue and setup the time stamp for delta in the source system. 
Delete the setup tables for the application component 
Fill the setup tables 
Load the setup table data using repair full request (scheduler menu option of info package) info package 

How to check whether the data source supports early delta initialization or not?

Go to SE16 in ECC, give table name: ROOSOURCE and enter 
In the next screen give data source like 2lis_02_sdr(purchase document header data source) name and enter 
if field ZDD_ABLE has a value 'X', then the data source supports early delta initialization 
If the filed has space, then the data source does not support early delta initialization.

Friday, 10 May 2013

Difference between V1, V2, V3 updates

V1 Synchronous update - Used for LIVE tables, after the records get updated system will send an acknowledgement. This degrades processing performance.

V2 Asynchronous update – LUW's will be Updated in front end without any acknowledgement. 

V3 Asynchronous with background updating – Updating happens in Background.

We use this concept in LO Extraction update modes.

Direct delta update mode uses V2 update. Recommended only when less number of records are there.

Queued delta is recommended for most of the cases and it will use V3 update. LUW’s will be updated to Extractor queue (LBWQ) in the form of tokens (pointers). We need to run a background job (V3 collective run) to push the data to delta queue from LIVE tables. All the records will be moved at once so no problem with sequence.

Unserialized V3 update also uses V3 update, only recommended when sequence of data is not important. DSO is not recommended as target when we use this update. 

Friday, 3 May 2013

Common Issues with Open Hub

1. Error message: 'Destination not supported' (Error Code RSBO 102)


when creating an open hub destination

Firstly the corrupt Open Hub destinations need to be repaired. To do this you need to check the table RSBOHDEST, for all Open Hub Destination entries where the field DESTYPE is initial/empty or is equal to 'FILE', you must change the DESTYPE for such entries to TAB in the table RSBOHDEST. TAB must be selected because it is not possible to select another valid DESTYPE in the table. When you no longer have the error message 'Destination type is not supported' you can change the destination type to what it should be in the maintenance for the Open Hub Destination in RSA1.

For the users that worked with Open Hub and have the problem that they cannot access RSA1 (not supported (RSBO102) error message), there should be an entry(for each user) in the personalisation table RSAWBN_USR_TREE with the field AWBUSER = to the name of the user ID that has the problem and the field AWBTREE = DEST. You need to delete the entries returned for this selection on the fields AWBUSER and AWBTREE only for the User ID's that have the problem from the table RSAWBN_USR_TREE and the problem should be resolved.

2. Errors when sending data to a 3rd party Open Hub Destination 

Message no. RSBO523 SYSTEM_FAILURE with function RSB_API_OHS_3RDPARTY_NOTIFY and target system x 
Message no. RSBO899 Bean RSB_API_OHS_3RDPARTY_NOTIFY not found on host x, ProgId=x: Object not found in lookup of x 
Message no. RSBK241 Error while updating to target x (type Open Hub Destination)
When you execute the DTP for OHD, the system stores the data in a DB table 

The 3rd party tool is notified with the Function Module RSB_API_OHS_3RDPARTY_NOTIFY, this function has to be implemented by the 3rd party tool, not in the BW system

To resolve this issue;

Check if the function exists on the 3rd party tool using "Extras" --> "function list" after you select the destination in SM59

Implement the necessary function on the 3rd party tool

If you require assistance to implement the function on the 3rd party system, please contact the relevant 3rd party support desk.

Some useful T-Code for BI performance tuning

T-CodeDescription
SM66Global Work Process Overview
ST02Tune Summary
ST06System monitor
STADSAP workload
ST05SQL Trace
SE30ABAP Trace
ST12Single transaction analysis(including ST05/ST30)
RSMOBW Load monitor
DB02DB Load overview
ST04DB Performance snapshot
RSBATCHBI Background management
RSODSO_SETTINGSMaintenance of runtime parameter of DSO
RSRVAnalysis and repair BI Objects
ST03Workload in system
RSRTQuery Monitor
RSRTRACEConfigure Trace Tool