Below is the view of ODQMON.
Queues
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
This is the source from which we are requesting data. BW system is a subscriber.
Subscription
This is the name of the DTP ( for BW ) when technical name of switched on Or it will the timestamp on which the subscription is created.
Clicking on subcription takes you to the list of all subcriptions for that datasource.
You can see on the top that 'subscriptions' is greyed out which tells you which screen of ODQMON you are in.
Subscriber
Name of the subscriber. There can be multiple subscribers to a single ODP source. Below screen show has subcription from BW system.
Subscription : Name of the subscription. In case of BW, it would be name of the DTP created for the source.
Requests
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
Other fields give info.
Requests
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 .
Subscription
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.
Point-To-Remember
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 : 2018-01-05 09:00:00
Delta 2017-01-05 12:00:00 had 0 records
Lower TSN : 2018-01-05 09:00:00 Upper TSN : 2018-01-05 09:00:00 - Because that was when delta records flowed.
Delta 2017-01-05 16:00:00 had 0 records
Lower TSN : 2018-01-05 09:00:00 Upper TSN : 2018-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 : 2018-01-05 09:00:00 Upper TSN : 2018-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.
Selection
If any selections are present in the DTP
Units
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 sequential transaction number 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 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 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 check individual TIDs depending on timestamp.
Do remember that if 'Calcualte Data Volume' is not clicked, we do not see entries in the subscription screen.
