Checking ODQMON for datasource loads

 Goal:

In this post we will look at a live scenario to load from business content datasource to BW and monitor the load in ODQMON like FULL, INIT,DELTA and REPEAT DELTA

Step 1: Activate your standard datasource in your ECC system

Go to transaction RSA5 in your ECC system, select this datasource and press 'Activate'. This step is similar to what we do in BI7

Step 2: Empty the set up tables in your source ECC system

Before loading full or init for this datasource, make sure the set up tables do not contain any data.

Go to transaction LBWG, give application as '11' and delete setup tables

Step 3: Fill set up tables

Go to transaction OLI7BW and fill the set up tables. You can give the following selections for filling the set up tables-

Step 4: Check your data in RSA3

Once the set up tables are filled, you can check in RSA3 where it will fetch some records from the set up tables.

Step 5: Replicate your datasource in BW.

Step 6: Activate your datasource

Step 7: Create a data flow with adso as target, transformation and DTP. Select adso type as standard dso. Save the data flow. Activate all your objects

Step 8: Run the delta DTP.

The first time run of delta DTP is Delta init and it fetches the records from the set up tables.

Once you run the delta DTP, it will automatically create a subscription in ODQMON with the DTP id.

Go to ODQMON transaction in your source.

Select the queue name as '2LIS_11_VAHDR". Double click on the queue to see the details.

You can filter the DTP name to select the relevant queue related to your DTP only. Tick the checkbox "Calculate Data Volume (Extended View)" to see the number of records and compression factor.

Step 9: Once the Delta init is completed, you can see the subscription and other details in ODQMON as well as you can see the details of DELTA INIT in the table ODQDATA_C.

Step 10: Trigger the Delta using the same DTP in BW side. Observe ODQMON.

You will observe that an new request is created in the same queue and subscription. But this time the storage is in table ODQDATA

It is important to understand the delta functionality here.

Once the orders are changed in source the changes go to application tables and extraction queue (SMQ1 in general or LBWQ for LO)

Once we run the V3 job, the changes come from extraction queue to delta queue if there is already a subscription for that queue.

The delta queue here is the table ODQDATA.

This data is retained for some time period and can be reextracted if delta failes in BW side. Delta DTP can be run again to fetch this data.

You can manage how long to retain the data in these queues by going to setting Goto- > Reorganize delta queues

Please note also that there is no background job created for the delta requests.

Job is seen only for init and Full requests.

Comments

Popular posts from this blog

Domains and Data Elements

Sample ABAP program for Updating notepad file data to Internal table and Sending it to Application server

OPEN SQL EXAMPLES IN ABAP – PART 2