Using the repair mode of the hash solution
With the function for checking the LBWQ for structure changes (the hash solution), a termination is forced when the update report RMBWV3xx is run (xx = application number) if the structure of the data in the LBWQ does not correspond to the current ABAP Dictionary version.
This occurs when changes are made to extract structures of the LO Customizing Cockpit, even though data of the 'old' structure was contained in the extraction queue (LBWQ).
This occurs when changes are made to extract structures of the LO Customizing Cockpit, even though data of the 'old' structure was contained in the extraction queue (LBWQ).
The subsequent actions must take place in a posting-free period. It is absolutely essential that new data does not arrive in LBWQ during repair mode.
Step 1: Lock your users and ensure that no IDocs are imported and that no batch tasks are running, and so on.
Step 2: Ensure that there is no longer any data in transaction RSA7.
Step 3: Then set the user parameter MCEX_REPAIR_MODE with the application-specific value. You will find this value in the relevant note of the application for the hash solution.
Step 2: Ensure that there is no longer any data in transaction RSA7.
Step 3: Then set the user parameter MCEX_REPAIR_MODE with the application-specific value. You will find this value in the relevant note of the application for the hash solution.
To set the user parameter MCEX_REPAIR_MODE use tcode SU2
Step 4: Undo the change to the extract structure/DataSource and replicate the DataSource to BW. Activate the transfer rules of the DataSource.
Step 5: Then start the report RMBWV3xx (xx = application number) manually in transaction SE38.
This report MUST be executed by the same user for which the user parameter was set.
All data that was generated with the 'old' structure is then updated and set in transaction RSA7.
The program termination occurs again when the first data record is posted with the 'new' structure.
Step 6: Then load the data in transaction RSA7 into BW.
Step 7: Then restore the structure changes. Replicate the DataSource into BW again and activate the transfer rules.
Step 8: Start the update report again. You should now be able to update all data.
Step 9: Finally, delete the user parameter MCEX_REPAIR_MODE.
Step 10: Document processing can now be reactivated.
For example:
Initial situation in LBWQ:
Data record 1 - structure 1
Data record 2 - structure 1
Data record 3 - structure 1
Data record 4 - structure 2
Data record 5 - structure 2
1.) Steps 4 - 6: Structure 1 is restored and the relevant data is updated.
New situation in LBWQ:
Data record 4 - structure 2
Data record 5 - structure 2
2.) Steps 7 - 8: Structure 2 is restored and the data is updated.
There is no longer any data in LBWQ.
If several structure changes occurred one after the other, and there are more than two structure versions in LBWQ, you must proceed step by step in the same sequence in which the versions were generated. Steps 4 to 8 must be executed repeatedly until the update report runs successfully again.
Step 5: Then start the report RMBWV3xx (xx = application number) manually in transaction SE38.
This report MUST be executed by the same user for which the user parameter was set.
All data that was generated with the 'old' structure is then updated and set in transaction RSA7.
The program termination occurs again when the first data record is posted with the 'new' structure.
Step 6: Then load the data in transaction RSA7 into BW.
Step 7: Then restore the structure changes. Replicate the DataSource into BW again and activate the transfer rules.
Step 8: Start the update report again. You should now be able to update all data.
Step 9: Finally, delete the user parameter MCEX_REPAIR_MODE.
Step 10: Document processing can now be reactivated.
For example:
Initial situation in LBWQ:
Data record 1 - structure 1
Data record 2 - structure 1
Data record 3 - structure 1
Data record 4 - structure 2
Data record 5 - structure 2
1.) Steps 4 - 6: Structure 1 is restored and the relevant data is updated.
New situation in LBWQ:
Data record 4 - structure 2
Data record 5 - structure 2
2.) Steps 7 - 8: Structure 2 is restored and the data is updated.
There is no longer any data in LBWQ.
If several structure changes occurred one after the other, and there are more than two structure versions in LBWQ, you must proceed step by step in the same sequence in which the versions were generated. Steps 4 to 8 must be executed repeatedly until the update report runs successfully again.
