If deleting outbound queue MCEX12 for one day, then how to recover data?

[Former Member]

On R3, we have been extracting 2LIS_12_VCITM (delivery item) daily with Delta load for many years. But recently someone activated 2LIS_12_VCHDR (delivery header) and both 2LIS_12_VCITM and 2LIS_12_VCHDR data went to the same outbound queue MCEX12. Howver because these two structures are different which make the following job to extract the data in this outbound queue to RSA7 failed that we have to delete outbound queue MCEX12. That means we loose one day data. Do anyone knows on how to do the recovery of the missing data due to the deletion of the outbound queue and also the subsequent data load recovery on BW system to a DSO object within BI7.0 environment?

Anyone's idea is greatly appreciated!

[dennis_scoville4 · Accepted solution]

To recover the deleted data, you can do the following:

1) Determing the missing shipment document numbers that were missed due to this.

2) Delete the Application 12 setup table in LBWG.

3) Fill the setup table using the document numbers determined in Step 1).

4) Execute a Full Repair InfoPackage into the PSA.

5) Load the DSO with a Delta mode DTP.

Steps 4) and 5) should be done whilst the normal delta processing isn't occuring.

[Former Member · Accepted solution]

hi Dennis Scoville,

Could you elaborate on step 3) Fill the setup table using the document numbers determined in Step 1).?

What's this setup table name? What's the function of it? And how to fill up the setup table with the missing Delivery doc numbers in step 1)?

Thanks and Looking forward to seeing your reply very soon!

[dennis_scoville4 · Accepted solution]

Could you elaborate on step 3) Fill the setup table using the document numbers determined in Step 1).?
What's this setup table name? What's the function of it? And how to fill up the setup table with the missing Delivery doc numbers in step 1)?

Just want to make sure that we're on the same page...you ask how to fill up the setup table with missing delivery documents. However, the extractor that you mentioned previously is for shipments (they are different). The SD flow is typically Sales Order -> Delivery -> Shipment -> Billing.

For Logistics extractors, those that start with 2LIS_NN_XXXXX, setup tables are required to be filled on the R3/ECC source system in order to do a Full extraction InfoPackage in BW. Deltas are saved to different tables. The setup tables are filled by executing transactions in the R3/ECC environment. Most of the transactions are named OLI*BW, but there are some exceptions to this and shipment data is one of them. For shipments setup, use tcode VTBW. Some of the setup transactions allow filtering by dates and some don't. In this case, the shipment document is the only filterable field to use because it doesn't have both created on and changed on date (it has only created on date).

To be able to find the shipment documents, go to tcode SE16 and use table VTTK. For the selection, do two separate queries: 1) one with the date or dates that you're missing data in the created on (ERDAT) field; and 2) one with the date or dates that you're missing data in the changed on (AEDAT). From that, get the shipment document number range or ranges and enter into the VTBW filter for the shipment document number.

[Former Member · Accepted solution]

hi Dennis Scoville,

I searched on Google just now and find 2LIS_12_VCITM is Delivery Item related, therefore it's not Shipment. Therefore we should use table LIKP to determine the created/modified Delivery docs on the missing date. We did see some expert uses this setup table MC12VC0ITMSETUP as the setup table, but we don't know how this setup table was determined and the parameters in this table are the followings:

Area

ID for BW Reorganization

BIN4 data element for SYST

BIN2 data element for SYST

Have no idea how to fill up the above table with the created/modified Delivery docs during that day.

Thanks and Looking forward to hearing from you very soon!

[dennis_scoville4 · Accepted solution]

My mistake...You're correct it is Delivery (I'm having a really bad day and I'm sure my brain lapses aren't helping others).

For deliveries, the transaction for creating the setup table is OLI8BW. This has the capabilities of filtering on Sales Org, Company and Delivery (Sales Document is the actual description).

So, the best bet is to get the missing delivery document ranges from LIKP, using the same methodology I described for querying VTTK.

Edited by: Dennis Scoville on Jul 30, 2009 2:25 PM

[Former Member · Accepted solution]

Dear Dennis Scoville,

Now we've got question about step 4) Execute a Full Repair InfoPackage into the PSA. The InfoPackage upload mode was 'Delta', after we perform a Full Repair with the update mode as 'Full', and then if we change the upload mode back to 'Delta', then there will be no any problem, right?

Thanks and looking forward to hearing from you soon!

[dennis_scoville4 · Accepted solution]

Now we've got question about step 4) Execute a Full Repair InfoPackage into the PSA. The InfoPackage upload mode was 'Delta', after we perform a Full Repair with the update mode as 'Full', and then if we change the upload mode back to 'Delta', then there will be no any problem, right?

Instead of changing your existing InfoPackage, I'd suggest creating a new InfoPackage with Update Mode of Full. This will ensure that you don't have an issue with your normal processes (e.g. if you forget to change the Update Mode back to Delta).

Once you have executed the process to extract the data, as Full Repair, and load to the DSO, be sure to delete that PSA request. If you don't delete the Full Repair request after loading to the DSO, when the next delta InfoPacakge and delta DTP to the DSO are executed, it will not only pickup the delta InfoPackage, it will also pickup the Full Repair InfoPackage.

[Former Member · Accepted solution]

Dear Dennis Scoville,

After we run the Full Repair InfoPackage to load the missing data into PSA, then how would we perform the DSO DTP load?

1. DSO DTP Delta load? or

2. DSO DTP Full load with DTP Filtered with the missing Delivery doc numbers?

Could you let us know why if we don't delete the full repair request from PSA, then next delta load will not only pickup the delta InfoPackage, it will also still pickup the Full Repair InfoPackage?

Another question is how the data flow is in R3 ECC? the data flow is like this: delta data is in the outbound queue and then it will be extracted to RSA7 by the V3 job? If this is the case, then how to identify this V3 job name that we could manually trigger it?

Thanks a lot and looking forward to hearing from you soon!

[dennis_scoville4 · Accepted solution]

After we run the Full Repair InfoPackage to load the missing data into PSA, then how would we perform the DSO DTP load?
1. DSO DTP Delta load? or 
2. DSO DTP Full load with DTP Filtered with the missing Delivery doc numbers?

Use a Delta load DTP from the PSA to DSO.

Could you let us know why if we don't delete the full repair request from PSA, then next delta load will not only pickup the delta InfoPackage, it will also still pickup the Full Repair InfoPackage? 

When I said that, I was thinking about the case if you are initially loading the DSO from a Full DTP. While deleting the PSA was our way of ensuring the Delta DTP didn't pickup the PSA requests already loaded, another way would be to execute a Delta DTP with the Processing Mode in the Execute tab set to 'No Data Transfer, Delta Status in Source Fetched'.

After re-reviewing your scenarion, if you run a Delta DTP, there's no need to delete the PSA request because once the Delta DTP to the DSO is executed, it marks that PSA request as fetched.

Another question is how the data flow is in R3 ECC? the data flow is like this:
1. delta data is in the outbound queue and then it will be extracted to RSA7 by the V3 job? If this is the case, then how to identify this V3 job name that we could manually trigger it?

That is exactly the flow. You can manually trigger the V3 job via tcode LBWE. Set the Update Mode to Unserialized V3 Update and then schedule from the Job Control link.

[Former Member · Accepted solution]

Dear Dennis Scoville,

Another thing we could neglect that we only consider the new created/modified records for LIPS table during the missing date, but didn't consider the deleted delivery docs or part of their items. We can use tables CDHDR and CDPOS to identify the deleted delivery records on ECC, and then we need to delete the corresponding records from BI system. So we would have to set these deleted records in PSA with RecordMode = 'R' to make such deletions in BW?

Thanks and looking forward to hearing from you soon!

[former_member202718]

Hi Keith,

I agrre with Dennis ,but you may have to take a Down Time for this to Fill the Set up Table such that the Docs are not Altered during the Fill Up.

Regarding the Downtime ,there are lot thread avaliable.

Rgds

SVU

[Former Member]

hi svu123,

About "taking a Down Time for this to Fill the Set up Table such that the Docs are not Altered during the Fill Up", you mean not to allow users to work on any delivery doc during this Fill up on R3 system, right?

Really appreciated your input!

[dennis_scoville4]

It's not truly "down time", it's more like "quiet time" that's recommended, but not always possible. "Quiet time" refers to a period where there is no transactions or batch jobs executing that could update the shipment data while you're extracting the data. In your case, as long as you have the delta extraction job (e.g. V3 job) executing on the R3/ECC source system while you're executing the process to fill up the setup table, you shouldn't run into the potential issue mentioned because you'll be executing a Delta mode InfoPackage as some point after the Full Repair InfoPackage and will pickup the change made to the document.

Here's the link to a blog that I authored some time back that discusses this: [https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14695] [original link is broken] [original link is broken] [original link is broken];