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.
******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”
A.
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 an issue 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 -> Rt click Display Variant -> Select the info package in the
hierarchy -> Go to RSA! -> Run the Info Package Manually -> Tools
-> Run Hierarchy/Attribute Change Run -> Select Hierarchy List (Here you
can find the List of Hierarchies) -> Execute.
