PSA level Errors are not displayed

Question

Hi friends,
    I'm using BI 7.0....up to PSA  i'm getting data  perfectly.. Even though some errors are there  i mean.. data mis match in my flatfile(for NUMC fields  I was enterd Charecter data... ... that time also.. psa level data was  showing green only.... if i upload into ODS  then only i'm getting  problem..
      but   in previous versions  it was showing  Red  (for error reacords..) in PSA level itself...
     for what reason  I'm not getting  like this.... is there  any  problem  with my procedure.. or   is this BI 7.0 feature..
plz clarrify..
Thanks
babu

Answer 1

Hi,
    Using the Error Handling function on the Update Parameters tab page in the scheduler, you can control the behavior of the BI system if data records with errors occur in the data flow with 3.x objects (use of transfer and update rules) when you are loading data using the PSA.
The system checks for data records with errors:
      in the transfer rules
      in the update rules
      when data is updated to the master data tables, text tables, or hierarchy tables
      when data is updated to the InfoCube
      when checking for referential integrity within an InfoObject against the master data tables or DataStore objects on the communication structure level.
Features
Incorrect records arising in transfer rules, update rules, when updating to a data target, or when checking for referential integrity, are highlighted and returned to the error handler. The error handler locates the original PSA records and writes the corresponding log. This function is not yet available for updating to DataStore objects.
Using the Error Handling function on the Update Parameters tab page in the scheduler, you can control how the system responds to incorrect data records.
Activities
       1.      Define how the system should react to incorrect data records
a.       No update, no reporting (default)
If errors occur, the system terminates the update of the entire data package. The request is not released for reporting. However, the system continues to check the records.
b.       Update valid records, no reporting (request red)
This option allows you to update valid data. This data is only released for reporting after the administrator checks the incorrect records that have not been updated and manually releases the request (using a QM action, that is, by setting the Overall status on the Status tab page in the monitor).
c.       Update valid records, reporting possible
Valid records can be reported immediately. Automatic follow-up actions, such as adjusting the aggregates, are also carried out.
With option a), the incorrect records are marked in red in the PSA maintenance. You can display the relevant error messages amodally, edit the records, and update the request manually. If it was not possible to write to the PSA (hierarchy or transfer method IDoc), an application log is written instead.
With options b) and c), a new request that is only updated to the PSA is formed from the incorrect records. Here you can edit the records of the new request in the PSA and start the update manually.
If errors arise when an InfoCube is updated, new requests are generated for incorrect records for each InfoCube combination. Among these requests, the incorrect records are updated to the PSA. These new requests have entered as data targets the InfoCubes for which there were incorrect records. If, for example, a record was updated to two InfoCubes by mistake, a request is generated for this record that contains both InfoCubes as data targets. In the PSA tree, the requests appear as successfully updated in the PSA. These new requests can then be triggered again for updating to the InfoCubes.
       2.      Specify the maximum number of incorrect data records that are allowed before the system terminates the load process. In the PSA, you can display the errors that have arisen up to that point. If you do not specify the maximum number of incorrect records after which termination should occur, the handling of incorrect data records is inactive and the update terminates after the first error.
       3.      Define how the BI system should react if the number of data records received by the BI system is not the same as the number of data records updated in BI.
A difference between the number of received and updated records can occur:
         in the transfer rules
         in the update rules
         when updating
Records are sorted, aggregated, or added.
If you set the No Aggregation Permitted indicator, the request is deemed incorrect if the number of received records is not the same as the number of updated records.
Regardless of this indicator, an error occurs if the number of selected records is not the same as the number of records received in the BI system.
Result
The monitor directs the user to the relevant error case and enables a direct navigation into the PSA or the respective error request.
If you want to continue processing the incorrect data records in a program that you have written yourself, you can use the method GET_ERRORS of class CL_RSSM_ERROR_HANDLER. The use of this method is documented in the RS_ERRORLOG_EXAMPLE.
More Information:
Checking and Changing Data Using the PSA APIs
To perform complex checks on data records, or to carry out specific changes to data records regularly, you can use delivered function modules (PSA-APIs) to program against a PSA table.
If you want to execute data validation with program support, select Tools ® ABAP Workbench ® Development ® ABAP Editor and create a program.
If you use transfer routines or update routines it may be necessary to read data in the PSA table afterwards.
Employee bonuses are loaded into an InfoCube and sales figures for employees are loaded into a PSA table. If an employee’s bonus is to be calculated in a routine in the transformation, in accordance with his/her sales, the sales must be read from the PSA table.
Procedure
       1.      Call up the function module RSSM_API_REQUEST_GET to get a list of requests with request ID for a particular InfoSource of a particular type. You have the option of restricting request output using a time restriction and/or the transfer method.
You must know the request ID, as the request ID is the key that makes managing data records in the PSA possible.
       2.      With the request information received so far, and with the help of the function module, you can
         read RSAR_ODS_API_GET data records from the PSA table
         write RSAR_ODS_API_PUT changed data records in the PSA table.
RSAR_ODS_API_GET
You can call up the function module RSAR_ODS_API_GET with the list of request IDs given by the function module RSSM_API_REQUEST_GET. The function module RSAR_ODS_API_GET no longer recognizes InfoSources on the interface, rather it recognizes the request IDs instead. With the parameter I_T_SELECTIONS, you can restrict reading data records in the PSA table with reference to the fields of the transfer structure. In your program, the selections are filled and transferred to the parameter I_T_SELECTIONS.
The import parameter causes the function module to output the data records in the parameter E_T_DATA. Data output is unstructured, since the function module RSAR_ODS_API_GET works generically, and therefore does not recognize the specific structure of the PSA. You can find information on the field in the PSA table using the parameter E_T_RSFIELDTXT.
RSAR_ODS_API_PUT
After merging or checking and subsequently changing the data, you can write the altered data records into the PSA table with the function module RSAR_ODS_API_PUT. To be able to write request data into the table with the help of this function module, you have to enter the corresponding request ID. The parameter E_T_DATA contains the changed data records. 
Result
The corrected data is now available for continued updates.
if it helps plz assign points