Idoc Overview

(1)

IDOC Overview

Session

By Kevin Nguyen-Tu

Dec 2005

IDOC through Inbound and

Outbound Processing

(2)

Acronyms and Abbreviations

ALE – Application Link Enabling

XI – Exchange Infrastructure

(3)

How Are…

Basic Type, Message Type, and IDOC related?

The Message Type is the data dictionary that contains one or more

Basic Type. The IDOC is the data container outcome from data

extraction through the message types. In a way, IDOC is the XML

Schema with Data associated to it. IDOC has a basic type which

consists of segments (ALE).

For example, the Message Type used in HR is HRMD_A, while the

Basic Type associated with it is HRMD_A01, HRMD_A02,

HRMD_A03,…HRMD_A06. From there, when data is extracted against

HRMD_A06, an IDOC is created using the data definition specified from

the message type.

(4)

Quick Ref: Transactions

SALE – IDoc Interface /

ALE IMG

This is the configuration menu node for

IDOC, similar to SPRO for normal functional configuration.

WEDI – SAP Easy Access

IDOC Menu

This is the user menu for the IDOC version,

similar to the standard SAP menu when you first enter on to SAP.

(5)

Quick Ref: Transactions

(cont’d)

WE02 – IDOC Listing

This transaction will list all of the IDoc

both for INBOUND and OUTBOUND

process. In the IDoc list, you will find

the status, segments, and data inside

the IDoc

PFAL – HR ALE Distrubtion

of HR Master Data

This transaction allows you to ALE

(push) HR Master Data from one SAP

system to another SAP system. Such

as from HR ECC to SRM client

(6)

Quick Ref: Transactions

(cont’d)

BD21 – Create IDOC from

Change Pointers

Extract data from change pointers

based upon Message Type. It will

create the IDOC corresponding to

the Message Type used and

automatically populate the IDOC will

the values pull out from change

pointers.

BD22 – Delete Change

Pointers

Over times, as changes happen in SAP

it will be track in change pointers.

Similar to an Audit Log. This will get

fairly large. This program will assist you

in doing some cleanup work

(7)

Quick Ref: Transactions

(cont’d)

WE19 – IDOC Inbound

Testing Tool

This transaction allow you to use a

newly created IDOC structure,

manually populate data into it and see

it post to the actual table / infotype.

BD73 – Reprocess Non

Posted IDocs

If an IDoc passing failed, you could use

this transaction to reprocess that exact

same IDoc with all the values already

in there.

(8)

Quick Ref: Transactions

(cont’d)

WE60 – Documentation

Allows you to specify a message type

and it will return the documentation on

the message type. It will list all the

infotype or values it support and the

structure.

BD53 – IDoc Reduction

Maintenance

Allows you to create a reduced

message based upon a standard

message type

(9)

Partner Profiles

Transaction WE20 is used to setup and maintain the Partner Profile. This is where you specify based upon a message type, what system the data should ALE over thru OUTBOUND interface.

In addition to setting up the partner profile, you will need to setup the receiver port RFC using transaction SM59, define the logical system, define distribution model, define the ports, and generate the partner profile via BD82. Go to the IMG SALE and visit the configuration tables.

(10)

Create Reduced Message Type

(11)

Maintain Distribution Model

From the SALE IMG node, you could access the Maintain / Display Distribution Model. This is where you setup filter criteria for the ALE process.

For example, during the ALE OUTBOUND process from System A to System B, you could specify to only send over a particular object type through this pipeline, such as Object Type O for Organizational

Objects. The connection is based upon a particular message type, so you could have more than one rules in the distribution model

(12)

How To Read An IDOC

IDOC Number

Status Code: 52 – Successful, 30 mean extraction done, ready for ALE process

Basic Type and Message Type. In the hierarchy world, the Message Type is the top, and then Basic Type. The IDOC is the result of the after data is populated.

System Connectivity Partner Profile Info

This goes hand in hand with the status code above. It will tell you the step by step status code, where the status code above

Example: A standard Message Type would be HRMD_A, the Basic Type would be HRMD_A01,

(13)

How To Read An IDOC (cont’d)

The IDOC segments are grouped by keys identifier. The top node is E1PLOGI, under it you have E1PITYP and E1Pxxxx.

E1PLOGI specify the PLVAR (Plan Version), OTYPE (Object Type), OBJID (Object ID), and OPERA (Operation Type)

E1PITYP will use PLVAR, OTYPE, and OBJID as the foreign keys, but add INFTY (Infotype), BEGDA (Begin Date) and ENDDA (End Date). E1Pxxxx is the actual INFOTYPE record itself. As you can see in the example to your right, E1PLOGI is grouped by the OTYPE and OBJID. All E1PITYP under it are associated with the corresponding infotype.

(14)

How To Read An IDOC (cont’d)

1. 2. 3. 4. Top E1PLOGI Under E1PLOGI, it is group by E1PITYP Under E1PITYP, it is group by the infotype Top E1PLOGI of next record

(15)

How To Test INBOUND IDOC

To test an INBOUND IDoc load, you will need to resort to a transaction WE19. Based upon the assumption you already have the partner profile setup and in place.

You could use an Existing IDOC that was created due to another process or an OUTBOUND ALE action, repopulated that for INBOUND loading.

If an existing IDOC is not available, you could use a message type or other method for INBOUND loading. Let say in our example we do have an available existing IDOC

(16)

How To Test INBOUND IDOC

(Cont’d)

This line specify the receiver and sending information. In such, it is the partner profile,

How are you going to do your Inbound Test? Standard Inbound will use standard code and standard function module to do the load. Inbound Function Module allows you to specify the function module you want to do the load. Inbound file will do standard load against a data file, rather than data populated from this screen

(17)

How To Test INBOUND IDOC

(Cont’d)

This is a sample IDOC tree structure

You have the standard E1PLOGI, E1PITYP, and E1Pxxx grouping you saw earlier. When double click on anyone of those line, a window with fields is available to populate values into

Once you populate the “Change Data Record” screen, it will look like this in the IDOC

(18)

How To Create OUTBOUND

IDoc From Change Pointers

1) Use Transaction BD21 or if access from SA38/SE38, use program code RBDMIDOC

2) Enter in the message type you would like change pointers to extract from

3) Upon successful extract, you will see the ALE log as green light. This will in turn create IDoc and ALE over to the designated system from the partner profile

(19)

How To Create OUTBOUND

IDoc w/o Change Pointers

1) Using the transaction PFAL or if accessing via SA38/SE38 the program RHALEINI

2) Populate the screen with the basic information you would like the program to create the IDoc and ALE over to the partner profile system. You could ship by a certain object type, object ID, infotype, subtype, and/or evaluation path. For example, I could ALE from the SANDBOX ECC system to SANDBOX SRM system all position object (OTYPE: S) with their infotype 1001 (relationship) and subtype 012 (the chief relationship).

3) Select the transfer mode: INSERT or UPDATE. To insert, it will delete the target system will the same information it is extraction, and re-insert the new information. The Update only send over data that had been changed to the target system.

4) This method will send by date parameters and not by object The program “HR: ALE Distribution of HR Master Data” allows you to transfer data from one system to another system through an ALE process via the IDoc segments