Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Idocs - Enhancements!

Former Member
0 Kudos

Hi Friends!

Can any one pls tell what all the enhancements which u ve worked on IDOCS.

Pls give step by step detail in Creation of segments & FM coding Please.

Looking for your Help.

Thanks In Advance.

Rahul.

2 REPLIES 2

Former Member
0 Kudos

Hi,

Go through this hope u can understand.

Change pointer

Change Pointer table is read and checked if changes were made to important fields , if so the outbound program will be triggered automatically , these have predefined interfaces

ALE/IDOC

IDOC Programming

There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is send to other system . Separate ABAP programs are written for these 2 processes and different configuration settings are required for each one .Depending upon the trigeering mechanism different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the database tables.

NEED FOR ABAP PROGRAMMING arises if

1)New IDOC was created

Depending upon the triggering mechanism i.e change pointer,message control

etc the programming technique changes and the type of process.

2)Existing IDOC was extended

User Exits are used to populate data in new segments added and to read them

back.

3)To enhance an exsiting process.

User Exits are used .

Basic structure of an OUTBOUND PROGRAM

The basic structure of all outbound programs is same. The CONTROL

record which is of TYPE EDIDC has to be filled. It contains important fields like

IDOCTP IDOC type

MESTYP Message Type

RCVPRN Recieving Partner (Destination)

RCVPRT Partner Type (it is LS i.e Logical System)

The DATA RECORD internal table which is of TYPE EDIDD has to be filled

in the same order as there are segments in the IDOC definition.

It has 2 important fields which are to be filled ,these are

SEGNAM Name of the segment

SEGDATA Data in the segment and can be upto 1000 bytes.This field

is corresponds to each data segment in the IDOC.

e.g.

DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.

DATA W_SEGDATA LIKE zsegment "custom segment zsegment

INT_EDIDD-SEGNAM = 'ZSEGMENT'

W_SEGDATA-field1 = value "taken from some table

W_SEGDATA-field2 = value "taken from some table

INT_EDIDD-SEGDATA = W_SEGDATA

APPEND INT_EDIDD

This will fill the data record corresponding to the segment ZSEGMENT . For all

segments the sam steps will be repeated until all the data corresponding to all the

segments in the idoc is filled in the internal table of type EDIDD.

There is only one control record and can be multile data records in the idoc

structure.

Which data is to be extracted from the tables to be filled in EDIDD type internal table is determined in standalone programs from the objects which are specified in the selection screen and from the object key passed to the function module in case of message control and is taken from BDCP table in case of change pointers using function modules "CHANGE_POINTERS_READ"

In case of stand alone programs and function modules based on change pointers method the function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for distribution ,in case of message control it is handled automatically by the RSNASTED program invoked by the message control.

OUTBOUND PROCESS AND OUTBOUND PROGRAM.

Outbound programs are used in outbound process to genearte IDOCs . There

purpose is to extract the data from the tables and to fill the IDOC data records

and the control record in the IDOC and pass ito the ALE layer for distribution to the recieving system .

Depending upon the triggering mechanism (how and when the outbound program will be started different techniques and interface is used for outbound program.

1)Message control

Application like PO(purchase order) creation use this technique , where the output type is linked to the application(Message control is a configurable cross application component which can be set in IMG .Such programs are created in the form of function modules and linked to the output type which is linked to the apllication.These have predefined interfaces.

In outbound programs(function module) that use message control the key of the

application document is passed to the function module whcig will read the data from the table depending upon the key passed(NAST structure) and fill the IDOC segemnts with the application data.The control record is also passed to the function module but is not fully filled, the rmaining fields are filled and the control is passed back to the calling program which is RSNASTED and is invoked by the

message control to process ALE and EDI output types and this program on recieving the IDOC data will create the physical IDOC in the system.

The parameteers passed to the function module are

IMPORTING PARAMETERS

OBJECT LIKE NAST

It contains documents key.

CONTROL_RECORD_IN LIKE EDIDC

It contains the partailly filled control record

EXPORETING PARAMETER

OBJECT_TYPE

CONTROL_RECORD_OUT LIKE EDIDC

TABLES

INT_EDID LIKE EDIDD

The internal table used to fill the data records in the same order as they exists in the IDOC.

The important parameters that should be filled in the custom function module are

CONTROL_RECORD_OUT and INT_EDIDD .The OBJK field of the structue NAST contains the key of the apllication document.

2)Stand alone programs

Generally used for Master Data transfer and as such depending upon the requirement can have different interfaces.The programs have a selection screen which has select options to select the objects, and parameters for specifying the recipient Logical System and the Message Type.

Data is selected based on the specified objects from the tables . and control record of type EDIDC is created and filled with important values like DIRECTION ,IDOCTP,RCVPRT,RCVPRN and MESTYP .

Data is filled in an internal table of TYPE EDIDD according to segment definitions

and in same order and the function module MASTER_IDOC_DISTRIBUTE is called passing the control record and the internal table containg IDOC data and importing an internal table consisting of control records for each communication IDOCS created.

3)Change pointer

Change Pointer table is read and checked if changes were made to important fields , if so the outbound program will be triggered automatically , these have predefined interfaces

ALE/IDOC Transaction

SALE Area Menu for ALE configurations.It includes transactions for

Logical System definition and linking it to a client, Transactions for

RFC Destination and Port Definition Etc.

SM59 RFC Destination

Here we specify the login settings for the destination including

the I.P address or Application Server name and the User name and

password.The information entered here is used to run Remote Function

Calls(RFC ) on the destination server .We can create number of types

of RFC Destinations but 3 types are important .

R/3 (R/3 to R/3), LS(logical system) and TCP/IP.

The name of the RFC destination should be same as that of Logical

System as it helps in creation of automatic partner profiles.

WE21 Port Definition.

There are 6 types of ports but only 2 types File and Transactional RFC

types of ports are important.

We have to specify the RFC Destination before a port can be created.

WE57 This is used to assign the Inbound function module to the Message Type

and to the IDOC Type.

WE42 This is used to define the process Code for Inbound Processing.

BD95 Define Filter object type .We can specify the field and the table it belongs

to as a filter object .

BD59 Assignment of Filter object type to the Message Type .Here we create the

link between Filter object and the segment and the message type and the

segment Field.

BD50 Set message Type to reducible.

BD65 Define Mandatory Fields.

BD64 Distribution Model . Also known as Customer Distribution Model Used to

define all the messages that will be exchanged between remote systems

and the name of thes logical systems. Any filters can also be specified.

The model once created has to be distributed on every system which will

be communicating ,It can be maintained on only One system.

BD21 Creating IDOcs from change pointers.

This can be used to create IDOCs from change pointers for a particular

message LIKE MATMAS.

BD22 This can be used to delete change pointers.

BD87 Status Monitor. Idocs can be selected base on number of criteria and there

processing status can be seen in detail.

BD10 Material Master Data Distribution .

Based on Message MATMAS.

BD12 Customer Master Data Distribution .

Based on Message CREMAS.

BD14 Vendor Master Data Distribution

Based on Message DEBMAS .

BDFG Generate ALE Interface for BAPI.

Here we specify the Business Object and the BAPI Function module for

which the interface has to be created.

WE31 Segment Editor.

This is used to create segments. We create the segment type and

segment definition is automatically created by editor e.g. Z1DUMMY is

segment type and Z2DUMMY is the segment definition .We specify the

fields and the data elements these cp\orresponds to create segments.

WE30 IDOC Editor

It is used to create a new IDOC Type or IDOC Extension .We specify the

segments that will be addd to the IDOC type.

WE02/05 IDOC List.

Various selct options and parameters are provided to select IDOCs

depending on the date, direction , mesage type etc.

WE20 Partner Profile

Here we create partner profile for each and every partner from / to which

the messages will be exchanged.There are 6 types of PF generally only

profiles of type LS(Logical System) ,KU(Customer) ,LI(Vendor) is used.

We specify the partner number and partner type and the agent and

the agent type responsible for handling of errors .

For every message send to the partner we have a outbound record and for

evry message coming from the partner we have the inbound record .

We specify the message in the otbound/inbound records ,double

clicking will take us to the detailed screen where the IDOC Type ,Port

and whether the IDCO will be immediatelt processed or collected are

mentioned.

Reward points if helpful.

Thanks

varma_narayana
Active Contributor
0 Kudos

Hi Rahul..

These are the Steps for IDOC enhancement.

IDOC EXTENSIONS

SAP delivers Basic IDOC types such as DEBMAS02, MATMAS02.

By extending the Basic IDOC type, you are actually creating a new IDOC type.

You create a new segment with the additional fields. This new segment has to be associated with one of the existing Basic IDOC segments. Then you create a new extension type, which is associated with the Basic IDOC type. This results in a new IDOC type. In order for ALE function modules to relate to this new IDOC type, the IDOC type is linked to the corresponding message type.

Note: that you should not add fields to existing segments but should create a new segment and associate it with an existing segment.

In our example, the Basic IDOC type DEBMAS02 is used to communicate Customer Master data to the SAP Customer Master application. Even though the application has a screen to enter and store a contact personâs business address DEBMAS02 does not have a segment or fields that communicate the contact persons business address. If your business requires that this business address be communicated to the other system through the ALE interface for Customer Master, then you have to extend the DEBMAS02 IDOC type, and enhance the corresponding ALE function module.

In DEBMAS02 the contact person fields are present in segment E1KNVKM and the business address of the contact person is stored on the SADR SAP table. You need to create a new segment, Z1SADRX, that is associated with E1KNVKM. This will be done in the process of creating an extension type ZDEBMASX. This extension type will then be associated with a new IDOC type, ZDEBMASZ. IDOC type ZDEBMASZ will be linked to message type DEBMAS for Customer Master. The final step in the IDOC extension process is to check the new objects. This check also verifies the structural integrity of the IDOC type. Letâs look at each of these steps in more detail.

1. Create an Extension Type and a New Segment.

Determine the fields on table SADR that you are going to provide for in the new segment Z1SADRX. You need fields for name, street, city, region, and country to give the business address of the contact person. You also need fields for the address number. ADRNR is a field in SAP tables such as SADR that uniquely identifies the address of an entity. This field is cross-referenced from other tables to the SADR table to obtain the full description of the address. Because this is an IDOC type for master data, the first field of the new segment will be MSGFN. The message function field informs the receiving system of the action to be taken for that particular segment. In the code that you write for populating the new segment, the value of the message function is the same as that of the parent segment E1KNVKM. In all, you will have 12 fields in segment Z1SADRX (see Table 1).

To create an extension type and new segment:

• Use transaction WE30 or from WEDI go to Development -> IDOC types.

• Enter ZDEBMASX for Object Name.

• Choose Extension Type.

• Click on Create.

• You will see a pop-up screen. Choose Create New, and enter a description. For version 4.x, enter DEBMAS02 in the Linked Basic Type field. Enter.

• You will see a screen with ZDEBMASX and its description in the first line. Click on this line, and press Create. For version 4.x, expand the tree of segments, and place the cursor on E1KNVKM.

• You will see a pop-up screen. Enter E1KNVKM as the reference segment. Enter.

• For 4.x, press Create after placing the cursor on segment E1KNVKM.

• You will see a line appear with E1KNVKM hierarchically below ZDEBMASX, with a description "Customer Master contact person (KNVK)."

• Click on this line and press Create. You will receive a message indicating that the new segment being created will be a child segment of E1KNVKM. Enter. A pop-up box appears for the new segment.

• Enter Z1SADRX as the segment type, 1 for Minimum, 1 for Maximum. Leave Mandatory segment unchecked. These entries imply that there is only one Z1SADRX segment for every occurrence of the E1KNVKM segment, and also that this segment is not mandatory. Note that if the parent segment is not mandatory, then the child segment should not be mandatory, because this could result in a syntax error during the creation or processing of the IDOC.

• For 4.x, you must first create the IDOC segment Z1SADRX (Iâll explain why in a moment) from the menu path WEDI -> IDOC -> Development -> IDOC Segment.

• Click on Segment Editor.

• On the next screen, click on Create.

• Enter a development class for the object. Enter.

• This will take you to the screen for segment definition. Enter a description for the segment. Enter the field name, data element, and the data element documentation name. In most cases, all three fields may have the same values. If you are using a field in the segment that is not present in the ABAP/4 data dictionary, you must first create the domain, data element, field, and appropriate documentation before using it in the new segment.

• Enter these three columns for all 12 fields. Save.

• Click on Generate/Activate, F3 to step back.

• From screen Maintain Segment, go to Segment Type -> Release. A checkbox now appears beside the segment definition Z1SADRX (see Figure 2). Check this box. Save.

• Save again to store the descriptions of the segment, F3 to step back.

• Save the extension type.

It is possible to have several new segments with relevant Basic IDOC type parent segments in a single extension type. However, you can form only one IDOC type based on a single extension type.

2. Create an IDOC Type.

The next step is to create an IDOC type by associating the extension type that you created with the Basic IDOC type. This is a simple process:

• From transaction WE30 or WEDI go to Development -> IDOC Types.

• Enter ZDEBMASZ for Object Name.

• Click on IDOC Type.

• Click on Create.

• Enter DEBMAS02 for Basic IDOC type.

• Enter ZDEBMASX for extension type.

• Enter a description.

• Enter.

• You will see a display of the composite IDOC type with all segments, including Z1SADRX (see Figure 3).

It is possible to associate only one extension type with a Basic IDOC type for a given IDOC type. However, you can have multiple new segments in an extension type.

3. Link IDOC Type to Message Type.

The next step is to link the new IDOC type to its corresponding message type. This is important, because this relationship is referenced in the partner profile parameters where you specify the message type and IDOC type to be used for that particular representative system. To link the message type:

• Use transaction WE82, or from WE30, go to Environment -> IDOC Type / Message Type, or from WEDI go to Development -> IDOC Type -> Environment Î IDOC Type / Message Type.

• Click on Display <-> Change.
• Click on New Entries.
• Enter DEBMAS for message type.
• Enter DEBMAS02 for Basic IDOC type.
• Enter ZDEBMASX for extension type.
• Enter your SAP R/3 release number for Release.
• Save.
This data is stored on the EDIMSG table and is accessed by several ALE processes to relate the message type to the IDOC type.
4. Check the IDOC Type.
Before checking the IDOC type for consistency, it is important to perform another step that releases the extension type to the IDOC type:
• From WEDI go to Development -> IDOC Types -> Extras -> Release Type, or from transaction WE30 go to Extras -> Release Type.
• For the Object Name ZDEBMASX and radio button Extension Type, click Yes.
• The extension type has now been "released."
You canât edit the extension type once itâs released. To cancel the release for further editing or deactivation, go to WE30 Î Extras Î Cancel release. The final step in the IDOC extension process is checking the validity of the IDOC type:
• From transaction WE30 or WEDI go to Development -> IDOC types.
• Enter ZDEBMASX for Object name.
• Click on Extension Type.
• From the Development Object menu select Check.
• Repeat the operation for IDOC type ZDEBMASZ.



ALE FUNCTION MODULE ENHANCEMENTS

Having extended the IDOC type to contain additional fields for an inbound or outbound application, you now want to enhance ALE function modules for populating the additional segment on the outbound or applying the additional segment data on the inbound application.

• For master data distribution, from SALE go to Extensions -> Master data distribution -> Setup additional data for message types. Search for message type DEBMAS in this example. You see an entry for DEBMAS associated with function module MASTERIDOC_CREATE_SMD_DEBMAS. This data is stored on table TBDME. The function module names for all master data message types follow this pattern: MASTERIDOC_CREATE_SMD_messagetype. This function module calls another function module of name MASTERIDOC_CREATE_DEBMAS or MASTERIDOC_CREATE_messagetype. Search for the words customer function, and you find several hits that can be used to add code to the function module.

• From WEDI got to Control -> Inbound process codes -> Inbound with ALE service -> Processing by function module (transaction WE42), or from WEDI go to Control -> Outbound process codes -> Outbound with ALE service -> With function module (transaction WE41). There will be function modules associated with the process codes. For inbound, the function modules usually follow this pattern: IDOC_INPUT_messagetype: for example, IDOC_INPUT_CHRMAS for inbound characteristics master.

• Use transaction WE57 or from WEDI go to Development -> Message/Application Object. The entries list the function module, Business Object, message type, and IDOC type that are used for inbound ALE/EDI interfaces.
Customer functions are not specific only to ALE and EDI but also to all programs/modules in SAP R/3. Customer function is a SAP enhancement component; the other two types are menu and screen enhancements.
All customer function exits are maintained in SAP enhancements and are found by using transaction SMOD. After executing transaction SMOD, pull down (F4) on the enhancement name field, and execute again. This provides you with a list of all SAP enhancements available. SAP enhancements are grouped by development class pertaining to an application area. Choose Application development R/3 SD master data distribution for development class VSV to lead to a screen that lists VSV00001 as an enhancement (see Figure 5). Press Component +/- to display its function exit components. There are four possible components listed, all of which are function exits (and are function modules) that are called from the ALE function modules in the form Call Customer Function Î001â. This is a special occurrence of the ABAP statement Call. Go to item Exit_SAPLVV01_ 001, which you need to enhance for the Customer Master outbound example of an IDOC extension. In the ALE-function module MASTERIDOC_CREATE_DEBMAS, the statement CALL Customer Function 001 is translated in the background to call component EXIT_SAPLVV01_001. Although this function exit can be edited using transaction SE37, you will use a simpler approach.
When you use SAP enhancements and their components, you manage them with an SAP object known as a project, which is like an envelope containing the selected enhancements and their components. A project can be used to control the execution of components and to transport them to other clients and instances in SAP. Basically, the process involves creating a project, including enhancements and components that are to be enhanced, editing the components, and then activating the project. The following process creates a project for our example Customer Master IDOC extension:
• Execute transaction CMOD.
• Enter name of project, say CSTMAST1.
• Click on Create.
• Enter a description of the project.
• Save.
• Click on SAP Enhancements.
• Enter VSV00001 for Enhancement.
• Save.
Once youâve created the project, edit the function exit components and activate the project. Remember that the code in the function exit enhancement will execute only if the project is activated.

Outbound interfaces. In an outbound ALE interface you use function exits (customer functions) to populate additional segments created by an IDOC extension or to modify the existing IDOC data segments as per business requirements. Previously, you identified that enhancement VSV00001 has a component EXIT_SAPLVV01_001 (function exit), which can be used for populating the additional data segment Z1SADRX that you created in the IDOC extension ZDEBMASX (IDOC type ZDEBMASZ, based on Basic IDOC type DEBMAS02). You also learned that the ALE function module that calls this function exit is MASTERIDOC_CREATE_DEBMAS, which has a statement Call Customer Function 001.
Browse the function module MASTERIDOC_CREATE_DEBMAS using transaction SE37. You will find that this customer function is invoked for every segment of IDOC type DEBMAS02. In fact, the function exit is called soon after the creation of an existing segment has been populated with data and appended to the IDOC data table (internal table). Also, the function exit is exporting the message type, IDOC type, and the segment name and is importing the IDOC extension type. It is also passing the IDOC data internal table. This indicates that the ALE function module is allowing you to populate additional segments for every existing segment and modify the existing segmentâs data.
Letâs write ABAP/4 code to accomplish the task of populating IDOC segment Z1SADRX with a contact personâs business address:
• From SE37, display function module MASTERIDOC_CREATE_ DEBMAS.
• Find Customer Function 001.
• Double-click on 001.
• The function EXIT_SAPLVV01_001 will be displayed.
• Double-click on INCLUDE ZXVSVU01.
• You will be asked to create a new include object. Proceed as desired.
• Enter code (as in Listing 1).
• Be sure to perform a main program check (Function Module -> Check -> main program) and extended program check (Function module -> Check -> Extended check).
Now that you have extended the IDOC and enhanced the ALE function module based on the requirements for the contact personâs business address on the Customer Master, letâs test the interface. You should create a logical system and define a port for this interface. You should also configure the Customer Distribution Model to indicate that message type DEBMAS is being distributed to this logical system. The only difference in configuration between a regular outbound ALE interface and an enhanced one is the partner profile definition. While maintaining the outbound parameters of the partner profile, make sure the IDOC type is ZDEBMASZ. The fields for Basic IDOC type and extension type are automatically populated with DEBMAS02 and ZDEBMASX, respectively.
To maintain the contact personâs business address of a customer:
• Use transaction BD12 or from BALE go to Master Data ->Customer -> Send and send that Customer Master record by executing the transaction after filling in the relevant fields such as customer number, message type, and logical system.
• Use transaction WE02 or WE05 to verify the IDOC created. You should see the new segment Z1SADRX populated with the correct data.
With SAP releases below 4.5B, you cannot capture changes to business address through change pointers because a change document object is not available for capturing business address changes, and also earlier releases have not been configured to write change documents for a contact personâs business address. If you would like this functionality, you can either create change document objects, generate function modules to create change documents, and perform ALE configuration to tie it in, or make a cosmetic change to the contact person screen data while changing the contact personâs business address so that it gets captured as a change to the Customer Master. Subsequently, the ALE enhancement that you performed captures the contact personâs business address.
Inbound interfaces. The process for enhancing inbound ALE interfaces is similar for outbound, with a few exceptions; specifically in the coding of customer functions (function exits) for the ALE/EDI function modules.
The first step is to create an IDOC extension for the specific Basic IDOC type by adding new segments at the appropriate hierarchy level: that is, associated to the relevant existing segment. Populate the data fields on the new segments with application data by the translator or external system/program before importing them into the R/3 System. Then, find the ALE function module that is invoked by the inbound processing. By browsing through the code or reading the documentation on the function exit enhancements using the SMOD transaction, identify the function exit in which you should place your code. The technique used in the code to post the additional or modified IDOC data to the application can vary based on the application rules and requirements, the data available at that point in processing, and the application function modules available to update the application tables. It is important to search first for application modules that process the data and see if they can be called within the function exit. If the additional data in the extended segments in specific to a custom table or resides in nonkey fields of a single or small set of tables, you may be able to update it directly by SQL statements in the function exit. This approach should be carefully evaluated and is certainly not highly recommended.
Another option is to use Call Transaction from within the function exit to process the additional data. For example, in the case of message type WMMBXY for inbound goods movements from a warehouse management system, the standard interface creates batches for materials, but does not update its characteristics. In such a case, you can use Call Transaction MSC1 to create the batch and assign characteristic values to it from within the function exit provided.


Reward if Helpful