How to Retrieve the Lost Logistics queues

Introduction:

This document describes the important procedure which is required in performing the reconstruction of the Lost/missing queues (LBWQ) for the Logistics applications.

In our day to day activities we might having issues with the queues where some of the queues might be missing for several reasons like Database error, Problems with RFC, an Accidental deletion of queue Or some other reasons..

Document explains the procedure to retrieve the missing data from the queues without needing the re-initialization and the down time.

SAP has delivered a transaction – LBWR and table – MCEX_DELTA_BACK in order to support this functionality with the OSS – Note 1008250 .

Procedure Steps:

Start the transaction – LBWR 

i] Enter the name of the application for which the backup needs to be considered. Update the section as MCEX<nn> where nn stands for Application number. If the application is Purchasing then use the Queue name as MCEX02 for Sales MCEX11 and etc.,

ii] Use “Customizing Changes Only” in the Reconstruction Extraction Queue section. Initially the customization is required to update the tables in order to update the back-up tables.

iii] Under Customizing section fill the below entries –

–          No. of Collective Processing

–          No. of Days with the Backup Data

1. No. of Coll. Processing –  This will make sure how many number of collective runs needs to be extracted or sent to the backup table. Numbers are considered based on the V3 setup which is present in the system.  If you have V3 job running hourly for application 12, then there will be 24 collective runs per day and 48 for 2 days of backup.
2. No. of Days with Backup Data – Update the days as to how many days of data is required to maintain in the backup tables. More the number, more space will be occupied. Hence update this as 2 or 3 days for the storage. Data will be automatically will be cleaned by the system itself according to the settings as per the customizing entries.

For Example:

If you enter –

1. No. of Coll. Runs with Backup as 96 (represents 4 days)
2. No. of Days with Backup as 2 days, the delta data of the last four days is therefore retained in backup table MCEX_DELTA_BACK.

If the periodicity of the collective runs changes, this period can also change. However, it always amounts to at least two days because of the setting for BACKUP_DAYS.

Settings can be viewed using the report – RMBWV3RE as well.

Note: If a value for BACKUP_DAYS (number of days for which the backup data is to be retained) was also defined, the larger number of entries in the backup table is retained.

Reconstructing the data:

Execute the report – RMBWV3RE or the transaction LBWR.

Update the processing Mode as – ‘Reconstruct the Queue from the Backup Table’.

Update the Time stamp or the No. Coll. Processing’s to be extracted from Backup tables to the queue and press F8 based on the initial analysis of which data is missing in the target systems in order avoid duplicates in BW.

OR

Say Yes to the below message.

This will bring the data for the last 4 days due to the number of collective runs (assuming the collective run has 1 hr periodicity)

Once done, check the update in LBWQ

The Queue name is marked as MCEX12_BACK which represents that this has come from the Backup tables of the reconstruction tables.

With the execution, the entries from the backup table has come to the LBWQ which can further used to push the data to the Delta Queue once the V3 runs.

Entries from the MCEX12_BACK.

  This will be moved to RSA7 for further extraction to BW.

Display data from the backup tables:

  You can view the data in LBWR transaction with the below settings –

Select the kind of data to be viewed either Header, Item or schedule line in the given list and you can choose the number of records for the output and then hit   the results:

  Entry from Backup table:

Precautions:

• Make sure that the Authorization object – M_QU_RE is assigned to restricted team who can actually judge the data to pull the same to BI without duplicating it.
• Data analysis has to be done thoroughly in BW in order to avoid any duplicates. If there is a data for a particular day, and if the data has been reconstructed using the time stamp, then it is important that the relevant data in BW is deleted before reconstructing!
• If the Document posted is the later version compared to the missing data, then the same has to deleted in BW before planning the reconstruction.
• To do reconstruction, the Customization should be been in place for the respective application.
• The settings can be transported to Q and P once after the proper testing of the parameters.

Applications in Scope:

1.     All logistics application. Initially the feature was not available for Global Trade Management (46) but the same has been updated with the OSS Note – 1570406.

Reference Notes:

1.       Note 1570406 – GTM: Backup table for queue MCEX_46

2.       Note 1008250 – Backup table for the queues of logistics extraction into BI