.png)
The following requests have to be created while Customizing the LO datasource:
1. Request for changing the status of the datasource from Active to Inactive
2. Request for Enhancing the datasource
3. Request for changing the status of the datasource from Inactive to Active
The 3 requests created
1. Inactive request – Customizing request
2. Enhancement request – Workbench request
3. Active request – Customizing request
These requests has to be transported from development to quality and production...
before transporting, following checks have to be maintained..
1. Delete the setup table
The setup table needs to be deleted first, before transporting the enhanced datasource.
For this go to t-code LBWG .
Enter the Application of your datasource.
E.g.: For 2LIS_13_VDKON, enter 13.
Click on execute.
2. Empty the Extraction Queue
The extraction queue also has to be emptied before the transport.
For that, go to SE38 and execute the program RMBWV3nn .
nn – Your application 11, 12, 13 etc.
3. Check the Extraction Queue
Once the above mentioned program is executed, check in the Extraction Queue
For this go to t-code LBWQ
The Queue (MCEXnn) for your application should not be present here if it is empty.
In our example MCEX13
4. Empty the Delta Queue
Empty the delta queue by executing the relevant Infopackages, so that the records in the delta queue will be pulled to BI, and hence the Delta Queue (RSA7) will be emptied.
5. User Locking
All users should be locked during the transport, so that there are no new postings during the transport. Only ALEREMOTE and your own user-id should be unlocked.
Now transport request...
After the transport
After the above requests are successfully transported, the following needs to be done
1.Replicate the datasource
After the transport, replicate your datasource in BW , so that the Customized structure is updated in BI.
2.Monitor the queues
Monitor the extraction queue (LBWQ) and delta queue (RSA7) in your source system, to check whether new records are being updated in these queues or not.
To confirm this, check the entries in these queues
3.Execute next delta
Once it is confirmed that the queues contain entries for the new records, the next delta infopackage can be executed.
1. Request for changing the status of the datasource from Active to Inactive
2. Request for Enhancing the datasource
3. Request for changing the status of the datasource from Inactive to Active
The 3 requests created
1. Inactive request – Customizing request
2. Enhancement request – Workbench request
3. Active request – Customizing request
These requests has to be transported from development to quality and production...
before transporting, following checks have to be maintained..
1. Delete the setup table
The setup table needs to be deleted first, before transporting the enhanced datasource.
For this go to t-code LBWG .
Enter the Application of your datasource.
E.g.: For 2LIS_13_VDKON, enter 13.
Click on execute.
2. Empty the Extraction Queue
The extraction queue also has to be emptied before the transport.
For that, go to SE38 and execute the program RMBWV3nn .
nn – Your application 11, 12, 13 etc.
3. Check the Extraction Queue
Once the above mentioned program is executed, check in the Extraction Queue
For this go to t-code LBWQ
The Queue (MCEXnn) for your application should not be present here if it is empty.
In our example MCEX13
4. Empty the Delta Queue
Empty the delta queue by executing the relevant Infopackages, so that the records in the delta queue will be pulled to BI, and hence the Delta Queue (RSA7) will be emptied.
5. User Locking
All users should be locked during the transport, so that there are no new postings during the transport. Only ALEREMOTE and your own user-id should be unlocked.
Now transport request...
After the transport
After the above requests are successfully transported, the following needs to be done
1.Replicate the datasource
After the transport, replicate your datasource in BW , so that the Customized structure is updated in BI.
2.Monitor the queues
Monitor the extraction queue (LBWQ) and delta queue (RSA7) in your source system, to check whether new records are being updated in these queues or not.
To confirm this, check the entries in these queues
3.Execute next delta
Once it is confirmed that the queues contain entries for the new records, the next delta infopackage can be executed.
The way you explain concepts is really inspiring..every topic is presented in a very simple manner and much clear to understand..Thanks for the noble job ..pls. keep up the good work now and ever :)
ReplyDeleteThank you
DeleteI have to accept this is best site to learn
ReplyDeleteIndeed, this is true.
DeleteWhy user should be locked? Before transport?
ReplyDelete