Change Pointers and Recovery Index

Hi,
Please give me any more details/docs/links about the Recovery index,indexing and Change Pointers.
Is there any configuration needs to be done for change pointers and indexing.
Regards,
Krishna

hi,
can you provide some more details.
which change pointers (and (reduced) message typesdo you mean?
regards,
Ralf

Similar Messages

Regd. change pointers and notifications

Hi,
The question might sound a little too broad.
But bear with me...Just give me a brief overview,
of how do I go about using change pointers....
Just correct me if I am wrong.
We create a change document object in the system, or use an existing one. About pointers I am not sure.
Then, through SPRO and ALE we activate the change pointer for some message type. then....??

Hi,
I haven't done this in a while, so please check my answer!
1) You activate change pointers in general in one transaction (I think it was BD61, but I'm not sure)
2) Then you activate them for certain master data (i. e. material, customer, ...) in another transaction which I don't recall atm.
3) Every time one of those master data objects is changed, the system generates a "change pointer", which you can basically just think of as an entry in a transparent table, which includes the type and key of your master data object (such as e. g. the material number).
4) You plan a background job which will go through those change pointers and which will generate a master IDoc (e. g. MATMASxx) for this data object. The change pointers are then reset (i. e. every item will only be sent once).
5) Depending on your ALE customization this master IDoc will be sent to a remote system.
You can refine this scenario using quite a bunch of different techniques. One of them is filtering (e. g. only materials with a certain material group, or based on classification etc.). Other options are reducing the Master IDoc, e. g. sending only relevant data instead of the whole master IDoc. There are even a few customer exits, if that doesn't suffice.
Hope that helps (please reward me if it does)!
Regards, Joerg

Change pointers and RFC

Hi All,
Is it possible to implement change pointers without creating idocs, but with only RFC's.
Actaully i am goign through aproject document which says the interfaces are implemented using change pointers and BADI's.I was in a understandign that there would be idocs created to communicate the master data changes to other systems.
But one of the person who involved in the interface development said that there are no idocs related involved related to the interfaces, its all RFC's enabled.
Can anyone please let me know if change pointers can also be implemented using RFC.
Thanks in advcane.

Hi,
this is described sufficiently in SAPHELP - in a nutshell:
Changepointers - as the name says - point at changes (change documents). Therefore the creation is together with change documents (at the end of FM CHANGEDOCUMENT_CLOSE.
Chane pointers are created for ALE message types (tcode WE81). This does not mean, that any ALE message has to follow - there might be another subsequent action.
Writing of CP must be enabled with BD50. With BD52 the tables/fields are customized. Precondition is, that the data element of the table field is enabled for change documents and that change documents are created. BADI
BDCP_BEFORE_WRITE allows further refinement (or any other action triggerd by the change). Note that both - change documents and CP - are created in update task - so you have to activate update debugging to see it in debug.
Storage of CP is in table BDCP2 (since release 7.00 former releases use BDCP and BDCPS). Read pointers with FM CHANGE_POINTERS_READ and set them to processed with CHANGE_POINTERS_STATUS_WRITE. If more than aprox. 1 Mio. pointers are read an overflow may occur - use CHANGE_POINTERS_READ_MODE_SET to set an appropriate block size and CHANGE_POINTERS_READ_INFO_GET to stirr the further processing. All FM are documented sufficiently.
Have fun!
hp
Edited by: Holger Pakirnus on Sep 14, 2011 3:58 PM

Idoc Conversion rule, Change pointers and Filters

Hi Experts,
Please any one can help me out, i need material or clear picture about Idoc Conversion rule, Change pointers and Filters where we can use these concepts what is the befit for these concepts.
Thanks in advance,
Ramesh.

Hi,
Check this link. It has got some of the tutorials you are looking for.
http://www.****************/Tutorials/ALE/ALEMainPage.htm
Cheers
VJ

Change pointers and Idoc creation

Hello,
I would like to create change pointers for any changes regarding one of our customer infotypes: 9002 (hrp9002)
I was able to do that, however, I'm struggeling with the details.
The problem is that I do not want to send any data related to infotype 9002. I just need this change pointer to trigger idoc creation for the related objects.
Example: Let's assume that infotype 9002 gets created for position S 40001234. Once a night a customer report is executed via a job which reads all unprocessed change pointers (including the one mentioned above) and sends the corresponding object. In this case, an Idoc for the holder of position 40001234 should be created WITHOUT data for infotype 9002.
The message type is HRMD_A.
What do I need to do?
Thank you for your input.

Hi,
For Info type 9002 we need to implement Badi HRALE00CHANGE_PTRS using below code.
   LOOP AT t_changed_objects INTO   wa_changed_objects .
    CASE wa_changed_objects-infty.
      WHEN '9002'.
        wa_cp_data-tabname = 'HROBJINFTY'.
        wa_changed_objects-plvar = '01' .
        wa_cp_data-tabkey = wa_changed_objects .
        wa_cp_data-cdchgid = 'U'.
* wa_cp_data-CDOBJCL = 'HRMD_A'.
        APPEND wa_cp_data TO t_cp_data1 .
    ENDCASE.
ENDLOOP.
IF t_cp_data1 IS NOT INITIAL .
    CALL FUNCTION 'CHANGE_POINTERS_CREATE_DIRECT'
      EXPORTING
        message_type          = 'HRMD_A'
      TABLES
        t_cp_data             = t_cp_data1
      EXCEPTIONS
        number_range_problems = 1
        OTHERS                = 2.
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.
ENDIF.
This code will create entry in BDCP2 table.
After thsi populating segemnet you need to code for below exit as .
EXIT_SAPLRHAL_003
   IF PNNNN_NAME = 'P9002' .
*FIELD-SYMBOLS: <FS_plog> TYPE ANY.   "Field Symbol for dynamic filling of data based on the structure
*Clearing the SUBRC
CLEAR SUBRC.
* fill workarea for infotype with infotype-data
ASSIGN pnnnn_data TO <FS_plog> CASTING TYPE P9002.
LS_9002 = <FS_plog>.
* move fields
MOVE-CORRESPONDING LS_9002 TO LS_p9002.
* fill IDoc-data with workarea for segmenttype
ASSIGN sdata_data TO <FS_plog> CASTING TYPE Z1P9002.
<FS_plog> = LS_P9002.
CONVERTED = ZCDP_IF_CONSTANTS_DTIRIS=>GC_CROSS .
ENDIF.
It will work fine.
Thanks
Anju

Attribute / Hierarchy Change Run and BWA Index

HI!
During my analysis to the perocess chains in our BW/BWA systems, I noticed that Change Run either rollup or update BWA indexes. I am not sure what Change Run exactly does for the indexes, so if you please can help in that it will be great. because we are inpecting that this may caused us a failure in BWA indexes before.
Thanks,
Ghassan Matar

Hi,
Kindly go throught the following link to more about the Hierarchy/Attribute Change Run in BWA indexes,
http://help.sap.com/saphelp_nw70/helpdata/en/9a/e1914206d7a970e10000000a155106/frameset.htm
Regards,
Balajee

Changing primary and recovery email addresses

My primary email address is now defunkt and i am no longer able to check it. iTunes will not let me change it to my current email address since it is listed as my recovery address. I have read all previous posts about this, but nothing seems to work because Apple has sent me a verification email to my old email address and will not let me to continue on to my account until it is verified.
Since I can not verify my old email, or change it to my new email, what am I supposed to do? It looks like I have to create a new email just for apple to be able to work around all this "security" nonsense.

http://forums.adobe.com/community/download_install_setup/creative_cloud_faq
-has a link to manage your membership which may help

Change Pointers - adding a new field to existing Change Document

Hi,
We have a requirement to capture the changes made to the Material object through the transaction C223. The changes to field MKAL-PRFG_F have to be captured.
There is an exisitng Change Document Object - MATERIAL. This is included in Message Type MATMAS. These are the steps we have done:
1. In SCDO - added the Z structure to the Change Document Object - Material. [Z structure contains the field MKAL-PRFG_F. Change pointer option is checked for this Data element.
2. Created a Z Message Type with reference as MATMAS.
3. In BD52 - we have listed the fields for the new Z Message Type created.
4. The Change Pointers - reactivated after the steps are done.
The changes to the field MKAL-PRFG_F through C223 Tcode are not recorded in BDCPV table.
Have we missed any steps here?
Thanks,
Pallavi

HI,
I don't think a new zmessage type is required in this case.. is the structure added to MARA table??The change document programs are there which triggers the iodcs... In SCDO transaction code , click on generation info for MATERIAL.. You will find the includes. The FM MATERIAL_WRITE_DOCUMENT creates entries in CDHDR and CDPOS, if we maintain entries in BD52 , the entries wil be written in BDCP and BDCPS tables.
Try to add your structure in MARA table as append strucre and then you can debug the IDOC from WE19 and use the FM "MASTERIDOC_CREATE_SMD_MATMAS" and then you also need to switch on Update Debugging on, to debug the changes in update FM MATERIAL_WRITE_DOCUMENT.
Please see if the change is reflected or not....
ELSE.
may be you need to create a new entry in SCDO and do all the ALE configurations for change pointers.
Please find the link for change pointers and also you can get lot of information on change pointers in SCN.
http://help.sap.com/saphelp_nw70/helpdata/EN/12/83e03c19758e71e10000000a114084/content.htm
Regards,
Nagaraj

PU12 or Change Pointers - which is better

Hi all,
Our Req is to track the changes in the infotype records which are valid as of today. The Receiver system would hold only one record at any point of time and it is valid as of today. But the sender system (SAP) may have Future or Past dated records.
Our approach for this would be using PU12 or Change Pointers.
If anyone of you worked with Change Pointers and/or PU12 for building interfaces from SAP to external systems using XI (proxy class calls), pls respond with the following queries.
--> Which one of these is a better approach?
--> In case of Change Pointers, how have you tracked and exported future dated and active back dated changes to the external interface.
--> Did you face any limitations with PU12/ Change Pointers approach.
Any help regarding this would be of great help.
Regatds,
Teja.

I don't know what PU12 do, but change pointer used to distribute only Master data.. Change pointer only generate an Idoc only for the changed fields rather for all the fields in idoc type..

Deletion change pointers are not going to ECC after C5

Hi,
My issue is that I am running C5 after Planning run.But deletion change pointers are not going to ECC.Because of this we have duplicate of orders in ECC.We are running CCR to bring back the "Planned orders with deletion change pointers and deleting again using RRP4.Why deletion change pointers are not going along with creation change pointer?Help will be highly appreciated.
Thanks&Regards
Venkadesh

Hi,
Check whether you have enabled the " delete events" check box. This check box will be valid if you are publishing the planning results thru background job.
If you set this indicator, the system deletes all selected change pointers without sending them first.
Thanks,
nandha

Reprocessing change pointers for MATMAS idoc

Hi
I have a situation where i executed BD21 for changes to materials but no idocs were created due to some issue with the distribution model. Now i have fixed the issue and would like to re process all the materials which were changed. Since i have already executed BD21, now no new idocs are being generated. Is there a way to reprocess the changed materials and generate the idocs again.
Thanks
Nag

Hi Roger
Thanks for your inputs. I am trying to generate idocs through the change pointers and not using output determination.
When i executed BD21 the first time, idocs were not generated due to some config issues. But the job ended successfully saying that idocs were generated and marked all the changed material documents under change pointers (But in WE02, the idocs never showed up actually).
Now i have fixed the issue in config and want to generate the idocs using the change pointers. Is there any way to regenerate the same idocs using BD21 or some alternative.
Thanks
Nag

HR Infotype change pointers

Hi Friends,
I have been trying to find how to activate the infotype change pointers and I could not find any helpful thread in this forum, in my case the program RPUAUD00 does not return any change logs.
Could someone please tell me how to activate the change logs for all the HR infotypes?
Thanks,
Muktar

OMG it's weird!
I guess maybe you miss some steps in configurations.
Please refer link blow: Re: Report for logged changes in infotype data
and http://sap.ittoolbox.com/groups/technical-functional/sap-hr/infotype-audit-log-2322026
Hope you can solve your issue soon, because it's really important report
Good Luck!
Woody.

Change pointers in ALE/IDOCs

Hi guys,
Can any let me know step by procedure to implenent change pointers using IDocs including ALE settings as i am new to this concept.
Any step by step example will be helpful. useful answers will be rewarded.
Thanks in advance.
Regards,
vinay

Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
To generate the IDOCS in case of change pointers we need to use the standard report
RBDMIDOC
we need execute the follwing t.code
BD61:to activate the change pointers globally
BD50,BD52: to activate message types ,and to enable the fileds for change pointers
Hope this link will help you regarding Change Pointer...
http://help.sap.com/saphelp_erp2005vp/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Change Pointer Configuration and extraction in HRPay.
Infotypes to be logged are in:
V_T585A,
V_T585B,
& V_T585C
Please view the table contents to understand the structure of these tables and how they are linked. These help you identify the cluster tables which store the data.
Payroll Cluster Table PCL4 contains the cluster table reference. (Please refer to the table structure below:
Payroll Custer Tables
http://www.planetsap.com/HR_ABAP_payroll.htm
Cluster tables combine the data from several tables with identical (or almost identical) keys into one physical record on the database.
Data is written to a database in compressed form.
Retrieval of data is very fast if the primary key is known.
Cluster tables are defined in the data dictionary as transparent tables.
External programs can NOT interpret the data in a cluster table.
Special language elements EXPORT TO DATABASE, IMPORT TO DATABASE and DELETE FROM DATABASE are used to process data in the cluster tables.
PCL1 - Database for HR work area; (long text, etc)
PCL2 - Accounting Results (time, travel expense and payroll); (payroll results)
PCL3 - Applicant tracking data;
PCL4 - Documents, Payroll year-end Tax data (change logs, etc)
Database Table PCL4
The database table PCL4 contains the following data areas:
LA change logs (long term documents)
SA Short-Term Documents for HR Master Data
SB Short-Term Documents for Applicant Master
SRTFD (PC400) = trans class always A for master data (1) pernr (8) info type (4) modified date (8) modified time (8) seqnr (4)
Please note that for the extraction of data, you have to use the date portion of the SRTFD and not the field value AEDTM(since it is not primary key).
Naming convention for INCLUDES when defining clusters. These INCLUDES will define the work area key above and the cluster data that is returned from an IMPORT:
RPCnxxy0
n = 1, 2, 3 or 4 (for PCL1, PCL2, PCL3, PCL4)
xx = cluster ID
y = country grouping (0 for international otherwise country indicator T500L)
Description of Cluster Data using Cluster RX as an Example
The data description is stored in the include RPC2RX00 in accordance with the above naming conventions.
RPC1TX00 - Long text cluster ID in table PCL1
RPC2RUU0 - Payroll results for the US cluster ID in table PCL2
RPC4LA00 - Change log cluster ID in table PCL4
Importing Data (I)
The IMPORT command causes data objects with the specified key values to be read from PCLn.
If the import is successful, SY-SUBRC is 0; if not, it is 4.
REPORT ZRPIMPORT.
TABLES: PCLn.
INCLUDE RPCnxxy0. "Cluster definition
Fill cluster Key
Import record
IMPORT TABLE1 FROM DATABASE PCLn(xx) ID xx-KEY.
IF SY-SUBRC EQ 0.
Display data object
ENDIF.
See sample program for long text.
Importing data (II)
Import data using macro RP-IMP-Cn-xy.
Check return code SY-SUBRC. If 0, it is successful. If 4, error.
Need include buffer management routines RPPPXM00
REPORT ZRPIMPORT.
*Buffer definition
INCLUDE RPPPXD00.
DATA: BEGIN OF COMMON PART 'BUFFER'.
INCLUDE RPPPXD10.
DATA: END OF COMMON PART 'BUFFER'.
*import data to buffer
RP-IMP-Cn-xy.
*Buffer management routines
INCLUDE RPPPXM00.
Cluster Authorization
Simple EXPORT/IMPORT statement does not check for cluster authorization.
Use EXPORT/IMPORT via buffer, the buffer management routines check for cluster authorization.
rpcbdt00 - include needed for importing from database PCL4(la) (Change log cluster ID)
Please note that data for change pointers is stored at two levels: 1) Header which has the key info and 2) BELEGE which has the changed info ie. Old value and new value.
Check standard program RPUAUD00
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an application. They also remember the user name and the time when the modification took place.
The decision whether a field modification is relevant for a change document is triggered by a flag of the modified fields data element. You can set the flag with SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else than a second log file specially designed for writing the change pointers which are meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE when saving the generated change document. So change pointers are automatically written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can be set up differently, so fields which trigger change documents are not necessarily the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or selectively. This is not the case: you always turn them on selectively. The switch to turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction updates, you better use the workflow from the change documents.
Arunsri
Posts: 307
Registered: 12/3/07
Forum Points: 246
Re: change pointers method
Posted: Feb 27, 2008 11:08 AM in response to: satish abap E-mail this message Reply
hi,,
Activating Change Pointers
Use
You can activate change pointers in the HR system to avoid distributing the entire structure when you make changes to the HR-ORG model, and distribute instead only the changes that you have made.
Procedure
1. In the Implementation Guide (IMG, transaction SALE), choose Modeling and Implementing ® Master Data Distribution ®Replication of Modified Data ® Activate Change Pointers ‑ Generally.
2. Set the activation status Activate Change Pointers ‑ Generally, and save your entry.
3. Choose the activity Activate Change Pointers for Message Types.
4. Set the active indicator for the message type HRMD_ABA.
5. Save your entries.
also see this link,
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Check the links below;
http://help.sap.com/saphelp_nw70/helpdata/en/f1/035c8cae3d11d3b540006094192fe3/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
Reward if useful

What is meant by change pointer and change request

hi,
what is meant by change pointer and change request in sap r3
plz can u any one notes or link on this , or if possible briefly tell about this..
i am looking for clear idea on this..
thanks
Ruban

With respect to Dictionary Change pointers means all the changes done to dictionary objects.
All the change logs with respect to tables are stored in CDHDR and CDPOS table
Change Pointers in broad sense are used with respect to IDOC
Change Pointers & Reduction of IDOCs.
Applications, which write change documents, will also try to write change
pointers for ALE operations. These are log entries to remember all modified
data records relevant for ALE.
Following Steps must be followed in case of Change Pointer.
1) Goto Transaction BD60.
Note down the Details of the Message Type for which change pointer has to activate. Details like Function Module, Classification Object, ALE object Type etc.
E.g. ZDEBP3
2) Next step is goto transaction BD53
Click on change button.
First select the segment for which the fields has to modified (either remove or
add ).
It will show the fields in a pop-up window where the user can select, deselect the respective fields.
Save the settings for the Message type. Dont forget to activate the change pointers by clicking Activate Change pointers button on the main screen.
3) Once the activation is done system will reset the settings for the Message type in Change pointers (BD60). Maintained the old settings for the Message type.
Check this FAQ
. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can deactivate change pointers for this messages type.
You can deactivate change pointers for the message type
and reactivate them again.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
3. Are there still too many change pointers to be processed?
The change pointers are analyzed with the transaction BD21 or the report RBDMIDOC in ALE and flagged as processed. If the change pointers are created periodically, this report should also run periodically.
4. Are no longer required change pointers reorganized in time?
The report RBDCPCLR (transaction BD22) to reorganize the change pointer should run periodically. Depending on how many change pointers are created or processed, you can schedule the background job hourly, daily or weekly. You should delete all obsolete and processed change pointers. You can also use this report for specified message types.
We come across change pointer technique while dealing with master data distribution thru ALE/IDOCs
When we want to reflect changes made to master data(i.e customer master, vendor master, material master ...) visible to other clients listed in customer distribution model, we follow change pointer technique.
What is customer distribution model?
A customer model depicts various messages (master data, transactional data) exchanged between the systems and establishes a sender and receiver of data
A customer model is always maintained on any system for the entire distributed network of SAP systems, so it must be distributed to various systems in the distributed network.
These r some details regarding change pointer technique which u may find it usefull.............
The change pointers technique is based on the change document technique, which tracks changes made to key documents in SAP, such as the material master, customer master, vendor master & sales orders. changes made to a document are recorded in the change document header table CHDHR, and additional change pointers are written in the BDCP table for changes relevant to ALE. BDCPS table stores the status of changed documents processed or not.
The process for distributing master data using change pointers involves the following steps.
The application writes change documents. SAP maintains change documents for
several objects in the system, such as materials, customers, invoices, and bank data, to provide an audit trail for changes made to an object. A change document object represents a set of tables for which changes are recorded. For example, the change document for the material master is named MATERIAL and it contains the various tables of the material master object, such as MARA and MARC.
When an application transaction makes changes to an object, the application writes change documents, which are stored in the CDHDR and CDPOS tables for each change made to an object.
Tip
Execute transaction SCDO to see a list of change document objects and
their tables.
The SMD (Shared Master Data) tool writes change pointers. When changes are made to an object, the SMD tool checks the ALE settings and consults the ALE distribution model to determine whether a receiver is interested in the object that was changed. If the system finds an appropriate receiver, the system creates change pointers in the BDCP table that point to change documents in the CDHDR table.
The ALE programs analyze change pointers and generate IDocs. SAP provides
standard function modules that read the change pointer table and generate IDocs for the objects that were changed. These programs are designed to ignore multiple changes and create only one IDoc. For example, if a material is changed four times before the function module is invoked, only one IDoc with the latest data from the material master data is created. The function modules are invoked by a standard report, RBDMIDOC. The selection parameters of this report allow you to specify the message type for which change pointers are to be analyzed. Configuration
you must carry out the following configuration steps to enable master data
distribution based on changes to the object.
Step 1: Enable Change Pointers Globally
Transaction: BD61
This option enables the change pointer process globally. Make sure that the flag is checked.
Step 2 :Enable Change Pointers for a Message Type
Transaction: BD50
This setting is required for activating change pointers for a specific message type.
make sure that the Active flag is checked for your message type.
Step 3 :Specify the Fields for Which Change Pointers Are to Be Written
Transaction: BD52
For standard master data objects such as the material, customer, and vendor objects, SAP already provides a list of fields for which change pointers are written. If you are satisfied with the standard set of fields, you can skip this step. If you want to add new fields, you must add entries for the required fields. If you are not interested in IDocs being generated for changes to a particular field, you can remove it from the list. For example, if you do not want to distribute the
material master for changes made to the Catalog Profile (RBNRM) field, you can delete this entry from the table.
Step 4: Changing a Field in the Master Data
Change a field in the master data object for which the change pointer is enabled. For example, if you change the net weight of a material in the material master data, a change pointer is written.
Tip : You can verify a change document and change pointer by viewing entries in
tables CDHDR and BDCP, respectively.
Step 5 :Executing Program RBDMIDOC to Process Change Pointers
Execute program RBDMIDOC to initiate the process of generating an IDoc. On the selection screen, specify the message type. For example, you can specify MATMAS. After you execute the process, it displays the number of entries processed.
Note :
Normally, you schedule this program to run frequently and start IDoc
generation for different message types.
Step 6 : View the idocs in WE02/05

Change Pointers Issue

Hi
Pls any body can give me step by step settings to save the changes to the DB tables(Change Log)
I am trying to read change pointers for a 1) FAGL_011PC table.But when ever i change the data using T Code FSE2 the data is saving in this table but the changes are not getting saved in CDHDR/CDPOS.
Chagne Log Check Box in tech Settings I Activated.
What shouls i Do ?
Thanks in Advance
PREETI Raj

Hi,
Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
Regards,
Shiva Kumar

Change Pointers and Recovery Index

Similar Messages

Maybe you are looking for