Extraction using ALE Change Pointers

Hi,
Can any one pls tell me what is the advatage of extracting r/3 data to bw using ALE Change Pointers. Any document on how to perform ale change pointer extraction will also be helpfull for me. Thanks in Advance
Regards,
Harish.

https://www.sdn.sap.com/irj/sdn/advancedsearch?query=change+pointer&cat=sdn_all

Similar Messages

Needs to update Infotype using ALE-Change Pointers-ECC 6.0

HR Experts,
We are using ECC 6.0. There are two SAP-HR systems.. for e.g system A and B.
We would like to send data from system A to B.
If there are any changes in system A for Infotype-0, 1, 2, 6, 8, the IDOC should be generated and it should deliver and update the infotypes in system B.
What message type I have to use?
Do I have to use change pointers?
If there is only change in any one of the above infotypes then it will generate IDOC for all above infotypes or just the changed one?
Thanks in advance for your help..
MP

Hi Frank,
Thanks for your quick reply!
I rewarded you with the points
How I have to choose which infotypes I have to transfer in message type HRMD_A, What tcode I have to use to configure this?
Do you know the BADI or User-Exit for enhancement of custom fields?
How I have to configure to transfer only the changed records OR transfer complete data? Where should I go to do this?
Thanks for your help in advance...
MP

ALE Change Pointers in source system not active

Hi All,
I am trying to load 0COSTELMNT using deltas. The initial load is OK and then i use a delta and it fails and i get the error:
"ALE Change Pointers in source system not active"
I have carried out the following steps in an attempt to resolve the problem - but it didnt. Anyone have any advice??
(1) Checked BD61 to confirm whether the change pointers are active
(2) Checked BDCP to confirm the number range is maintained
(3) Checked SALE (Activate change pointers for message types) to confirm whether the change pointer has been activated for the type we need:
COCOKA Control segment CO object/cost element
COELEM Cost element master data
(4) In transaction snum, Selected number ranges and confirmed the intervals are setup
No. 01
FROM: 0000000001
TO: 0000009999
(5) Activate transfer structure
(6) Replicate Datasources
Thanks,

If you are transferring master data from source system, the BD61 setting on the source system should be checked.
Why it has been unchecked - not sure (likely someone did it by mistake).
It shouldn't have any effect on txnl delta. What will be effected though is that you will have lost delta of the ALE based data sources for the period this setting was unchecked.

ALE change Pointers for delta load

The master data datasource is 0CRM_BPSALESCL_ATTR, which is in my source system use change pointers for delta loading. When I use delta loading, the error is "ALE change pointers are not set up correctly". I went to the source system, and use BD61 to activate change pointers. But it does not work. Then I created new Business partners to make changes. I can find these new records in table CDHDR and CDPOS, but there is no records found in table BDCP. And my delta loading still got the error as "ALE change pointers are not set up correctly."
Can anybody give me advice?
Thanks,
Wenjie

Hi, Ron,
Thanks for your reply. I already assign points to you.
I relicated the datasource, and re-active the transfer structure, but it still doesn't work. My one more question is that do I run BD61 on BI system or on source system? I did on source system only. And is there any more setting need to be done on source system? Because my error message said setting on source system is wrong.
Thank you very much.
wenjie

Does ALE change pointers capture the hard deletes?

Hello Team,
We have requirement to capture the hard deletes.
If my table has 10 records, if one get deleted, i would like to know this.
This table is planned to broadcast across the R3 systems, hence we were thinking about to create ALE change pointers.
My question is does ALE change pointers supports hard deletes (or) just new or changed?
Thanks in advance,
Angelo

Hi Angelo,
Change pointers are usually based on change documents. It's essentially the responsibility of the application to determine for what change pointers (and possibly change documents) are written. If you're creating your own change pointers you also have the option to just generate them directly (without writing any change document using function module CHANGE_POINTERS_CREATE_DIRECT). Thus you of course have the freedom to also generate them for hard table deletes - all completely up to you.
Cheers, harald

IDOC trigger using Z change pointers for standard SAP table

For IDOC trigger, is using custom change pointers on standard SAP master data tables, a good idea? A seasoned abaper told me "it will mess with the standard" and further told to go with scheduled job.
So, for example, say that my data for table T001K is updated via transports in PRD and I need to transfer this updated data via IDOC to an external system. Since there is no standard message type for this data, I will create a new one. Further, I will create a new change pointer for table T001K (it already has six fields with their data elements activated for Change Documents). Then I link the message type and the new change pointer. And so on an so forth. I have followed the procedure given here:SAP Tips: A to Z of Custom Change Pointer
Now, the question is, will this be a good idea to capture data and trigger IDOC? Or a batch program with calls to standard FM to read CDHRD/CDPOS be a more suitable option.
I need to know if a near instantaneous data transfer (and an effecient one as far as the system performance and reliability is concerned) can be acheived. If there is any other way of doing this, I am not aware of it!
Any one has any input/experience on this?

Hi Viktor,
I think the batch program approach would be a good solution as the by this way you are taking matter into your own hands rather giving control to the SAP framework because you may have to test out the other approach as to how the standard SAP framework is behaving for custom change pointers.
Thanks,
Ravi

Restrict IDoc creation by using deactivate change pointers

Hi Experts,
I am trying to restrict the creation of IDOCS by deactivate the change pointers from a ztable. if the record in ztable and BDCP table match then i should deactivate the change pointer. And restrict the creation of Idocs.
pls, suggest me soon... its urgernt.......
Regards,
CHK

Maybe using program RBDCPCLR to delete change pointers you don't want to use?

ALE change pointers

Hi All!
I want to trigger the ALE system at a fixed time schedule for eg at 4PM daily.is it possible in change pointers or there is any other alternative.
Please advice
regards
Prasanna Kumar

Hi prasanna,
This link would be very helpful for u:
http://help.sap.com/saphelp_erp2005/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Hope this helps u,
Regards,
Nagarajan

Hi experts in ale what is change pointers technique , how we will use ,

hi experts in ale what is change pointers technique , how we will use , & when plz explain

Hi,
Refer the Below links
[http://articles.techrepublic.com.com/5100-10878_11-1048973.html|http://articles.techrepublic.com.com/5100-10878_11-1048973.html]
[http://abapprogramming.blogspot.com/2008/01/ale-change-pointers.html|http://abapprogramming.blogspot.com/2008/01/ale-change-pointers.html]
Regards,
SB

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

Change pointers in ale

hi experts,
what is use of change pointers in ale?please give me help about change pointers?

hi,
If you want to distribute master data changes with the SMD tool (Shared Master Data), changes to the master data objects are flagged for distribution by change pointers (Master Data Distribution).
The SMD tool is connected to the change document interface. If the master data changes are to be distributed, the application writes a change document. The contents of this are passed to the SMD tool. The tool writes change pointers, reads the application data and creates the master IDoc.
The master IDoc is then passed to the ALE layer, which sends it to all interested systems.
Regards,
Pankaj Singh

Problem with Chang pointers in ALE

1) what is Chang pointers? use of change pointers? with example if possible?

Hi Sudharsan,
Please go through the following link
http://help.sap.com/saphelp_nw04s/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
thanks
Sekhar.

Extract the new , changed , deleted vendor master data -urgent pls

Hi all,
I have require ment like i need to extract all new, changed and deleted data from SAP TO MAXIMO
i need to send to a windows environment which both systems share,
i am using LFA1 ,CDHDR , CDPOS Tables , i will get the reuired information , can i use gui_download
to download to windows environment which both system are mapped to a common shared folder.
i will extract the infrmation and sent to a shared folder.
this a backround job schedule daily once.and also i have to sent the file contents to spool also.
please suggent some code existing or how to do the logic behind.
shall i use open data set
read data set
close data set.
please suggest ways of doing............urgent.
regards
kodamanchili

With regards to the writing out of the data that, you are correct that you should use the Data Set commands if you are attempting to write a file out to the application server. If you are using any sort of EAI tool then there maybe are other ways specific to the tool for sending data, such as some of the tools utilize RFCs to send the data.
For the actual identifying of the changed records, it is best not to write delta interfaces directly against the change document tables (CDHDR and CDPOS). Instead you should be ustilizing change pointers. Change pointers are transient data stored in the BDCP and BDCPS tables (combiend togehter into view BDCPV) or stored in BDCP2 if configured to use this newer change poitner table for much better performance.
An instance of a change pointer in the change pointer tables will indicate the record that has changed and point to the changed document in the change document tables that can be referenced to extract more specific information.
The nice thing about change pointers are:
- They are transient, at the end of your extract you clear the ones that you've extracted so that the next time you will get the ones that have been pulled since then.
- You can setup instances of your change pointer object that are specific to an extract program so that two extract programs for similiar or even completly the same data won't itnerfere with each other.
- The CDHDR and CDPOS tables are great for extracting changes that have occured over time for a specific instance of a buisenss document (ex. Vendor) but do not perform well over time for extracting all changes associated with all instances of a buisness document (ex. All vendors that have had changes since the last run of the program). Programs that extract directly against CDHDR and CDPOS do perform delta extract functionality are oftern a performance problem as time progresses and the tables grow in size. If used properly Change Pointers are efficient becuase the tabels can be kept small and are optimized for the extracting of deltas.
For any tables that log change documents in CDHDR and CDPOS you can configure change pointers to be populated in the BDCP* tables.
Change pointer configuration:
- BD61 - Activate change pointers globally within the SAP instance
- WE81 - Need to create an ALE message type (even if you're not actaully going to connect it to an IDoc)
- BD50 - Activate change pointer functionality for your message type
- BD52 - Define the individual change documents, tables and fields that you want to have as part of your tracking
Your extract program will use two functions:
- CHANGE_POINTERS_READ - Use this to get a list of all change pointers since the last execution
- CHANGE_POINTERS_STATUS_WRITE - Use this to mark the change pointers as extracted so that they won't get picked up on the next execution
Transaction BD22 (Program RBDCPCLR) should be scheduled to run regularily to delete from the change pointer tables the records that have been marked as processesd.
Note - A common mistake that is made is that the change pointers are read, some filtering is done for specific ones that should be extracted and then only the extracted ones have their change pointer status updated. It's important to update the status on all of the change pointers because otherwise they'll be picked up again on the next run of the program and will be filtered out again, so over time the number of selected change pointers will keep growing since they will never get purged from the change poitner tables.
Note that the BDCP and BDCPS tables have a number of performance issues when the selections are done against them due to the way they are joined and the crieteria that is used for selecting. Becuase of this SAP has implimented a new change pointer table BDCP2 which is a single table as opposed to using a join. In order to utilize BDCP2:
- Used SM30 to update V_TBDME. For your message type turn on the checkbox for BDCP2.
- Run program RBDCPMIG for your message type, this will migrate existing pointers over to the BDCP2 table. If you can guarentee that there are no existing pointers then you can use SM30 to update for your message type the target of the pointers as being BDCP2
~Ian

Change Pointers Needed

Hi All,
Please give me a scenario to expalin about change pointers.
Regards,
Srik

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 points hope this helps u,

When transferring HR data from ECC to CRM via change pointers

When transferring HR data from ECC to CRM via change pointers ,certain data is getting earsed in CRM
paricularly the last name and first name of BUT000
Do you have any idea why this could be happening
Thanks in advance

Hi Kittu,
Change pointers. Change pointers are R/3 objects that mark changes to SAP master data. Change pointers are managed by mechanisms in a Shared Master Data (SMD) tool and are based on Change Document (CD) objects. CD objects record the changes occurring to master data at a field level. These changes are stored in tables CDHDR (header table) and CDPOS (detail table). ALE configuration provides a link between CD objects and change pointers. Internal mechanisms update tables BDCP and BDCPS, which host the change pointers. While CD objects are application-data-specific, the processing status of change pointers is message-type-specific. Also, the ALE change pointers are activated first at a general level and then at the message-type level.
use this links kittu.
http://help.sap.com/saphelp_nw04/helpdata/en/ab/27bde462848440ba70cf8eb348c86f/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/0f/9d563cf19bcb43e10000000a11405a/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/ab/27bde462848440ba70cf8eb348c86f/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
Creating a change pointer and subsequently triggering an IDOC
thanks
karthik

Extraction using ALE Change Pointers

Similar Messages

Maybe you are looking for