BD61 - Activate Change pointers(global)

BD50- Activate change pointers for message type

Then tables for which change pointers to be set.Here tables are stored as object.

also check BD59.

1) Tcode BD61---> check the change pointers activated check box

save and goback.

2) Tcode BD50---> check the MATMAS check box save and comeback.

3) Tcode BD51---> goto IDOC_INPUT_MATMAS01 select the checkbox save and comeback.

4) Tcode BD52---> give message type : matmas press ok button.

select all what ever you want and delete remaining fields.
save & come back.
5) 5) go to Tcode MM02 select one material and try to change the description and save it

it will effects the target systems material desciption will also changes

6) goto Tcode SE38 give program Name is : RBDMIDOC and Execute

give Message type : MATMAS and Executte

Raja T

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.

Hi,
use this steps.
Change Pointers:
-Change documents are working based on change document technique which
tracks changes made to the key documents (Material Master, Customer
Master, Vendor Master ..etc) in SAP.
-Changes made to the keydocuments are recorded in the change document
Header table i.e. CDHDR and Item table CDPOS, Additional change
pointers are written in the BDCP and BDCPS tables.
-Change pointers technique is used to initiate the outbound process
automatically when master data is created or changed.
-A standard program RBDMIDOC is sechuled to run on periodic basis to
evaluate the change pointers for a message type and starts the ALE
process for distributing the Masterdata to the appropriate destination.
-'Object' is collection of fields of different database tables. T.code
for creating an object is SCDO.

Configuration for Change Pointers:

-

1. BD61 Active change pointers generally

- Check the checkbox "Change pointers activated -generally"
- Save it
2. BD50 Active change pointers for Message Type
- Message Type
Active
MATMAS
check the check box
3. SCDO Change Document Objects
- Check whether the "MATERIAL" is available in the object list.
4. BD52 Maintain Table Views
- Enter the Message type "MATMAS" and press enter.
- OBJECT
TABLE NAME FIELD NAME
Ex: MATERIAL
MARA
BISMT
5. BD60 Additional data for message types
- Message Type
Function Module

Table

Ex:
MATMAS MASTERIDOC_CREATE_SMD_MATMAS MARA
6. WE20 Partner Profile
7. BD64 Distribution Model
8. Create a Material by using T.Code MM01
9. SE38 Run the program RBDMIDOC by passing Message type "MATMAS"
10. WE02 IDOC List
Regards,
S.Nehru.

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/fram
eset.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.