Troubleshooting Real-Time Data Acquisition

You monitor the data transfer in the monitor for real-time data acquisition (RDA).Problems can occur when data is transferred to the PSA or posted from the PSA to the InfoProvider.

If an error occurs, the daemon terminates the data transfer. You can analyze and correct the error, and then restart the data transfer.

You are in the monitor for real-time data acquisition. The daemon displays the status.

Troubleshooting in the Monitor for Real-Time Data Acquisition

To facilitate troubleshooting and error classification, and therefore make it easier to correct errors, the daemon records information and displays it in the monitor for real-time data acquisition. Before every processing step in the assigned InfoPackage or DTP (opening a request or executing a DTP for example), the daemon records context information, such as daemon number, InfoPackage or  DTP, time stamp of the RDA run and job name for processing on the database.If an error occurs, the daemon deletes the context information from the database or overwrites it. Context information for the errors is recorded, indicating whether they are error messages, exceptions or runtime errors. Each error is given a sequential number. The error information and context information is stored and displayed until the errors for an InfoPackage or DTP have been reset.This is done automatically if a new request could be created, or manually using the monitor for real-time data acquisition.

On every display level except for subsequent process chains, the monitor for real-time data acquisition displays the number of errors since the last time a status display was reset. For InfoPackages and DTPs, the errors are counted and displayed by the daemon.For DataSources and daemons, the number or errors and the status is aggregated over the assigned objects.This meaning of the various statuses is as follows:

In the InfoPackage for real-time data acquisition, you define the maximum number of tolerated errors per request before RDA processing will be stopped. If the number of tolerated errors recorded for an InfoPackage since last time it was reset exceeds the maximum number of errors defined in the InfoPackage, execution of the InfoPackage and all assigned DTPs will be stopped. If the number of errors recorded for a DTP since last time it was reset exceeds the maximum number of tolerated errors defined in the InfoPackage, execution of the DTP will be stopped.

To troubleshoot errors in real-time data acquisition, proceed as follows:

1. Find the requests with errors using the status display.
2. In the context menu for the request, choose Display Errors.

   A dialog appears displaying the errors, together with the context information for processing, sorted by time stamp.

3. For more detailed analysis, you have the following navigation options:
   • For error messages and exceptions: Double-click the Error Message column to display the application log messages.
   • For runtime errors: Double-click the Error Message column to display the ABAP dump analysis.
   • Double-click the InfoPackage or DTP column to display the InfoPackage DTP maintenance screen.
   • Double-click the Background Log column to display the job overview.
   • Double-click the Request column to display the monitor for the request.
4. Use the messages provided to determine whether the error occurred during extraction or in the transformation.

Only delete the daemon assignment for the DataSource if an error occurs in one of multiple assigned DataSources

If multiple DataSources are assigned to the daemon, and you want to correct an error in one DataSource, we recommend that you delete the daemon assignment for this DataSource so that the load process can continue.

To do this, choose Delete Assignment in the context menu for the DataSource.

Correcting Errors That Occur During Extraction

If the PSA request is red because errors occurred during extraction, for example the RFC connection was interrupted, the background job was deleted, or the system terminated the program, proceed as follows:

1. Check the data in the PSA.

   To do this, in the monitor for the PSA request, choose PSA Maintenance.

2. If the technical status of the request is red and you have corrected the error that occurred during extraction, proceed as follows: Delete the request from the PSA, repeat the delta update into the PSA, and execute a repair process chain. If you have deleted the daemon assignment for the DataSource, re-assign the daemon to the DataSource in order to continue the data transfer with real-time data acquisition. Otherwise, restart the daemon. The steps you take are as follows:
3. Delete the request from the PSA.

   To do this, open the list of requests in the PSA by double-clicking on the PSA request in the Data Target column. Select the request with errors and choose Delete.

4. To repeat the last delta update, create a standard InfoPackage for the DataSource in the Data Warehousing Workbench, choose Delta Update on the Update tab page, and execute the InfoPackage.
5. Check the status of the PSA request in the extraction monitor.
6. Go back to the Monitor for Real-Time Data Acquisition.
7. In the context menu for the data transfer processes assigned to the DataSource, choose Generate Repair Process Chain.

   The system creates a process chain in the display component Repair Process Chains for Real-Time Data Acquisition (RDA) for a data transfer process. The chain is assigned the following processes in addition to the start process:

   • Data transfer process
   • For DataStore objects (belonging to the HybridProvider), activation of the data in the DataStore object (no activation is required for write-optimized DataStore objects)
   • Subsequent process chains if they were defined for the data transfer process
     Note

     One repair process chain can be generated for each data transfer process. The chain cannot be changed or transported.

8. In the context menu for the data transfer processes, choose Execute Repair Process Chain. The relevant process chain starts immediately and performs the repair as follows:
   • The standard DTP is executed. All data that is not yet in the InfoProvider is transferred there from the PSA.
   • For standard DataStore objects (belonging to the HybridProvider): Once the data has been posted to the DataStore object, the data is activated. If you are using a HybridProvider, the system automatically triggers the data transfer to the InfoCubes belonging to the HybridProvider.
   • If there are subsequent process chains for the data transfer process, these are executed.
9. Activate the data transfer again with real-time data acquisition.
   • If the daemon was previously terminated, start it again by choosing Start Daemon in the context menu for the daemon.
   • If you previously deleted the assignment of the DataSource to the daemon because the daemon is still processing other DataSources and if the daemon is already running, assign thee DataSource to the daemon again by choosing Assign Daemon in the context menu of the DataSource.The daemon includes the DataSource in the processing with a few minutes delay.

Updating Delta Requests that were not Updated or that are Incorrect from the PSA to the InfoProvider

In some situations, a PSA table can contain one or more completed delta requests that have not been posted to the InfoProvider yet or have been posted there with errors.

Errors can occur for example in the transformation in data that does not have the expected data format. If this happens, proceed as follows in the monitor for real-time data acquisition:

1. Check the status of the DTP request by choosing Monitor in the context menu for the request.

   If the status of the request is red, proceed as follows:

2. Check whether the data for the DTP request is correct in the InfoProvider.

   To do this, choose Administer Data Target in the monitor for the DTP request.

3. If the DTP request has the status 'red' due to technical problems in the transformation for example, but the data in the InfoProvider is correct, change the status of the DTP request to 'green' if the corresponding PSA request has status 'green' and re-activate the data transfer with real-time data acquisition (step 8).
4. If the data in the InfoProvider contains errors, check the transformation and correct the errors.
5. To repeat the DTP request, set the status to 'red' if necessary and delete the request.

   In the context menu in the monitor for real-time data acquisition, call InfoProvider administration by double-clicking on the Data Target  column for the data transfer process. You can perform both functions here. For DataStore objects, the DTP request containing the errors is deleted along with the activation log request. For InfoObjects, the system deletes the status information about the DTP request but not the data itself.

6. In the monitor for real-time data acquisition, choose Generate Repair Process Chain in the context menu of the data transfer process.

   See step 7 in the previous section.

7. In the context menu for the data transfer process, choose Execute Repair Process Chain. The process chain starts immediately and performs the repair.

   See step 8 in the previous section.

8. Activate the data transfer again with real-time data acquisition.

   See step 9 in the previous section.

If the Daemon Cannot be Started

You cannot start the daemon in the following cases:

• A PSA table that is the source of a data transfer process assigned to the daemon contains one or more completed delta requests that have not yet been written to the InfoProvider.

  The system suggests that you generate and execute a repair process chain. The procedure is described in the previous section.

  If you do not want to define any more values for the InfoProvider using RDA after executing the repair process chain, delete the assignment to the DataSource in the monitor for real-time data acquisition from the context menu for the data transfer process instead of executing step 8.

• For DataStore objects (belonging to the HybridProvider): The target of a data transfer process assigned to the daemon contains one or more completed delta requests have not been activated yet.

  You proceed as follows:

  1. Select the delta requests that have not been activated yet in the DataStore object administration screen and activate the data by pressing Activate.
  2. If do not want to define any more values for the DataStore object using RDA, delete the assignment to the DataSource in the monitor for real-time data acquisition from the context menu for the data transfer process.
  3. To reactivate the data transfer with real-time data acquisition, open the monitor for real-time data acquisition and start the daemon from the context menu.
• Requests are deleted in the target of a data transfer process assigned to the daemon.

  Wait until all requests from the InfoProivder have been deleted and restart the daemon.

Problems After Restarting the System

If requests with status red appear due to terminated processes after restarting the system, this might be because the background jobs for real-time data acquisition could not be ended properly when the system was stopped. When stopping and starting systems, we therefore recommend using soft shutdown. When making system copies, we recommend running report RS_SYSTEM_SHUTDOWN. For more information, see the documentation for basic administration tasks in SAP NetWeaver BW.