This section discusses the main programming steps involved in the creation of a master IDoc.
Figure 14: Outbound Processing: Creating a Master IDoc
There are different mechanisms that can lead to the generation of a master IDoc:
• Master data replication using Shared Master Data (SMD)
This mechanism is based on change documents. You can schedule a report to generate IDocs for changed master data and replicate it in one or more target systems at regular intervals.
• Message control
Many applications use messages: for example, creating an order. The generic service used for this is known as message control. You can use message control to specify in the system whether a message is to be printed or sent electronically.
• Application program
In order to understand how a master IDoc is generated, it does not matter which method is used to call the IDoc-generating program. For SMD or message control, this must be a function module with a defined interface.
Otherwise, it can be implemented as a report or as a function module. The following sections focus on the elements within the application program.
These elements are identical for all mechanisms.
Figure 15: When is an IDoc Generated?
In the application program, a structure must be defined that contains information for the control record. The type of this structure is defined in the ABAP Dictionary, and is calledEDIDC. Most fields in the control record are filled by the ALE layer. At least the IDoc type and the message type must be filled in the application program. This structure is later passed to the ALE layer together with the master IDoc.
Figure 16: Outbound Program: Control Record
Hint: Because ABAP is constantly but compatibly changing, different syntax variants can be used for defining the same structure.
To clarify the SAP programs, these variants are summarized here.
• As of release 4.5, a Dictionary type can be referenced withTYPE. The syntax for a structure with the nameedidc_sis therefore:
DATA edidc_s TYPE edidc.
• As of release 3.0, a Dictionary type can be referenced withLIKE. The syntax for a structure with the nameedidc_sis therefore:
DATA edidc_s LIKE edidc.
• For release 2.2, the syntax for a struc-ture with the name edidc_s is as follows:
DATA BEGIN OF edidc_s.
INCLUDE STRUCTURE edidc.
DATA END OF edidc_s.
Figure 17: Outbound Program: Internal Table for Master IDoc
In the application program, an internal table must be defined that contains the application data of the master IDoc. The row type of this internal table is defined in the ABAP Dictionary, and is callededidd.
The row type consists of a control part with the following fields:
• MANDTClient
• DOCNUM IDoc number
• SEGNUMSegment number
• SEGNAMName of the segment type
• PSGNUMSegment number of the parent segment
• HLEVELHierarchy level
The data part of the row type contains the fieldSDATA.
This internal table first has to be filled according to the rules of an IDoc type, and is then passed to the ALE layer as a master IDoc.
Hint: Due to the constantly changing nature of ABAP, there are different syntax variants that can be used for defining an internal table. To clarify the SAP programs, these variants are summarized as follows:
• As of release 4.5, a Dictionary type can be referenced withTYPE. For an internal table with the nameedidd_t, this is as follows:
DATA edidd_t TYPE STANDARD TABLE OF edidd WITH DEFAULT KEY.
• As of release 4.0, there are different table types. The table type required here is called a standard table. The syntax for an internal table with the nameedidd_tis as follows:
DATA edidd_t LIKE STANDARD TABLE OF edidd WITH DEFAULT KEY.
or, in abbreviated form:
DATA edidd_t LIKE TABLE OF edidd.
• As of release 3.0, a Dictionary type can be referenced withLIKE. The syntax for an internal table differs from the definition of a structure by the addition ofOCCURS. The syntax for an internal table with the nameedidd_tis therefore:
DATA edidd_t LIKE edidd OCCURS 0.
• For release 2.2, the syntax for an internal table with the name
edidd_t is: DATA BEGIN OF edidd_t OCCURS 0.
INCLUDE STRUCTURE edidd.
DATA END OF edidd_t.
Figure 18: Outbound Program: Row Structure of the Master IDoc The master IDoc is structured in rows. First, a segment must be filled.
This requires a help structure with the row type edidd(here called edidd_s). In the control part of the segment, at least the name of the segment type must be entered, in the fieldsegnam. The structure of the data part must correspond to the description of this segment type. The easiest way to achieve this is to create a structure with the row type of the corresponding Dictionary structure type, and fill the fields of this structure. Note that the data must be entered in an external format.
This means that all numeric fields must be converted to character format and copied, left-justified, to the target field. For more detailed information on the mapping procedures, see the ALE Programming Guide.
You can then use theMOVEcommand to copy the data into thesdatafield of the segment. For structures, this command has the effect that all characters of the structure will be copied, left-justified. For more information on the
MOVEcommand, see the keyword documentation forMOVE.
Figure 19: Outbound Program: Structure of the Master IDoc
You structure a master IDoc by attaching or inserting the segments using anAPPENDorINSERTstatement. Note the following for the segment attributes of the IDoc type:
• Mandatory segment: The IDoc must contain at least one row with this segment type
• Optional segment: The IDoc does not have to contain a row with this segment type
• Min. number: There must be at least this number of segments
• Max. number: Cannot be exceeded
• For a child segment, the parent segment must also be available (in the row before the first child segment)
Figure 20: Passing the Master IDoc to the ALE Layer
The control record and the master IDoc are transferred to the ALE layer using the function moduleMASTER_IDOC_DISTRIBUTE. The ALE layer supplements the fields of the control part of the master IDoc. This includes numbering the segments and filling the fields for the hierarchy level, the row number of the parent segment, and the IDoc number.
Hint: The function module returns the control records of all the communication IDocs to the program. You therefore need to define another internal table with the row typeedidcin your program, and transfer it to theTABLESinterface of the function module. The internal table can remain empty.
Hint: If the IDoc is to be generated in the same logical unit of work (LUW) as the application document, and the application document is generated by update, the function module MASTER_IDOC_DISTRIBUTE
must also be called with the additionIN UPDATE TASK.
Figure 21: Example: Outbound Processing for the Message Type MATMAS
The example displayed here is a process diagram showing outbound processing for the material master message typeMATMAS.
• In Business Transaction Events (BTEs), a function module is called that follows the naming conventionOPEN_FI_PERFORM<name of BTE>.
• You recognize Business Add-Ins on an interface by the naming conventionIF_EX_<badi>- A reference variable must be defined in the declaration section: DATA ref_name TYPE REF TO if_ex_<badi>.
- and a method call (CALL METHOD ref_name->...)