Enhancement doubts-- Ajay Das or anybody

[Former Member]

Hi all,

i was following a discussion about enhancement in which they mentioned about ALE Delta and change pointer tables

message types which i am giving below.

message type RS*nnn, MATMAS

TABLES: TBD62, BD52, BDCP

I think that when we say ALE delta it refers to master data delta...am i right

and what are these CHANGE POINTERS and the tables i mentioned.

Can somebody please explain me their role in delta and how and where are they associated and in which type of delta they play their role for eg: in master data or transaction delta if yes for transaction delta is it for all the application areas.

thanks and regards

Sreedhar

[Former Member · Accepted solution]

Hi Sreedhar,

I know the following tables and concepts, and are about Master Data extractors.

Change pointers are related to following tables:

ROOSGEN (where you find connection beetween DataSource and Message Type) and tables BDCP and BDCPS.

Here you can find all data about new and changed records to be uploaded into BW. A new record in these tables is added for every change in a field of the extractor for the related Master Data.

Ciao.

Riccardo.

[Former Member · Accepted solution]

Hi Riccardo,

thanks for the information, and i was really confident that their are many other experts and Gurus around SDN with lots of indepth knowledge thanks again. I have seen in one of the link of Ajay Das mentioning about these concepts so i mentioned his name, and i really appreciate your immediate help.

with your explaination.

Every master data extractor will have an entry when a change r a new record is created for the master data extractor in table BDCP and BDCPS (what is the difference between these two)

i am assuming that in these tables we will have the delta triggering fields recorded when ever some change happens they create a record. (am i right)

What is message type and how is that connected to datasource.

Because i have read in one of the link that if we add a specific field to these tables then they will also trigger delta and get records to the delta queue. (please clarify this point as well)

thanks once again.

Regards

Sreedhar

[Former Member · Accepted solution]

Hi Sreedhar,

The I do not know the exact difference beetween BDCP and BDCPS. I know that if a field is flag for delta you can, with the message, translate it into a field for delta activation, meaning that if this field change you have a new record in BDCP and in delta queue for the related Master Data.

All processed fields in BDCP have a particular status and can be deleted by the corresponding standard jobs that refresh BDCP.

If you want to know the steps for introducing new delta fields in a DataSource please write me to riccardoventu@virgilio.it, I will send you the related steps. Please write also the object of the mail and please wait forthe answer, because I have to translate all my documents.

Would you please send me also the documents or the link to the documents you have read about this enhancements.

Ciao.

Riccardo.

[Former Member · Accepted solution]

If you look at the description of the tables in SE11, it will help. BDCPS is for keeping the status of the change pointer, while BDCP is the main change-pointer table.

These table keep the key of the tables if a delta-able field is changed. (eg if you change material-group, the corresponding material no, alongwith time-of-change and other info will be stored; at the time of extraction, it will read data from the material tables based on this key value and create the delta record).

Every ALE (or IDOC) message has an identifier which tells receiver as to what type of message it contains. In case of master data datasources, message type tells what master data is being transferred (each master data is assigned a unique message type, you can probably see this in txn WE81 on source system).

The last point is true, under certain conditions. If the field is from the same underlying table (from which other delta-able fields are already triggering delta), and, it is change-log enabled (data-element property for this field), and it is also defined in BD52.

Let us know if there is any specific field/datasource that you are trying to work with and have similar issue.

[Former Member · Accepted solution]

Hi gurus,

Thanks for the info and i am keying down my understanding .

<b>For master data delta handling:-</b>

SAP has placed some fields in the Application tables with data elements change document enabled...that means whenever any change happens to this field that will be recorded in the BDCP and also this application table is also assigned a message type.. these fields are called change pointers becoz they hold the changes to the application table.

And every master data datasource is assigned to a message type, so when we trigger delta load from BW the system will check in the BDCP through concerned message type for the changed records and start pulling them to BW.

this the mechanism

so if we want to have delta automatically triggered then we need to add the field to the base table of the master data and see that its data element is change document enabled. then enhance it to the extract structure it will automatically pick the changes to the BW no need of user exit.

<b>One more addition to my question plz bare with me.</b>(if this is not related to the above topic plz inform me i will open another thread )

One more weblog i read and ...all these days i was thinking in the LO cockpit flow..only

Application tables, statistica tables, setup tables and

for delta....extraction queue, update tables, delta queue..comm structures but now i came across these CDHDR and CDPOS tables for i have read in Ajay Das weblog stating them as change document tables. what role do they play and when do they come into picture.

thanks and regards

SReedhar

Message was edited by: Sreedhar M

[Former Member · Accepted solution]

Your understanding on how delta for master data works is correct.

On your question of change document tables -

- These are tables that capture all the change information for important application data. Eg if a purchase order is changed, you see the new values in the corresponding txn (say me23), however it is important to keep the history of change (who changed it, what was earlier value, when was it changed and so on). Change document tables store this history. Since it is resource consuming (DB space as well as CPU time to update these additional tables), these are used only if the data is important (which you decide at design time by enabling change-log flag on table and data elements).

In general, these tables are used to store and display changes to data. In addition, ALE uses it to create IDOCs out of it (for master data) for sending it to other systems.

What all has been mentioned above is true in source system context, not related to BW (ie all this is done even when there is no BW).

In the weblog where you might have seen it mentioned, it is used to determine/find when a custom (Z*) field was modified. Since a custom field won't trigger delta (and the assumption was that it was txn data, not master data which uses ALE/Change-pointers - txn data doesn't use change-pointer mechanism for delta), the workaround was to read the change-document tables to find if this custom field has been changed and if so build the record for extraction.

That (what is in that particular weblog) is only one of the few options to record delta for custom fields.

In brief, change-document tables are not specific for BW extraction, these are there in source system for many uses; and if you need to build a logic to process history data and there is no other option, you can look into these tables for such info.

Let us know if you have further queries on this.