Skip to Content

How to process subscription manually from ODQMON

hi all,

I had done streaming for one of the chain for one week it was working fine but suddenly after few days it started to fail with error message Invalid entry TSN_CONFIRMED>TSN_REQUESTED , operation open_delta_no_data could not be done.

-> current system working on BW/4HANA 1.0

is there any way to process these subscription manually from source ODQMON as i checked in queue it looks fine but not sure why streaming does not work.

if there is a way it will save lot of time and effort by not doing re-init instead resuming the stream

-laksh

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Sep 13, 2018 at 09:17 AM

    Hi,

    I wrote a whole bible about the issue and then I found this SAP Note: 2625466 - Creation of DTP Realtime request based on ODP source fails with exception. This is a correction for this issue, it looks like it already happened in the past xD

    To anyone who may be interested... or if you need to troubleshoot this despite the Note...I made my remarks considering the ODQMON perspective, I am not an expert in WHM (Process Chains, streamings etc).

    Firstly, check the message you are receiving:

    a) "Invalid entry TSN_CONFIRMED>TSN_REQUESTED" = this means that you are requesting a delta from a time in the past where delta data was already requested and loaded. If this subscription has a TSN for "the past", the mechanism would be totally messed up if allowed this action. Explanation: TSN sorts data written to the Queue in a sequential manner, so it cannot allow a delta data to be written in an space that is already occupied (even if it is not there anymore, for example, a space occupied chronologically).

    b) .... "operation open_delta_no_data could not be done" = it is trying to say there is no more data here to load - it is not an feasible TSN pointer anyway so "the program" cannot explain why at this stage, however, these kind of error messages are improved often and you can have Note 2622317 applied for taken advantage of that. c. "is there any way to process these subscription manually from source ODQMON ?" = from where I stand , I would be interested in set the pointer in ```TSN_REQUESTED`` to the right position ( == or > to ``TSN_CONFIRMED``), OR , TSN_CONFIRMED <= TSN_REQUESTED (which probably will cause duplicated data and i can think about tons of issue with consistency...so opt for the first one) .

    -> Before changing anything, I would check if data starting with this TSN pointer is already in BW (check job in ODQMON vs. Request monitor, it looks like this load is there already but is not the current one (which is failing). If it is, you could delete the requests from this point and forward and perform this load again.

    I hope I understood you well when I say request and not subscription. You can have several similar subscriptions, but within one, you will have the requests. They *must not overlap*. However, this call for data is done from BW side and it is done only if when new data is available to be picked up.

    -> This made me think that you have a request failed in BW (from now on I was pointing out possible rootcause, which doesn`t matter much since I found Note 2625466 above. This hypothetical request got into source system, the job ran there fine, but didn`t god concluded in BW (due a timeout for example! it will finish on source and set the TSN, but in BW, the load will remain with the old TSN that wasn`t successfull. When new data is post, BW goes there using that old TSN failed, and then a lot of inconsistencies start to occur (God knows to which extension). If there is new info in ODQDATA, the Realtime daemon will Inform subscribers (BW) about new data and update ODQ-tables (like ODQSSN and ODQREQ). I advise to check their consistency in ODQSSN - is TSN_REQ = TSN_CONFIRMED?. What are the values you see as last one for each ? they probably differ in seconds due to job selections parameters.. If the request failed - we can keep this going forever btw - why there was not a delta repeat? Did someone set it to green (noooooo pls) ?, why the PC execution was allowed to continue if there was a failure ? and so on ...

    Feel free to share your doubts, and kindly the results so I get to know the end of the history ..

    Cheers!

    Add comment
    10|10000 characters needed characters exceeded

    • HI Tania,

      Thank you for providing useful and insightful details.

      following are observations and which i saw when the issue started

      1) set the pointer in ```TSN_REQUESTED`` to the right position ...... How can i Do it ??? this is question i have in mind is is there any way by which i can manually update via FM/prog somewhere a table entry in backend for TSN_REQ and TSN_CONFIRMED as i dont find anything in RSPMREQUEST

      2) I advise to check their consistency in ODQSSN - is TSN_REQ = TSN_CONFIRMED?. What are the values you see as last one for each ? they probably differ in seconds due to job selections parameters.... YES the values i saw were different, I dont have latest error message but here is sample error which i got when i saw issue for first time. but there is no difference in job selection parameters

      3) If the request failed - we can keep this going forever btw - why there was not a delta repeat? Did someone set it to green (noooooo pls) ?, why the PC execution was allowed to continue if there was a failure ?

      PC got failed; its execution was not continued, when we got this error ; we deleted the red request and repeated the DTP but it failed with same error msg

      4) kindly the results so I get to know the end of the history ..

      I had no choice but to re-init again which is very irritating and frustating as it took one weeknd of mine

      dtp-error.png (101.7 kB)
  • Sep 25, 2018 at 03:13 PM

    Hi! Look what I found yesterday.. 2157434-"RDA_START fails with: Pointer {...} must first be closed" << this makes a lot of sense. It states the open_delta_no_data as well but just information, no code correction... check it out later on.

    Now, talking about business............. TSN_REQUESTED ... so, to put it manually, then you will need the note I gave before ( 2625466 ) - from official point of view. The code of the note shows the correction to the issue.. now it assigns to the TSN_CONFIRMED the same value as TSN_HIGH, before wasn't like that so it looks like some delay could ended up generating a 'bigger value' in the end.. So, if you change it manually in table ODQSSN, it won't help because is the framework that writes in the table.. and that is true for the opposite. The subscriptions won't get updated after the entries used in the code change.. (which are the entries of the table).

    Creating something yourself it will be a very messy so I don't believe that even customizing you will get that. If I didn't have that code, I would delete every request that failed and in the DTP, put the delta pointer.. we do that to debug from BW to Source. So let's say you have everything deleted,you might trigger another init with the pointer of ODSSN last TSN_CONFIRMED = TSN_REQ, but that would be opening the door for inconsistency as well... look how many places (and I didn't even checked everything) you can see this data:

    and last, but not least (it was a quick analysis in my test system, nothing huge):

    As you can see, change those things manually is not something trivial (in matter of consistency).

    Please bear in mind that such change would never be recommended. I just used your example to analyze a little further how the pieces are brought together.

    By looking the code correction from Note 2625466, it avoid it to happen 'now' because it the update of ODQSSN only happens if current tsn_confirmed is not higher than the current requested.

    Let me know if something wasn't clear, it was a big brainstorming :D

    Cheers!


    Add comment
    10|10000 characters needed characters exceeded