ALE/IDOC: Change pointer for transactional and custom data

[Former Member]

Dear Experts,

I am supposed to create change pointer for transactional and custom data.

Can anybody kindly guide how this can be achieved.

(If this cant be achieved kindly guide why).

Thanks,

Sanjay

[former_member823402]

Hi Sanjay,

The change pointer concept in SAP is related to tracking the change log of master data in SAP.

For tracking the changes to the transactional data, SAP has provided the concept of Change Documents. ( CDHDR / CDPOS )

Kindly refer the below link for more details on Change Pointers.

Change Pointer (Master Data Distribution) - IDoc Interface/ALE - SAP Library

Hence if you want to track the changes to transactional data kindly refer to the below link for creating changing documents.

Logging Using Change Documents - Auditing and Logging - SAP Library

The reason why we use Change Pointers for master data and change documents for transactional data is due to the frequency of changes.

i.e.

Master data is created once and changed less frequently.

Transactional data is created & changed more frequently.

Regards,

Bhawit Kumar

[Former Member]

Thanks for kindly replying.

Even change pointer for master data uses CDPOS/CDHDR/BDCP tables.

Can you kindly guide weather change pointer is meant only for MASTER data?

[Former Member]

Hi Sanjay

If you are referring to some Z fields by "custom data", well in that case you also need to activate change pointers for those required Z fields..

Briefly steps are :

Change document needs to be activated at data element level

Change document object & update program needs to be created.

Develop logic and use update program to write changes to CDHDR & CDPOS.

Develop program to fetch change details and generate IDOC.

Usually for standard message type/basic types all above steps are already taken care by SAP (BD21). For custom requirement you might need to design things from scratch.

BR

Ansumesh

[Former Member]

Thanks for kind reply.

Is creating transactional/custom entry in CDPOS/CDHDR sufficient to trigger change pointers?

Custom records entry can be created using SCDO.

[Former Member]

Change pointers trigger, if change document attribute at data element level is activated for the respective fields that are to be tracked.

But to write change history to CDHDR/POS, one has to create change document object (at SCDO) for the changed fields and generate a update program.

After that update program/FM can be used further to actually writing the changes CDHDR/POS.

Information given here is with respect to change document. Remember there is good amount of differences in between change pointer & change document. From IDOC perspective the process is absolutely different from Change document.

BR

Ansumesh

Message was edited by: Ansumesh Samal

[Former Member]

Hi,

change pointers are there to track changes. mostly used to track DB-Changes. The Field Processed in BDCP2 shows you what change is new and hwat change is already processed. there are several FMS such as "Read new changes" and "set processed flag"

You need to know the tables CDHDR CDPOS and BDCP2.

Also you need to know the Transactions SCDO, WE81, BD50 and BD52.

Fubas of Function Group SCP1 and BD01.

you can create change pointers directly with FM CHANGE_POINTERS_CREATE_DIRECT

or use the change pointer object generic FM to create change pointers from change pointer objects.

regards

Stefan Seeburger

[Former Member]

Thanks Stefan.Does above reply mean change pointers are possible for transactional data and custom data both?

Can you kindly explain a bit about the coding required around the function module CHANGE_POINTERS_CREATE_DIRECT.

Also can you kindly guide how CDPOS/CDHDR and BDCP is to be used along with SCDO for change pointers?

[Former Member]

Hi senjay deshpande,

the standard usage of changepointers is to track db changes automatically. changes on standard tables are tracked by standard change objects. All dataelements that has to be recorded have to have the flag "record changes" enabled.

When you have a z-table. You can achive the same when defining z-change-objects.

you can also call the FM ZXXXXXXXXX_WRITE_DOCUMENT (XXXXXX = CHANGE_DOCUMENT) in your own transaction to create a new entry for change_object. You support the old values and the new values and the Fuba creates all the records for all linked CHANGE_POINTERS (MESSAGE-TYPS) in CDHDR CDPOS BDCP2.

You can also just create the change_pointer-records (Message_type-recoords) BDCP2-Records when calling CHANGE_POINTERS_CREATE_DIRECT. But then you do not have CDHDR and CDPOS entries.

But you are also able to read the chenge_pointers from BDCP2 via CHANGE_POINTERS_READ

and set them to processed with CHANGE_POINTERS_STATUS_WRITE as when having the whole Object created via transaction SCDO.

CHANGE_POINTERS_CREATE_DIRECT is easy to handle since you just give the values that you want to be shown in BDCP2-Tab   

      ls_bdi_chptr-tabname = 'test'. "or Tabname if you have 1
     ls_bdi_chptr-fldname = 'KEY'.
     ls_bdi_chptr-cdobjcl = 'test2'. "or change_pointer Object if you have 1
     ls_bdi_chptr-cdchgid = 'I'.

So yes you are also able to track "transactional data" and you can decide to just use it as a framework to track things, or to look up the old value befor the change.

regards

Stefan Seeburger

[Former Member]

Hey JD,

Were you able to implement change pointer for transactional data.

I too have a similar requirement for triggering an idoc when some specific fields of order are changed.

the requirement is to use only change pointers and no NACE thing...

so if you could elaborate on how did you achieve this , it would be of great help..

thank you in advance!

Regards,

Sukhada S

[Jelena_Perfiljeva]

sukhada sheth wrote:

Were you able to implement change pointer for transactional data.
I too have a similar requirement for triggering an idoc when some specific fields of order are changed.
the requirement is to use only change pointers and no NACE thing...

JD has not logged in on SCN since July 2015. Also we are not supposed to "piggyback" our questions on the old discussions and need to open our own in case our question is not answered by the existing posts on SCN.

However, this idea is just fundamentally wrong. It's like saying "we need to cut down this tree, but instead of using an axe or a saw (which we already have and they work fine) we must use a hammer (that we don't have, so will need to run to the store to buy it)".

For transactional data we have change documents and changes are distributed using output. This functionality works perfectly fine in SAP. Change pointers (not to be confused with change documents) have nothing to do with the transactional data. You might want to go back to whomever came up with this suggestion and ask them what is a specific reason they must use a hammer instead of a better tool suited for the job.

[Jelena_Perfiljeva]

To my knowledge, change pointers are used only for master data (it's distributed by ALE differently than transactional data). Transactional data (custom or not, I guess the same technology would apply) is likely using change documents but not change pointers. You could look at how this is implemented with the ORDCHG IDoc, for example, and purchase orders.

There is a good book by Arvind Nagpal that covers pretty much every possible aspect of ALE/IDocs. Also look up 'IDoc Cookbook'.

[Jelena_Perfiljeva]

There is plenty of information already out there on the change documents, just search in Google.

You might want to clarify what transactional data you mean exactly. From my experience, change pointers are a pain in the back. They take up space and then somehow disappear and you end up spending the whole day investigating. As I've mentioned, transactional data is usually distributed differently, using output that is created when transaction is saved. So there is simply no need for change pointers even if it's feasible to bolt them on, so to say. Just because something is available doesn't mean we have to use it.

Perhaps whoever came up with such requirement didn't even know the difference between change pointers and change documents.