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.
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”
- 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)
