Skip to end of metadata
Go to start of metadata

Queues view

Queue is created when a ODP datasource is created in any source systems.
Queue status gives us if the queue is active / inactive in the system. Queue can be become inactive when [any | one (?)] subscription is deleted.
Subscription gives the count of subscriptions and requests gives total number of subscriptions.
You can click on "Calculate Data Volume ( Extended View ) to see more metrics. The reason it is not checked is that it takes more time to show the view due to all calculations.

Subscriptions view

Subscriber Type
This is type of the source from which we are requesting data. BW, Data Service, HANA all can be the subscribers.
This is the name of the DTP ( for BW ) when technical name is switched on Or it will the timestamp on which the subscription is created.
Clicking on that subscription takes you to the list of all subscriptions for that datasource.
You can see on the top that 'Subscriptions' is greyed out which tells you which screen of ODQMON you are in.
Name of the subscriber. There can be multiple subscribers to a single ODP source. Below screen show has subscription from BW system.
No. of subscriptions for the datasource.
Last TSN confirmed
TSN : Transaction Sequence Number.
This is the timestamp when the request was completed.
Last TSN Requested
This is when the request came from the source. 

Requests view

Use Technical Names when reading data.
Composite Request

This is the DTP Request ID which initiated in BW by DTP. This can be found in DTP header details. If you switch off the technical names, you can see the timestamp in form
{2017-01-01 14:43:15 000009 EST} , else, you can see the DTRP_* ID .
Name of the DTP / Timestamp when it was created, when technical names off.
Extraction Requests
This has the timestamp when the request originated from the source.
Lower Limit for TSN
This is the timestamp of the last successful delta.
Upper Limit for TSN
This is when the new delta is triggered.
ODP does not capture timestamps of delta when 0 records are extracted.
eg : A DTP is run at 10 PM on 4th January,2017 and then at 9:AM , 12:PM, 4 PM and 8 PM on 5th January, 2017.
Delta 2017-01-04 22:00:00 had 10 records as delta.

Delta 2017-01-05 09:00:00 had 15 delta records
Lower TSN : 2017-01-04 20:00:00 Upper TSN : 2017-01-05 09:00:00

Delta 2017-01-05 12:00:00 had 0 records
Lower TSN : 2017-01-05 09:00:00 Upper TSN : 2017-01-05 09:00:00 - not 2017-01-05 12:00:00, because 09:00:00 was when delta records flowed.

Delta 2017-01-05 16:00:00 had 0 records
Lower TSN : 2017-01-05 09:00:00 Upper TSN : 2017-01-05 09:00:00 - Because that was when delta records flowed. The limits are same as earlier one.

Delta 2017-01-05 20:00:00 had 20 records
Lower TSN : 2017-01-05 09:00:00 Upper TSN : 2017-01-05 20:00:00 - The lower limit remains when the last delta with records to upper limit which is present timestamp.

Extraction Mode
Type of Extraction
Background Job
This is the job which extracts data . ODQ_<Date>_<TimeUTC>_<sequence>_C.
If any selections are present in the DTP

Units view

This is where you can see the the actual request data. This only has requests which had delta records.
Unique Time Stamp ID - TSN
The sequential transaction number (TSN) sorts transactions that write data to the delta queue into a defined sequence, with regard to delta replications. The TSN is set at the end of a transaction, shortly before the database commit, and then assigned to the transaction ID of this transaction.
Transaction ID
The transaction ID identifies a transaction from the perspective of the delta queue. The ID is assigned to the queue at the start of a transaction, in other words, before data from this transaction is written to the queue. Therefore the ID does not necessarily reflect the commit sequence when two transactions are compared. The commit sequence is only defined when a TSN is assigned at the end of a transaction, shortly before the database commit
It also gives Units, Rows, Size etc.
Double click on the TSN, and it gives you data this specific request has extracted.

Data is present in the queue depending on the "Reorganize Delta Queues" setting in the system.
Data can be retrieved as long as the request is seen but once reorg. delta queues are done, that delta will be missed.

Checking New Delta Records in ODP

For (some) of the regular datasources, when new deltas are generated, we can see them in RSA3. That is not the same for ODP datasources.
We need to see that data here in ODPMON.

Go to ODQMON -> Subscription. Here check 'Calculate Data Volume'.
If there are values showing up in the Units and Rows, that means that this datasource has new delta entries which can be extracted to BW or other source systems.
If it is 0, there are no delta entries generated after previous extraction.

If you want to see the records, double click in on the subscription and go to the requests and unit.
There is no pointer here to tell which transaction IDs are extracted in Target systems.
But, depending on the timestamps of the last extraction , we can see which of the TIDs are yet to be extracted.
TIDs are generated when there is a change in the system. So we do not have all the changes written to the same TID.
In the screen shot, there are 4 units and 20 Rows.
That does not mean, all the 20 rows are part of one TID. 8 rows can be written at one time and 2 at one time and 10 at the other time.
When it is extracted to BW, everything from the last run is extracted.
This is kind of similar to seeing data in RSA3, expect we cannot see all the data at one, instead checking individual TIDs depending on timestamp.

Do remember that if 'Calculate Data Volume' is not clicked, we do not see entries in the subscription screen.
<Originates from :>

Investigate failed requests in ODQMON

  • No labels