Scope of the Document: This document provides a list of all manual activities that are required pre & post QMR or upgrade for R/3 systems.
What is Delta Queue and Delta Queue Clean up?
Delta Queue is used as a queue for accumulating all the new data from the R/3 systems. BW Delta Queue Monitor (via. Transaction RSA7), we use this to see transferred data (delta) for a Data Source and a Target system. Cleaning up of delta queues in the various R/3 systems so as to ensure that no data is missed during the upgrades is referred to as Delta Queue Cleanup. It’s often required due to the reason that whenever there is an upgrade, the structures of various tables belonging to a Data source get changed & may cause a loss of data in case if the queue contains data. Issues might also be faced in performing the upgrade.
List of manual activities to be performed before the upgrade
1) Pulling up details of all the delta queues from R/3 systems.
We need to go to the R/3 system for which upgrade is there & need to get the details of all the data sources from the delta queues before the upgrade process. We can pull in the details using the transaction RSA7. Please find the screenshot below:
2) Analyzing the Queues
We need to analyze all the data sources in the delta queue & check the status of a data source whether Red / yellow / Green. The Red / Yellow status for a data source in the Delta Queue ensures that there are some issues with the last init or delta is corrupt for the data source. Yellow status indicates that the delta load is in progress or sometimes in cases where the delta is corrupt & requires a fresh init.
In case if the status of a data source in the delta queue is red / yellow pre upgrade, then we need to check the date of last load using the data source on the BW side or we can check the delta pointer as well.
In case if the load was done in past let’s assume 3 -4 months back we can just ignore to investigate the reason why they have red / yellow status, no need to pull the data for such data sources to BW.
We will also notice that there would be some data sources for which the number of LUW’s (A LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet of an application extractor) is 0 in the delta queue. We still need to run at least one delta info package to make sure that nothing gets missed.
For the ones with some entries, we will need to ensure that we run the delta info packages several times until the LUW entries for all the data sources in the delta queues become zero. Usually this scenario would only be useful in case when the users have been locked (except the unlocked users, ones responsible for delta queue cleanup or the upgrade process). Once all the users have been locked & postings have stopped, and at least two subsequent delta loads bring zero records, then we can assume that there is no more data for the respective data source & we can stop running the info packages.
Note: A strange scenario might be faced during the delta queue cleanup while extracting data from some of the data sources. All the delta loads might bring same number of records during there each run & the queue would never get empty even after several runs. This type of issue occurs only in cases where the extraction didn’t happen for a very long time.
As the extraction has stopped long back, we can simply delete the previous init requests (before deleting the previous init requests, please make sure that we are copying the selections used in the old init & before performing a new init without data transfer we need to check if the same selections are applicable for the new init as well). There might be scenarios where the there might be more than one init updates but they would be with different selections, so don’t get confused in case if you see more than one init update for a data source ( There can’t be two init updates possible for a data source with the same selection).
This would ensure that the delta queue gets empty on R/3 side & we can provide a sign off to Basis / ERP team to perform the activities on their part.
3) Performing Delta & Init Updates
In order to perform the delta and init updates we would first need to identify the info packages corresponding to the data sources. Once we have identified the info packages, then we can start using them for performing the loads until the queue’s are completely empty.
Using the delta info package to perform the cleanup
This same delta info package needs to be run several times until two subsequent delta loads bring zero records.
In case if we are facing the issue mentioned in the Note above, then we would need to perform the init update without data transfer to make the queue empty.
Using the init info package to perform the fresh init
We would need to delete the previous init & there after we can run a fresh init without data transfer. We can use the same delta info package to perform the init but it’s always advisable to use a separate info package all together for performing the init.
We would need to delete the previous init before performing the new init as given below. We would need to use the path as Double click on any info package belonging to the respective data source for which cleanup is required -> Scheduler -> Initialization options for the source system -> Select the previous init request -> Click on delete -> Some messages will popup -> Select check mark -> You will see no init request in the initialization options tab once the init is deleted.
Performing the fresh init as per the requirement:
Once all the queues have zero entries in the Delta Queue (Using Transaction RSA7 in R/3 system), we can provide the sign off to the BASIS / ERP team to proceed with the R/3 system upgrade. The queue would look similar to the screenshot below once all the data has been pulled in from the all the data sources.
Once the Upgrade for R/3 has started, we should make sure that all the delta requests should be pushed from the PSA to the corresponding data targets so that data is not missed once the regular loads start.
4) Post Upgrade Activities
Once the Upgrade / QMR is complete, the system would be released only to a certain group of users (only to people involved in the Upgrade). We might notice that several data sources in the Delta queue might turn up to be in red status. Somewhat similar to the screenshot below:
We should not get carried away by such status & conclude that something has gone wrong after the upgrade process. It’s mandatory process to replicate all the data sources & also the transfer rules in case if the flow is a 3.x flow. Once the replication is successful, the status would change back to green.
Replication is required because after the upgrade the structural changes for various tables need to be mapped / updated to the data sources present in BW, time stamp also need to be matched with R/3 timestamp.
Replication of a Data Source
In case of a 3.x data flow additional step of activation of the transfer rules would be required. We can activate the transfer rules using the program “RS_TRANSTRU_ACTIVATE_ALL”.
Go to transaction SA38 / SE38 -> RS_TRANSTRU_ACTIVATE_ALL-> Execute
Enter the info source name corresponding to the 3.x flow data source along with the source system name and execute. Leave the check boxes for LOCK & Only Active unchecked.
Execute the transaction. If you have appropriate authorizations then the transfer rules would be completely activated and you would see a green status in the log. You can check the log to see which transfer rules were activated. In case if you face authorization issues then you would need to get appropriate authorization before this step is successful.
Once the activation is complete, then the delta loads should run perfectly fine thereafter.
In case if you face any issues in activating the transfer rules then you would notice that after giving selections in the program, you would find the overall status as RED. In such case, there is an authorization issue for the corresponding info sources & the issue needs to be escalated to Security team for gaining proper access for those info sources.
Once the activation is complete, there should not be any issue in running the delta loads thereafter.
5) Some Points to Remember
a) All the activities of init, metadata replication, activation of transfer rules should be preferable done before the postings start again.
b) Init would be required only in case if there delta is corrupt & is not working as desired.
c) Escalations for the authorization related issues should be routed to Security group / Basis / ERP team as soon as possible without any delay.
d) Please make sure that we are updating all the delta requests from PSA to targets so that any data inconsistency can be avoided in future.
Still after the replication or activation of transfer rules, if the issue is faced, escalate to your security team / ERP team for help.
Note: Some content has been erased manually considering the security guidelines in mind.
- SAP Managed Tags:
3 Comments
