cancel
Showing results for 
Search instead for 
Did you mean: 

Delta queue with transparent tables based on table data changes

Former Member
0 Kudos

Dear all,

once, I was able to find a document (maybe a how-to, if I'm not wrong) that covered a very interesting solution, that I need to implement due to a specific requirement.

Let me explain what's the catch.

In the source system (SAP based), there's a couple of tables that have an unsorted key but doesn't have dates or timestamps. I need to retrieve the information from such tables with a delta procedure. Due to the lack of delta supporting fields, I can't enable generic delta or even FM-based extraction.

The solution I saw once, suggested that Source System's tables could have the change log enabled from within the data dictionary (SE11) and then, that data change monitoring could be coupled with the delta queue mechanism (tRFC or qRFC enabled).

Could you, please, help me with that subject or, if possible, try to recover the document that explained that? Be sure I have put all my efforts trying to find that doc. by myself.

Many thanks,

Michel

Accepted Solutions (1)

Accepted Solutions (1)

m_verbaan2
Active Participant
0 Kudos

Hi Michel,

I'm not aware of any document but I made use of such a delta-mechanism a couple of times. Be aware that you should not use it for large tables or tables of which the content changes a lot (inserts/modifications/deletions). The system will create many huge logs which will consume a lot of disk-space.

Procedure:

1) Activate the logging on your table (SE11 -> enter table name -> go to Technical settings -> flag 'Log data changes')

2) Create a Generic DS based on FM (should be possible!) but do not touch the delta functionality; this has to be build into the FM

3) For the FM e.g. use a copy of RSAX_BIW_GET_DATA_SIMPLE

4) Customize the code to your needs; in the first call fetch the data from the change logs using FM DBLOG_READ_WITH_STATISTIC

5) This FM has dates and times as import parameters. As you don't have them you could create a Z-table in which you keep track of the extractions done. For the next load you then exactly know which logs to fetch (since stored date & time of last load).

Hope this helps you getting up to speed! It's a bit of a hassle but once set up will work fine.

Grtx

Marco

Former Member
0 Kudos

Marco,

many thanks! I'll give it a try.

Many thanks!

Former Member
0 Kudos

Marco, many thanks for your hints.

It has worked, although:

- Basis has to activate the DB logging in our system. This is something yet to be reviewed with them. Otherwise, no DB changes will be captured.

- The document/presentation I saw once, proposed a more sophisticated / elegant way to post the changed entries into the change log, in a simmilar way the LO extractors work (V1 updates), considering xxHDR & xxPOS tables, where the changed entries are collected into a tRFC/qRFC queue.

Anyway, points awarded.

If somebody else has this document, please, let me know. I'll be thankful for any tips on that.

Best regards,

Michel

Answers (1)

Answers (1)

former_member205352
Active Contributor
0 Kudos

Just checking :

You seem to be talking of numeric pointer concept of enabling delta.Is it ?

Former Member
0 Kudos

Nope. Unfortunately,there's no way to use a numeric pointer, as it's an unsorted key.

Let me add something: the key is randomly generated... just to make things more complicated.

That's why the solution proposed by Marco sounds good (and in fact, it's very close to what I saw in the past - I'll give it a try first)

Thanks