SAP ABAP ALE and IDOC Explained

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

IDOC ALE Transactions

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 these 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 corresponds 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 add to the IDOC

type.

WE02/05 IDOC List. Various select options and parameters are provided to select IDOCs depending on the date, direction ,

message 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 every message coming from the partner we have the inbound record.

We specify the message in the outbound/inbound records, double clicking will take us to the detailed screen where the

IDOC Type, Port and whether the IDOC will be immediately processed or collected are mentioned.

IDOC Status Code

Status Description

00 Not used, only R/2 01 IDoc generated

02 Error passing data to port 03 Data passed to port OK

04 Error within control information of EDI subsystem 05 Error during translation

06 Translation OK 07 Error during syntax check

08 Syntax check OK 09 Error during interchange handling

10 Interchange handling OK 11 Error during dispatch

12 Dispatch OK

13 Retransmission OK 14 Interchange Acknowledgement positive

15 Interchange Acknowledgement negative 16 Functional Acknowledgement positive

17 Functional Acknowledgement negative 18 Triggering EDI subsystem OK

19 Data transfer for test OK 20 Error triggering EDI subsystem

21 Error passing data for test 22 Dispatch OK, acknowledgement still due

23 Error during retransmission 24 Control information of EDI subsystem OK

25 Processing despite syntax error (outbound) 26 Error during syntax check of IDoc (outbound)

27 Error in dispatch level (ALE service)

28 Not used 29 Error in ALE service

30 IDoc ready for dispatch (ALE service) 31 Error - no further processing

32 IDoc was edited 33 Original of an IDoc which was edited

34 Error in control record of IDoc 35 IDoc reloaded from archive

36 Electronic signature not performed (timeout) 37 IDoc added incorrectly

38 IDoc archived 39 IDoc is in the target system (ALE service)

40 Application document not created in target system 41 Application document created in target system

42 IDoc was created by test transaction

50 IDoc added 51 Application document not posted

52 Application document not fully posted 53 Application document posted

54 Error during formal application check 55 Formal application check OK

56 IDoc with errors added 57 Test IDoc: Error during application check

58 IDoc copy from R/2 connection 59 Not used

60 Error during syntax check of IDoc (inbound) 61 Processing despite syntax error (inbound)

62 IDoc passed to application

63 Error passing IDoc to application

64 IDoc ready to be transferred to application 65 Error in ALE service

66 IDoc is waiting for predecessor IDoc (serialization) 67 Not used

68 Error - no further processing 69 IDoc was edited

70 Original of an IDoc which was edited 71 IDoc reloaded from archive

72 Not used, only R/2 73 IDoc archived

74 IDoc was created by test transaction

IDOC Functions

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' EXPORTING

VALUE(MASTER_IDOC_CONTROL) LIKE EDIDC STRUCTURE EDIDC

" Control record of master IDoc VALUE(OBJ_TYPE) LIKE SERIAL-OBJ_TYPE DEFAULT ''

VALUE(CHNUM) LIKE SERIAL-CHNUM DEFAULT '' TABLES

COMMUNICATION_IDOC_CONTROL STRUCTURE EDIDC " Control records of created comm. IDocs

MASTER_IDOC_DATA STRUCTURE EDIDD " Data records of master IDoc

EXCEPTIONS ERROR_IN_IDOC_CONTROL

" Incorrect entry in IDoc control record

ERROR_WRITING_IDOC_STATUS " Error when writing IDoc status records

ERROR_IN_IDOC_DATA " Incorrect entry in IDoc data records

SENDING_LOGICAL_SYSTEM_UNKNOWN " Own logical system unknown

CALL FUNCTION 'CHANGE_POINTERS_READ'

EXPPORTING VALUE(ACTIVATION_DATE_HIGH) LIKE SY-DATUM DEFAULT

SPACE VALUE(ACTIVATION_DATE_LOW) LIKE SY-DATUM DEFAULT SPACE

VALUE(ACTIVATION_TIME_HIGH) LIKE SY-UZEIT DEFAULT

'000000' VALUE(ACTIVATION_TIME_LOW) LIKE SY-UZEIT DEFAULT

'000000' VALUE(CHANGE_DOCUMENT_OBJECT_CLASS) LIKE CDPOS-

OBJECTCLAS DEFAULT SPACE

VALUE(CREATION_DATE_HIGH) LIKE SY-DATUM DEFAULT SPACE VALUE(CREATION_DATE_LOW) LIKE SY-DATUM DEFAULT SPACE

VALUE(CREATION_TIME_HIGH) LIKE SY-UZEIT DEFAULT '000000' VALUE(CREATION_TIME_LOW) LIKE SY-UZEIT DEFAULT '000000'

VALUE(MESSAGE_TYPE) LIKE BDCPS-MESTYPE VALUE(READ_NOT_PROCESSED_POINTERS) LIKE BDCPS-

PROCESS DEFAULT 'X'

TABLES

CHANGE_POINTERS STRUCTURE BDCP MESSAGE_TYPES STRUCTURE BDMSGTYP OPTIONAL

EXCEPTIONS ERROR_IN_DATE_INTERVAL

ERROR_IN_TIME_INTERVAL

CALL FUNCTION change_pointers_status_write.

IMPORTING VALUE(MESSAGE_TYPE) LIKE EDIDC-MESTYP

TABLES CHANGE_POINTERS_IDENTS STRUCTURE BDICPIDENT

Examples of Inbound function modules are

IDOC_INPUT_BLAOCH IDoc inbound processing: change

Ccontract IDOC_INPUT_BLAORD IDoc inbound processing: Create

Contract IDOC_INPUT_MATMAS01 IDoc inbound processing: Material

Master

Examples of Outbound function modules are IDOC_OUTPUT_BLAOCH

IDOC_OUTPUT_BLAORD