Change_pointers_read FM

Hi All,
I have a requirement like whenever a class(cl02) is created,an idoc should be created.
I have maintained two fields in BD52 :class and clint of klah table.
object       table name      field name
klasse      klah                 class
klasse     klah                  clint
I creted a new class in cl02 and in cdpos the corresponding entery is updated/reflected.
But while tried to crete idoc through BD21,the change_pointers_read is not capturing the cretion/change of the respective class.
Can anyone help me on this

Thanks for your reply.
Message type is already maintained and activated.
Basically we need to trigger idoc,when a 1:class is created(KLAH table)
2: when a class type is changed for a material(table kssk)
3:when the characteristics(of a class) is changed/created for a material(table CABN/AUSP)
But now here when I am changing anu og the above 3 options ,an Idoc is not getting triggered .While debugging I noticed, Change_pointers_read FM is not capturing those data.
I am not sure whether this is the right way to get these details or is there any other FM's for retreiving the data related to material classfication.can u help?

Similar Messages

Change pointers in case of purcahse order

The scenario is to send data through idoc when i create/change delete certain fields in purchase order.
I hace used change pointer scenario for it
can u plz see what i have missed out in my configuration ..
Here are the steps i followed .
1) created a logical custom message us we81 .
2) created custom idoc using we 30
3) Linked custom mesage and idoc using we 82
4) Activated my custom message using bd50 .
5) Assigned fields to message using bd52 ie
Einkbeleg EKKO waers , EKPO-netpr ..etc
6) Assigned cutom message and custom function module
(z...smd_custommsg) via bd60
7) tried to execute the message using BD21 ..
Now the issue is that entries are being created in change document table(cdhrd/cdpos)
but no entry in BDCP/BDCPS..
please give your valuable inputs to it
Thanks In advance

hi,
You can acheive this by writing a custom program.
in the program you need to use function module 'CHANGE_POINTERS_READ' for reading the change pointers.
Give document object class as the object name in bd52 and give read_not_processed_pointers as 'X'.
Looping at the output table and using function module CHANGE_POINTERS_CREATE_DIRECT you can create an entry in bdcp table for the respective purchase order.
After this you can use SUBMIT rbdmidoc WITH mestyp = message_type AND RETURN.
Regards
Sridevi S

What are the message types available for Vendor Address?

Hi Everybody,
I need to read the all the change pointers of Vendor Address using the function moudle 'CHANGE_POINTERS_READ'. To call this FM I need to pass Address's Message Type. I am passing ADRMAS as message type. but i am not getting any records into change pointers internal table.
Pls help me out by informing the message type of Vendor Address.
Regards,
Nagaraju Maddi

Hi,
The address group is in the segment E1BPAD1VL1-ADDR_GROUP.
Check the table TSAD7 for Address groups (central address management)
Reward points
Regards

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

Chnage pointers for a report

Hi,
I have a requirement where in I have to modify all the articles (MARC-MATNR) which are specified in the selection screen of a report. This report would be running in back ground for every one hour. user would not be entering input in the selection screen, since report would be running as a bactch job. whenver the article is changed and new article is created my report has to get triggerred.But it does not mean that the program should be run at the very moment a new article is created or changed. It just means that program should run for only those records which have undergone any of the below 4 changes in the last 1 hour
( 1.Supply source field MARC-BWSCL is changed for a article
2.vendorEORD-LIFNR is changed for a article
3. new purchasing source list is added (EORD Records) for a article.
4. new article is created).
Can anyone please tell me how to proceed with this requirement
Thanks in advance
Ram Devi

Another way is
Enable the change pointers for the 4 fields you mentioned for article master using transaction code SCDO.This will be create change pointer entreis in BDCPV tables
then
   CALL FUNCTION 'CHANGE_POINTERS_READ'
          EXPORTING
            message_type                = gc_message_type
            read_not_processed_pointers = 'X'
          TABLES
            change_pointers             = lt_chgptrs_tab.
if any values found you can run your report , then after that. then call the following fm to update the processed entreis in change pointer table to be marked as processed, so next time theses entries will not consider
          CALL FUNCTION 'CHANGE_POINTERS_STATUS_WRITE'
            EXPORTING
              message_type           = gc_message_type
            TABLES
              change_pointers_idents = gt_pointer_id.
a®

ALE/IDOC[custom table]

Hi All,
I have a doubt regarding the type of programs used to post the idocs using ALE in the outbound process.
Please also tell me which program I will use to post a custom table of mine to another server using ALE/IDOC.
Please also tell me the procedure to do the same mentioned above.
Please help. Its a urgent requirement...........................
Thanks in advance......................................................

hi,
u can do it using CHANGE POINTERS method.For this u need to do the following configurations.
1>WE81
2>WE31
3>WE30
4>WE82
5>SCDO
6>BD61
7>BD52
8>BD50
9>BD60
10>WE20
11>BD64.
First create an object in tcode -SCDO,there u specify ur tablename.
now the fields which are there in the ztable,in the further characteristics of the dataelement u need to check the check box CHANGE DOCUMENT HEADER.Now in SCDO u need to generate the upgarde program,the sap will generate four includes,u need to call them in ur program.
U need to write one FM ,where u need to use the FM's.
CHANGE_POINTERS_READ,
CHANGE_POINTERS_STATUS_WRITE.
Regards,
nagaraj

Jobs related issue (how table BDCP updated)

hi expert,
job xxxxx is running in R/3 which update other system (3plp).
The main concept is that. Whatever changes taken place in master
Data this change is passes through Idoc to other system.
My issue is related to customer master data. Job is including those
customer( 321304) which have not been change. I can see this customer
number in job spool. But when I see changes in customer master (321304)
there is no change on that date. So this behavior is wrong.
Job must include those customers who are changed on that date.
Jobs is running fine for more customer but, not working fine for few customer
In ABAP analysis I found that
the program it calls the standard Function Module CHANGE_POINTERS_READ. The function module outputs the customer 321304 and change pointer number 198919387. But when I checked this customer, it hasnu2019t been changed since 2007.
Then I checked table BDCP (for change pointers) and got this:
I donu2019t know how table BDCP was updated and why change pointer 198919387 was created for KNA1.
Regds
alicia k

Hi Alicia,
Kindly check this to find how BDCP gets updated.
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.
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields.
Dont forget to reward points if found useful.
Thanks,
Satyesh

Requirements for IDOC

Hi friends,
Could you please tell me the details required for doign a IDOC scenario.
I want the details seperately when IDOC is a sender and also when IDOC is a receiver.
Note: High reward points for the reply

HI
IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.
Idoc creation
IDOC Programming
There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is send to other system . Separate ABAP programs are written for these 2 processes and different configuration settings are required for each one .Depending upon the trigeering mechanism different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the database tables.
The basic structure of all outbound programs is same. The CONTROL
record which is of TYPE EDIDC has to be filled. It contains important fields like
IDOCTP IDOC type
MESTYP Message Type
RCVPRN Recieving Partner (Destination)
RCVPRT Partner Type (it is LS i.e Logical System)
The DATA RECORD internal table which is of TYPE EDIDD has to be filled
in the same order as there are segments in the IDOC definition.
It has 2 important fields which are to be filled ,these are
SEGNAM Name of the segment
SEGDATA Data in the segment and can be upto 1000 bytes.This field
is corresponds to each data segment in the IDOC.
e.g.
DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.
DATA W_SEGDATA LIKE zsegment "custom segment zsegment
INT_EDIDD-SEGNAM = 'ZSEGMENT'
W_SEGDATA-field1 = value "taken from some table
W_SEGDATA-field2 = value "taken from some table
INT_EDIDD-SEGDATA = W_SEGDATA
APPEND INT_EDIDD
This will fill the data record corresponding to the segment ZSEGMENT . For all
segments the sam steps will be repeated until all the data corresponding to all the
segments in the idoc is filled in the internal table of type EDIDD.
There is only one control record and can be multile data records in the idoc
structure.
Which data is to be extracted from the tables to be filled in EDIDD type internal table is determined in standalone programs from the objects which are specified in the selection screen and from the object key passed to the function module in case of message control and is taken from BDCP table in case of change pointers using function modules "CHANGE_POINTERS_READ"
In case of stand alone programs and function modules based on change pointers method the function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for distribution ,in case of message control it is handled automatically by the RSNASTED program invoked by the message control.
You can get the all description from below tcodes
WE60-> Documentation for IDoc types
WE09-> Search for IDocs by Content
BD87-> Status Monitor for ALE Messages
WE63 -- information about Standard IDOC in R/3
WE64 - Details about process codes
WE82, WE30, WE31 -- IDOC Types.
SAP R/3
R/3 to XI
1) RFC Destination (SM59)
a) Choose create.
b) Specify the name of the RFC destination
c) Select connection type as 3 and save
d) In the technical settings tab enter the details SAP SID/URL and system number#.
e) Enter the Gateway host as same details above SID/URL.
f) Gateway service is 3300+system number#.
g) In the Logon /Security tab, enter the client user & Password details of Destination system.
h) Test the connection and remote logon.
2) Create Port (We21)
a) First Select Transactional RFC and then click create button
b) Enter the destination port name as SAP+SID (The starting char should be SAP)
c) Enter the destination client.
d) Enter the RFC Destination created in SAP R/3 towards other system.
e) Save
3) Create Partner Profile (WE20)
a) Create New
b) Create the Partner no. name as same the logical system name of the destination system.
c) Select Partner type LS
d) Enter details for Type: US/USER, Agent, and Lang.
e) Click on the + button to select the message type.
f) Select Partner no. and LS which ever create above.
g) Select Message type
h) Select Process code related to the Message type.
I) save.
XI to R/3
1) RFC Destination (SM59)
a) Choose create.
b) Specify the name of the RFC destination
c) Select connection type as 3 and save
d) In the technical settings tab enter the details SAP SID/URL and system number#.
e) Enter the Gateway host as same details above SID/URL.
f) Gateway service is 3300+system number#.
g) In the Logon /Security tab, enter the client user & Password details of Destination system.
h) Test the connection and remote logon.
2) Create Port (IDX1) ( Create port to get IDOC Meta data from sender system)
a) Select create new button
b) Enter the port name as SAP+SID (The starting char should be SAP)
c) Enter the destination client.
d) Enter the RFC Destination created in SAP R/3 towards other system.
e) Save
3) Load Meta Data for IDOC (IDX2) (To maintain IDOC Metadata, it is needed by XI because XI needs to construct IDOC-XML from IDOC. It is not needed by any sap system).
a) Create new
b) IDOC Message Type
c) Enter port created in IDX1.
Details ABT IDOC??????
1)Use WE60 transaction.
2)you need list of basic type idocs then use t.code WE60.
To display IDOC list in particular time intervel use we02 or we05.
where u can find the outbound and inbound processing idoc's.
use t.code 'wedi' to get more information on idoc's.
3)You can use the WE60 for Idoc Documentation
& we can use WE30 for Idocs list
Refer the below links for furtehr assistance
ALE/ IDOC
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapgenie.com/sapedi/idoc_abap.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm
http://www.allsaplinks.com/idoc_sample.html
http://www.sappoint.com/abap.html
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.allsaplinks.com/idoc_sample.html
cheers

IDOCs creation - Transfer Orders(TOs) for Deliveries - Basic doubts, thanq

Hi Experts,
Am new to IDOCs. I hv a requirement, so, request u that, Can I get some Wht to do tips from u?
My doubts:
1- I hv been asked to create IDOC, Wht does it mean?
2 - How the created IDOC will be get posted?
My requirement is:
Original inbound idoc sent from Gentran will update the delivery with all serial numbers per material for all serialized product. The message code will be the indicator that a Transfer Order-TO, idoc must be created for TO confirmation.
I need to do===>   Should be executed only when the message code on the delivery idoc is u201CTOCu201D. Look up the warehouse code on the delivery header using the delivery nbr in the delivery idoc. Create a new TO confirm idoc per delivery idoc being processed. Create a line item on this idoc for every line on the delivery idoc. Each TO line includes the delivery number and delivery item number so the TO number and line number can be looked up in table LTAP by using the delivery number and line item number found on the delivery idoc. There will be at 2 transfer orders for each delivery item b/c of the 2 step pick process, so select the TO nbr that has 916 as the destination storage type (LTAP-NLTYP). There may be more than 1 pair of TOs per delivery item so this must be completed for each TO found relevant to each delivery item.
The inbound delvry03 idoc will update the delivery with the serial numbers as part of the standard functionality. Since the transfer order must also be confirmed with the quantities on the inbound idoc, an additional idoc must be created from within the delivery update process. The transfer order can be updated and confirmed using the standard idoc and function module which should be created and initiated from the delivery update function module customer exit.
Source = DELVRY03     Destination = WMTCID01
Record Name-Field Name-Record Name-Field Name-Description---Comments
E1EDL20     VBELN-E1LTCOH-LGNUM-Warehouse Number-Look w/ idoc delivery nbr
E1EDL20     VBELN-E1LTCOH-TANUM-Transfer Order Number- Look w/ idoc delivery nbr
E1EDL24     POSNR-E1LTCOI-TAPOS-Transfer Order Line Item- Look w/ idoc delivery line nbr
EVERY THING IS DATA TRIGGERED!!!
thanq
Edited by: Srinivas on Jun 27, 2008 4:41 PM

IDOC Programming
There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is send to other system . Separate ABAP programs are written for these 2 processes and different configuration settings are required for each one .Depending upon the trigeering mechanism different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the database tables.
NEED FOR ABAP PROGRAMMING arises if
1)New IDOC was created
Depending upon the triggering mechanism i.e change pointer,message control
etc the programming technique changes and the type of process.
2)Existing IDOC was extended
User Exits are used to populate data in new segments added and to read them
back.
3)To enhance an exsiting process.
User Exits are used .
Basic structure of an OUTBOUND PROGRAM
The basic structure of all outbound programs is same. The CONTROL
record which is of TYPE EDIDC has to be filled. It contains important fields like
IDOCTP IDOC type
MESTYP Message Type
RCVPRN Recieving Partner (Destination)
RCVPRT Partner Type (it is LS i.e Logical System)
The DATA RECORD internal table which is of TYPE EDIDD has to be filled
in the same order as there are segments in the IDOC definition.
It has 2 important fields which are to be filled ,these are
SEGNAM Name of the segment
SEGDATA Data in the segment and can be upto 1000 bytes.This field
is corresponds to each data segment in the IDOC.
e.g.
DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.
DATA W_SEGDATA LIKE zsegment "custom segment zsegment
INT_EDIDD-SEGNAM = 'ZSEGMENT'
W_SEGDATA-field1 = value "taken from some table
W_SEGDATA-field2 = value "taken from some table
INT_EDIDD-SEGDATA = W_SEGDATA
APPEND INT_EDIDD
This will fill the data record corresponding to the segment ZSEGMENT . For all
segments the sam steps will be repeated until all the data corresponding to all the
segments in the idoc is filled in the internal table of type EDIDD.
There is only one control record and can be multile data records in the idoc
structure.
Which data is to be extracted from the tables to be filled in EDIDD type internal table is determined in standalone programs from the objects which are specified in the selection screen and from the object key passed to the function module in case of message control and is taken from BDCP table in case of change pointers using function modules "CHANGE_POINTERS_READ"
In case of stand alone programs and function modules based on change pointers method the function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for distribution ,in case of message control it is handled automatically by the RSNASTED program invoked by the message control.
OUTBOUND PROCESS AND OUTBOUND PROGRAM.
Outbound programs are used in outbound process to genearte IDOCs . There
purpose is to extract the data from the tables and to fill the IDOC data records
and the control record in the IDOC and pass ito the ALE layer for distribution to the recieving system .
Depending upon the triggering mechanism (how and when the outbound program will be started different techniques and interface is used for outbound program.
1)Message control
Application like PO(purchase order) creation use this technique , where the output type is linked to the application(Message control is a configurable cross application component which can be set in IMG .Such programs are created in the form of function modules and linked to the output type which is linked to the apllication.These have predefined interfaces.
In outbound programs(function module) that use message control the key of the
application document is passed to the function module whcig will read the data from the table depending upon the key passed(NAST structure) and fill the IDOC segemnts with the application data.The control record is also passed to the function module but is not fully filled, the rmaining fields are filled and the control is passed back to the calling program which is RSNASTED and is invoked by the
message control to process ALE and EDI output types and this program on recieving the IDOC data will create the physical IDOC in the system.
The parameteers passed to the function module are
IMPORTING PARAMETERS
OBJECT LIKE NAST
It contains documents key.
CONTROL_RECORD_IN LIKE EDIDC
It contains the partailly filled control record
EXPORETING PARAMETER
OBJECT_TYPE
CONTROL_RECORD_OUT LIKE EDIDC
TABLES
INT_EDID LIKE EDIDD
The internal table used to fill the data records in the same order as they exists in the IDOC.
The important parameters that should be filled in the custom function module are
CONTROL_RECORD_OUT and INT_EDIDD .The OBJK field of the structue NAST contains the key of the apllication document.
2)Stand alone programs
Generally used for Master Data transfer and as such depending upon the requirement can have different interfaces.The programs have a selection screen which has select options to select the objects, and parameters for specifying the recipient Logical System and the Message Type.
Data is selected based on the specified objects from the tables . and control record of type EDIDC is created and filled with important values like DIRECTION ,IDOCTP,RCVPRT,RCVPRN and MESTYP .
Data is filled in an internal table of TYPE EDIDD according to segment definitions
and in same order and the function module MASTER_IDOC_DISTRIBUTE is called passing the control record and the internal table containg IDOC data and importing an internal table consisting of control records for each communication IDOCS created.
3)Change pointer
Change Pointer table is read and checked if changes were made to important fields , if so the outbound program will be triggered automatically , these have predefined interfaces
ALE/IDOC Transaction
SALE Area Menu for ALE configurations.It includes transactions for
Logical System definition and linking it to a client, Transactions for
RFC Destination and Port Definition Etc.
SM59 RFC Destination
Here we specify the login settings for the destination including
the I.P address or Application Server name and the User name and
password.The information entered here is used to run Remote Function
Calls(RFC ) on the destination server .We can create number of types
of RFC Destinations but 3 types are important .
R/3 (R/3 to R/3), LS(logical system) and TCP/IP.
The name of the RFC destination should be same as that of Logical
System as it helps in creation of automatic partner profiles.
WE21 Port Definition.
There are 6 types of ports but only 2 types File and Transactional RFC
types of ports are important.
We have to specify the RFC Destination before a port can be created.
WE57 This is used to assign the Inbound function module to the Message Type
and to the IDOC Type.
WE42 This is used to define the process Code for Inbound Processing.
BD95 Define Filter object type .We can specify the field and the table it belongs
to as a filter object .
BD59 Assignment of Filter object type to the Message Type .Here we create the
link between Filter object and the segment and the message type and the
segment Field.
BD50 Set message Type to reducible.
BD65 Define Mandatory Fields.
BD64 Distribution Model . Also known as Customer Distribution Model Used to
define all the messages that will be exchanged between remote systems
and the name of thes logical systems. Any filters can also be specified.
The model once created has to be distributed on every system which will
be communicating ,It can be maintained on only One system.
BD21 Creating IDOcs from change pointers.
This can be used to create IDOCs from change pointers for a particular
message LIKE MATMAS.
BD22 This can be used to delete change pointers.
BD87 Status Monitor. Idocs can be selected base on number of criteria and there
processing status can be seen in detail.
BD10 Material Master Data Distribution .
Based on Message MATMAS.
BD12 Customer Master Data Distribution .
Based on Message CREMAS.
BD14 Vendor Master Data Distribution
Based on Message DEBMAS .
BDFG Generate ALE Interface for BAPI.
Here we specify the Business Object and the BAPI Function module for
which the interface has to be created.
WE31 Segment Editor.
This is used to create segments. We create the segment type and
segment definition is automatically created by editor e.g. Z1DUMMY is
segment type and Z2DUMMY is the segment definition .We specify the
fields and the data elements these cp\orresponds to create segments.
WE30 IDOC Editor
It is used to create a new IDOC Type or IDOC Extension .We specify the
segments that will be addd to the IDOC type.
WE02/05 IDOC List.
Various selct options and parameters are provided to select IDOCs
depending on the date, direction , mesage type etc.
WE20 Partner Profile
Here we create partner profile for each and every partner from / to which
the messages will be exchanged.There are 6 types of PF generally only
profiles of type LS(Logical System) ,KU(Customer) ,LI(Vendor) is used.
We specify the partner number and partner type and the agent and
the agent type responsible for handling of errors .
For every message send to the partner we have a outbound record and for
evry message coming from the partner we have the inbound record .
We specify the message in the otbound/inbound records ,double
clicking will take us to the detailed screen where the IDOC Type ,Port
and whether the IDCO will be immediatelt processed or collected are
mentioned.

SMD Tool. No change pointers log on table CDHDR nor CDPOS.

Hi everyone.
I'm trying to use the SMD tool. I've created my Message Type, and my Change Document Object(Tcode SCDO).
Priorly, I've tested the ALE Layer configuration, by sending iDocs of my message type directly with the MASTER_IDOC_DISTRIBUTE Function Module, and it works fine. I mean, I have no problem with sending iDocs or the ALE configuration.
In the transaction SCDO I've logged my Object Type, and I've assigned the table THOC (Public Holiday Calendar), from wich I want to monitoring the field DATUM, wich is flagged as "Copy as Internal Table" and "Doc. for individual fields at delete". Also in this transaction (SCDO), I've created the Update pgm.
In transaction BD95, I've inserted my ALE Object Type, and I've assigned the table THOC and the field DATUM to my Object. Field DATUM is referenced to the DATUM Data Element. Due that the Data Element DATUM isn't flagged as "Change Document", I've changed the Data Element referenced by the field DATUM for one copy of the Data Element DATUM, wich I've flagged as "Change Document".
My Message Type is alredy on the following tables:
Tcode BD50: The checkbox for monitoring Change Pointers is on.
Tcode BD52: Where I've assigned my ALE Object, the table THOC and the field KEY.
Tcode BD59: Where I've assigned to it the segment of my Message Type, and the field (same field type) wich corresponds to the field DATUM of table THOC.
Tcode BD60: The ref. msg. is the same as my Message Type, i've created the function module to create the iDocs containing the delta information (via tcode BD21 I alredy reach this FM that I've created), there's no table nor Object Type Associated (in this step I've tried both cases, with table THOC and my Object Type assigned, and both not assigned), the checkboxes "ID for reducible message type" and "BDCP2 OK" are off.
The Change Pointers in Tcode BD61 is on.
After all this configuration steps, I still cannot see logs of my Change Document Type in tables CDHDR nor CDPOS. Besides, when I run Tcode BD21 with my message type, and when the program reaches my Function Module (Z_MASTERIDOC_CREATE_SMD_xxxxx), the function CHANGE_POINTERS_READ with my ALE Object gets no records. At this step, the same function (CHANGE_POINTERS_READ) with another ALE Object does get records.
Table BDCPS alredy contains records for my Message Type, and in those records, the "Process" field is empty.
Am I missing one step or something?
Can anyone help me please?
Thanks in advice.
Regards.

Hi everyone.
I'm trying to use the SMD tool. I've created my Message Type, and my Change Document Object(Tcode SCDO).
Priorly, I've tested the ALE Layer configuration, by sending iDocs of my message type directly with the MASTER_IDOC_DISTRIBUTE Function Module, and it works fine. I mean, I have no problem with sending iDocs or the ALE configuration.
In the transaction SCDO I've logged my Object Type, and I've assigned the table THOC (Public Holiday Calendar), from wich I want to monitoring the field DATUM, wich is flagged as "Copy as Internal Table" and "Doc. for individual fields at delete". Also in this transaction (SCDO), I've created the Update pgm.
In transaction BD95, I've inserted my ALE Object Type, and I've assigned the table THOC and the field DATUM to my Object. Field DATUM is referenced to the DATUM Data Element. Due that the Data Element DATUM isn't flagged as "Change Document", I've changed the Data Element referenced by the field DATUM for one copy of the Data Element DATUM, wich I've flagged as "Change Document".
My Message Type is alredy on the following tables:
Tcode BD50: The checkbox for monitoring Change Pointers is on.
Tcode BD52: Where I've assigned my ALE Object, the table THOC and the field KEY.
Tcode BD59: Where I've assigned to it the segment of my Message Type, and the field (same field type) wich corresponds to the field DATUM of table THOC.
Tcode BD60: The ref. msg. is the same as my Message Type, i've created the function module to create the iDocs containing the delta information (via tcode BD21 I alredy reach this FM that I've created), there's no table nor Object Type Associated (in this step I've tried both cases, with table THOC and my Object Type assigned, and both not assigned), the checkboxes "ID for reducible message type" and "BDCP2 OK" are off.
The Change Pointers in Tcode BD61 is on.
After all this configuration steps, I still cannot see logs of my Change Document Type in tables CDHDR nor CDPOS. Besides, when I run Tcode BD21 with my message type, and when the program reaches my Function Module (Z_MASTERIDOC_CREATE_SMD_xxxxx), the function CHANGE_POINTERS_READ with my ALE Object gets no records. At this step, the same function (CHANGE_POINTERS_READ) with another ALE Object does get records.
Table BDCPS alredy contains records for my Message Type, and in those records, the "Process" field is empty.
Am I missing one step or something?
Can anyone help me please?
Thanks in advice.
Regards.

How to get an idoc?

Hi gurus:
When i change a record in R/3,how can i get the record's idoc?
alex zhang

hi
U can use Change pointers:
 ALE Change Pointers
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.
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
Turn on change pointer update generally
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
Currently (release 40B) 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.
Dispatching ALE IDocs for Change Pointers
Change pointers must be processed by an ABAP, e.g. RBDMIDOC.
The actual distribution of documents from change pointers must be done by an
ABAP, which reads the change pointers and processes them. The standard ABAP
for that is RBDMIDOC. For recurring execution it can be submitted in a scheduled
job using SM35 .
Reward points for helpful ans.
Regards
Aarti

DISTRIBUTION OF ALE IDOC

HI GURUS
i want detailed distributiuon on ale idoc processing along with transaction codes step by step
plzzz its urgent
baskar

ALE
Outbound:
Step 1. Application document is created when transaction is saved.
2. Message control is invoked.
3. Messages are processed by system.
4. Messages are Edited (if desired).
5. Output (ALE / EDI) is checked
6. Validate against Message control record from Partner Profile
7. Application Document is saved.
8. Entry NAST table is created for every selected output program
along with Medium & Timing.
9. Check for Process Immediately .
If (yes)
Determine Processing Program from TNAPR Table.
ELSE
Execute RSNASTED Program.
10. Read Partner Profile to determine Process Code.
11. Process Code points to the Function Module & Invoked.
12. IDoc is generated.
13. Check for ALE Request.
if (Yes)
Perform Filters, Conversions, Version Changes etc.
Else.
IDoc is stored in DATABASE.
INBOUND:
Step 1. EDI Subsystem creates an IDoc file from EDI Messages
2. Subsystem calls Functional Module EDI_DATA_INCOMING from startRFC program.
3. Data in Control Record is validate against the Partner Profile.
4. IDoc is generated in Database and syntax check is carried out.
5. IDoc file is deleted once file read.
6. Event PROCESSSTATE REACHED is triggered in Idoc Object Workflow.
7. Check for Process Immediately.
If NO
Execute RBDAPP01 Program
Else
Read Process Code from Partner Profile
Process Code Points to Function Module
Application Document Posted.
further help:
check url
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapgenie.com/ale/configuration.htm
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapdevelopment.co.uk/training
And also u can get lots of inof from the below link.
http://www.sapgenie.com/ale/why_ale.htm
**************************************************8
http://service.sap.com/ale
ABOUT ALE AND IDOC
Go through this hope u can understand .
ALE/IDOC
IDOC Programming
There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is send to other system . Separate ABAP programs are written for these 2 processes and different configuration settings are required for each one .Depending upon the trigeering mechanism different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the database tables.
NEED FOR ABAP PROGRAMMING arises if
1)New IDOC was created
Depending upon the triggering mechanism i.e change pointer,message control
etc the programming technique changes and the type of process.
2)Existing IDOC was extended
User Exits are used to populate data in new segments added and to read them
back.
3)To enhance an exsiting process.
User Exits are used .
Basic structure of an OUTBOUND PROGRAM
The basic structure of all outbound programs is same. The CONTROL
record which is of TYPE EDIDC has to be filled. It contains important fields like
IDOCTP IDOC type
MESTYP Message Type
RCVPRN Recieving Partner (Destination)
RCVPRT Partner Type (it is LS i.e Logical System)
The DATA RECORD internal table which is of TYPE EDIDD has to be filled
in the same order as there are segments in the IDOC definition.
It has 2 important fields which are to be filled ,these are
SEGNAM Name of the segment
SEGDATA Data in the segment and can be upto 1000 bytes.This field
is corresponds to each data segment in the IDOC.
e.g.
DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.
DATA W_SEGDATA LIKE zsegment "custom segment zsegment
INT_EDIDD-SEGNAM = 'ZSEGMENT'
W_SEGDATA-field1 = value "taken from some table
W_SEGDATA-field2 = value "taken from some table
INT_EDIDD-SEGDATA = W_SEGDATA
APPEND INT_EDIDD
This will fill the data record corresponding to the segment ZSEGMENT . For all
segments the sam steps will be repeated until all the data corresponding to all the
segments in the idoc is filled in the internal table of type EDIDD.
There is only one control record and can be multile data records in the idoc
structure.
Which data is to be extracted from the tables to be filled in EDIDD type internal table is determined in standalone programs from the objects which are specified in the selection screen and from the object key passed to the function module in case of message control and is taken from BDCP table in case of change pointers using function modules "CHANGE_POINTERS_READ"
In case of stand alone programs and function modules based on change pointers method the function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for distribution ,in case of message control it is handled automatically by the RSNASTED program invoked by the message control.
OUTBOUND PROCESS AND OUTBOUND PROGRAM.
Outbound programs are used in outbound process to genearte IDOCs . There
purpose is to extract the data from the tables and to fill the IDOC data records
and the control record in the IDOC and pass ito the ALE layer for distribution to the recieving system .
Depending upon the triggering mechanism (how and when the outbound program will be started different techniques and interface is used for outbound program.
1)Message control
Application like PO(purchase order) creation use this technique , where the output type is linked to the application(Message control is a configurable cross application component which can be set in IMG .Such programs are created in the form of function modules and linked to the output type which is linked to the apllication.These have predefined interfaces.
In outbound programs(function module) that use message control the key of the
application document is passed to the function module whcig will read the data from the table depending upon the key passed(NAST structure) and fill the IDOC segemnts with the application data.The control record is also passed to the function module but is not fully filled, the rmaining fields are filled and the control is passed back to the calling program which is RSNASTED and is invoked by the
message control to process ALE and EDI output types and this program on recieving the IDOC data will create the physical IDOC in the system.
The parameteers passed to the function module are
IMPORTING PARAMETERS
OBJECT LIKE NAST
It contains documents key.
CONTROL_RECORD_IN LIKE EDIDC
It contains the partailly filled control record
EXPORETING PARAMETER
OBJECT_TYPE
CONTROL_RECORD_OUT LIKE EDIDC
TABLES
INT_EDID LIKE EDIDD
The internal table used to fill the data records in the same order as they exists in the IDOC.
The important parameters that should be filled in the custom function module are
CONTROL_RECORD_OUT and INT_EDIDD .The OBJK field of the structue NAST contains the key of the apllication document.
2)Stand alone programs
Generally used for Master Data transfer and as such depending upon the requirement can have different interfaces.The programs have a selection screen which has select options to select the objects, and parameters for specifying the recipient Logical System and the Message Type.
Data is selected based on the specified objects from the tables . and control record of type EDIDC is created and filled with important values like DIRECTION ,IDOCTP,RCVPRT,RCVPRN and MESTYP .
Data is filled in an internal table of TYPE EDIDD according to segment definitions
and in same order and the function module MASTER_IDOC_DISTRIBUTE is called passing the control record and the internal table containg IDOC data and importing an internal table consisting of control records for each communication IDOCS created.
3)Change pointer
Change Pointer table is read and checked if changes were made to important fields , if so the outbound program will be triggered automatically , these have predefined interfaces
ALE/IDOC Transaction
SALE Area Menu for ALE configurations.It includes transactions for
Logical System definition and linking it to a client, Transactions for
RFC Destination and Port Definition Etc.
SM59 RFC Destination
Here we specify the login settings for the destination including
the I.P address or Application Server name and the User name and
password.The information entered here is used to run Remote Function
Calls(RFC ) on the destination server .We can create number of types
of RFC Destinations but 3 types are important .
R/3 (R/3 to R/3), LS(logical system) and TCP/IP.
The name of the RFC destination should be same as that of Logical
System as it helps in creation of automatic partner profiles.
WE21 Port Definition.
There are 6 types of ports but only 2 types File and Transactional RFC
types of ports are important.
We have to specify the RFC Destination before a port can be created.
WE57 This is used to assign the Inbound function module to the Message Type
and to the IDOC Type.
WE42 This is used to define the process Code for Inbound Processing.
BD95 Define Filter object type .We can specify the field and the table it belongs
to as a filter object .
BD59 Assignment of Filter object type to the Message Type .Here we create the
link between Filter object and the segment and the message type and the
segment Field.
BD50 Set message Type to reducible.
BD65 Define Mandatory Fields.
BD64 Distribution Model . Also known as Customer Distribution Model Used to
define all the messages that will be exchanged between remote systems
and the name of thes logical systems. Any filters can also be specified.
The model once created has to be distributed on every system which will
be communicating ,It can be maintained on only One system.
BD21 Creating IDOcs from change pointers.
This can be used to create IDOCs from change pointers for a particular
message LIKE MATMAS.
BD22 This can be used to delete change pointers.
BD87 Status Monitor. Idocs can be selected base on number of criteria and there
processing status can be seen in detail.
BD10 Material Master Data Distribution .
Based on Message MATMAS.
BD12 Customer Master Data Distribution .
Based on Message CREMAS.
BD14 Vendor Master Data Distribution
Based on Message DEBMAS .
BDFG Generate ALE Interface for BAPI.
Here we specify the Business Object and the BAPI Function module for
which the interface has to be created.
WE31 Segment Editor.
This is used to create segments. We create the segment type and
segment definition is automatically created by editor e.g. Z1DUMMY is
segment type and Z2DUMMY is the segment definition .We specify the
fields and the data elements these cp\orresponds to create segments.
WE30 IDOC Editor
It is used to create a new IDOC Type or IDOC Extension .We specify the
segments that will be addd to the IDOC type.
WE02/05 IDOC List.
Various selct options and parameters are provided to select IDOCs
depending on the date, direction , mesage type etc.
WE20 Partner Profile
Here we create partner profile for each and every partner from / to which
the messages will be exchanged.There are 6 types of PF generally only
profiles of type LS(Logical System) ,KU(Customer) ,LI(Vendor) is used.
We specify the partner number and partner type and the agent and
the agent type responsible for handling of errors .
For every message send to the partner we have a outbound record and for
evry message coming from the partner we have the inbound record .
We specify the message in the otbound/inbound records ,double
clicking will take us to the detailed screen where the IDOC Type ,Port
and whether the IDCO will be immediatelt processed or collected are
mentioned.
Steps relate to idoc
Creation of IDoc
To Create Idoc we need to follow these steps:
1)Create Segment ( WE31)
2)Create Idoc Type ( WE30)
3)Create Message Type ( WE81)
4)Assign Idoc Type to Message Type ( WE82)
Creating a Segment
a)Go to transaction code WE31
b)Enter the name for your segment type and click on the Create icon
c)Type the short text
d)Enter the variable names and data elements
e)Save it and go back
f)Go to Edit -> Set Release
g)Follow steps to create more number of segments
Create IDOC Type
a)Go to transaction code WE30
b)Enter the Object Name, select Basic type and click Create icon
c)Select the create new option and enter a description for your basic IDOC type and press enter
d)Select the IDOC Name and click Create icon
e)The system prompts us to enter a segment type and its attributes
f)Choose the appropriate values and press Enter
g)The system transfers the name of the segment type to the IDOC editor.
h)Follow these steps to add more number of segments to Parent or as Parent-child relation
i)Save it and go back
j)Go to Edit -> Set release
Create Message Type
a)Go to transaction code WE81
b)Change the details from Display mode to Change mode
c)After selection, the system will give this message The table is cross-client (see d)Help for further info). Press Enter
e)Click New Entries to create new Message Type
f)Fill details
g)Save it and go back
Assign Message Type to IDoc Type
a)Go to transaction code WE82
b)Change the details from Display mode to Change mode
c)After selection, the system will give this message The table is cross-client (see d)Help for further info). Press Enter.
e)Click New Entries to create new Message Type.
f)Fill details
g)Save it and go back
Look at these links
ALE/ IDOC
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.sappoint.com/abap/ale.pdf
http://www.sappoint.com/abap/ale2.pdf
http://www.sapgenie.com/sapedi/idoc_abap.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm
http://www.allsaplinks.com/idoc_sample.html
http://www.sappoint.com/abap.html
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
http://www.allsaplinks.com/idoc_sample.html
ALE/ IDOC/ XML
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp
http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm
Just follow the procedure
Sending System(Outbound ALE Process)
Tcode SALE ? for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 ? Create Model View
Tcode BD82 ? Generate partner Profiles & Create Ports
Tcode BD64 ? Distribute the Model view
Message Type MATMAS
Tcode BD10 ? Send Material Data
Tcode WE05 ? Idoc List for watching any Errors
Receiving System(Inbound ALE )
Tcode SALE ? for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 ? Check for Model view whether it has distributed or not
Tcode BD82 -- Generate partner Profiles & Create Ports
Tcode BD11 Getting Material Data
Tcode WE05 ? Idoc List for inbound status codes
ALE IDOC Steps
Sending System(Outbound ALE Process)
Tcode SALE ?3 for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 !V Create Model View
Tcode BD82 !V Generate partner Profiles & Create Ports
Tcode BD64 !V Distribute the Model view
This is Receiving system Settings
Receiving System(Inbound ALE )
Tcode SALE ?3 for
a) Define Logical System
b) Assign Client to Logical System
Tcode SM59-RFC Destination
Tcode BD64 !V Check for Model view whether it has distributed or not
Tcode BD82 -- Generate partner Profiles & Create Ports
Tcode BD11 Getting Material Data
Tcode WE05 !V Idoc List for inbound status codes
Message Type MATMAS
Tcode BD10 !V Send Material Data
Tcode WE05 !V Idoc List for watching any Errors
STEP 1)a Goto Tcode SALE
Click on Sending & Receiving Systems-->Select Logical Systems
Here Define Logical Systems---> Click on Execute Button
go for new entries
-System Name : ERP000
-Description : Sending System
-System Name : ERP800
-Description : Receiving System
press Enter & Save
it will ask Request
if you want new request create new Request orpress continue for transfering the objects
B) goto Tcode SALE
Select Assign Client to Logical Systems-->Execute
000--> Double click on this
Give the following Information
-Client : ERP 000
-City :
-Logical System
-Currency
-Client role
Save this Data
Step 2) For RFC Creation
Goto Tcode SM59-->Select R/3 Connects
Click on Create Button
RFC Destination Name should be same as partner's logical system name and case sensitive
to create the ports automatically while generating the partner profiles
give the information for required fields
RFC Destination : ERP800
Connection type: 3
Description
Target Host : ERP000
System No:000
lan : EN
Client : 800
User : Login User Name
Password:
save this & Test it & RemortLogin
STEP 3) Goto Tcode BD64 -- click on Change mode button
click on create moduleview
short text : xxxxxxxxxxxxxx
Technical Neme : MODEL_ALV
save this & Press ok
select your just created modelview Name :'MODEL_ALV'.
goto add message type
Model Name : MODEL_ALV
sender : ERP000
Receiver : ERP800
Message type :MATMAS
save & Press Enter
STEP 4) Goto Tcode BD82
Give Model View : MODEL_ALV
Partner system : ERP800
execute this by press F8 Button
it will gives you sending system port No :A000000015(Like)
STEP 5) Goto Tcode BD64
select the modelview
goto >edit>modelview-->distribute
press ok & Press enter
STEP 6) goto Tcode : BD10 for Material sending
Material : mat_001
Message Type : MATMAS
Logical System : ERP800
and Execute
STEP 7)goto Tcode : BD11 for Material Receiving
Material : 100-300
Message Type : MATMAS
and Execute --> 1 request idoc created for message type Matmas
press enter
Here Master Idoc set for Messge type MATMAS-->press Enter
1 Communication Idoc generated for Message Type
this is your IDOC
Change Pointers
how to change the description of a material using ALE Change Pointers.
I will give the following few steps
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
ALE/IDOC Status Codes/Messages
01 Error --> Idoc Added
30 Error --> Idoc ready for dispatch(ALE Service)
then goto SE38 --> Execute the Program RBDMIDOC
29 Error --> ALE Service Layer
then goto SE38 --> Execute the Program RSEOUT00
03 Error --> Data Passed to Port ok
then goto SE38 --> Execute the Program RBDMOIND
12 Error --> Dispatch ok
Inbound Status Codes
50 Error --> It will go for ALE Service Layer
56 Error --> Idoc with Errors added
51 Error --> Application Document not posted
65 Error --> Error in ALE Service Layer
for 51 or 56 Errors do the following steps
goto WE19 > give the IDOC Number and Execute>
Press on Inbound function Module
for 65 Error --> goto SE38 --> Execute the Program RBDAPP01 then your getting 51 Error
Regards
vasu

Change pointers for customizing table

Hi,
Requirement is when ever a new entry is created/updated/deleted from the customized table 'ztable' an IDOC need to be generated.
Any one can help me out the proper steps to solve this.
Full points will be rewarded to the correct answer.
Urgent please !!!
Regards,
Suman

1. In T-Code add all the table and its fields to a message type.
2. Create a program for triggering a Idoc.
3. In the program call the functional module 'CHANGE_POINTERS_READ' with the above message type, This FM will return those table fields that are changed to a specific date.
4. Pass read_not_processed_pointers parameter of the 'CHANGE_POINTERS_READ'   as 'X' to get the latest changes. Ex:
        CALL FUNCTION 'CHANGE_POINTERS_READ'
          EXPORTING
            message_type                = gc_message_type
            creation_date_high          = s_erdat-high
            creation_date_low           = s_erdat-low
            creation_time_high          = gc_time_high
            creation_time_low           = gc_time_low
            read_not_processed_pointers = 'X'
          TABLES
            change_pointers             = lt_chgptrs_tab.
lt_chgptrs_tab will have all the table fields that are changed .
5. Trigger a Idoc with those values.
6. In the triggering is successful call FM 'CHANGE_POINTERS_STATUS_WRITE ' and pass those table fields that are sent through Idoc to write in database that the changes are already sent through Idocs. Ex:
    CALL FUNCTION 'CHANGE_POINTERS_STATUS_WRITE'
            EXPORTING
              message_type           = gc_message_type
            TABLES
              change_pointers_idents = gt_pointer_id.
          COMMIT WORK.
gt_pointer_id will have all the change pointer if from lt_chgptrs_tab table that are send through Idocs.

Multiple changes per HMRD outbound IDoc

We are currently implementing HR (SAP ECC 6.0) and having a problem with HRMD outbound IDocs.
Currently the system is creating a change pointer each time an Employee record is changed - we then run RBDMIDOC for the message type and it creates one IDoc for all changed employees using message type HRMD_A07.
However, we'd like to have one IDoc per employee change - so if 10 employees are changed we get 10 IDocs. Is this possible? (The reason is that the recipient system will send an ALEAUD message for each IDoc and we want to be able to identify the specific employee that failed in the event of any errors).
I think the problem is caused by the message type HRMD_A07 having a maximum of 9999999999 E1PLOGI segments. We don't want to create a bespoke message type so any suggestions would be appreciated.
Thanks and regards,
JB

I don't think there is standard program to handle the scenario. But my suggestion is to create Z Report.
Inside the Z report the call the Standard function module
CHANGE_POINTERS_READ which will return the change pointers, from the list of change pointer get the objects for which IDOC needs to be generated.
With this data call the standard report RHALEINI, in a loop for each employee.
The report will generate an IDOC for each call. U can check whether the IDOC is generated or not, by importing values from the memory ID COMM_HRMD_A into table COMM_CONTROL. if IDOC is generated successfully, call the functon module CHANGE_POINTERS_STATUS_WRITE to update the status of the change pointers.
This logic will Useful. Kindly award points, if satisfies ur requiement
With regards
K.Varadharajan

What is memory idoc , communication idoc

plz tell me about
         memory idoc , communication idoc.

hi kalyan,
Master IDOC : This idoc collects all the required data into
single IDOC and this is temporarily stored in memory.
Communication IDOC: there can be n number of communication
IDOCs generated. This comes into picture after the Master
IDOC is validated from the distribution model . And this
IDOC is stored in database table . you can see this IDOC
from we02 tcode..comm idoc is the physical idoc which is reciever specific
IDOC Programming
There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is send to other system . Separate ABAP programs are written for these 2 processes and different configuration settings are required for each one .Depending upon the trigeering mechanism different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the database tables.
NEED FOR ABAP PROGRAMMING arises if
1)New IDOC was created
   Depending upon the triggering mechanism i.e change pointer,message control
   etc the programming technique changes and the type of process.
2)Existing IDOC was extended
   User Exits are used to populate data in new segments added and to read them
   back.
3)To enhance an exsiting process.
   User Exits are used .
Basic structure of an OUTBOUND PROGRAM
The basic structure of all outbound programs is same. The CONTROL
record which is of TYPE EDIDC has to be filled. It contains important fields like
IDOCTP      IDOC type
MESTYP    Message Type
RCVPRN    Recieving Partner (Destination)
RCVPRT    Partner Type (it is LS i.e Logical System)
The DATA RECORD internal table which is of TYPE EDIDD has to be filled
in the same order as there are segments in the IDOC definition.
It has 2 important fields which are to be filled ,these are
SEGNAM Name of the segment
SEGDATA Data in the segment and can be upto 1000 bytes.This field
                is corresponds to each data segment in the IDOC.
e.g.
DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.
DATA W_SEGDATA LIKE zsegment "custom segment zsegment
       INT_EDIDD-SEGNAM = 'ZSEGMENT'
       W_SEGDATA-field1 = value    "taken from some table
       W_SEGDATA-field2 = value    "taken from some table
       INT_EDIDD-SEGDATA = W_SEGDATA
       APPEND INT_EDIDD
This will fill the data record corresponding to the segment ZSEGMENT . For all
segments the sam steps will be repeated until all the data corresponding to all the
segments in the idoc is filled in the internal table of type EDIDD.
      There is only one control record and can be multile data records in the idoc
structure.
Which data is to be extracted from the tables to be filled in EDIDD type internal table is determined in standalone programs from the objects which are specified in the selection screen and from the object key passed to the function module in case of message control and is taken from BDCP table in case of change pointers using function modules "CHANGE_POINTERS_READ"
      In case of stand alone programs and function modules based on change pointers method the function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for distribution ,in case of message control it is handled automatically by the RSNASTED program invoked by the message control.
OUTBOUND PROCESS AND OUTBOUND PROGRAM
Outbound programs are used in outbound process to genearte IDOCs . There
purpose is to extract the data from the tables and to fill the IDOC data records
and the control record in the IDOC and pass ito the ALE layer for distribution to the recieving system .
Depending upon the triggering mechanism (how and when the outbound program will be started different techniques and interface is used for outbound program.
1)Message control
Application like PO(purchase order) creation use this technique , where the output type is linked to the application(Message control is a configurable cross application component which can be set in IMG .Such programs are created in the form of function modules and linked to the output type which is linked to the apllication.These have predefined interfaces.
In outbound programs(function module) that use message control the key of the
application document is passed to the function module whcig will read the data from the table depending upon the key passed(NAST structure) and fill the IDOC segemnts with the application data.The control record is also passed to the function module but is not fully filled, the rmaining fields are filled and the control is passed back to the calling program which is RSNASTED and is invoked by the
message control to process ALE and EDI output types and this program on recieving the IDOC data will create the physical IDOC in the system.
The parameteers passed to the function module are
IMPORTING PARAMETERS
OBJECT LIKE NAST
It contains documents key.
CONTROL_RECORD_IN LIKE EDIDC
It contains the partailly filled control record
EXPORETING PARAMETER
OBJECT_TYPE
CONTROL_RECORD_OUT LIKE EDIDC
TABLES
INT_EDID LIKE EDIDD
The internal table used to fill the data records in the same order as they exists in
the IDOC.
The important parameters that should be filled in the custom function module are
CONTROL_RECORD_OUT and INT_EDIDD .The OBJK field of the structue NAST contains the key of the apllication document.
2)Stand alone programs
Generally used for Master Data transfer and as such depending upon the requirement can have different interfaces.The programs have a selection screen which has select options to select the objects, and parameters for specifying the recipient Logical System and the Message Type.
Data is selected based on the specified objects from the tables . and control record of type EDIDC is created and filled with important values like DIRECTION ,IDOCTP,RCVPRT,RCVPRN and MESTYP .
Data is filled in an internal table of TYPE EDIDD according to segment definitions
and in same order and the function module MASTER_IDOC_DISTRIBUTE is called passing the control record and the internal table containg IDOC data and importing an internal table consisting of control records for each communication IDOCS created.
3)Change pointer
Change Pointer table is read and checked if changes were made to important fields , if so the outbound program will be triggered automatically , these have predefined interfaces
thanks
abdul
reward me if usefull

Change_pointers_read FM

Similar Messages

Maybe you are looking for