SAP ABAP

ERP basis and sap netweaver overview

Data Ports ( WE21 ) in idoc

IDoc data can be sent and received through a multitude of different media. In order to decouple the definition of the media characteristics from the application using it, the media is accessed via ports.A port is a logical name for an input/output device. A program talks to a port which is presented to it with a common standard interface. The port takes care of the translation between the standard interface format and the device dependent format.Communication media is defined via a port definition.

Instead of defining the communication path directly in the partner profile, a port number is assigned. The port number then designates the actual medium. This allows you to define the characteristics of a port individually and use that port in multiple profiles. Changes in the port will then reflect automatically to all profiles without touching them.

Typical ports for data exchange :

• Disk file with a fixed name
• Disk file with dynamic names
• Disk file with trigger of a batch routine
• Standard RFC connection via TCP/IP
• A network channel
• TCP/IP FTP destination (The Internet)
• Call to a individual program e.g. EDI converter

Every application should send or receive its data via the logical ports only. This allows you to easily change the hardware and software used to make the physical I/O connection without interfering with the program itself.The transactions used to define the ports are

• WE21 to create the port and assign a logical name, and
• SM59 to define the physical characteristics of the I/O device used.

The difference between the port types is mainly the length of some fields. E.g. does port type 3 allow segment names up to 30 characters in length, while port type 3 is constrained to a maximum segment name of 8 characters.

related post

ABAP IDOC'S INTRODUCTION
IDOC'S MESSAGE CONTROL
DIFFERENCE BETWEEN IDOC AND BAPI
IDOC'S OUT BOUND TRIGGERING
ERP Master data and data warehouse concept

ERP sap Business process cycle for abaper

Defining the partner profile for ALE IDOC

The transaction WE20 is used to set up the partner profile.

WE20 :

The profiles are defined with transaction WE20, which is also found in the EDI master menu WEDI. From there you need to specify partner and partner type and whether you define a profile for inbound or outbound. Additionally, you may assign the profile to a NAST message type.

Partner type :

e.g. : LI=Supplier ,CU=Customer, LS=Logical system

The partner type defines from which master data set the partner number originates.The partner types are the ones which are used in the standard applications for SD, MM or FI. The most important types for EDI are LI (=Lieferant, supplier), CU (Customer) or LS (Logical system). The logical system is of special interest when you exchange data with computer subsystems via ALE or other RFC means.

Inbound and outbound definitions :

For every partner and every direction of communication, whether you receive or send IDocs, a different profile is maintained. The inbound profile defines the processing routine. The outbound profile defines mainly the target, where to send the data .

Link message type to outbound profile :

If you send IDocs out of an application’s messaging, i.e. a communication via the NAST table, then you have to link the message type with an IDoc profile. This is also done in transaction WE20.

Inbound profiles determine the processing logic :

The processing code is a logical name for the processing function module or object method. The processing code is used to uniquely determine a function module that will process the received IDoc data. The inbound profile will point to a processing code.

MYSAP ERP advantages and main features

ERP Master data and data warehouse concept

Partner Profiles and Ports

R/3 defines partner profiles for every EDI partner. The profiles are used to declare the communication channels, schedule, and conditions of processing.Partner profiles declare the communication medium to be used with a partner.Ports define the physical characteristics of a communication channel.If you define an ALE scenario for your IDoc partners, you can use the ALE automated partner profile generation ( → ALE ).

IDoc Type and Message Type

An IDoc file requires a minimum of accompanying information to give sense to it. These are the message type and the IDoc type. While the IDoc type tells you about the fields and segments of the IDoc file, the message type flags the context under which the IDoc was sent.

IDoc type signals syntactical structure :

A receiver of an IDoc must know the exact syntactical structure of the data package received. Naturally, the receiver only sees a text file with lines of characters.In order to interpret it, it is necessary to know which segment types the file may contain and how a segment is structured into fields. SAP sends the name of the IDoc type in the communication header.

The IDoc type describes the file structure. The IDoc type is defined and viewable with transaction WE30.

Examples of IDoc types are MATMAS01, ORDERS01, COND_A01 or CLSMAS01.

The message type is an identifier that tags the IDoc to tell the receiver how the IDoc is meant to be interpreted. It is therefore the tag for the semantic content of the IDoc.

Examples of message types are MATMAS, ORDERS, COND_A or CLSMAS.

The combination of IDoc type and message type gives the IDoc the full meaning. Theoretically, you could define only a single IDoc type for every IDoc you send. Then, all IDocs would have the same segments and the segments would always have the same field structure. According to the context some of the record fields are filled; others are simply void. Many antiquated interfaces are still working that way.Typical combinations of IDoc and message types are the following:

Message Type IDoc Type

Sales order, older format ORDERS ORDERS01

Sales order, newer format ORDERS ORDERS02

Purchase Requisition PURREQ ORDERS01

The example shows you that sales orders can be exchanged in different file formats. There may be some customers who accept the latest IDoc format ORDERS02, while others still insist on receiving the old format ORDERS01.

The IDoc format for sales orders would also be used to transfer a purchase requisition. While the format remains the same, the different message type signals that it is not an actual order but a request.Partner profiles play an important role in EDI communications. They are parameter files which store the EDI partner dependent information.Partner profiles define the type of data and communication paths of data to be exchanged between partner .

When data is exchanged between partners, it is important that sender and receiver agree on the exact syntax and semantics of the data to be exchanged. This agreement is called a partner profile and tells the receiver the structure of the sent file and how its content is to be interpreted.For any combination of message type and receiving partner, a profile is maintained .

The following information is defined with the partner profile.

• IDoc type and message type as key identifier of the partner profile

• Names of sender and receiver to exchange the IDoc information for the respective IDoc and message type .

• Logical port name via which the sender and receiver, resp. will communicate

The communication media is assigned by the profile.

If you exchange e.g. sales orders with partners, you may do this via different media with different customers. There may be one customer to communicate with you via TCP/IP (the Internet) while the other still insists on receiving diskette files.

Profiles cannot be transported :

They must be defined for every R/3 client individually. They cannot be transported using the R/3 transport management system. This is because the profile contains the name of the sending system, which is naturally different for consolidation and production systems.

Profiles define the allowed EDI connections :

The profiles allow you to open and close EDI connection with individual partners and specify in detail which IDocs are to be exchanged via the interface.

Profiles can also used to block an EDI communication :

The profile is also the place to lock permanently or temporarily an IDoc communication with an EDI partner. So you shut the gate for external communication with the profile.

ABAP IDOC'S PROCESSING

IDOC'S OUTLOOK

Converting Data into IDoc Segment Format

The physical format of the IDocs records is always the same. Therefore, the application data must be converted into a 1000 character string.

Fill the data segments which make up the IDoc :

An IDoc is a file with a rigid formal structure. This allows the correspondents to correctly interpret the IDoc information. Were it for data exchange between SAPsystems only, the IDoc segments could be simply structured like the correspondent DDIC structure of the tables whose data is sent.

However, IDocs are usually transported to a variety of legacy systems which do not run SAP. Both correspondents therefore would agree on an IDoc structure which is known to the sending and the receiving processes.

Transfer the whole IDoc to an internal table, having the structure of EDIDD :

All data needs to be compiled in an internal table with the structure of the standard SAP table EDIDD. The records for EDIDD are principally made up of a header string describing the segment and a variable length character field (called SDATA) which will contain the actual segment data.

FORM PACK_LINE TABLES IDOC_DATA USING 'THEAD' E_THEAD.

TABLES: THEAD.

MOVE-CORRESPONDING E:THEAD to Z1THEAD.

MOVE ‚Z1THEAD’ TO IDOC_DATA-SEGNAM.

MOVE Z1THEAD TO IDOC_DATA-SDATA.

APPEND IDOC_DATA.

ENDFORM.“

Fill control record :

Finally, the control record has to be filled with meaningful data, especially telling the IDoc type and message type.

IF IDOC_CONTRL-SNDPRN IS INITIAL.

SELECT SINGLE * FROM T000 WHERE MANDT EQ SY-MANDT.

MOVE T000-LOGSYS TO IDOC_CONTRL-SNDPRN.

ENDIF.

IDOC_CONTRL-SNDPRT = 'LS'.

* Trans we20 -> Outbound Controls muss entsprechend gesetzt werden.

* 2 = Transfer IDoc immediately

* 4 = Collect IDocs

IDOC_CONTRL-OUTMOD = '2'. "1=imediately, subsystem

CLEAR IDOC_CONTRL.

IDOC_CONTRL-IDOCTP = 'YAXX_TEXT'.

APPEND IDOC_CONTRL.

IDOC'S OUT BOUND TRIGGERING

Developing an Outbound IDoc Function

This is an individual coding part where you need to retrieve the information from the database and prepare it in the form the recipient of the IDoc will expect the data.

Read data to send :

The first step is reading the data from the database, the one you want to send.

FUNCTION Y_AXX_COOKBOOK_TEXT_IDOC_OUTB.

*"----------------------------------------------------------------------

*"*"Lokale Schnittstelle:

*" IMPORTING

*" VALUE(I_TDOBJECT) LIKE THEAD-TDOBJECT DEFAULT 'TEXT'

*" VALUE(I_TDID) LIKE THEAD-TDID DEFAULT 'ST'

*" VALUE(I_TDNAME) LIKE THEAD-TDNAME

*" VALUE(I_TDSPRAS) LIKE THEAD-TDSPRAS DEFAULT SY-LANGU

*" EXPORTING

*" VALUE(E_THEAD) LIKE THEAD STRUCTURE THEAD

*" TABLES

*" IDOC_DATA STRUCTURE EDIDD OPTIONAL

*" IDOC_CONTRL STRUCTURE EDIDC OPTIONAL

*" TLINES STRUCTURE TLINE OPTIONAL

*" EXCEPTIONS

*" FUNCTION_NOT_EXIST

*" VERSION_NOT_FOUND

*"----------------------------------------------------------------------

CALL FUNCTION 'READ_TEXT'

EXPORTING

ID = ID

LANGUAGE = LANGUAGE

NAME = NAME

OBJECT = OBJECT

TABLES

LINES = LINES.

* now stuff the data into the Idoc record format

PERFORM PACK_LINE TABLES IDOC_DATA USING 'THEAD' E_THEAD.

LOOP AT LINES.

PERFORM PACK_LINE TABLES IDOC_DATA USING 'THEAD' LINES.

ENDLOOP.

ENDFUNCTION.

Converting Data into IDoc Segment Format :

The physical format of the IDocs records is always the same. Therefore, the application data must be converted into a 1000 character string.

Fill the data segments which make up the IDoc :

Transfer the whole IDoc to an internal table, having the structure of EDIDD :

FORM PACK_LINE TABLES IDOC_DATA USING 'THEAD' E_THEAD.

TABLES: THEAD.

MOVE-CORRESPONDING E:THEAD to Z1THEAD.

MOVE ‚Z1THEAD’ TO IDOC_DATA-SEGNAM.

MOVE Z1THEAD TO IDOC_DATA-SDATA.

APPEND IDOC_DATA.

ENDFORM.“

Fill control record :

Finally, the control record has to be filled with meaningful data, especially telling the IDoc type and message type.

IF IDOC_CONTRL-SNDPRN IS INITIAL.

SELECT SINGLE * FROM T000 WHERE MANDT EQ SY-MANDT.

MOVE T000-LOGSYS TO IDOC_CONTRL-SNDPRN.

ENDIF.

IDOC_CONTRL-SNDPRT = 'LS'.

* Trans we20 -> Outbound Controls muss entsprechend gesetzt werden.

* 2 = Transfer IDoc immediately

* 4 = Collect IDocs

IDOC_CONTRL-OUTMOD = '2'. "1=imediately, subsystem

CLEAR IDOC_CONTRL.

IDOC_CONTRL-IDOCTP = 'YAXX_TEXT'.

APPEND IDOC_CONTRL.

outbound triggaring part 3

ale change pointers

creation of idoc data

IDOC'S OUT BOUND TRIGGERING

Creation of the IDoc Data

R/3 provides a sophisticated IDoc processing framework. This framework determines a function module which is responsible for creating or processing the IDoc.

Function module to generate the IDoc :

The kernel of the IDoc processing is always a distinct function module. For the outbound processing, the function module creates the IDoc and leaves it in an internal table, which is passed as an interface parameter.During inbound processing the function module receives the IDoc via an interface parameter table. It would interpret the IDoc data and typically update the database either directly or via a call transaction.

Function are called dynamically :

The function modules are called dynamically from a standard routine. Therefore, the function must adhere to a well-defined interface.

Function group EDIN with useful routines :

You may want to investigate the function group EDIN, which contains a number of IDoc handler routines and would call the customised function.

Copy and modify existing routines :

The easiest way to start the development of an outbound IDoc function module is to copy an existing one. There are many samples in the standard R/3 repository'; most are named IDOC_OUTBOUND* or IDOC_OUTPUT*

Outbound sample functions are named like IDOC_OUTPUT* :

FUNCTION IDOC_OUTPUT_ORDERS01

Inbound sample functions are named like IDOC_INPUT* :

FUNCTION IDOC_INPUT_ORDERS01

Outbound sample functions for master data are named like MASTERIDOC_INPUT* :

FUNCTION MASTERIDOC_CREATE_MATMAS

Interface Structure of IDoc Processing Functions

To use the standard IDoc processing mechanism, the processing function module must have certain interface parameters because the function is called dynamically from a standard routine.The automated IDoc processor will call your function module from within the program RSNASTED, usually either from the FORM ALE_PROCESSING or EDI_PROCESSING.In order to be compatible with this automated call, the interface of the function module must be compliant.

FUNCTION Z_IDOC_OUTBOUND_SAMPLE.

*" IMPORTING

*" VALUE(FL_TEST) LIKE RS38L-OPTIONAL DEFAULT 'X'

*" VALUE(FL_COMMIT) LIKE RS38L-OPTIONAL DEFAULT SPACE

*" EXPORTING

*" VALUE(F_IDOC_HEADER) LIKE EDIDC STRUCTURE EDIDC

*" TABLES

*" T_IDOC_CONTRL STRUCTURE EDIDC

*" T_IDOC_DATA STRUCTURE EDIDD

*" CHANGING

*" VALUE(CONTROL_RECORD_IN) LIKE EDIDC STRUCTURE EDIDC

*" VALUE(OBJECT) LIKE NAST STRUCTURE NAST

*" EXCEPTIONS

*" ERROR_IN_IDOC_CONTROL

*" ERROR_WRITING_IDOC_STATUS

*" ERROR_IN_IDOC_DATA

*" SENDING_LOGICAL_SYSTEM_UNKNOWN

*" UNKNOWN_ERROR

Inbound functions are also called via a standard mechanism.

FUNCTION IDOC_INPUT_SOMETHING.

*" IMPORTING

*" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD

*" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC

*" EXPORTING

*" VALUE(WORKFLOW_RESULT) LIKE BDWFAP_PAR-RESULT

*" VALUE(APPLICATION_VARIABLE) LIKE BDWFAP_PAR-APPL_VAR

*" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK

*" VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS

*" TABLES

*" IDOC_CONTRL STRUCTURE EDIDC

*" IDOC_DATA STRUCTURE EDIDD

*" IDOC_STATUS STRUCTURE BDIDOCSTAT

*" RETURN_VARIABLES STRUCTURE BDWFRETVAR

*" SERIALIZATION_INFO STRUCTURE BDI_SER

outbound triggaring part 3

ale change pointers

IDOC design and Processing

IDocs are usually created in a four step process: retrieving the data, converting it to IDoc format, adding a control record, and delivering the IDoc to a port.

Collect data from R/3 database :

This is the single most important task in outbound processing. You have to identify the database tables and data dependencies which are needed in the IDoc to be sent.The smartest way is usually to select the data from the database into an internal table using SELECT * FROM dbtable INTO itab ... WHERE ...

Wrap data in IDoc format :

The collected data must be transformed into ASCII data and filled into the predefined IDoc segment structures. The segment definitions are done with transaction WE31 and the segments allowed in an IDoc type are set up in transaction WE30. Segments defined with WE31 are automatically created as SAP DDIC structures. They can be viewed with SE11, however, they cannot be edited.

Create the IDoc control record :

Every IDoc must be accompanied by a control record which must contain at least the Idoc type to identify the syntactical structure of the data and the name and role of the sender and the receiver. This header information is checked against the partner definitions for outbound. Only if a matching partner definition exists, can the IDoc be sent. Partner definitions are set up with transaction WE20.

Send data to port :

When the partner profile check matches, the IDoc is forwarded to a logical port, which is also assigned in the partner profile. This port is set up with transaction

WE21 and defines the medium to transport the IDoc, e.g. file or RFC.

The RFC destinations are set up with transaction SM57 and must also be entered in table TBDLS with an SM31 view. Directories for outbound locations of files are set up

with transaction FILE and directly in WE21. It also allows the use of a function

module which generates file names. Standard functions for that purpose begin like

EDI_FILE*.

How SAP Standard Processes Inbound IDocs :

When you receive an IDoc the standard way, the data is stored in the IDoc base and a function module is called, which decides how to process the received information.

EDID4 - Data :

Data is stored in table EDID4 (EDID3 up to release 3.xx, EDIDD up to release 2.xx)

EDIDC - Control Record :

An accompanying control record with important context and administrative

information is stored in table EDIDC.

Event signals readiness :

After the data is stored in the IDoc base tables, an event is fired to signal that there is an IDoc waiting for processing. This event is consumed by the IDoc handler, which decides, whether to process the IDoc immediately, postpone processing, or decline activity for whatever reason.

EDIFCT - Processing function :

When the IDoc processor thinks it is time to process the IDoc it will search the table EDIFCT , where it should find the name of a function module which will be called to process the IDoc data.

This function module is the heart of all inbound processing. The IDoc processor will

call this routine and pass the IDoc data from EDID4 and the control record from

EDIDC for the respective IDoc.

Function has a fixed interface :

Because this routine is called dynamically, it must adhere to a strict convention All

function interface parameters must exactly match the calling convention.

EDIDS - Status log :

The processing steps and their respective status results are stored in table EDIDS.

Status must be logged properly :

In addition, the routine has to properly determine the next status of the IDoc in table EDIDS; usually it will be EDIDS-STATU = 53 for OK or 51 for error.

(74)

ABAP IDOC'S PROCESSING

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 .

It then calls dynamically a function module whose name is stored in table TBDME for each message type.

Call Function Tbdme-Idocfbname

Exporting

Message_Type = Mestyp

Creation_Date_High = Date

Creation_Time_High = Time

Exceptions

Error_Code_1.

Example :

A complex example for a function module, which collects the change pointers, can be examined in:

MASTERIDOC_CREATE_SMD_DEBMAS .

This one reads change pointers for debtors (customer masters). During the processing, it calls the actual IDoc creating module

MASTERIDOC_CREATE_DEBMAS .

To summarize the change pointer concept

• Change pointers record relevant updates of transaction data

• Change pointers are written separate from the change documents, while at the same time

• Change pointers are evaluated by a collector run

BDCPS : Change pointer: Status

BDCP : Change pointer

BDCPV : A view with BDCP and BDCPS combined: Change pointer with status

TBDA2 :

Declare activate message types for change pointers with view V_TBDA2.or transaction BD50 or .

SALE -> Activate change pointers for message types

TBD62 : The view V_TBD62 defines those fields which are relevant for change pointer creation. The table is evaluated by the CHANGE_DOCUMENT_CLOSE function.The object is the same used by the change document. To find out the object name,look for CHANGE_DOCUMENT_CLOSE in the transaction you are inspecting or see table CDHDR for traces.

Tables involved in change pointers processing :

Object

Table name

Field

DEBI

KNA1

NAME3

DEBI

Kann1

ORT01

DEBI

Kann1

REGIO

ABAP IDOC'S PROCESSING

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 field’s 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.