Professional Documents
Culture Documents
Common Production Failures BW
Common Production Failures BW
Summary
This Knowledge brief helps BW Consultants as Quick reference guide, in solving Complex production
Issues,
Author: Devakar Reddy TatiReddy
1 Transactional RFC Error(trfc) Non Updated IDOCs in the Source System.
1.1 Why does the error occur?
tRFC Transact Remote Function Call Error, occurs whenever LUWs (Logical Unit of
Works) are not transferred from the source system to the destination system.
1.2 What happens when this error occur?
Message appears in the bottom of the Status tab in RSMO. The error message would
appear like tRFC Error in Source System or tRFC Error in Data Warehouse or simply
tRFC Error depending on the system from where data is being extracted.
Sometimes IDOC are also stuck on R/3 side as there were no processors available to
process them.
1.3 What can be the possible actions to be carried out?
Once this error is encountered, we could try to Click a complete Refresh F6 in RSMO,
and check if the LUWs get cleared manually by the system.
If after couple of Refresh, the error is as it is, then follow the below steps quickly as it
may happen that the load may fail with a short dump.
Go to the menu Environment -> Transact. RFC -> In the Source System, from RSMO. It
asks to login into the source system.
Once logged in, it will give a selection screen with Date, User Name, TRFC options.
On execution with F8 it will give the list of all Stuck LUWs. The Status Text will appear Red for
the Stuck LUWs which are not getting processed. And the Target System for those LUWs should
be WP1CL015, thats the Bose BW Production system. Do not execute any other IDOC which is
not related have the Target System as WP1CL015.
Right Click and Execute or F6 after selection, those LUWs which are identified properly. So that
they get cleared, and the load on BW side gets completed successfully.
When IDocs are stuck go to R/3, use Tcode BD87 and expand IDOC in inbound Processing tab for
IDOC Status type as 64 (IDoc ready to be transferred to application). Keep the cursor on the error
message (pertaining to IDOC type RSRQST only) and click Process tab (F8) . This will push any
stuck Idoc on R/3.
Monitor the load for successful completion, and complete the further loads if any in the Process
Chain.
Once confirmed with the error, we go ahead and check the Detail tab of the Job Overview to check
which Record, field and what in the data has the error.
Once we make sure from the Extraction, in the Details tab in the Job Overview that the data was
completely extracted, we can actually see here, which record, which field, has the erroneous data.
Here we can also check the validity of the data with the previous successful load PSA data.
When we check the data in the PSA, it will show the record with error with traffic signal as Red. In
order to change data in PSA, we need to have the request deleted from Manage Tab of the
InfoProvider first, only then it will allow to change the data in PSA.
Once the change in the specific field entry in the record in PSA is done, we then save it. Once data
in PSA is changed. We then again reconstruct the same request from the manage tab. Before we
could reconstruct the request, it needs to have QM status as Green.
This will update the records again which are present in the request
Monitor the load for successful completion, and complete the further loads if any in the Process
Chain.
Green .
For successful activation of the failed request, click on the Activate button at the bottom, which
will
open another window which will only have the request which is/are not activated. Select the request
and then check the corresponding options on the bottom. And then Click on Start
This will set a background job for activation of the selected request.
Monitor the load for successful completion, and complete the further loads if any in the Process
Chain.
In case the above does not work out, we check the size of the Data Package specified in the
InfoPackage. In InfoPackage -> Scheduler -> DataS. Default Data Transfer. Here we can set the size
of the Data Package. Here we need to reduce the maximum size of the data package. So that
activation takes place successfully.
Once the size of the Data Package is reduced we again re trigger the load and reload the complete
data again.
Before starting the manual activation, it is very important to check if there was an existing failed
Red Request. If so make sure you delete the same before starting the manual activation.
This error is encountered at the first place and then rectified as at that point in time system is not
able to process the activation process via 4 different Parallel processes. This parameter is set in
RSCUSTA2 transaction. Later on the resources are free so the activation completes successfully.
7 Caller 70 is missing.
7.1 Why does the error occur?
This error normally occurs whenever BW encounters error and is not able to classify them. There
could be multiple reasons for the same
o Whenever we are loading the Master Data for the first time, it creates SIDs. If system is
unable to create SIDs for the records in the Data packet, we can get this error message.
o If the Indexes of the cube are not deleted, then it may happen that the system may give the
caller 70 error.
o Whenever we are trying to load the Transactional data which has master data as one of the
Characteristics and the value does not exist in Master Data table we get this error. System
can have difficultly in creating SIDs for the Master Data and also load the transactional data.
o If ODS activation is taking place and at the same time there is another ODS activation
running parallel then in that case it may happen that the system may classify the error as
caller 70. As there were no processes free for that ODS Activation.
o It also occurs whenever there is a Read/Write occurring in the Active Data Table of ODS.
For example if activation is happening for an ODS and at the same time the data loading is
also taking place to the same ODS, then system may classify the error as caller 70.
o It is a system error which can be seen under the Status tab in the Job over View.
7.2 What happens when this error occur?
The exact error message is System response "Caller 70" is missing.
It may happen that it may also log a short dump in the system. It can be checked at "Environment ->
Short dump -> In the Data Warehouse".
7.3 What can be the possible actions to be carried out?
If the Master Data is getting loaded for the first time then in that case we can reduce the Data
Package size and load the Info Package. Processing sometimes is based on the size of Data
Package. Hence we can reduce the data package size and then reload the data again. We can also
try to split the data load into different data loads
If the error occurs in the cube load then we can try to delete the indexes of the cube and then reload
the data again.
If we are trying to load the Transactional and Master Data together and this error occurs then we can
reduce the size of the Data Package and try reloading, as system may be finding it difficult to create
SIDs and load data at the same time. Or we can load the Master Data first and then load
Transactional Data
If the error is happening while ODS activation cause of no processes free, or available for processing
the ODS activation, then we can define processes in the T Code RSCUSTA2.
If error is occurring due to Read/Write in ODS then we need to make changes in the schedule time of
the data loading.
Once we are sure that the data has not been extracted completely, we can then go ahead and delete
the red request from the manage tab in the InfoProvider. Re-trigger the InfoPackage again.
Monitor the load for successful completion, and complete the further loads if any in the Process
Chain.
Check the error message completely and also check the long text of the error message, as it will tell
you the exact Master Data which is locked by user ALEREMOTE.
The lock which is set is because of load and HACR timing which clashed. We first need to check
RSA1 -> Tools -> HACR, where in we would get the list of InfoObjects on which HACR is currently
running. Once that is finished only then, go to the TCode SM12. This will give you few options and
couple of default entries. When we list the locks, it will display all the locks set. Delete the lock for
the
specific entry only else it may happen that some load which was running may fail, due to the lock
released.
Now we choose the appropriate lock which has caused the failure, and click on Delete. So that the
existing lock is released. Care should be taken that we do not delete an active running job.
Preferable avoid this solution
When HACR finishes for the other Master Data, trigger Attribute change run for this Master Data.
Here if the job status for the Delay (sec.) is increasing instead of Duration(sec.) then it means
there is some problem with the extraction job. It is not running, and is in delay.
It may happen sometimes that there is no active job and there is a job which is in finished status with
the current date/time.
The extract job and the status job both needs to be checked, because it may happen that the extract
job is finished but the extract status job has failed, as a result of which it did not send success status
to BW. But the extraction was complete. In such cases, we manually change the status of the Extract
Program Process in the PC in BW to green with the help of the FM ZRSPC_ABAP_FINISH.
Execute the FM with the correct name of the Program process variant and the status F. This will
make the Process green triggering the further loads. Here we need to check if there is no previous
Extract Program Process is running in the BW system. Hence we need to check the PC logs in detail
for any previous existing process pending.
Monitor the PC to complete the loads successfully.
If in case we need to make the ABAP Process within the PC to turn RED and retrigger the PC, then
we execute the FM ZRSPC_ABAP_FINISH with the specific variant and Job Status as R which
will turn the ABAP process RED.
This usually needs to be done when the Extraction Job was cancelled in R/3 due to some reason &
we have another job in Released state and the BW ABAP Process is in Yellow state. We can then
make the ABAP Process RED via the FM, and then re-trigger the PC.
We need to identify the person who is responsible for FTPing the file on the Application server. A
mail already goes to the responsible person, via the error message in the Process. But we also need
to send a mail, regarding the same.
The Process Chains which are having the system command Process in them, and the corresponding
actions to be taken.
following
selections:
1. copy the variant from the popup to the variante of table rspcprocesslog
2. copy the instance from the popup to the instance of table rspcprocesslog
3. copy the start date from the popup to the batchdate of table rspcprocesslog
Press F8 to display the entries of table rspcprocesslog.
Now open another session and goto transaction se37. Enter RSPC_PROCESS_FINISH as the name of the
function module and run the fm in test mode.
Now copy the entries of table rspcprocesslog to the input parameters of the function module like
described
as follows:
1. rspcprocesslog-log_id -> i_logid
2. rspcprocesslog-type -> i_type
3. rspcprocesslog-variante -> i_variant
4. rspcprocesslog-instance -> i_instance
5. enter 'G' for parameter i_state (sets the status to green).
Now press F8 to run the fm.
Now the actual process will be set to green and the following process in the chain will be started and
the
chain can run to the end.
ABAP PROGRAM:
*&---------------------------------------------------------------------*
*& Report ZRSPC_PROCESS_FINISH *
*& *
*&---------------------------------------------------------------------*
************************************************************************
* Author: Jesper Christensen
* Date: Mar 22nd 2006
* Type: Executable Program
* Purpose/Description : Restart process chain after a failed request
*
************************************************************************
* MODIFICATION LOG
************************************************************************
* Date | Change Number | Initials | Description
************************************************************************
* 03/22/06 JMCHRIS Program created
*
*
************************************************************************
REPORT zrspc_process_finish .
PARAMETERS: VARIANT TYPE rspc_variant OBLIGATORY,
INSTANCE TYPE rspc_instance OBLIGATORY,
DATE TYPE SY-DATUM OBLIGATORY,
state TYPE rspc_state OBLIGATORY default 'G'.
DATA : logid TYPE rspc_logid,
chain TYPE rspc_chain,
type TYPE rspc_type,
p_vari TYPE rspc_variant,
instan TYPE rspc_instance,
jobcount TYPE btcjobcnt,
batchdat TYPE btcreldt,
batchtim TYPE btcreltm.
DATA: LS_PCLOG LIKE RSPCPROCESSLOG.
* select the process log
SELECT SINGLE * FROM RSPCPROCESSLOG INTO LS_PCLOG
where variante = variant
and instance = instance
and batchdate = date.
if sy-subrc = 0.
* Set the status
CALL FUNCTION 'RSPC_PROCESS_FINISH'
EXPORTING
i_logid = LS_PCLOG-log_id
* i_chain = LS_PCLOG-chain
i_type = LS_PCLOG-type
i_variant = LS_PCLOG-variante
i_instance = LS_PCLOG-instance
i_state = state
* i_job_count = jobcount
i_batchdate = LS_PCLOG-batchdate
* i_batchtime = batchtim
EXCEPTIONS
error_message = 1.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE 'I' NUMBER sy-msgno