some more errors

 

1         Introduction

 

Generally, when a process fails an error analysis has to be done first. Explanations have to be given what happened and why this happened. Steps for resolution have to be given. A fix should only be applied when the steps for resolution are agreed. In the end a root cause analysis has to be given.

 

 

2         Fixes Applicable to Errors Globally

 

2.1      General Failed Extraction

2.1.1   Loading into PSA , Update Subsequently in Data Targets

The current policy is to use the following InfoPackage option for data processing.

 

 

With this option all data packets are first loaded into the PSA. Packets are loaded in parallel processes up to limit specified in table ROIDOCPRMS.

 

 

When the load into the PSA is complete the packets are loaded into the data target in a sequential manner. In the past years this option used to be the only reliable and stable one.

2.1.2   Places to Inspect

A failed extraction is usually indicated with a red traffic light in the monitor. Note that the light may turn to red much later than the actual error happens (by timeout). In some cases the extraction does not even appear in the monitor. This happens for instance when the error occurs before the selection parameters are determined. Also failed enqueues many lead to this situation. Generally, the following places are proposed to check in case of errors in the following order.

 

The RSMO monitor status tab

 

 

The error messages of the RSMO monitor status tab

 

 

The long-text can sometimes be very helpful!

 

The RSMO monitor details tab. Here check all relevant branches.

 

 

Note, that full message display can be helpful:

 

 

Check for cancelled job (SM37) in BW and the source system. Check for short dumps (ST22) in BW and the source system.

Check the system log (SM21) in BW and the source system.

Use SM37 and find the according BI_BTCH*, BIREQU*, BI_BOOK jobs. Check the job logs for messages indicating errors.

Check the IDocs, see below.

Check tRFC with sm58, see below.

2.1.3   Failed Booking into the Data Target

When the PSA load is through as indicated below then the update into the InfoCube can be done manually.

 

 

The easiest approach is to delete the failed request from the InfoCube via Admin Workbench / InfoCube / Manage. The request can be reconstructed from the Reconstruction tab.

 

 

You can monitor the created reconstruction job in sm37.

 

Attention: In the job chain, take care about the InfoPackage post-processing. Almost all InfoPackage have a subsequent process defined.

 

 

 

 

 

Verify that the next step that is scheduled on the subsequent event has been triggered. You may need to wait a few minutes until the subsequent process is visible in SM37 or RSMO. In case that the subsequent event was not fired do this manually using SM64 or program YWZX_EVENT_RAISE. Compare the job-chain documentation of the location when in doubt what the next process should be.

 

Also check that the subsequent BADI processing has run when it is defined. You can lookup table YYWZ0_BADI_2_FB to find the function module that is actually called from the BADI.

 

The template knows only two BADI functions. One is to complete the delta entry in table YYWZR_DELTA_TSTP for the home-grown delta management (FuMo Y_WZR_DELTA_WZR_SR011_01). You can check table YYWZR_DELTA_TSTP to find out whether the BADI ran successfully. The other BADI triggers special events after Static Reporting uploads (FuMo Y_WZR_SR_BADI_EVENT_TRIGGER). You can check the according event collector to find out whether the BADI ran successfully.

2.1.4   Missing Data Packets / Missing IDocs

Data packets are transferred using transactional RFC. In case that data packets do not arrive in BW you can check SM58 on the source system.

 

 

You can use the context menu to execute the tRFCs manually.

 

You can navigate from the monitor to investigate about IDocs.

 

 

You can also use transaction BD87 in the according system. In rare cases IDocs can be missing. Error messages can be seen this way. Manual processing is possible via BD87.

 

Sample for this issue is ReqID REQU_6ZUITX96ZN98EHM2J96F7YB77 in PBW.

 

 

The details tab will immediately show a missing IDOC.

 

 

 

 

 

 

 

 

 

 

The BW Idoc field is blank so no IDOC was processed in BW.  The OLTP IDOC field is populated which means an IDOC was sent from R/3.  In this case PGY.

 

Checking each IDOC transfer, we can list all IDOCs in both R/3 and BW.

 

 

 

BD87 in BW shows a status of 53 which means okay.

 

Table EDIDS shows the same.

 

BD87 in R/3 (PGY) shows a status of 03 which means okay.

 

Table EDIDS shows the same.

 

 

 

2.2      Master Data Load Failures

2.2.1   Invalid Characters

Check if invalid character is in accepted in SAP.  To check, debug load from PSA.

 

Select only record with invalid character.

 

Debug and then check hexadecimal equivalent of characters. 

(1)   If no hexadecimal equivalent, raise GIMS to CCM and inform that the data from R/3 needs to be changed.  Specify table and entries in the table that should be changed.  For an example, refer to GIMS 1686588.

(2)   If there is a hexadecimal equivalent, check table RSALLOWEDCHAR if character is available (most likely not that’s why you encountered the error. =))  Note that lower case

characters for invalid characters are never maintained in this table as per H.O.  If there’s a need to maintain the said character, raise a GIMS to HO (Raymund-Jose del-Rosario – not anymore, it’s now Marlon Clemente. hehehe) so that this may be added.  A GIMS should be raised because we are not authorized in transaction RSKC where we can add the invalid character.  For an example, refer to GIMS 1761003.

ASCII Table

 

 

QUICK FIX / TEMPORARY SOLUTION

Load data up to PSA only.  Once in PSA, manually modify the data and then load up to data target (click on PROCESS MANUALLY in the STATUS tab via RSMO).  Do this until fixes has been applied.

 

 

2.2.2   Duplicate Records

Raise a GIMS to CCM.  For an example, refer to GIMS 1718060.

The GIMS should have the following information: Table and entries that are causing duplicates.

To get table, get the datasource.  Inside the infopackage, you can immediately get the datasource technical name. 

 

Use this datasource as input in table ROOSOURCE from your source system (ANA or PNA).  In the said table, you’ll be able to get the table where the datasource is pulling the data from.

 

You can get the same information from transaction RSO2.

Note that if the duplicate record is for management area, the first four characters of the management area already indicates the company code.

QUICK FIX / TEMPORARY SOLUTION

Load data up to PSA and then click on IGNORE DUPLICATE RECORDS.  Do this until fixes has been applied.  Remove “IGNORE DUPLICATE RECORDS” once R/3 has deleted duplicates.

 

 

2.2.3   Error Handling BW Functionality

Another solution for both MD issue is to use the error handling functionality of BW.

 

The error handling options define how incorrect data is handled:

No update, no reporting. This option means that if there is an error, no records are updated and, hence, will not be available for reporting. All incorrect records are highlighted in red in the Data Monitor and can be manually corrected and loaded individually.

Valid records updated, no reporting (request red). This option specifies that if an error occurs, all valid records will still be updated but will not be available for reporting. The request will stay in a red status, which will not update the reporting read pointer. All invalid records are physically separated from valid records in a new request that is written to the PSA for error handling and subsequent update.

Valid records updated, reporting possible (request green). This option specifies that even if errors occur, the data loaded in the request should update the reporting read pointer to make it immediately available for reporting. All invalid records are physically separated from valid records in a new request that is written to the PSA for error handling and subsequent update.

Termination by number of records. This parameter is a threshold for the number of invalid records that are permitted before the data load aborts.

No aggregation allowed. If this flag is set, the number of records read into BW must equal the number of records that are updated. If any records are generated, deleted, or aggregated, an error ensues.

2.2.4   Locking Issue

More often than not this should be fixed by simply repeating the load.  What needs to be done further is to check what is causing the locks and modify the chain accordingly to avoid it.  Check SM37 jobs and see what are other parallel loads running.

2.2.5   Errors in Infopackage Groups

When IPG jobs fail, the status in SM37 is still COMPLETED.  You have to go to the LOGS to check where it failed (this means in which IP it failed).

 

To fix, you have 2 options:

(1)   Rerun the whole IPG from RSA1 removing IPs that completed from the list.  If you do this, please make sure that you save back the IPG to BATCH_NY to its original state.  Otherwise, we’ll have problems in the next run.  If you want to repeat all IPs, just  go to transaction SM37, copy the job and then release the job immediately.

(2)   Manually rerun each IP to follow starting from the failure.  You can refer to the last successful IPG as basis.  Use transaction RSRQ.

 

2.3      Opening Balances

The template approach to load opening balances is to load first into an ODS (usually WxR_O001) and then to run a delta update into the LGL cube. The load into the ODS is a full load. The ODS will generate the required delta information.

 

Note, that some locations still use the old method to load directly into the LGL cube. Here the InfoPackage is configured with the deletion option. When the InfoPackage is completed the previous request with the same or more comprehensive selections will be deleted. Since the former request is usually picked up by the delta into the GLRM cube the former request is not actually deleted but reversed. Note that reversals are run from the PSA. Thus, this procedure can only work when PSA is available for the previous opening balances load.

2.3.1   The Full Load into the Opening Balances ODS Cancels

When the full load into the opening balances ODS fails, the request can simply be removed from the ODS. The data load can be repeated. Loading can be continued. Make sure the ODS activation runs as intended.

2.3.2   ODS Activation Cancels

This happened in rare cases when the activation started too early and the actual data request was not through. In particular the automatic request activation has proved to be instable.

 

The activation can be repeated. Use program RSODSACT1 for simplicity.

 

2.4      Cancelled BSEG / COEP / COM Extraction

The R/3 standard tables BSEG/BKPF (FI) and COEP/COBK (CO) are extracted using generic extraction. These extractions use a home-grown delta mechanism. The data target is the LGL cube.

 

 

In case of a cancelled BSEG/COEP/COM extraction the request can be deleted from the according cube. Additionally the delta table YYWZR_DELTA_TSTP has to be cleaned up. The entry of the failed request has to be removed. Always select the according company code and data source.  Also compare the timestamp of the selected entry to make sure to delete the right record. A complete download of the table should be downloaded before modifications to this table are done.

2.4.1   BSEG/COPA Load Failure Due to MD Issue

Issue experienced here is because the one-time master data load for new entities were not done.  Error is triggered by the update rules.

 

To fix, simply do a one-time MD load for the company code in question and then reload from PSA.

 

 

2.5      Cancelled Cube to Cube Delta

We are using the standard SAP cube-to-cube delta mechanism. In case a delta request fails the according request can be deleted and the delta can be re-run.

 

Take care about potential post-processing.

2.6      Cancelled CO-PA

The CO-PA extraction is realized using an SAP application specific data source. Most locations use the SAP generic delta.

 

An overview about the data source and the delta timestamp can be obtained using KEB2.

 

 

For generic delta the delta timestamp is kept in table ROOSGENDLM. CO-PA delta requests are only confirmed with the start of the next extraction. Red requests can be deleted and re-run.

 

2.7      Cancelled Aggregate rollup

When the aggregate rollup cancels there is definitely a serious problem in place like table space overflow. Make sure to check the job log, sm21, st22, … to find the root cause. Only then repeat the rollup. Run at least data reconciliation based on spot checks. In case the aggregate is not too big rather go for a complete rebuild of the aggregate, i.e. deactivate the aggregate from the admin workbench and activate again.

 

There are also reports available to do so:

SAP_AGGREGATES_ACTIVATE_FILL

SAP_AGGREGATES_DEACTIVATE

YWZX_ADMIN_TOOL

 

Study the job that failed and look for post-processing steps.

 

 

1.1.1   Metachain Deactivation

Run the chain that failed due to deactivation via the program

 

RSPC_API_CHAIN_START.

 

Just input the PC.  Do not tick any checkbox.

Once this manual run completed, force to green the failed metachain in the main PC that was executed.

 

1.1.2   Interrupt Issues

The following can be done whenever there’s an issue with the interrupt:

Check if the event that’s supposed to be triggered was simply undetected.  Go to SM64 and check the event history.

 

 

Check table RSPCINTERRUPTLOG if there’s an instance waiting for an event.

 

 

Note:

When the “Log-ID of a Run” and the “Instance ID” are blank, there was an event triggered even prior to the part where the Interrupt process variant in the PC is triggered.  This will be cleared by the reset interrupt program.

When only the “Boolean” field is blank, it means that the Interrupt process variant is already triggered but it’s still waiting for the event.

 

Check if there’s a release job for the INTERRUPT_WAIT.  Right click on the Interrupt process variant and then choose Display all Wait jobs.

 

Before triggering the event that the interrupt is waiting, check if the pre-requisite process is indeed complete.  You can trigger the event manually by using the program YWZX_EVENT_RAISE or by going to transaction SM64 and executing it.

 

 

1.2      Monitors to Check on Failures

1.2.1   Monitor Jobs - SM37

 

1.2.2   Dump Analysis - ST22

 

 

1.2.3   System Log - SM21

 

 

 

1.2.4   Database Performance Analysis - ST04

 

 

 

1.2.5   Database Performance. Tables and Indexes

prod ERRORS

 The following issues are in the below format:

 

BW Error

Possible Causes

Solution

 

 

1

Failure occurred When delta Update is going on from one data target to another data target.

 

1.TRFC error

2. Data is incorrect(error records).

3.Locked by ALEREMOTE or user.

In Monitor check the technical status of the request for red status and then, delete the request from the data target

 

If its delta update, In the source datatarget reset the delta. Retrigger the infopackage to load data again.

If its Full update, restart job again after deleting error request from the datatarget.

 

 

 

 

2

Maestro job abended with error code or PR1 batch job did not run or get delayed.

 

This can be due to some upgrade issue or some changes are done in Maestro schedule.

Maestro jobs are handled by Production Services, if job is abended with a error code, ticket will be raised by SAP BASIS team looks at Maestro problems. If there is a issue with PR1 batch job, ticket is raised for SAP team.

 

 

 

3

 Database errors : Enable to extend Table, enable to extend the Index.

For example.

Database error text.

 "ORA-01653: unable to extend table                         

 SAPR3./BIC/AZUSPYDO100 by 8192 in tablespace PSAPODS2D"                                

 

This is due to lack of space available to put further data.

 

 

This is Database error. Short dump message indicates this error message. Ticket is raised for DBA Elizabeth Mayfield who provides the space required. If the update mode is delta, technical status of job is changed to red and request is deleted from the datatarget. Infopackage for Delta update is triggered again to get delta from R/3 back. If its full

update,request is deleted from the datatarget and Infopackage is triggered again to get full update.

 

 

 

 

 

 

 

 

 

 

``4

Dead Lock                                                                                   

 

Database error text........: "ORA-00060: deadlock detected while waiting for            

 resource"                                                                              

Internal call code.........: "[RSQL/INSR//BIC/FZPUR_VNDR ]"                             

Please check the entries in the system log (Transaction SM21).                          

This can happen when SMON is running or any DBA process is running.

Contact the DB People Ticket is raised for DBA who can adjust the schedules for SMON process.

 

 

 

 

5

Time Stamp errors :

 

This can happen when there is some changes done on datasource and datasource is not replicated.

Execute T code SE38 in BW give programme name as RS_Transtrucuture_activate and execute the programme. Give Info source and Source System and activate. This will replicate the data source and its status is changed to active. Once this is done, delete the request by changing technical status to red and trigger Infopackage to get delta back from source system.

 

 

 

 

 

 

 

 

 

 

6

Error log in PSA- Error occurred while writing to PSA.

This is because of corrupt data or data is not in acceptable format to BW.

Check the cause of the error in Monitor in detail tabsrip.This gives the record number and Infoobject having format issue. Compare the data with correct values and detaermine the cause of failure. Change the QM status of request in datatarget to red and delete the request. Correct the incorrect data in PSA and then upload data into data target from PSA.

 

 

 

7

Duplicate data error in Master data upload:

 

This can happen if there are duplicate records from the source system. BW do not allow duplicate data records.

If it’s a delta update,change the technical status in the monitor to red and delete the request from the datatarget.If its full upload delete the request.Delete the request. Schedule again with the option in the Infopackage ,“without duplicate data” for master data upload.

 

 

 

 

8

Error occurred in the data selection:

 

This can occur due to either bug in the infopackage or incorrect data selection. In the infopackage.

Data selection checked in the infopackage and job is started again after changing the technical status to red and deleting the error request from the data target.

 

 

 

9

Processing (data packet): No data:

 

This can be because of some bug in Infopackage, rescheduling with another Infopackage corrects the problem.

This type of problem we can solve with copy the Info package and reschedule the data.

 

 

 

 

10

Process Chain failed.

 

Errors occurred in one of the job in the process chain

 

Attend failure manually and go to process chain log for today and right click on the next job and select Repeat Option. This will execute all  remaining jobs in process chain.

 

 

 

11

Errors occurred in (IDocs and TRFC) here only one Data package arrived in BW that’s also with error:

Non Updated IIDOCs found in the source system.

This can happen when in source system job is terminated or source system or BW is not available for whole period of data upload. This can also happen if resources are not sufficient in source system.

IIDOC’s need to be processed manually either in OLTP or in BW depending on the failure. Error message in monitor in status tabstrip will  take you to either BW or OLTP wherever there is a problem. Process IDOC’s ,this will start the left over packets and will finish the load.

This situation we have to check the Idocs so we have to check Idoc in WE05 and know the status these are WE51, WE52, WE53 may be and next goto WE 19 there we have to execute the exist Idoc with successfully loaded Idoc.

 

 

 

12

Processing (data packet): Errors occurred-Update ( 0 new / 0 changed ) : Errors occurred-Error records written to application log.

 

This can be because of data not acceptable to datatarget although data reached PSA.

Data checked in PSA for correctness and after changing the bad data data uploaded back into datatarget from PSA.

 

 

 

13

Process Chains: Errors occurred in Daily Master Data

This occurs when Transaction data is loaded before Master data.

Ensure to load Master data before Transaction data. Reload data depending on update mode(Delta/Full Update)

 

 

 

 

14

Errors occurred-Transfer rules ( 0 Records ) :

 

These errors happen when the transfer rules are not active and mapping the data fields is not correct.

 Check for transfer rules, make relevant changes and load data again.

 

 

 

 

15

Missing messages -Processing end: Missing messages

This can be because of incorrect PSA data, transfer structure, transfer rules, update rules and ODS. 

Check PSA data, Transfer structure, transfer rules, Update rules or datatarget definition.

 

 

 

16

Other (messages): Errors occurred in data selection

The 'valid from' date is smaller than the mimimum date, The 'valid from' date is smaller than the mimimum date, Error in node time interval with the ID 00000011 . Details in next message, The 'valid from' date is smaller than the mimimum date.

 

Change the selection option and reload data.

 

 

 

17

Activation of ODS failed

This happens when data is not acceptable to ODS  definition. Data need to be corrected in PSA.

Check  for Infoobject which has caused this problem in the monitor details tabstrip. Delete request from datatarget after changing QM status to red. Correct data in PSA and update data back to datatarget from PSA.

 

 

 

18

Source System not available

This can happen when request IDOC is sent source system, but the source system for some reason is not available.

Ensure that source system is available. Change technical status of request to red and delete request from datatarget. Trigger Infopackage again to get data from source system.

 

 

 

 

 

 

 

19

Caller 70 missing

IDOC’s not processed completely.

Idoc Problem, Either wait till time out & process Idoc from detail monitor screen, or go to BD87 & process Idoc with status = YELLOW ( be careful while processing IDOCS from BD87, choose only relevant Idocs

 

 

 

20

Object corrupted- Delta Management of Master data lost but allows Full update.

 “

Update Mode R not supported. “

This happened during mass failures due to database space issue.

Reinitialization or there is one program for repair of Info object. During reinitialization ensure to use option of Only PSA, avoid duplicate data and subsequently into datatargets.

Go to Transaction code RSRV to check consistency of Infoobject.

 

 

 

21

Error while opening file from the source system.

This happens when  either file is open  or file is not deposited on server or not available.

Arrange for file,delete error request from datatarget and trigger Infopackage to load data from file.

 

 

 

22

Object locked by user

This can happen when user or ALEREMOTE is accessing the same table.

Change the technical status of job to red,delete request from datatarget and trigger Infopackage again. If its delta update it will ask for repeat delta,Click on Yes button.

 

 

 

 

23

While load is going on in R/3 table is locked

This happens when some datasource is accessing R/3 transparent table and some transaction takes place in R/3

Change the technical status of job to red in the monitor and retrigger the job again from R/3.

 

 

 

24

Change run already started by ALEREMOTE

This can happen due to overlapping of same request to Program.

Go to  Transaction  Code RSATTR,see if its running. Once its finished,repeat the job