The declaration of valid combinations is done to allow validation, if the system can
handle a certain combination.



The combination of message type and IDoc type determine the processing algorithm. This is
usually a function module with a well defined interface or a SAP business object and is set up
in table EDIFCT.
The entry made here points to a function module which will be called when the IDoc
is to be processed.

The entries for message code and message function are usually left blank. They can
be used to derive sub types of messages together with the partner profile used.
Figure 25: Assign a handler function to a message/message type
The definition for inbound and outbound IDocs is analogous. Of course, the function
module will be different.

R/3 uses the method of logical process codes to detach the IDoc processing and the
processing function module. They assign a logical name to the function instead of specifying the physical function name.

The IDoc functions are often used for a series of message type/IDoc type
combination. It is necessary to replace the processing function by a different one.
E.g. when you make a copy of a standard function to avoid modifying the standard.
The combination message type/IDoc will determine the logical processing code,
which itself points to a function. If the function changes, only the definition of the processing codes will be changed and the new function will be immediately
effective for all IDocs associated with the process code.

For inbound processing codes you have to specify the method to use for the
determination of the inbound function.



This is the option you would usually choose. It allows processing via the ALE
scenarios.



After defining the processing code you have to assign it to one or several logical
message types. This declaration is used to validate, if a message can be handled by
the receiving system.

The inbound processing code is assigned analogously. The processing code is a pointer to a function module which can handle the inbound request for the specified IDoc and message type.

The definition of the processing code is identifying the handler routine and assigning a serious of processing options.

You need to click "Processing with ALE", if your function can be used via the ALE
engine. This is the option you would usually choose. It allows processing via the
ALE scenarios.



Associate a function module with a process code
For inbound processing you need to indicate whether the function will be capable of
dialog processing. This is meant for those functions which process the inbound data
via call transaction. Those functions can be replayed in visible batch input mode to
check why the processing might have failed.






RELATED LINKS

IDocs should be sent out at certain events. Therefore you have to define a trigger. A lot of consideration is required to determine the correct moment when to send out the IDoc. The IDoc can be triggered at a certain time or when an event is raised. R/3 uses several completely different methods to determine the trigger point.

There are messages to tell the system that there is an IDoc waiting for dispatching, there are log files which may be evaluated to see if IDocs are due to send and there can be a workflow chain triggered, which includes the sending of the IDoc.

The simplest way to create IDocs, is to write an ABAP. The individual ABAP can either be a triggering ABAP which runs at certain events, e.g. every night, or it can be an ABAP which does the complete IDoc creation from scratch.


A triggering ABAP would simply try to determine which IDocs need sending and
call the appropriate IDoc creation routines.

You may also imagine the ABAP to do all the job. As this is mostly reinventing the
wheel, it is not really recommended and should be reserved to situation, where the
other solution do not provide an appropriate mean.


You can use the R/3 message concept to trigger IDocs the same way as you trigger SAPscript printing.

One of the key tables in R/3 is the table NAST. This table records reminders written
by applications. Those reminders are called messages.

Every time when an applications sees the necessity to pass information to a third
party. a message is written to NAST. A message handler will eventually check the
entries in the table and cause an appropriate action.

The concept of NAST messages has originally been designed for triggering
SAPscript printing. The very same mechanism is used for IDocs, where the IDoc
processor replaces the print task, as an IDoc is only the paperless form of a printed
document.

The messages are usually be created using the condition technique, a mechanism
available to all major R/3 applications.

The conditions are set up the same way for any output media. So you may define a
condition for printing a document and then just change the output media from
printer to IDoc/EDI or ALE.

Creating NAST messages is a standard functionality in most of the SAP core
applications. Those applications - e.g. VA01, ME21 - perform calls to the central
function module MESSAGING of group V61B. The function module uses
customizing entries, mainly those of the tables T681* to T685*.

A NAST output message is stored as a single record in the table NAST. The record
stores all information that is necessary to create an IDoc. This includes mainly an
object key to identify the processed object and application to the message handler
and the sender and receiver information.


Creating NAST messages is a standard functionality in most of the SAP core
applications. Those applications - e.g. VA01, ME21 - perform calls to the central
function module MESSAGING of group V61B. The function module uses
customizing entries, mainly those of the tables T681* to T685*.


A NAST output message is stored as a single record in the table NAST. The record
stores all information that is necessary to create an IDoc. This includes mainly an
object key to identify the processed object and application to the message handler
and the sender and receiver information.

(61)

RELATED POSTS

The messages are typically processed by

FORM ENTRY in PROGRAM RSNAST00.

If we are dealing with printing or faxing and

FORM EDI_PROCESSING in PROGRAM RSNASTED.

If we are dealing with IDocs

FORM ALE_PROCESSING in PROGRAM RSNASTED.

If we are dealing with ALE.

The following piece of code does principally the same thing as RSNAST00 does and
makes full use of all customizing settings for message handling.

TABLES: NAST.
SELECT * FROM NAST ...
PERFORM einzelnachricht IN PROGRAM RSNAST00

The processing routine for the respective media and message is customized in the
table TNAPR. This table records the name of a FORM routine, which processes the
message for the chosen media and the name of an ABAP where this FORM is found.

The ABAP RSNAST00 is the standard ABAP, which is used to collect unprocessed NAST
message and to execute the assigned action.

RSNAST00 can be executed as a collector batch run, that eventually looks for
unprocessed IDocs. The usual way of doing that is to define a batch-run job with
transaction SM37. This job has to be set for periodic processing and start a program
that triggers the IDoc re-sending.

Cave! RSNAST00 will only look for IDocs which are set to NAST-VSZTP = '1' or '2'
(Time of processing). VSZPT = '3' or '4' is ignored by RSNAST00.

Start RSNAST00 in the foreground first and find the parameters that match your
required selection criteria. Save them as a VARIANT and then define the periodic
batch job using the variant.

If RSNAST00 does not meet 100% your needs you can create an own program
similar to RSNAST00. The only requirement for this program are two steps:


* Read the NAST entry to process into structure NAST
tables nast.
data: subrc like sy-subrc.....
select from NAST where .......
* then call FORM einzelnachricht(rsnast00) to process the record
PERFORM einzelnachricht(rsnast00) USING subrc.

(62)


RELATED POSTS

Sending IDocs Via RSNASTED

Standard R/3 provides you with powerful routines, to trigger, prepare and send out IDocs in a controlled way. There are only a few rare cases, where you do not want to send IDocs the standard way.

The ABAP RSNAST00 is the standard routine to send IDocs from entries in the message control. This program can be called directly, from a batch routine with variant or you can call the FORM einzelnachricht_screen(RSNAST00) from any other program, while having the structure NAST correctly filled with all necessary information.

If there is an entry in table NAST, RSNAST00 looks up the associated processing
routine in table TNAPR. If it is to send an IDoc with standard means, this will
usually be the routine RSNASTED(EDI_PROCESSING) or RSNASTED(ALE_PROCESSING) in the case of ALE distribution.


RSNASTED itself determines the associated IDoc outbound function module,
executes it to fill the EDIDx tables and passes the prepared IDoc to the port.

You can call the standard processing routines from any ABAP, by executing the
following call to the routine. You only have to make sure that the structure NAST is
declared with the tables statement in the calling routine and that you fill at least the key part and the routine (TNAPR) information before.

TABLES NAST.
NAST-MANDT = SY-MANDT.
NAST-KSCHL = 'ZEDIK'.
NAST-KAPPL = 'V1'.
NAST-OBJKY = '0012345678'.
NAST-PARNR = 'D012345678'.
PERFORM einzelnachricht_screen(RSNAST00).

Calling einzelnachricht_screen determines how the message is processed.
If you want to force the IDoc-processing you can call it directly:

TNAPR-PROGN = ''.
TNAPR-ROUTN = 'ENTRY'.
PERFORM edi_processing(RSNASTED).

(65)

Unfortunately, there are application that do not create messages. This is especially true for master data applications. However, most applications fire a workflow event during update,which can easily be used to trigger the IDoc distribution.

Many SAP R/3 applications issue a call to the function SWE_EVENT_CREATE
during update. This function module ignites a simple workflow event.

Technically a workflow event is a timed call to a function module, which takes the
issuing event as the key to process a subsequent action.

If an application writes regular change documents (ger.: Änderungsbelege) to the
database, it will issue automatically a workflow event. This event is triggered from
within the function CHANGEDOCUMENT_CLOSE.

The change document workflow event is always triggered, independent of the case whether a change document is actually written.

In order to make use of the workflow for IDoc processing, you do not have to go
through the cumbersome workflow design procedure as it is described in the
workflow documentation. For the mentioned purpose, you can register the workflow
handler from the menu, which says Event Coupling from the BALD transaction.

Triggering the IDoc from a workflow event has a disadvantage: if the IDoc has to be
repeated for some reason, the event cannot be repeated easily. This is due to the
nature of a workflow event, which is triggered usually from a precedent action.

Therefore you have to find an own way how to make sure that the IDoc is actually
generated, even in the case of an error. Practically this is not a very big problem for IDocs. In most cases the creation of the IDoc will always take place. If there is a problem, then the IDoc would be stored in the IDoc base with a respective status. It will shown in transaction WE05 and can be resend from there.

Workflow Event From Change Document:

Most application fire a workflow event from the update routine by calling the
function

FUNCTION swe_event_create

You can check if an application fires events by activating the event log from
transaction SWLD. Calling and saving a transaction will write the event’s name and
circumstances into the log file.

If an application does not fire workflow events directly, there is still another chance that a workflow may be used without touching the R/3 original programs.

Every application that writes change documents triggers a workflow event from
within the function module CHANGEDOCUMENT_CLOSE, which is called form the
update processing upon writing the change document. This will call the workflow
processor.

FUNCTION swe_event_create_changedocument:

Both workflow types are not compatible with each other with respect to the function
modules used to handle the event.

Both will call a function module whose name they find in the workflow linkage
tables. swe_event_create will look in table SWETYPECOU while

swe_event_create_changedocument would look in SWECDOBJ for the name of the
function module.

If a name is found, the function module will then be called dynamically. This is all
to say about the linkage of the workflow.

The dynamic call looks like the following.

CALL FUNCTION swecdobj-objtypefb
EXPORTING
changedocument_header = changedocument_header
objecttype = swecdobj-objtype
IMPORTING
objecttype = swecdobj-objtype
TABLES
changedocument_position = changedocument_position.

(67)

RELATED POSTS

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.

(69)

RELATED POSTS

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

(71)

RELATED POSTS

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)

RELATED POSTS

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

(76)

RELATED POSTS

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 :

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.

(78)

RELATED POSTS

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.

(85)

RELATED POSTS

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.

(88)

RELATED POSTS

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.

(89)

Related posts

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.

(90)

related post

RFC provides interface shims for different operating systems and platforms, which provide the communication APIs for doing RFC from and to R/3.

SAP R/3 is designed as a multiserver architecture. Therefore, R/3 is equipped with a
communication architecture that allows data exchange and communication between
individual R/3 application and database servers. This communication channel also
enables R/3 to execute programs running on a remotely connected server using RFC
technology.

SAP R/3 provides special routines to enable RFC from and to R/3 for several
operation systems. For NT and WINDOWS the DLLs are delivered with the
SAPGUI Non SAP R/3 programs can access function modules in R/3, which is done by
calling an SAP provided interface stem. Interfaces exist for UNIX, Windows and
IBM S/390 platforms.

R/3 systems which are tied together via TCP/IP are always RFC capable. One R/3
system can call function modules in a remote RFC system, just as if the function
where part of the own calling system.

A function module can be called via RFC if the function has RFC enabled. This is a
simple flag on the interface screen of the function.

Enabling RFC for a function does not change the function. The only difference
between RFC-enabled and standard functions is that RFC functions have some
restriction: namely, they cannot have untyped parameters.

A text in SAP is an ordinary document, not a customizing or development object.
Therefore, texts are never automatically transported from a development system to a
production system. This example helps to copy text into a remote system.

R/3 RFC is not limited to communication between R/3 systems. Every computer providing
support for the RFC protocol can be called from R/3 via RFC. SAP provides necessary API libraries for all operating systems which support R/3 and many major programming languages e.g. C++, Visual Basic or Delphi.

Calling a program via RFC on a PC or a UNIX system is very much like calling it in
another R/3 system. Indeed, the calling system will not even be able to recognize
whether the called program runs on another R/3 or on a PC.

To make a system RFC compliant, you have to run an RFC server program on the
remote computer. This program has to have a calling interface which is well defined
by SAP. In order to create such a server program, SAP delivers an RFC
development kit along with the SAPGUI.

The RFC call to Windows follows the OLE/ACTIVE-X standard, while UNIX is
connected via TCP/IP RFC which is a standard in all TCP-compliant systems.

In order to call rfcexec, it has to be defined as a TCP/IP destination in SM59. R/3
comes with two destinations predefined which will call rfcexec either on the R/3
application server SERVER_EXEC or on the front end LOCAL_EXEC.

By specifying another computer name you can redirect the call for RFCEXEC to the
named computer. Of course, the target computer needs to be accessible from the R/3
application server (not from the workstation) and have rfcexec installed.

The object interface of rfcexec supports two methods only, which are called as
remote function call from R/3.

(96)

RELATED POSTS

Every time a change document is written, a workflow event for the change document object is triggered. This can be used to chain unconditionally an action from a transaction.

The most interesting chaining point for workflow events is the creation of the change document. Nearly every transaction writes change documents to the database. This document is committed to the database with the function module CHANGEDOCUMENT_CLOSE. This function will also trigger a workflow event.

The workflow handler triggered by an event which is fired from change documents is defined in table SWECDOBJ . For every change document type, a different event handler can be assigned.

This is usually a function module and the call for it is the following:

CALL FUNCTION swecdobj-objtypefb

EXPORTING

changedocument_header = changedocument_header
objecttype = swecdobj-objtype

IMPORTING

objecttype = swecdobj-objtype

TABLES

changedocument_position = changedocument_position.

Change pointers are created by calling FUNCTION CHANGEDOCUMENT_CLOSE which writes the usual change documents into table CDHDR and CDPOS. This function then calls the routine CHANGE_POINTERS_CREATE, which creates the change pointers.

CALL FUNCTION 'CHANGE_POINTERS_CREATE'

EXPORTING

change_document_header = cdhdr

TABLES

change_document_position = ins_cdpos.

Trigger a Workflow from Messaging :

The third common way to trigger a workflow is doing it from messaging.

When the R/3 messaging creates a message and processes it immediately, then it actually triggers a workflow. You can use this to set up conditional workflow triggers, by defining a message with the message finding and link the message to a
workflow.

You define the message the usual way for your application as you would do it for
defining a message for SAPscript etc. As a processing media you can assign either
the type W for workflow or 8 for special processing.

The media type W for workflow would require defining an object in the object repository. We will only show how you can trigger the workflow with a standard
ABAP using the media type 8.

You need to assign a program and a form routine to the message in table TNAPR.
The form routine you specify needs exactly two USING-parameters as in the
example below.


TABLES: NAST.

FORM ENTRY USING RETURN_CODE US_SCREEN.


na call your workflow action

RETURN_CODE = 0.
SY-MSGID = '38'.
SY-MSGNO = '000'.
SY-MSGNO = 'I'.

SY-MSGV1 = 'Workflow called via NAST'.

CALL FUNCTION 'NAST_PROTOCOL_UPDATE'

EXPORTING

MSG_ARBGB = SYST-MSGID
MSG_NR = SYST-MSGNO
MSG_TY = SYST-MSGTY
MSG_V1 = SYST-MSGV1
MSG_V2 = SYST-MSGV2
MSG_V3 = SYST-MSGV3
MSG_V4 = SYST-MSGV4

EXCEPTIONS

OTHERS = 1.

ENDFORM.

In addition, you need to declare the table NAST with a tables statement public in the
ABAP where the form routinely resides. When the form is called, the variable NAST
is filled with the values of the calling NAST message.

(102)

RELATED POSTS

ALE is a simple add-on application based on the IDoc concept of SAP R/3. It consists of a couple of predefined ABAPs which rely on the customisable distribution scenario. These scenarios simply define the IDoc types and the pairs of partners which exchange data.

ALE defines the logic and the triggering events which describe how and when IDocs are exchanged between the systems. If the ALEE engine has determined which data to distribute, it will call an appropriate routine to create an IDoc. The actual istribution is then performed by the IDoc layer.

The predefined distribution ABAPs can be used as templates for own development ALE uses IDocs to transmit data between systems.

ALE is, of course, not restricted to the data types which are already predefined in
the BALE transaction. You can write your ALE distribution handlers which should
only comply with some formal standards, e.g., not bypassing the ALE scenarios.

All ALE distribution uses IDocs to replicate the data to the target system. The ALE
applications check with the distribution scenario and do nothing more than call the
matching IDoc function module, which is alone responsible for gathering the
requested data and bringing them to the required data port. You need to thoroughly
understand the IDoc concept of SAP beforehand, in order to understand ALE.

The process is extremely simple: Every time a data object, which is mentioned in an
ALE scenario changes, an IDoc is triggered from one of the defined triggering
mechanisms. These are usually an ABAP or a technical workflow event.

Distribution ABAPs are started manually or can be set up as a triggered or timed
batch job. Sample ABAPs for ALE distribution are those used for master data
distribution in transaction BALE, like the ones behind the transaction BD10, BD12
etc.

The workflow for ALE is based on change pointers. Change pointers are entries in a
special database entity, which record the creation or modification of a database
object. These change pointers are very much like the SAP change documents. They
are also written from within a change document, i.e. from the function
CHANGEDOCUMENT_CLOSE. The workflow is also triggered from within this
function.

SAP writes those ALE change pointers to circumvent a major draw back of the
change documents. Change documents are only written if a value of a table column
changes, if this column is associated with a data element which is marked as
relevant for change documents (see SE11). ALE change pointers use a customised
table which contains the names of those table fields which are relevant for change
pointers.

(111)

RELATED LINKS

ALE is customised via three main transaction. These are SALE, WEDI and BALE.

This is the core transaction for SALE customizsng. Here you find everything ALE
related which has not already been covered by the other customising transactions.

WEDI - IDoc Administration :

Here you define all the IDoc related parts, which make up most of the work related
to ALE.

BDBG - Automatically generate IDocs From A BAPI :

Good stuff for power developers. It allows you to generate all IDoc definitions
including segments and IDoc types from the DDIC entries for a BAPI definition.

ALE Customizing SALE

All ALE special customiing is done from within the transaction SALE, which links
you to a subset of the SAP IMG.

The scenario defines the IDoc types and the pairs of IDoc partners which participate
in the ALE distribution. The distribution scenario is the reference for all ABAPs and
functionality to determine which data is to be replicated and who could be the
receiving candidates. This step is, of course, mandatory.

The change pointers can be used to trigger the ALE distribution. This is only
necessary if you really want to use that mechanism. You can, however, send out
IDocs every time an application changes data. This does not require the set-up of the
change pointers.

SAP allows the definition of rules, which allow a filtering of data, before they are
stored in the IDoc base. This allows you to selectively accept or decline individual
IDoc segments.

ALE allows the definition of conversion rules. These rules allow the transition of
individual field data according mapping tables. Unfortunately, the use of a function
module to convert the data is not realized in the current R/3 release.

The filter and conversion functionality is only attractive on a first glance. Form
practical experience we can state that they are not really helpful. It takes a long time to set up the rules, and rules usually are not powerful enough to avoid modifications in an individual scenario. Conversion rules tend to remain stable, after they have once been defined. Thus, it is usually easier to call an individual IDoc processing function module, which performs your desired task more flexibly and easily.

Basic settings have to be adjusted before you can start working with ALE.

Before we start, we need to maintain some logical systems. These are names for the
RFC destinations which are used as communication partners. An entry for the
logical system is created in the table TBDLS.

Finally. you will have to assign a logical system to the clients involved in ALE or
IDoc distribution. This is done in table T000, which can be edited via SM31 or via
the respective SALE tree element.

The distribution model (also referred to as ALE-Scenario) is a more or less graphical approach to define the relationship between the participating senders and receivers.
The distribution model is shared among all participating partners. It can, therefore,
only be maintained in one of the systems, which we shall call the leading system.

Only one system can be the leading system, but you can set the leading system to
any of the partners at any time, even if the scenario is already active.
This will be the name under which you will address the scenario. It serves as a
container in which you put all the from-to relations.

You can have many scenarios for eventual different purposes. You may also want to
put everything in a single scenario. As a rule of thumb, it proved as successful that
you create one scenario per administrator. If you have only one ALE administrator,
there is no use having more than one scenario. If you have several departments with
different requirements, then it might be helpful to create one scenario per
department.

The model view displays graphically the from-to relations between logical systems.
You now have to generate the partner profiles which are used to identify the
physical means of data transportation between the partners.

A very useful utility is the automatic generation of partner profiles out of the ALE scenario.

Even if you do not use ALE in your installation, it could be only helpful to define the EDI partners as ALE scenario partners and generate the partner profiles.
If you define the first profile for a partner, you have to create the profile header first.

The partner class is only a classification value. You can give an arbitrary name in order to group the type of partners, e.g. EDI for external ones, ALE for internal ones, and IBM for connection with IBM OS/390 systems.

(121)

RELATED LINKS

There is a very powerful utility which allows you to generate most IDoc and ALE interface objects directly from a BAPI’s method interface.

Every time BAPI is executed, the ALE distribution is checked.

For each of the parameters in the BAPI's interface, the generator created a segment for the IDoc type. Some segments are used for IDoc inbound only; others for IDoc outbound instead. Parameter fields that are not structured will be combined in a single segment which is placed as first segment of the IDoc type and contains all these fields. This collection segment receives the name of the IDoc type.

Defining Filter Rules :

ALE allows you to define simple filter and transformation rules. These are table entries which are processed every time the IDoc is handed over to the port. Depending on the assigned path, this happens either on inbound or outbound.

Using the OLE/Active-X functionality of R/3 you can call R/3 from any object aware language.

Actually it must be able to do DLL calls to the RFC libraries of R/3. SAP R/3 scatters the documentation for these facilities in several subdirectories of the SAPGUI installation.

R/3 can exchange its IDoc by calling a program that resides on the server
The programs can be written in any language that supports OLE-2/Active-X technology
Programming skills are mainly required on the PC side, e.g. you need to know Delphi, JavaScript or Visual Basic well .

(130)

The Microsoft Office suite incorporates with Visual Basic for Applications (VBA) a fully object oriented language. JavaScript and JAVA are naturally object oriented. Therefore you can easily connect from JavaScript, JAVA, WORD, EXCEL and all the other VBA compliant software to R/3 via the CORBA compatible object library (in WINDOWS known also DLLs or ACTIVE-X (=OLE/2) components).

Visual Basic is finally designed as an object oriented language compliant to DCOM
standard.

JavaScript is a typical object oriented language which is compliant to basic CORBA,
DCOM and other popular object standards.

SAP R/3 provides a set of object libraries, which can be registered with Visual
Basic. The library adds object types to VBA which allow RFC calls to R/3.
The libraries are installed to the workstation with the SAPGUI installation. They are
technically public linkable objects, in WINDOWS these are DLLs or ACTIVE-X
controls (which are DLLs themselves).

The object library SAP contains among others the object type FUNCTIONS whose
basic method CALL performs an RFC call to a specified R/3 function module. With
the call you can pass object properties which will be interpreted as the interface
parameters of the called function module.

If the RFC call appear not to be working, you should first try out to call one of the
standard R/3 RFC function like RFC_CALL_TRANSACTION_USING (calls a
specified transaction or RFC_GET_TABLE (returns the content of a specified R/3
database table).

SAP R/3 provides a set of object libraries, which can be registered with JavaScript
to allow RFC calls to R/3.

The object library SAP contains among others the object type FUNCTIONS whose
basic method CALL performs an RFC call to a specified R/3 function module.
If the RFC call appears to be not working, you should first try out to call one of the standard R/3 RFC functions like RFC_CALL_TRANSACTION_USING (calls a
specified transaction) or RFC_GET_TABLE (returns the content of a specified R/3
database table).



Call Transaction From Visual Basic for WORD 97

This is a little WORD 97 macro, that demonstrates how R/3 can be called with a mouse click directly from within WORD 97.

This macro calls the function module RFC_CALL_TRANSACTIION_USING .
This function executes a dynamic call transaction using the transaction code
specified as the parameter.

You can call the macro from within word, by attaching it to a pseudo-hyperlink.
This is done by adding a MACROBUTTON field to the WORD text. The macrobutton statement must call the VBA macro R3CallTransaction and have as the one and only parameter the name of the requested transaction MACROBUTTON R3CallTransaction VA02
This will call transaction VA02 when you click on the macrobutton in the text
document. You can replace VA02 with the code of your transaction.


R/3 RFC from JavaScript

JavaScript is a typical object oriented language which is compliant to basic CORBA,
DCOM and other popular object standards.

SAP R/3 provides a set of object libraries, which can be registered with JavaScript
to allow RFC calls to R/3.

The libraries are installed to the workstation with the SAPGUI installation.
The object library SAP contains among others the object type FUNCTIONS whose
basic method CALL performs an RFC call to a specified R/3 function module.

If the RFC call appears to be not working, you should first try out to call one of the standard R/3 RFC functions like RFC_CALL_TRANSACTION_USING (calls a
specified transaction) or RFC_GET_TABLE (returns the content of a specified R/3
database table).

(136)