ale training

PricewaterhouseCoopers LLP SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

PwC Consulting

SAP ALE

Training Program

SAP Release 4.6C

Summary Table Of Contents

Chapter 1 – ALE Overview 1

Chapter 2 – Introduction to IDocs 11

Chapter 3 – Modeling ALE Distribution 25

Chapter 4 – Communication Parameters

Chapter 5 – ALE Architecture

Chapter 6 – Data Distribution Methods

Chapter 7 – ALE Monitoring

Chapter 8 – Error Handling

Chapter 9 – Using ALE for Interfaces

Chapter 10 – IDoc Processing Features

Chapter 11 – ALE Performance

Chapter 12 – IDoc Reduction

Chapter 13 – IDoc Extension

Chapter 14 – IDoc Creation

Chapter 15 – IDoc Processing



1 Chapter 1 – ALE Overview

1.1.1 Review of SAP System Terminology

From a System Infrastructure view, an SAP system consists of three layers:

� The Database Layer stores and retrieves all data. The database contains all of

the data related to the SAP system, including the ABAP programs, the

configuration data, the master data, and the transaction data.

� The Application Layer executes the SAP programs and processes requests from

users.

� The Presentation Layer contains the SAP Graphical User Interface (GUI), and

handles all user input and output.

Together, the three layers make up the three-tiered client-server architecture of SAP.

We can distribute the three layers over any number of physical computers. However,

there may only be one database server.

From a Database or Configuration view, the SAP system consists of:

� Client-Independent data, such as ABAP programs, client-independent tables, etc.

� One or more Clients. Each client contains its own client-dependent configuration

(company hierarchy, process configurations, etc.), master data (customer,

material, vendor, etc.), and transaction data.



1.1.2 Logical Systems

We define all communication in ALE as links between logical systems. A logical system is a

system containing applications that are coordinated to work with one set of data. A logical

system can be:

� A specific client on a specific SAP system

� A non-SAP system

� A file-based interface

Since logical systems are the basis of all ALE configurations, the ability to define them

should be restricted to as few people as possible.



1.1.3 What is ALE?

Application Link Enabling (ALE) is the set of tools, programs, and data definitions that

provides the mechanism for distributing SAP functionality and data across multiple systems.

ALE enables the construction and operation of distributed applications.

1.1.3.1 The Basic Ideas of ALE

ALE is a technology introduced by SAP with its 3.0 release. Its purpose was to overcome

the limitations of a single SAP system. A single SAP system that runs on top of one

database often does not fulfill the needs of larger corporations, either from a business or a

technical perspective.

ALE allows the implementation of loosely coupled SAP systems; each of the SAP systems

has its own database and is essentially independent from the other systems. ALE allows us

to distribute data between different systems and different business processes.

The distribution of data happens at the application server level (Hence, Application Link

Enabling).

SAP supports a number of distribution scenarios, which define how different SAP systems

can interact. The scenarios define what messages are sent back and forth between the

systems (for example, Contract information needs to be exchanged between systems that

run central purchasing and systems that run decentral purchasing).

The “data container” that carries the message is the Intermediate Document, or IDoc. SAP

delivers over 100 IDoc types to support its distribution scenarios; along with the IDocs

come the associated programs to generate (on the outbound side) or to process (on the

inbound side) IDocs.

Part of ALE is a communication infrastructure; specifically ALE uses the “transactional RFC”

technology to ensure the transaction consistency across system boundaries. ALE also ties

into SAP workflow to handle errors in the data transfer process



1.1.4 Why use ALE?

ALE provides for the integration of distributed applications, but why would we distribute

applications in the first place? There are several technical and business reasons:

� System Performance: The transaction load is too heavy for a single

SAP system.

� High Availability Requirements: The company cannot afford downtime due to

backups, maintenance, upgrades, etc.

� SAP Release Coordination: Different units of the organization may require

different releases of the SAP software.

� Very Large Database: Companies with very large databases may need to

distribute the data across multiple SAP systems.

� Business Structure: Business units may require independence and autonomy for

day-to-day operations, and yet still need to share some data and functionality with

other units in the enterprise.

� Interfacing with non-SAP systems: The company may wish to maintain certain

applications on non-SAP systems, while at the same time integrate these

applications and their data with the SAP system.

� Keep development system data in sync with production data: An

organization may wish to keep the data on a development system the same as on

a production system.

� Maintain configuration and master data across clients: Organizations using

multiple clients may wish to maintain certain data on a client-independent basis.



1.1.5 What can we distribute with ALE?

We can distribute all types of data with ALE:

� Control or Customizing Data: Control data includes all configuration objects that

define how the SAP system is organized. This includes the enterprise structure

configurations, global settings, etc.

� Master Data: Master data objects that can ALE can distribute include:

o Material Master

o Customer Master

o Vendor Master

o Cost Centers

o Activity Types

o G/L Accounts

o Characteristics/Classes/Classifications

o and many others

� Transaction Data: Transaction data is data related to specific business

transactions or processes (e.g. sales orders, credit memos, invoices).

SAP delivers several hundred predefined distribution scenarios. If a standard solution is not

provided, then we can develop a custom scenario to distribute any data required by the

business. The number of supported business scenarios increases with each SAP release.

1.1.5.1 Example distribution scenario: Sales and Distribution

The sales system provides only the logistics data that the warehouse requires to fill an

order. Summary information is reported into the central sales information system. All of

the data sent references a single order document.



1.1.5.2 Example distribution scenario: Blanket

Purchasing

The central purchasing system sends the local purchasing system the data required to

carry out an individual transaction. Summary release statistics are reported to the central

purchasing information system. As with SD scenarios, there is a single document reference.



1.1.6 What is EDI?

Electronic Data Interchange (EDI) is an industry standard for data exchange between

business partners (customers, vendors, etc.).

This is the distinction between EDI and ALE: ALE is primarily for data exchange between

systems within the same organization, where EDI is primarily for data exchange

between companies.

SAP uses the ALE services to implement EDI functions from within the R/3 system.

Conceptually, EDI functionality is layered on top of ALE functionality.



1.1.7 ALE Components

SAP provides ALE services for distributing applications, and the tools to tailor these

services to the organization’s specific requirements. The three ALE services form a layered

architecture, where each layer depends on the layers below it.

The ALE Services are:

� Application Services: This is where the SAP applications (SD, FI, MM, etc.)

generate their data and documents. This is not specific to ALE, but is part of the

standard processing in SAP (i.e.. posting an invoice). Existing SAP programs are

“ALE-enabled” to allow them to work with ALE.

� Distribution (or “ALE”) Services: This is where the distribution of the data and

documents occurs. This layer determines the recipients, formats and filters the

data, and creates the ALE Intermediate Documents (IDocs).

� Communication Services: This layer provides the vehicle for actually moving the

data and documents (the ALE IDoc) from one logical system to another. This layer

employs communication techniques such as X.400/X.500, TCP/IP, EDI,

Asynchronous RFC, etc.

SAP also provides a set of tools for configuring and customizing the ALE implementation:

� Customizing Tools: The customizing tools provided by SAP define what is to be

distributed, and how the distribution is to occur. These tools include the following.

o Model Maintenance Tool: A tool used for configuring the flow of data

between systems

o Shared Master Data (SMD) Tools: Tools within SAP used for distributing

master data

o Customization parameters within SAP for IDoc filtering

and conversion

� Development Tools: Tools for creating and modifying IDocs. These tools allow for

the maintenance of IDoc types, as well as the individual segments that make up

the IDocs.



1.1.8 The Future of ALE

ALE (meant as IDocs and associated function modules for extract and update) is so

completely embedded in all SAP offerings that eliminating it would be difficult. In particular:

� Most mySAP.com components use ALE

� SAP is still facing major scalability issues in terms of putting tens of thousands of

users on one database. Therefore ALE remains the closest thing they can offer to a

distributed processing environment.

� Many clients are using ALE, so the absence of ALE support would cause problems

� ALE is important to many processes within the R/3 system

� Most third party complementary software uses IDocs as the main means of

communication

In the future, SAP will continue providing more standard scenarios and enhance the

customizing and development features.



2 Chapter 2 – Introduction to IDocs

2.1.1 The Intermediate Document (IDoc)

The Intermediate Document, or IDoc, is the main component of all interface functionality

in SAP. Each interface message type has an associated IDoc type. The IDoc, in turn,

defines the structure and formatting of the data contained within the message type.

IDocs provide support for customized development:

� API for development

� Easy to use and apply

� Real-time or asynchronous interface connection

� Independent of external system data requirements

� Independent of type of external system

The data interface standard is standardized according to the following

key rules:

� The documentation of the interface is published.

� SAP takes responsibility for compatibility of the interface standard for its own

applications.

� Field lengths and types are defined according to the data element definitions of the

EDIFACT EDI standard and SAP’s data repository.

� Codes for coded fields are taken from international standards where the standard

applies.



2.1.2 IDoc Types and Message Types

We need to make a distinction between an IDoc and an IDoc type:

� An IDoc type is the definition of a specific data structure.

� An IDoc is an actual instance of data based on an IDoc type. Therefore, there can

be many IDocs created from a single IDoc type.

The structure of IDoc types is very similar to the structure of EDI messages. In fact, SAP

loosely based its IDoc structures on the EDIFACT standards.

We also need to distinguish between an IDoc type and a message type:

� An IDoc type specifies the structure of the data.

� A message type specifies the meaning of the data.

An IDoc type can support multiple message types. For example, the IDoc type ORDERS01

supports purchase orders, change orders, quotes, and confirmations, each using a

different message type.

A given message type may not use all of the data defined in an IDoc type.

The IDoc structure does not change with direction. That is, the structure is exactly the

same for inbound and outbound IDocs.



2.1.3 IDoc Structure

An IDoc consists of three record types:

� Control Record: Contains the data that uniquely identifies the IDoc.

� Data Records: Contain the application data related to the message type. An IDoc

may have multiple data records, called segments. A data segment is made up of a

key section and a data section. The key section uniquely identifies its respective

data segment.

� Status Records: Contain the information relative to the various statuses that the

IDoc encounters, such as IDoc created, document posted, etc.

The IDoc is data stored in a structured format. It is a medium for data transfer. An IDoc is

not a process nor executable code.

SAP originally developed IDocs for EDI, and then adopted the IDoc concept and structure

for its ALE interface.



2.1.4 The IDoc Control Record

The Control Record stores the characteristics of the IDoc. Some of the more important

fields are:

� IDoc ID Number (DOCNUM)

� IDoc type (DOCTYP)

� Direction (In or Out) (DIRECT)

� Name of Sender (SNDPRN)

� Name of Receiver (RCVPRN)

� Processing Status (STATUS)

� EDI Message Type (if EDI) (STDMES)

Control Records are stored in the R/3 transparent table EDIDC, keyed by IDoc ID number.

This ID number is assigned by SAP for all IDocs.



2.1.5 The IDoc Data Records

The Data Records contain the actual application data. Some of the more important fields

are:


� Segment Name (SEGNAM)

� IDoc Data (SDATA) (structure differs with each IDoc type)

The Data Records are stored in table EDID4 (EDID2 in prior versions), keyed by IDoc

number and segment number. The table structure is 71 bytes of administration data (IDoc

number, segment identifier, etc.) followed by 1000 bytes of free-form application data.

Each segment type uses a different format for the 1000 bytes of

application data.

2.1.6 Data Record Hierarchy

Information that relates to the object as a whole is stored in the main segment.

Hierarchical information is stored in separate segments. Each segment typically

corresponds to a different database table.

Attributes of a segment:

� The fields of the segment. Each field is assigned a length and a data element from

the ABAP dictionary.

� Whether the segment is required or optional in a valid IDoc.

� The minimum and maximum number of instances of the segment.



2.1.6.1 Example – Material Master

As an example, consider the Material Master IDoc Type (MATMAS01). Each material has

information that is common throughout an SAP implementation. This data is stored in the

main segment. Each material has some information that is different for each plant, which

is stored in a separate plant segment. Within a plant, the material can be stored in

multiple storage locations, each of which requires a storage location segment for its

information. We can store several different descriptions of the material (for different

languages, for example).

2.1.6.2 Example – Sales Order

As another example, consider the purchase order / sales order IDoc Type (ORDERS01).

Each order has information that is common throughout an SAP implementation. This data

is stored in the main segment. Each order has some information that is different for

various kinds of data, which is stored in a separate sub-segment (e.g. conditions, partner

information and document item data). Within a document item, there are different kinds of

data for an order item, each of which requires a subsequent segment for its information

(e.g. terms of delivery and terms of payment).



2.1.7 IDoc Status Record

The status records are stored in table EDIDS, keyed by IDoc ID Number and date/time.

Some of the more important fields are:


� IDoc Status (STATUS)

� Date/Time Status was generated (CREDAT, CRETIM)

� Status Text (STATXT)

The STATUS field is:

� 1 - 49 for Outbound Messages

� 50 - 99 for Inbound Messages

The possible values for the status are stored in table TEDS2. A list is in

the Appendix.

As the IDoc undergoes processing (both in and out), a status record is added to it at each

step.



2.1.8 IDoc Structure Utility

To view the structure of a specific IDoc, use the IDoc Structure Utility. Enter the IDoc type

and execute. You can expand each segment to look at its child segments or its data fields.

Transaction: WE60

Menu Path: Tools I Business Communication I IDoc I IDoc Basis I Documentation I

IDoc types



2.1.9 Maximized vs. Reduced IDocs

A maximized IDoc contains all the data available in the master data record. This IDoc

contains all the fields available whether those input fields are needed by the distributed

systems or not. In the SAP-standard delivered maximized IDoc, not all the fields are

activated. The user needs to go into the message type to activate all the fields for transfer.

Reduced IDocs are maximized IDocs that have been modified to only include the data that

is valuable to the distributed systems. The reduction excludes those fields that the

distributed system does not need and therefore makes the IDoc easier to use.

Reducing an IDoc does not reduce network traffic. The entire maximized IDoc is still sent

to the partner system, we just can’t see it all.

Reduced IDocs are created for a specific message type. This has two implications:

� A reduced IDoc can be created for multiple distributed systems or specifically for

one distributed system, but either way, the reduced IDoc type becomes a new

IDoc type and must be treated as such. In other words, the maximized and

reduced IDoc types are not interchangeable.

� Reduced IDocs cannot be used with many third-party mapping tools, such as

Mercator.



2.1.10 Viewing IDocs on the System

Transaction: WE05

Menu Path: Tools I Business Communication I IDoc I IDoc Basis I IDoc I IDoc Lists

You can display a list of IDocs in the system with the IDoc Lists transaction. Specify IDoc

criteria such as date/time created, message type, partner, etc. to limit the results.

The resulting screen lists IDocs by direction (inbound/outbound), status, and message

type. You can “drill down” into the IDoc list to see detailed information such as control

records, status records, and data records.



This list depicts the drill-down on MATMAS IDocs with status 03. Note that several IDocs

are listed.



You can double-click on an individual IDoc to look at its control, data, and status records:

Double click on "Control rec." to see the control record.

Single click on any data record to see its fields.

Double click on any status record to see it in detail.

Transaction WE02 is similar to WE05, but it sorts IDocs by message type before status.

2.1 Exercise: IDoc Structure

This exercise will give you practice in reading and understanding the structure of an IDoc.

Run the IDoc Structure Utility (WE60). Answer the following questions.

What are the required segments in the IDoc type MATMAS02 (Material Master)?

In IDoc type DEBMAS01 (Customer Master), what is the parent segment of segment

E1KNVPM?

List the data fields of segment E1WYTTM in IDoc type CREMAS01 (Vendor Master)?

What data element is assigned to field NTGEW of segment E1EDP09 in IDoc type

DESADV01 (Shipping Notification)?

What is the maximum number of “Document Header Partner Information Additional Data”

segments in a Purchasing/Sales IDoc (type ORDERS02)?

In an ORDERS02 IDoc, what does the field DATUM represent in segment E1EDK03 if the

value of the field IDDAT is ‘010’?



3 Chapter 3 – Modeling ALE Distribution

3.1.1 Distribution Models

The distribution model describes the flow of data between logical systems:

� What systems are there?

� What applications will run on which systems?

� What systems will SEND data?

� What systems will RECEIVE the data?

� Other rules for data distribution?

ALE uses the model to control data distribution. The ALE system will not distribute any

data unless you specify the data flow in a distribution model.



3.1.2 Model Views

You can split the distribution model into one or more views. This lets you break down

complex distribution scenarios into more manageable pieces, or to separate business areas

or systems into separate views.

Although you can think of the views as different models, there is really only one model on

any system. This model is a union of all of the model views that are defined.

3.1.3 SAP Support

SAP delivers a large set of predefined message types, with the programming needed to

use them, with the R/3 system. With each message type, SAP provides:

� Functionality to create outgoing messages

� Functionality to process incoming messages

� The data structures needed by the message

We will look at several SAP messages in detail throughout this course.

If SAP does not provide a message functionality that you need, you can create it yourself.

This is the focus of the IDoc Programming part of this course.



3.1.4 Model Ownership

Each model view is owned by one logical system

We maintain the model on its owner logical system, and then distribute the model view to

all of the other systems. ALE provides the distribute function to send a model view to the

other logical systems. The other systems then have display-only access to the model.



3.1.5 Defining Logical Systems

Transaction: BD54

Menu Path: SALE I Sending and Receiving Systems I Logical Systems I Define Logical

System

Before building a distribution model, we must define the logical systems that we will be

using. The Logical System Definition transaction will access the list of logical system

names. Click on New entries to create new logical systems.



3.1.6 Assigning a Logical System Name to the Client

Transaction: SCC4

Menu Path: SALE I Sending and Receiving Systems I Logical Systems I Assign Client

to Logical System

The Logical System table only stores names and descriptions of the logical system names.

We actually assign the logical system names to physical systems in the Client Maintenance

transaction. Simply double-click on a client, change the field Logical system, and save.

There is a one-to-many relationship between physical systems (or clients) and logical

systems. That is, we assign each client one logical system name, but several logical

systems can point to the same client.

Remember that a logical system can point to a non-SAP system as well, so we don’t need

to allocate every logical system to a client.



3.1.7 Model Maintenance

Transaction: BD64

Menu Path: SALE I Modeling and Implementing Business Processes I Maintain

Distribution Model and Distribute Views

We use the Model Maintenance program to define the distribution model views.

To create a new model view, click on Create Model view.

Remember that there is really only one model. Each model view is a part of the entire

model.

Each model view has one owner system. You can maintain the model only from its owner

system. The owner of a model view is set to the system on which you create it. Models

distributed from other systems will be grayed out on the list.

To define a new message flow between systems, click on Add message type. Enter the

model view, the sending logical system name, the receiving logical system name, and the

name of the message type, and save.



3.1.8 Filter Objects

You can use a filter object to limit the content of a message in the model. For example,

you can configure a Customer message to be sent only if the company code is equal to

0001.[1]

Multiple filter objects are linked with an OR if they are the same object,

AND otherwise. For example, if you define the following filter objects:

� Plant 001

� Plant 002

� Division 01

� Division 02

The resulting filter will be (Plant 001 OR Plant 002) AND (Division 01 OR Division 02).

[1]

Note: A filter object actually filters out IDoc segments, not entire IDocs. Here is how it works, for

those interested: Each segment of the IDoc containing a field of the specified object type with a value

different than any filter value is deleted from the IDoc, along with its child segments, if it has any. If

the deleted segment is mandatory in the IDoc, then its parent segment is also deleted. If the highest-

level segment is deleted, than the entire IDoc is not sent.



To define a filter object:

� Navigate to the model view/message type that you want to filter, and expand the

tree to show filter groups.

� Double click on "No filter set", (or "Data filter active", if one exists).

� Click on Create filter group

� Select the field that you want to use in the filter.

� Enter the value to filter by.

� Save the model.

3.2 Exercise: Model Maintenance

In this exercise you will create a new distribution model view and assign a message flow

between two SAP systems.

Goal: On the system designated as your "Sales” system set up the customer model

MODEL## (where ## is the last two digits of your SAP logon ID) with the message

MATMAS sent to the system designated as your "Warehouse” system.

Caution: Only one person at a time can perform shaded steps. Please work quickly so that

others will not be locked out for too long!

A. Define a logical system

Define the logical systems that you will use:

1. Log into your Sales system. You will define communication parameters between this

system and your Warehouse system. Execute the ALE configuration IMG with

transaction code SALE.

2. Create a logical system name for your Sales system.

a. Execute BD54.

b. Click New Entries.

c. Enter your Sales system's logical system name and a short description.

d. Click Save.



3. Create a logical system name for your Warehouse system using the same process.

4. Log into your Warehouse system, and repeat the creation of the logical system names.

Notes:

1. The logical system table is client-independent. This means that if your Sales and

Warehouse systems are different clients on the same physical system, you only need

to create the logical system names once.

2. Since class participants are sharing senders and receivers, one or both of your logical

system names may already exist. If so, just verify that they exist and move on.



B. Allocate logical systems to clients

Each client on a system must have a logical system name, so that it will know what

modeled messages apply to it.

1. From your Sales system, execute SCC4.

2. Double click on the client assigned as your Sales system.

3. Enter the sender's logical system name in the Logical system field and save.

4. Repeat this process for your Warehouse system.

Note: Since participants are sharing Sales and Warehouse systems, one or both of your

logical systems may already be allocated. If so, just verify that they are correct and move

on.

C. Maintain the Communications Model

The customer distribution model defines what messages are permitted between the

systems. You will model a material message flow. The message type you will use is

MATMAS.

1. Log into your Sales system. This system will "own" your model view, and you should

perform ALL model maintenance on this system.

2. Execute BD64

3. Click on Switch between display and edit mode to go into edit mode.

4. Click on Create Model view to create a new model view. Enter the model name

(MODEL##) and a description and save.

5. Add a message type under your model view. Enter your Sales system as the sender,

your Warehouse system as the receiver, and the message type (MATMAS), and save.

6. MATMAS now appears in the model hierarchy as a supported message to send to your

Warehouse system. Click on Save to save the model.

D. Add a filter object.

Add the following filter constraints to your model:

Plant: 2000 or 4000

Division: 01

1. Go to Model maintenance on your Sales system

2. Position the cursor on the MATMAS message flow you defined earlier, and double click

on "No filter set".

3. Select Create filter group. Expand the values and double click on Plant.

4. Enter 2000 as the Object value, and save.

5. Repeat this procedure to add the other two filter objects.

6. Using the menu path Edit # Delete, delete your filter group, since it will interfere with

future exercises



4 Chapter 1 – IDoc Processing Features

There are a number of processing features in ALE that permit you to further refine what information is sent to what

logical systems in the ALE constellation. These features include:

� Filtering out segments of an IDoc that shouldn’t be sent to a particular logical system

� Converting the values or formats of certain fields in the IDoc

� Using classes to freely define which master data records are sent to which logical system



4.1.1 Segment Filtering

Segment filtering prevents pre-defined segments of an IDoc from being sent to a particular receiving system. The

filtering is dependent on the message type and the receiver.

This prevents unnecessary data from being sent to a system that does not need that data. In general, it is more

efficient to perform filtering on the outbound side, thus reducing unnecessary network traffic. However, SAP also

provides segment-filtering capabilities on the inbound side.

For example, material master records may be maintained centrally at headquarters. This information must be

distributed to all manufacturing facilities, but those facilities may not be interested in the accounting view of

materials. In that case, the accounting view may be filtered out when the IDoc is sent to the manufacturing facility.

Other distributed systems that are interested in the accounting view may still receive that view.

To use filtering, you must first determine which functional information is required on each system. Then you must

identify the appropriate segments to filter out.

Transaction: BD56

Menu Path: SALE I Master Data Distribution→Modeling and Implementing Business Processes I Scope of Data for Distribution I

Filter IDoc Segments

In transaction BD56, enter the appropriate message type. Then click on New Entries, and enter the sending system,

the receiving system, and the segment to filter out. The system types will be “LS” for logical system. You can add

multiple entries for the same sending and receiving systems to filter out multiple segments.

Note: Although the menu path for this program goes through "Master Data Distribution", filtering will work for any

message type, not just those for master data.

Note: If you filter out a segment, you must ensure that the segment's child segments are also filtered out.



4.1.2 Field Conversions

In some cases, we may need to convert the values that belong to certain fields when sending data between

systems. For example, material master type codes for material type may be different on a legacy system than they

are in SAP. A material type of “ROH” (for raw material) in SAP may correspond to a numeric code (such as “01”) in

the legacy system.

ALE has the ability to convert field values when sending data between systems. We can use this capability instead of

external translation programs. We can convert data on either the inbound or the outbound side (or both).

We specify conversion rules at the field level, along with selection criteria that govern when the rule will take effect

(for example, set the moving average price equal to the standard price only if the moving average field is blank).

Here are the steps for defining a field conversion:

� Step 1: Define the rule.

Transaction: BD62

Menu Path: SALE I Converting Data Between Sender and→Modeling and Implementing Business Processes

Receiver I Define Rules for IDoc Segment Names

o Click on Change.

o Enter the information onto a blank line:

� Name of the rule

� Description

� Segment that the rule applies to

o Save your entries



� Step 2: Maintain the rule.

Transaction: BD79


Receiver I Maintain Rules

o Enter the rule name and click on Change.

o Double-click on a field you want to convert.

o Enter the conversion rule and save. There are several possible rules you can use:

� Copy a field unchanged.

� Convert a field in some way.

� Set the field to a constant.

� Set the field to the value of a system variable.



� Step 3: Assign the rule to a message flow.

Transaction: BD55


Receiver I Assign Rule to Message Type

o Enter the message type and enter.

o Click on New entries and enter the information:

� Sending system (type is “LS”)

� Receiving system

� Segment to apply the rule on

� Name of the rule

o Save your entries.



4.1.3 Distributing Master Data with Classes

If standard filter objects are not sufficient to specify how to distribute master records to the various ALE systems,

SAP permits you to create freely definable classes of master data records to be distributed together.

You implement classes using the standard classification functionality of SAP. We only have time here for a quick

overview.

You can use classes only with customers, vendors, and materials.

You can distribute your classes as master data using ALE or by CTS. You must send the class to each individual

system that will use it.

Note: Classes were called “Lists” in previous versions. Also, the meaning of the word "class" here is different from

the meaning in ABAP Objects programming.

Directions for setting up distribution with classes:

Transaction: CL02

Menu Path: Logistics I Central Functions I Classification I Master Data I Classes

Transaction CL02 will maintain classes. You must specify the class name and the type. You select the type from the

class type hierarchy.

� You must use a classification type that is configured for use with ALE. These types are usually called

ALM(material), ALV (vendor), etc.

Transaction: CL24N

Menu Path: Logistics I Central Functions I Classification I Assignment I Assign Objects/Classes to Class

Transaction CL24N lets you assign objects to your class.

To send all of the members of one or more classes, specify the names of the classes in the BD10 Listing field.

This procedure will not send the actual classification information, unless you check the Send material in full checkbox.

If you do this, make sure that you send the actual classes to the other systems first (or at the same time, using

serialized messages).



4.1.4 Controlling Distribution Using Classes

Transaction: BD68

Menu Path: SALE I Modeling and Implementing Business Processes I Master Data Distribution I Distribution Using Object Classes I

Assign Classes to Receiving Logical System

You can limit master data distribution between two logical systems to members of a certain class. This requires two

steps:

� Transaction BD68. This tells the ALE system what classes you want to enable distribution for, for a given

logical system and message type.

� Add a filter object to the distribution model for the proper systems and messages, selecting Distribution

via classes.

That’s it! Now if you try to send a master data record not in the specified class, the ALE layer will not create a

communication IDoc.



4.1.5 Serialization

4.1.5.1 IDoc Level

For some IDoc types it might be a problem if one IDoc is overtaken by another IDoc, because later updates would be

overwritten by earlier ones. Since this is dependent on the IDoc type this serialization function is not built into the

ALE layer. It must be coded within the application function module.

We’ll discuss this more in the IDoc programming part of the course.



4.1.5.2 Message Level

Sometimes, two message types are interrelated, and must be processed in the right order. Examples:

� Material Master and Classification Master.

o If we create a material, classify it, and want to send it to another system with the classification

information, we must use two message types: MATMAS and CLFMAS. But the receiving system

cannot process the CLFMAS message until it adds the material from the MATMAS message!

� Purchase Orders

o If we send a purchase order (ORDERS) with a new vendor (CREMAS) or a new material

(MATMAS), we need to send the vendor or material along with the PO. The receiving system

then needs to process the vendor and the material before the purchase order.

Beginning with R/3 release 4.0, SAP provides functionality to ensure the correct processing order of messages.

These are the steps you must follow to use the serialization functions:

� Create the serialization group and assign message types to it.

� Maintain the proper message flow configuration in the distribution model and the partner profiles.

� Schedule the programs to perform the distribution.



4.1.6 Configuring Message Serialization

First, we define a serialization group. By defining a serialization group, we can specify that certain message types

must be processed in a predetermined order.

Transaction: BD44

Menu Path: SALE I Modeling and Implementing Business Processes I Master Data Distribution I Serialization for Sending and

Receiving Data I Serialization Using Message Types I Define Serialization Groups

Note: Although the menu paths for the Serialization programs go through "Master Data Distribution", serialization

will work for any message type, not just those for master data.

There are two steps in defining a serialization group:

� Create the serialization group.

o Click on New entries, enter your group’s name and a description, and save.

o Assign message types to the serialization group: Click the selection button next to your group,

and then double-click on "Assignment of logical messages to serial. group".

o Click on New entries, and add a line for each message type you want in the group. Indicate the

proper processing order by setting the sequence number for each message.

o Save.

You must create the serialization group on both the sending and receiving systems.



4.1.6.1 Distribution Model and Partner Profile Configuration

To use the serialization functions, you need to configure a message type SERDAT in addition to the master data

message types.

You must also configure the message flows in the model and partner profiles correctly:

� Outbound:

o Master data messages: Collect IDocs.

o SERDAT message: Transfer immediately.

� Inbound:

o Master data messages: Processing type Background, no override with express flag.

o SERDAT message: Processing type Immediate processing.



Finally, you must define the settings for inbound processing:

Transaction: BD44

Menu Path: SALE I Modeling and Implementing Business Processes I Master Data Distribution I Serialization for Sending and

Receiving Data I Serialization Using Message Types I Define Inbound Processing

Click on New entries, and enter the information:

� Your serialization group name

� The message types in the group

� The sending logical system name

� The packet size (number of IDocs) transferred to the application at a time.

� Whether parallel processing is permitted

� The server group to use.

We’ll discuss parallel processing and server groups in the Performance chapter.



4.1.6.2 Scheduling ABAP Programs

To use the serialization features, you must schedule the following two programs to run at appropriate times:

� RBDSER01

o This program does the same thing as RBDMIDOC: it reads the system change pointers and

creates IDocs for any master data records that have changed (or been added). It differs from

RBDMIDOC in that it only creates IDocs for master data messages that are members of a

specified serialization group.

� RBDSER02

o This program does two things:

� It sends the IDocs created by RBDSER01.

� It schedules program RBDSER03 at a time interval you specify in the selection screen.

The program RBDSER03 uses the program RBDMOIND (discussed in the next chapter) to check for successful IDoc

dispatch for all IDocs sent by RBDSER02. If all IDocs were successfully sent, then it sends a message of type

SERDAT to start the inbound processing. The receiving side then processes the SERDAT message, which triggers

the processing of the other messages in the correct order.

4.2 Exercise: Filtering Out an IDoc Segment

Remember: Only one person at a time can perform shaded steps!

1. For IDoc type MATMAS03, find the segment that contains material valuation data.

2. Using BD56, filter out the material valuation data segment for message type MATMAS for your Sales and Warehouse systems.

3. On your Sales system, create a new material master record (transaction MM01).

a. Use Material group and Industry sector as specified in the guide handed out in class.

b. Select the Basic Data 1 and the Accounting 1 views.

c. Specify 0001 as the plant.

4. Use BD10 to send your material master record to your Warehouse system. (Note: If you have

not fully configured MATMAS message flow between your systems, you will have to complete that configuration (Model, RFC destination, port, and partner profiles) before you can complete this step.)

5. Check the IDoc overview to examine the data records for your IDoc to see if the material valuation segment was filtered out.

6. Log in to your Warehouse system to see if your material came through and if the valuation data

was filtered out.

4.3 Exercise: Converting a Field Value

Only one person at a time can perform shaded steps.

The Material Master table has a field (in the Basic Data view) called Drawing Document.

Determine the segment and field used for the Drawing Document in IDoc type

MATMAS03.

Define a conversion rule RULE## for MATMAS for sending materials from your Sales system to your Warehouse system.

Configure your rule to effect the following conversions:

a. If the drawing document number is between 255 and 300, change it to 37.

b. If the drawing document number is equal to 254, change it to 129.

c. Leave any other drawing document number unchanged.

Activate IDoc conversion for MATMAS when sending from your Sales system to your

Warehouse system.

Create and send enough materials to test your conversion rules thoroughly.

4.4 Exercise: Distribution Using Classes

Only one person at a time can perform shaded steps.

A. Create and use a class to send material master data.

1. Create a class CLASS## for material master data. Use the class type predefined for ALE.

2. Add at least two materials to your class.

3. Send the materials from your Sales system to your Warehouse system using your class.



4. Check that the correct materials were sent.

B. Restrict material master distribution to members of your class.

5. Add “Distribution via Classes” as a filter object to your distribution model.

6. On your Sales system, assign your class when sending to your Warehouse system.

7. Try to send a range of materials, some in your class and some not, and verify that only the

materials in your class are sent.



5 Chapter 2 – ALE Performance

The performance of an ALE implementation depends on many factors:

� Programs

� Hardware

� Database

� Application

� Data volume

� Message type

� Size of the IDoc

Usually if there is a performance bottleneck, it is in the processing of inbound IDocs. This generally takes much

longer than creating the outbound IDoc.

Here are some sample performance statistics (measured on a PwC project) to give an idea of the time required.

Remember that actual performance depends on all of the factors above, so your performance may be very different.

Outbound Processing

(IDocs / second)

Inbound Receiving

(IDocs / second)

Inbound Posting

(IDocs / second)

10 5 <1

This chapter makes some suggestions for improving and controlling the performance of ALE IDoc processing, on both

the outbound and inbound systems.



5.1.1 Timing of IDoc Processing

5.1.1.1 IDoc creation

We can’t control the timing of transaction data.

Use change pointers to keep track of master data that needs to be sent. Schedule the master data send at a time

when system load is low.

5.1.1.2 Transfer to Communication Layer

For master data, specify Collect IDocs in the partner profiles, then schedule program RSEOUT00 to send the IDocs at

an appropriate time.

You can do the same thing with any transaction data that does not need to be sent immediately.

5.1.1.3 Inbound IDoc Processing

Specify Background processing in the partner profiles, then schedule program RBDAPP01 to process the inbound

IDocs at a slower time.



5.1.2 Processing IDocs in Parallel

Transaction: RZ12

Menu Path: SM59 I RFC I RFC Groups

5.1.2.1 Creating IDocs

If you have more than one application server available, you can process IDocs in parallel. To do this, you need to

define a server group, using transaction RZ12.

Parallel creation only works for manual master data send, which uses all available dialog processes. The program

RBDMIDOC cannot handle parallel execution, and runs in a single dialog process.

There is no reason to create transaction data IDocs in parallel, since transactions are single events.

5.1.2.2 Sending

The sending of IDocs with tRFC communication automatically uses all available dialog processes.

5.1.2.3 Processing

IDocs grouped into a packet are processed in one dialog process. IDocs not in packets will use all available dialog

processes.

When processing IDocs in the background, you can specify a server group for parallel processing. If you select

Parallel posting in the RBDAPP01 program, the IDoc processing will use a separate dialog process for each IDoc

packet. If you do not, the system will use all available dialog processes in the local server.

Caution: Processing inbound IDocs in parallel is inherently asynchronous, since the system uses RFC calls to

communicate with other servers in the group. Do not use parallel processing for processing inbound IDocs in an

interface that needs to be real-time.



5.1.3 Processing IDocs in Packets

Processing IDocs in packets improves system performance by reducing the number of function module calls, and by

using fewer dialog processes.

5.1.3.1 Creation

For a manual master data send, you can specify a packet size.

5.1.3.2 Sending

If you select Collect IDocs in the sending partner profile, you must use the program RSEOUT00 to send the IDocs.

You would normally schedule this to run at an appropriate time.

You can send IDocs in packets by setting the Pack.size field in the partner profiles.

The smaller the size of an IDoc, the larger the packet size can be. A general guideline is a packet size between 10

and 200 IDocs.

5.1.3.3 Processing:

Some processing function modules can process multiple IDocs with a single call. These function modules process

many IDocs within one LUW, which improves database performance.

Grouping IDocs into packets is good even for function modules that do not support mass processing, because the

system processes the IDocs within one dialog process, which reduces system load.

You need to carefully balance packet processing and parallel processing. If your packets are too large, you will

reduce the ability to process in parallel.



5.1.4 Managing Communication

Normally, the system will start a batch job to restart a failed RFC connection. This can result in blocking of batch

jobs. To stop this, select Destination→TRFC Options from SM59 (RFC Destination maintenance). Select the Suppress

background job if conn.error checkbox.

You can restart unsuccessful connections with the program RSARFCEX.

Program RBDOIND will check that outbound IDocs have successfully connected to the receiving system.

5.1.5 IDoc Archiving

Transaction: SARA

Although IDoc archiving is the responsibility of the Basis team, the ALE developer should have a basic understanding

of it. Using transaction SARA - the object type is IDOC. This creates a backup of the IDoc database tables. Once the

tables have filled the space available, the system will stop writing IDocs to the database. There is no message to

indicate this, so the Basis team needs to monitor it.



6 Chapter 3 – IDoc Reduction

SAP supplies “maximized” IDocs containing all segments and fields required for the basic requirements of the

message type. A customer implementation may use a certain message type, but may only need to populate a subset

of the segments/fields. We can “reduce” this IDoc to simplify the communication.

Reduced IDocs are IDocs modified to only include the data that is valuable to the receiving systems. The reduction

excludes those fields that the receiving system does not need and therefore makes the IDoc easier to use.

Reducing an IDoc does not necessarily reduce network traffic. It can remove segments that would otherwise have

been sent (as can segment filtering in the distribution model), but for those segments still sent, the entire segment

is transmitted. The ALE layer will put a NODATA character – a "/" – into each field removed from the segment. The

receiving system will ignore fields that have this value.

For example, suppose that Business A and Business B each want to assign their own material group to a material.

We can reduce the MATMAS03 IDoc to create a new message type that does not transmit the material group. We

can then transmit other changes to the material without overwriting the material group.

Note: We can only reduce IDocs for master data.

6.1.1 Steps in IDoc Reduction

Here are the steps you must follow to create a reduced IDoc:

� Create a new message type

� Choose the segments and fields you want to include

� Activate the new message type

� Turn on/off change pointers

� Transport the new message type to other systems

� Configure the new message flow (Model, Partner Profiles)



6.1.2 Creating a Reduced Message Type

Transaction: BD53

Menu Path: SALE --> Modeling and Implementing Business Processes --> Master Data Distribution I Scope of Data for Distribution I

Message Reduction I Create Reduced Message Type.

To create a reduced message type, use transaction BD53.

You must base your new reduced message type on a message type that

SAP supplies.

After activating the required fields and segments (see the following section), save the reduced message type.

If you want to use change pointers to trigger the reduced messages, click on Activate change pointers. This adds

entries in the change pointer tables (BD50 and BD52) to configure change pointer use.

The new message type is client independent. However, change pointer activation is not. You must activate change

pointers in each client in which you want to use them.



6.1.3 Setting the Segment Structure

In essence you are creating a copy of the SAP-supplied message type. Your new message type inherits the same

IDoc type as the SAP supplied message type, therefore the same segments and fields.

All segments possible for reduction are displayed here. Segments that are required have a (*) following them, not

selected a (-), and selected a (+). For a complete key, use menu option Color/character→Utilities keyInitially all

segments that are not required are not selected. To select a segment place your cursor on the segment and press

the Select pushbutton. You must select a segment before selecting any fields in that segment.

Once a segment is active, you can access the fields in the segment by double-clicking on that segment. As with the

segments, required fields are marked with (*), non-selected with (-), and selected by (+) (see key from previous

slide). To select a field or fields, place a check mark beside them and press the Select button. This changes the

indicator from (-) to (+) and selects the field.

� Caution: Double-clicking on a field or putting a checkmark in the box next to it and pressing enter is not

sufficient to select it! If you do this and simply return to the previous screen you will lose your changes!

When all segment/field selections are complete, click Save to save your segment structure.



6.1.4 Transporting the Reduced Message Type

Transaction: BD63

Menu Path: SALE --> Modeling and Implementing Business Processes --> Master Data Distribution I Scope of Data for Distribution I

Message Reduction I Generate Transport Request for Message Type

After creating and activating your new message type, other systems need to recognize it. You can accomplish this by

putting the message type into its own correction and transporting it.

If, however, the correction that the message type is in has other data that you don’t want transported, you can put

the message type in a separate correction

for transport. Use transaction BD63. Enter your reduced message. The system will ask you for a change request

number to use.

� Remember: This is an optional step. If the transport assigned when the message type was created is valid

for transporting, then you can skip

this step.

6.2 Exercise: IDoc Reductions

Shading indicates one person per system at a time. Others will be "locked out"!

A. Creating a Reduced Message Type.

8. Log into your Sales system and create a reduced message type named ZMATMASR## where ## is the last two digits of your logon ID. Base your reduced message type on the SAP supplied message type MATMAS.

9. Choose and activate the segments and fields of your choice. Note: Make note of what segments and fields you chose for verification later!

a. Note: Normally you would transport your newly created message type to the other systems in

your ALE constellation using a CTS request. However, since reduced IDoc types are client-

independent, this is not necessary here.

B. Sending an IDoc using your Reduced Message Type.

10. On your Sales system, modify your customer distribution model MODEL##. Add an entry from your Sales system to your Warehouse system for your reduced message type.

11. Distribute the model and generate it on both systems.

12. Return to your Sales system. Create a material with MM01. Go to transaction BD10 and send your material to your Warehouse system. (See chapter 8 exercises for step-by-step instructions. Remember: Replace the message type with your ‘reduced’ message type!)

13. Check your IDoc statistics on the Sales system. Do you see your outbound IDoc (filter by your Warehouse partner)? Look at your data records. Which fields are being sent and which are not (the character '/' indicates an empty field)?

14. Check your IDoc statistics on the Warehouse system. Do you see your inbound IDoc (filter by

your Sales partner)? Did it process successfully?

C. Using Change Pointers

15. From the main BD53 screen, activate change pointers for your reduced message type.

16. Add a new material, or change an existing one.

17. Run the ABAP program RBDMIDOC, specify your reduced message type ZMATMASR##, and execute. The program should create at least one IDoc from your material.

Question: When you run RBDMIDOC, you may create more than one master IDoc. Why might this

happen?



7 Chapter 4 – IDoc Extension

Customer requirements may require more segments or fields than what an SAP supplied IDoc supplies. You can

“extend” this SAP IDoc to add the needed information.

An extended IDoc is based on an SAP supplied IDoc. The extension type inherits the segments associated with the

SAP supplied IDoc, and those segments are available in the extended IDoc.

To extend an IDoc, add customer-defined segments to existing IDocs. You cannot add fields to existing SAP

segments!



7.1.1 Create The Extension Segment

Transaction: WE31

Menu Path: Tools I Business Communication I IDoc I IDoc Basis I Development I IDoc segments

The first step in extending an IDoc is to create the new segments that will go into that IDoc. There are some rules

that you need to follow when creating the segments:

� The name of each segment type must start with ‘Z1’

� For each field in the segment you need to define a field name and a

data element.

� The data element for the segment structure must be of data type ‘CHAR’.

How to create new segments:

� Run the segment maintenance transaction WE31.

� Type your new segment name, and click on Create.

� Define the fields of your segment:

o Field name

o Data Element for the field (from the ABAP dictionary).

o Do not change the Export length!

� Save the segment

� Run Segment -->Check to check the segment for consistency.

� Release the segment for transport. Select Edit -->Set Release. Note that the “Release’ column now has a

check mark.



7.1.2 Create the Extension IDoc Type

Transaction: WE30

Menu Path: Tools I Business Communication I IDoc I IDoc Basis I Development I IDoc types

or: WE31 I Goto I IDoc type editor

After you create the segments to be added to the extension type, you can create the extension type itself. Execute

transaction WE30, enter the extension name, select Extension type, and click Create. You now have three options:

� Create new type: Does not refer to other extension types

� Create copy: Copies info from an extension type that already exists

� Create successor: Extends an extension type from a previous release

of R/3. You can only have one version of an extension type for

each release.

Enter the Basic IDoc type that this extension type will extend.

The screen now shows the structure of the IDoc type you used as

a reference.

Position the cursor on one of the segments and click Create. This will insert an extension segment as a child of the

selected segment.

NOTE: A segment cannot appear more than once in an IDoc type! You must control the use of duplicate segments

with the segment attributes (the next screen).

The segment attribute screen appears. Enter the information and save.

Extension segments should not be mandatory (for future upgrades), and will need to have minimum and maximum

number of instances defined. This answers the question, “for each instance of the parent segment, how many

instances of the child segment may we have?”

You can press the Segment Editor pushbutton to view or change the segment definition.



7.1.3 Create the new Message Type

You can only use an extension IDoc type by assigning it to a message type. You can create a new message type for

this.

First the message type itself needs to be created.

Transaction: WE81

Menu Path: Tools I Business Communication I IDoc I IDoc Basis I Development I Message types

or: WE30 I Environment I Message types

Create a new entry and save. Use SAP established customer naming conventions (good form is to start with a Z and

retain the rest of the related SAP message type, so, for example, MATMAS becomes ZMATMAS).

After creating the message type, associate it with the corresponding Basic IDoc Type and Extension Type. This

relationship is used when IDocs are sent to or received from a partner to determine what segments are valid and

what the hierarchy for those segments is.

Transaction: WE82

Menu Path: Tools I Business Communication I IDoc I IDoc Basis I Development I IDoc type/message

or: WE30 I Environment I IDoc type/message

Create a new entry and enter the Message type, Basic IDoc type, Extension type, and Release, and save your data.

Note: the release assignment is not valid for prior SAP releases.

One message type can be associated with many basic IDoc types; however, you need a one-to-one relationship for

distribution via ALE.

If a message type is no longer uniquely identified to an IDoc, you can restore unique allocation using transaction

BD69.



7.1.4 Check the Extension Type

After creating a new extension type, it’s a good idea to test it.

From the main Develop IDoc Types screen select the IDoc type you want to check and select Check→Development

Object. This check will try to verify all objects related to the object you selected for validity and consistency. All

return codes should be zero (RC =0), except "Extension type is not released (RC =4)".

Do not release the extension type until you have tested it. The extension type can be ‘unreleased’, but it is fairly

complicated to do. A segment’s release, however, can be canceled without much difficulty. Once you have tested

your extension type, and everything works right, you can release the extension. To do that, go to transaction WE30,

and select the menu option Set →Edit release.

Changes to released types are not allowed. You have to do Edit Cancel release → to enable modifications.



7.1.5 Communication Parameters

Remember that all ALE configuration is based on the message type. Since you have created a new message type,

you must properly configure the ALE layer to process your new message. This includes:

� Adding your new message type to the distribution model.

� Creating partner profiles.

NOTE: You must create the inbound partner profile manually. The generation function will not work because the

system does not know how to process your new message type. More on this later.



7.1.6 Master Data Outbound Configuration

If your extension is to handle master data, there is more configuration to do:

� If distribution is to be done automatically through change pointers, then you must activate them for the

extended message type.

� The system must know which fields should trigger the creation of

change pointers.

� When creating the extension, the system needs to know which function module to use.

7.1.6.1 Activate Change Pointer for Message Type

If your extension type will handle master data using change pointers, you need to activate the change pointers.

When creating a reduced IDoc type, the system does this automatically, but when creating an extension you must

enter it yourself, using transaction BD50. See the Distribution Methods chapter for details.

7.1.6.2 Activate Change Document Items

Transaction: BD52

Menu Path: Tools I ALE I ALE Development I IDocs I Change I Define change-relevant fields

For standard SAP supplied messages, all fields within the message type will create change pointers by default. With a

customer created extension message type, you must explicitly state what field(s) will trigger the creation of change

pointers when changed.

The easiest way to determine the entries is to copy them from the message type you are modeling. Each row

entered indicates that any modification to that field causes the creation of a change pointer.

If you want to create a change pointer when a master data item is added, add a record with the table name and the

field name KEY.



7.1.7 Assign Function Modules to Message Type

7.1.7.1 Outbound

Transaction: BD60

Menu Path: Tools I ALE I ALE Development I IDocs I Change I Define function module for evaluation

When you create an extension IDoc type, you must tell SAP how to populate it.

SAP updates this table for you automatically when you create a reduction, but not when you create an extension!

You can click New Entries and enter the message type, the IDoc type, and the name of the function module used to

populate the IDoc, but it’s much easier and safer to copy the entry from the message you based your extension type

on.

Transaction: WE41

Menu Path: Tools I Business Communication I IDoc Basis I Control I Outbound Process Code

If you are using Message Control for transactional data, you also need to specify an outbound process code in the

partner profile. The system uses this process code to determine which function module to use to create the IDoc.

You can click New Entries and enter the name of the function module used to populate the IDoc, but it’s much easier

and safer to copy the entry from the message you based your extension type on.

7.1.7.2 Inbound

Transaction: WE57

Menu Path: Tools I ALE I ALE Development I IDocs I Inbound Processing I Function module I Assign IDoc type and message

type

On the inbound side, the SAP system must know what function module is to process that message type and

extension.

Enter the function module name, the basic IDoc type, the extension type, and the message type.

It’s much easier and safer to copy the entry from the message you based your extension type on.



7.1.8 Filling and Extracting Extension Segments

Although the segments are now defined to be sent or received, there is no current way to manipulate the data in the

segments. We need to make some source code changes!

To post and extract data to and from an IDoc extension, we need to find a user exit in the application code. User

exits are found in the function modules, which are tied to the process codes used by ALE. The ABAP code to process

an IDoc extension is added within an INCLUDE statement in the user exit.

We'll discuss how to program IDoc segments in the next two chapters.

7.2 Exercise: Creating an IDoc Extension

Only one person at a time can perform shaded steps. Others will be "locked out"!

This exercise has two objectives:

18. Create an extension of the SAP supplied IDoc MATMAS03.

19. Configure the distribution of Master data using Change Pointers.

IMPORTANT: Use the object names given in these directions! If you use different names, the supplied user exit will not work!

Scenario:

Springfield Nuclear Power, Inc. is implementing SAP for its three nuclear power plants. They need to configure Material Master transfer using ALE, but the SAP-supplied material tables do not have the proper fields for radioactive materials. Therefore, they have created a custom table, called ZMARANUC, to store extra information for the few materials that are radioactive. This table stores two

extra pieces of information for each material that is radioactive: the Half-Life and the Half-Life Unit. Note that most materials are not radioactive, so they will not have an entry in this table.

In order to transfer these radioactive materials using ALE, we need to build an extension to IDoc type MATMAS03 to store the extra information. We also need to write user exit code on the Sales system to populate this segment from table ZMARANUC, and read the data on the Warehouse system into table ZMARANUC.

This is your task.

Summary of steps needed to build this scenario:

1. Create an extension segment

2. Create an extended IDoc type to merge this segment with MATMAS03

3. Create and configure a new message type for your extended IDoc type

4. Configure the creation of IDocs using change pointers

5. Perform outbound configuration

6. Perform inbound configuration

7. Test the scenario

Detailed instructions:

Step 1: Create an extension segment (both sending and receiving systems)

20. Create a development class called ZAL##, where ## is your user number. (Use SE80 to do this.)

Create a new change request when prompted.

21. In the segment editor (WE31) create an extension segment named Z1SEGNUC#### where #### is your logon ID. It should have the following fields:

Field Name Data Element

MATNR MATNR

HALFLIFE ZHL

UNIT ZHLU

22. Check and release the segment.



Step 2: Create an extended IDoc type to merge this segment with

MATMAS03 (both sending and receiving systems)

23. In the IDoc type editor (WE30) create an extension type named ZEXTNUC#### where ####

is your logon ID. Use the SAP IDoc type MATMAS03 as your reference type.

24. Add your segment Z1SEGNUC#### to the IDoc as a child of E1MARAM. Make the segment optional, with minimum and maximum number equal to 1.

Step 3: Create and configure a new message type for your extended IDoc

type (both sending and receiving systems)

25. Create a new message type called ZMESNUC#### where ## is your logon ID. (WE81)

26. Associate your new message type to your Extension Type and SAP supplied Basic IDoc Type MATMAS03. (WE82)

27. Check and release your extended IDoc type



Step 4: Configure the creation of IDocs using change pointers (sending system)

28. Make sure that Change Pointers are activated generally. BD61

29. Activate Change Pointer creation for your new message type. BD50.

30. Configure the change document items for your extended message type. Add an entry for object “MATERIAL”, table name MARA, field name "KEY". This will cause the creation of change pointers when creating a material. BD52.

Step 5: Perform outbound configuration (sending system)

31. Maintain the function module to create your extended message type. BD60. Copy the entry for

message type MATMAS. You only need to change the message type to your extended message type and enter.

32. Modify your customer distribution model MODEL##. Add an entry from your Sales system to your Warehouse system for your extended message type.

33. Generate the outbound partner profile.

34. Distribute the model to your Warehouse system.

Step 6: Perform inbound configuration (receiving system)

35. Configure the function module to process your extended message type. Run WE57 and copy the entry for function module IDOC_INPUT_MATMAS01 / Basic IDoc MATMAS03 / Message type MATMAS.

a. Enter your extension type.

b. Replace message type MATMAS with your extended message type

c. Enter.

36. Generate the inbound partner profile. Important: Set the inbound parameters to Trigger by background

program!



Step 7: Test the scenario

On your Sales system:

37. Run transaction MM01 and create a new material. Be sure to write down the material number created!

38. Run custom transaction ZNUC to add the extension information to table ZMARANUC for this

material. Use any number for the Half-Life, and “H” (hours) for the Half-Life Unit.

39. Run the program RBDMIDOC (or transaction BD21). This program creates IDocs from change pointers that have been created for the message type you specify. In this case specify your extended message type. If all is set up correctly, you should receive a message that at least one master IDoc and communication IDoc were created.

40. Check your IDoc statistics. Do you see your outbound IDoc?

On your Warehouse system:

41. Run APAB program RBDAPP01 (or use transaction BD87) to process your IDocs.

42. Check your IDoc statistics. Do you see your inbound IDoc? Did it process successfully?

43. Run SE16 to look at table ZMARANUC. Was the extension data posted properly?

Question: Why was it necessary to use RBDAPP01 to process the inbound IDocs?



8 Chapter 4 – Communication Parameters

This chapter describes the fundamental communication configurations for ALE. These are the minimum

configurations required to establish a simple data transfer.

• RFC Destinations

Transaction: SM59

Menu Path: Tools H →Administration Administration I RFC→Network destinations

An RFC (Remote Function Call) destination defines the connection parameters to another system. There are many

types of RFC destination, with the most common being R/3 and TCP/IP connections.

RFC Destination configuration is required for SAP-to-SAP ALE distribution, but is not needed for inbound distribution,

or outbound distribution using a file interface (such as a legacy system interface or a file-based EDI scenario).

RFC destinations should “map” to the desired logical system. In fact, if the RFC destination has the same name as its

corresponding logical system, configuration is easier because we can automatically generate the partner profiles

(described later).

The maintenance of the RFC destinations is not a part of the automatic transport and correction system. We need to

make the settings manually on all systems.

To create or maintain RFC destinations, use transaction SM59.

For R/3 connections for SAP-to-SAP distribution, indicate the target machine and instance along with necessary login

information. The Test connection function checks the connection with the external system and allows you to check

the performance times for making this connection. The Remote logon function allows you to logon to the remote

system and start a session.

CAUTION: The names of RFC destinations are case-sensitive!



For TCP/IP connections, specify the path, program, and machine that will receive and process outbound IDocs.

The program can reside on the application server, a specific machine, or on the workstation itself.

The Test connection function allows you to check the performance times for connecting to the external system.



• Ports

Transaction: WE21

Menu Path: Tools H →Business Communication IDoc I Port→IDoc Basis Definition

Ports establish the linkage between the partner profiles (discussed in detail later in this chapter) and the RFC

destinations for outbound transfers. They also indicate if the transfer is file based or tRFC (or R/2, etc.).

To create a port, use transaction WE21.There are several types of port. Some of the more important ones are:

� Transactional RFC

� File

� R/2 system

� XML

The system can automatically generate a transactional RFC port if the logical system name is the same as its

corresponding RFC destination (between R/3 systems only!). You need to create ports manually for all other system

types.

•

• Transactional RFC Ports

Transactional RFC ports point to an RFC destination, which must exist before creating the port. Simply create a new

entry and associate it to a pre-created RFC destination (field Logical destination).

tRFC ports merely function as a pointer to an RFC destination. We define the actual connection parameters in the

RFC destination itself.

Define a tRFC port for R/3 to R/3 connections and for any R/3 to external system connections that use a remote

function call interface.



• File Ports

File ports can contain configuration for any or all of the following:

� Outbound file: A file to receive outbound IDocs.

� Inbound file: A file to supply inbound IDocs.

� Status file: A file to store IDoc status records.



To configure a file name for one of these files you need to supply

the following:

� The directory (on the application server) where the file is found. End this entry with a ‘/’ character.

� The name of the file. You have two options: o Specify the actual file name.

o Choose a function module that generates a filename from timely information, such as date, time,

message type, or user id.

•

• XML Ports

An XML port is similar to a File port, with these differences:

� Only outbound transmission is supported.

� The file will be written in XML format, rather than IDoc text.

You also have the option of including a Document Type Definition (DTD) in the XML file created.



• Partner Profiles

Transaction: WE20

Menu Path: Tools H →Business Communication IDoc I Partner→IDoc Basis Profile

The partner profiles tell the ALE layer how to send messages between systems.

Given a message type and a communication partner system, the partner profile specifies information that the ALE

layer needs to properly create or process the IDocs. This information is different for senders and receivers.

The partner profile configures the ALE layer, while the RFC destinations and ports configure the communication layer.

The Partner number is the logical system name of the “other” system:

� In the sending system profiles, the Partner number is the receiving system.

� In the receiving system profiles, the Partner number is the sending system.

The Partner type is always “LS” (logical system) for ALE.

Partner class is a free text field that lets you classify partners.

Receiver of notifications is a Workflow configuration for error handling.

After you create the profile, then assign parameters to it as follows.

Message Control parameters control the sending of messages from an application that uses Message Control (also

called Output Determination) - Separation of Sales and Distribution, for example.

We'll look at this configuration in detail in a later chapter.



• Partner Profile Outbound Parameters

The outbound parameters provide information for creating outbound IDocs:

� The receiver port to use. This port can point to an RFC destination or to a file, as discussed earlier.

� Whether to send the IDocs immediately or to collect them for sending in batches.

� If IDocs are collected for batch sending, the package size to use.

� The IDoc type to use for the message.

� Workflow configuration for handling errors.

We’ll discuss the collection of IDocs for batch sending in a later chapter.



• Partner Profile Outbound Parameters

The inbound parameters provide information for processing inbound IDocs:

� The process code to use. This code points to a function module (or to a workflow) that processes the IDocs.

� Whether to process the IDocs immediately, or to wait to process in the background.

� Workflow configuration for handling errors.

We’ll discuss the processing of IDocs in the background in a later chapter.



• Partner Profile Generation

Transaction: BD82

Menu Path: BD64 H Generate→Environment partner profiles

Under most circumstances, SAP can use your distribution model to generate partner profiles for you automatically.

Restrictions on generation:

� Each receiving logical system in the model must have an RFC destination defined with the same name as the logical system.

� The receiving system will not generate a profile for any message received with a different receiving logical system name than is allocated to it.

Normally, you maintain the distribution model on one system, distribute it to the other systems, and generate the

partner profiles on each system from the model.



Parameters for the program:

� The model view or views from which to generate profiles

� Workflow configuration for errors

� Outbound IDoc packaging options

� Inbound IDoc background processing options

The results are color-coded:

� Green: The generation was successful

� White: The profile or parameter already exists

� Red: an error occurred during generation

You can double-click on any line in the results to run the corresponding maintenance program.

If you have errors, you can correct the problem and run the generation again, or maintain the profiles manually.



• Model Distribution

Menu Path: BD64 I Edit H →Model view Distribute

Typically, you maintain the distribution model on the one system designated as the owner of the model. Then you

distribute it to the other remote SAP systems.

To distribute a model to another system, you must have:

� configured an RFC destination for that system.

� The SYNCH message type configured in the partner profile for that system. The profile generation

program will automatically create this profile parameter for all systems represented in any model that you

generate. Therefore, you should generate your model on its owner system before distributing it to other systems.

Remember to generate the partner profiles on the other systems after distributing the model.

To distribute a model:

� Enter the name of the model view you want to send

� Click the boxes of the systems you want to receive the model view. The program will automatically check any systems that are represented in the model as sender or receiver, but you can add or remove systems

from the list.

� Execute.

The program will give you color coded messages with success (white) or failure (red) for each receiving system.



• ALE Configuration Summary

• Inbound

Configuration requirements are similar for all inbound transactions, regardless

of type.



• Outbound

Outbound ALE messages require configuration of all pieces (logical systems, RFC destinations, ports, partner profiles,

and distribution model).

R/3 to R/3 uses a RFC type destination and a transactional RFC type port.

R/3 to Legacy RFC based uses a TCP/IP type destination pointing to a

server program executable that receives and processes the IDoc and a RFC type port.

R/3 to Legacy File based uses only a File type port with an outbound file parameter pointing to the path and filename

the IDoc is to be written to.

R/3 to Legacy File based with RFC uses a TCP/IP type destination pointing to RFCEXEC and a File type port with a

command file parameter pointing to a server executable that receives and processes the IDoc.

• Exercise: ALE Communication Parameters

In this exercise, you will configure message flow between two SAP systems using ALE. You

will distribute a material record from one client to another

Caution: Only one person at a time can perform shaded steps. Please work quickly so that others will not be locked

out for too long!

A. Define the RFC Destination

In order to communicate with your Warehouse system, your Sales system must know how

to reach it.

1. Run SM59. If the RFC Destination for your Warehouse system does not exist, create it.

If it does exist, proceed to Partner Profile Generation, below.

2. Enter the information:

a. RFC Destination: your Warehouse logical system name. CAUTION: This field is

case-sensitive!

b. Connection Type: 3

c. Description: descriptive text

d. Client: your Warehouse system's client number

e. User: your logon id. CAUTION: Do not select the Current user checkbox.

f. Password: your logon password

g. Target host: your Warehouse system's host name

h. System number: your Warehouse system's system number

3. Click Save.

4. You can click on Test Connection to test the connection to the other system, or Remote

Login to log into it.



B. Generate the Outbound Partner Profile

You will now create a partner profile, which combines your logical system with the

message types defined and associates it with a port to the physical system.

1. Environment I Generate partner profiles from the Model Maintenance (BD64).

2. Enter your model name (MODEL##) and click on Execute.

3. The system automatically creates the appropriate partner profile and generates color-

coded status messages about what it did. If any of your messages are red, this

indicates an error, which you should correct before proceeding.

4. Go to Environment # Change partner profile (or WE20) to see what the automatic

generation did. (Created a port and a partner profile.)

C. Distribute the Customer Model

You will now distribute the distribution model you created earlier to the other system.

1. Run BD64. (Distribution Model Maintenance).

2. Highlight your distribution model and follow menu path Edit # Model View # Distribute.

Enter your model name and enter.

3. Select the proper system to receive the model and execute. You should see a message

indicating successful transfer.

D. Generate the Inbound Partner Profile

1. Repeat the partner profile generation (Step B above) on your Warehouse system to

create the partner profile on that system.

Note: Ignore any errors listed involving an RFC destination for your Sales system. This

will not affect inbound processing.



E. Send a Material

1. Test your configuration by sending a material from your Sales system to your

Warehouse system.

2. Log back into your Sales system.

3. Create a new material using transaction MM01. Use the information on the sheet

handed out in class to create the material. Make note of the material number assigned!

4. Execute transaction BD10. This is the ALE Material Master Data Distribution program.

5. Enter the number of the material you created, the message type to use (MATMAS),

and your Warehouse system name, and then click Execute.

6. You should see message boxes saying that 1 master IDoc was set up and 1

communication IDoc was sent.

7. Run transaction WE05 to look at the status of your message. The status should be 03

“Data passed to port OK”.

8. Drill down into the IDoc to look at the control, data, and status records.

9. Log into your Warehouse system and use WE05 to look at the received message. Its

status should be 53 “Application document posted”.

10. Drill down into the IDoc to look at the control, data, and status records. How are they different from the outbound records in the Sales system?

11. Run transaction MM03 to see if your material was successfully added to the receiving

database.

• Exercise: Using a File Port

In this exercise, you will configure material output to a file port, then read input from this

port.

A. Configure Outbound File Port

1. On your Sales system, run transaction WE21.

2. Highlight File, then click on Create.

3. Name your port PORT##, where “##” is the last two digits of your logon ID.

4. Enter a short description, and make sure that release 4.x record types is checked.

5. On the Outbound file tab, change the Physical directory to “/tmp/” (note a / at both

the beginning and the end), and select the function module

EDI_PATH_CREATE_USERNAME. Leave the Outbound file field blank.

6. Save.

B. Configure Outbound Processing

2. Create a new logical system (BD54) called FILE##. Do not allocate this logical system

to any client.

3. Change your distribution model (BD64) to add a message:

a. Sending System: Your Sales system

b. Receiving System: Your FILE## logical system

c. Message Type: MATMAS

4. Save your model.

5. You will not be able to generate the partner profile automatically (Why not?). Run

WE20 to enter it manually. Click Create and enter the information:

a. Partner Number: FILE##

b. Partner Type: LS

6. Save, and then click on Create outbound parameter. Enter the information:

a. Message Type: MATMAS

b. Receiver Port: FILE##

c. Output mode: Transfer IDoc immediately



d. Basic Type: MATMAS03

7. Save.



C. Send a Material

1. Run MM01 to create a new material. Follow the guidelines on the sheet given out in

class.

2. Use BD10 to send this material to your logical system FILE##. You should get one

Master IDoc and one Communication IDoc.

3. Run AL11, and double click on the /tmp directory.

4. Double click on the file named with your username to look at the IDoc.

D. Using an XML port.

1. Create a new XML port called XML##. Use the same outbound parameters as in step A

above.

2. Change your partner profile entry for the FILE## logical system to use the XML##

port instead of the FILE## port.

3. Resend your material to the FILE## logical system.

4. Use AL11 to look at the resulting XML file. (Note: The system does not put newlines

into the XML file, so you will not be able to see the entire file. If you want to look at

the entire file, ask the instructor for help.)



9 Chapter 5 – ALE Architecture

• Outbound Processing

• Application Transaction

� Create the application document o Outbound processing begins with the SAP application transaction. This transaction creates a

document that needs to be sent to another system with ALE.

o The application does not post its data yet. Instead, it waits until the ALE layer creates the

outbound IDocs.



� Read the Distribution Model o When the SAP application is ready to post the document to the database, it queries the ALE

distribution model to determine whether it needs to send the data somewhere with ALE.

o Some transactions may also check the distribution model for filter objects. These filters specify

certain pieces of data that the receivers do not need, and determine which objects the

application will include in the IDoc. If the transaction does not look at the filter objects, then the

ALE layer will do the filtering.

o If no ALE IDoc is needed, the SAP application posts the application data in its normal manner.

o Alternatively, the application can use Message Control to determine if it needs to create an IDoc. We will discuss Message Control in a later chapter.

� Create the Master IDoc o If the model indicates that the application program needs to create an IDoc, then it does so by

calling a function module appropriate for the message type.

o The application passes this Master IDoc to the Distribution Layer in an SAP internal table.

• Distribution (ALE) Layer

� Read the Distribution Model. o If the SAP application did not specify a receiver for the message, the ALE layer reads the

distribution model to determine the receiver(s). It also processes any filter objects (from the model) associated with the message flow.

� Create the Communication IDocs

o The ALE layer then creates a separate copy of the Master IDoc, called a Communication IDoc, for each receiver.

o If there are no receivers defined in the model, processing stops and the application posts its

data to the database.



� ALE Layer IDoc Processing o Next, the ALE Layer performs a series of IDoc conversions, if needed:

� Segment filtering. The ALE layer can remove any segments that the receiver does not

need. These segment filters are dependent on the message type and the receiver.[2]

� Field Value Conversion. The ALE layer can perform some simple conversion of values

in the IDoc’s fields. The conversion of field values is dependent on the message type

and the receiver. Examples of field value conversions might include converting a 10-

digit customer number to a 15-digit customer number, suppressing the value of a

particular data field, etc. Conversion of field values will reduce the system performance, so use it only when other methods are not appropriate.

� Version Conversion. The ALE layer can convert the IDoc’s control record to a different

R/3 release version. We specify the version of control record that a logical system

uses in the port configuration. This feature lets us distribute applications across

multiple SAP releases, and is the reason SAP guarantees that ALE will work between

different releases.

o IDoc Creation

� After the ALE layer completes the IDoc processing, it stores the Communication IDocs

in the sending system’s database (in EDIDC, EDID4, and EDIDS). � The system creates links (in the control record) to the application document and to

the tRFC transaction id for the call to the other system

� After the call to the ALE layer completes, the application will post its data to the

database and commit work. This ensures that the application document creation and

the IDoc creation occur in the same logical unit of work.

[2]

Note that there are two levels of filtering: IDoc level and segment level. The filter objects defined in

the model primarily filter entire IDocs. The ALE layer can also filter out specific segments, which is

what we’re talking about here. We’ll discuss this in more detail in a later chapter.



• Communication Layer

� Once the ALE layer has created the IDoc, it sends it to Dispatch Control, which controls how the IDoc is

sent (file interface or tRFC) and when the IDoc is sent (immediately or periodically in batches). Dispatch Control uses the technical communication parameters that we set in the partner profile.

� When the ALE IDoc is complete and Dispatch Control has determined when and how to send it, the

Communications Service actually transmits the message.

� Sending the outbound IDocs in batch reduces the communications overhead.



• Inbound Processing

• Communication Layer

The Communication layer receives an IDoc by tRFC, EDI, or some other method, and passes it to the Distribution

(ALE) Layer.

• Distribution (ALE) Layer

The ALE Layer performs the same IDoc processing as on the outbound side:

� Segment Filtering The segment filter removes any segments that the receiving system does not need for this message type.

� Field Value Conversion. The ALE layer can provide simple data mapping and conversion.

� Version Conversion. The ALE layer can convert the control record to the required version.

Following this pre-processing, the ALE layer writes the resulting IDoc to the SAP database, and creates a link to the

IDoc in the source system.

After the ALE layer stores the pre-processed IDoc in the database, it reads the inbound configuration to determine:

� What type of input processing is required (Function Module or Workflow)

� When the IDoc is processed by the SAP application (immediately or periodically in batches)

� Which users to notify if there is an error in processing

The ALE Layer then passes the IDoc data directly to the appropriate SAP application.

• Application Layer

The SAP application reads and processes the information in the IDoc and creates an application document for posting

to the SAP database.

Once the application document is ready for posting, the application posts it to the database and updates the IDoc’s

status records in the same Logical Unit of Work.

The ORDERS and ORDCHG IDocs are exceptions to this timing. In both cases, the application executes a CALL

TRANSACTION first, and then updates the status records.

When the SAP application processes the IDoc, it can check the serialization. Using the timestamp of the IDoc, the

application can determine if it has already received a more recent IDoc for the same inbound document. If it has, it

may wish to avoid posting the data in the overtaken IDoc.

Not all of the SAP applications use this serialization capability.



• Outbound Processing for EDI

This is the normal process flow for creation of outbound EDI IDocs. An EDI scenario may or may not use all of these

elements.

The application program creates its document (purchase order, etc), and calls the Message Control system.

Message Control (also called Output Determination) determines where to send the document. This may include

printing a hard copy or sending by ALE or EDI. If out by ALE or EDI (that is, by IDoc) is required, then Message

Control writes a record to the NAST table.

ABAP program RSNAST00 (which is scheduled to run on a periodic basis) reads the NAST records and creates

outbound IDocs for each one, based on the ALE configuration. It writes these IDocs to the IDoc tables (EDIDC,

EDID4, EDIDS). If the partner profile is set to "Send immediately", then the ALE layer will send the IDocs at this

time.

If the partner profile is set to "Collect IDocs", then the ALE layer will not send the IDocs until the ABAP program

RSEOUT00 (also scheduled for periodic execution) runs. This program calls the ALE layer to send all collected IDocs

of any specified message types.

The ALE layer does two things in sending an IDoc, whether it is directly from RSNAST00, or by the running of

RSEOUT00:

� Writes the IDocs to the file specified in the file port.

� Executes the program RFCEXEC. This program is not an ABAP program, but rather an SAP-supplied

program that runs on the operating system.

RFCEXEC, in turn, executes a shell script or other program that activates the EDI translator.

In general, this script will run the translator, passing it the name of the file containing the IDocs, which the

translator then reads.

The EDI translator vendor will generally supply the shell script that RFCEXEC uses to start the translator running.



10 Chapter 6 – Data Distribution Methods

• Configuring Master Data Fetch

We can trigger the distribution of Master Data from either the source system or the destination system.

Use a send when you create or maintain a master data record on a central system and push it out to multiple

distributed systems.

� If the data does not exist on the receiving system, then the receiving system creates it.

� If the data DOES exist on the receiving system, then the receiving system changes the record. It only changes the information that is different from the record on the receiving system.

� You can send any of the types of master data available to ALE.

Use a fetch when you create or maintain a master data record on a distributed system and pull it in to the central

system.

� If the data does not exist on the fetching system, then the fetching system creates it.

� If the data DOES exist on the fetching system, then the fetching system changes the record. It only changes the information that is different from the record on the fetching system.

� You cannot fetch all master data types. You can only fetch those master data types that have a fetch message type defined. Currently, these are: material, customer, vendor, general ledger, profit center, cost

center, and activity type information.

To configure a fetch, simply define a fetch message type in the direction opposite from the master data message

type in the distribution model, then use the appropriate master data fetch program.



• Triggering Methods

The methods we can use to trigger ALE distribution vary by the data type.

• Master data

� Manual Program o We can send data directly from an ABAP program. SAP provides such programs for most kinds of

master data. You can access these programs with menu path Tools # ALE # Master Data

Distribution.

o Enter the appropriate data on the master data send/fetch screen, which includes the master

data to be sent, the message type, and the logical system of the receiving system (send only).

o If you do not enter a logical system, then any logical system that has the pertinent message

type in the distribution model will be included in the ALE transmission. This is useful when there

is one central system where the data is created and then transmitted out to multiple distributed systems via ALE.

� Automatic Send o We can use Change Pointers to automatically distribute the data.

o If a user creates, changes, blocks, or deletes a master record, the Shared Master Data (SMD)

system will send the record automatically.

o If multiple changes are made to a master record between distributions, the system will

incorporate all of the changes into one change document for that master record.

o Automatic distribution will work for all the master data types available to ALE.

o IDoc distribution using the SMD is generally a batch (not real-time) process. The system does

not send IDocs at once, but rather waits for the next scheduled send. However, with

customization of the tool, you can achieve near-real-time distribution.



• Transaction data

� Direct ALE Call

o The transaction program may contain a call to the ALE layer to send the IDoc directly.

� Message Control

o We can use Message Control to automatically distribute the data. The message control system

allows the sending of data in real-time.



• Automatic Master Data Send with Change Pointers

SMD outbound processing begins with the SAP application transaction that changes master data that needs to be

sent to another system with ALE. The application does not post its data yet. Instead, it waits until the change

document and change pointers are written.

The change document service examines which fields have been changed. If the field that is changed is one that

receiving systems are interested in, the program writes a change pointer to the database. Change pointers are the

mechanism by which the SMD tool operates. The change pointers are message type specific, and also indicate which

part of the master data record changed (that is, which database table was modified). The ALE-relevant fields are

configurable by message type.

A standalone program (RBDMIDOC) analyzes the unprocessed change pointers. Normally this program is scheduled

to run periodically for different message types. When it finds a change pointer for a particular object, it creates a

master IDoc for the object referenced by the change pointer.

The ALE layer reads the distribution model and generates communication IDocs as usual, including filtering, version

change, ALE rules, etc.



• Configuring the SMD Tool

These are the steps needed to configure an automatic master data send:

Transaction: BD61

Menu Path: SALE I Modeling and Implementing Master data Distribution→Business

Processes I Replication of Modified Data I Activate Change Pointers - Generally � Activate change pointers generally. Use BD61. This “turns on” the SMD system, and allows the automatic

change detection routines to work. You must activate this flag in order for ANY change pointers to be

written.

Transaction: BD50

Menu Path: SALE I Modeling and Implementing Master data Distribution→Business

Processes I Replication of Modified Data I Activate Change Pointers for Message Types � Activate change pointers for message type. Use BD50. This sets up data change detection for individual

message types.

Transaction: BD52

Menu Path: Tools I ALE I IDocs→ALE Development I Engineering Change

Management I Define Change-Relevant Fields � Define change-relevant fields. Use BD52.This allows you to set which fields in the master data record

should trigger the writing of a change pointer. SAP proposes a default set, which usually, but not always, includes every field in the table. This is optional – if you want to use SAP's default set of fields, you do not

need to configure this.

� Schedule IDoc creation job. This program (RBDMIDOC) will look for records that have changed, and send them to the appropriate receiving systems, based on the distribution model.



• Message Control

Message Control (also called Output Determination) is a part of the functional configuration that determines

what output types to use when creating a transaction document.

We can configure a document to produce many kinds of output:

� Printed forms on a printer

� Fax output

� EDI output

� ALE output

The methods for configuring message control differ in each functional area, and message control is not available for

all functional areas. Specifically, only MM and SD applications can use it.



• Hierarchy of Message Control Components

The configuration of Message Control involves many layers of components. These components are as follows, with

examples for configuration of sales orders:

� Application -- The application area. Each application capable of message control has a unique two-

character ID. o Example: Sales

� Scheme -- In general, the application document created. May also be called Procedure. A scheme defines a set of possible output types for an application. Although several can be configured, only one is

active. This is the set of possible outputs for an application. This does not mean they will all be generated.

Using transaction VOFM it is possible to add requirements to an output type in the scheme. A requirement

is a special ABAP program used to implement complex business logic. For example, an order is not created

unless data meets certain validations.

o Examples: Order, Quotation

� Output Type -- The type of message created. May also be called Message Type (but this is not the same as an ALE message type). The output type defines the characteristics of the output, such as medium,

timing, etc.

o Examples: Order confirmation, internal order message



� Access Sequence -- Defines the fields used to look up condition tables. This identifies the business rules to check before proposing output, and the order in which to check them. You can chose exclusive or

inclusive rules. An exclusive rule means that when the first rule evaluates to true, the system proposes the

output ignoring the remaining rules in the access sequence. With inclusive rules, all rules must be true

before the output is proposed. It is also possible to add ABAP requirements through VOFM to check

specific business rules based on the fields in the condition table.

o Examples: Order type, Sales org/customer

� Conditions -- A list of outputs to create under certain conditions. These are the actual values checked in the business rule. The system will only propose an output when the values match the records in the

condition table. A large set of standard tables is available, or you can create new ones.

o Example: EDI for customers in sales organization 0001, printed output for all others



• Configuring Message Control

The R/3 system comes with a set of default message control configurations, which we can add to or change. These

include all of the application areas, as well as most schemes you will ever need.

In general, you should define these components from the bottom up. That is, you should create the condition tables,

then the access sequences, and so on to finish with the scheme.

SAP considers schemes, output types, and access sequences to be configuration data. You will find the programs to

maintain them in the IMG. For example, the IMG path for Sales Documents is: Sales and Distribution --> Basic

Functions --> Output Control --> Output Determination --> Output Determination Using the Condition Technique -->

Maintain Output Determination for Sales Documents

Condition records are application data. You find the programs to create them as part of the application menu path.

For example, the menu path to create condition records for Sales Documents is: Logistics --> Sales and distribution -

-> Master data --> Output --> Sales document --> Create.



Here are some common configuration hierarchies:

Materials Management:

Application/Transaction Condition Type Procedure Logical Message Type

EF/Purchase Order NEU RMBEF1 ORDERS

EF/P.O. Change NEU (with change flag) RMBEF1 ORDCHG

EA/Request for Quote NEU RMBEA1 REQOTE

Sales and Distribution:

Application/Transaction Condition Type Procedure Logical Message Type

V1/Sales Orders BA00 V10000 ORDRSP

V1/Quotations AN00 V06000 QUOTES

V2/Delivery Notes LAVA V10000 DESADV

V3/Invoicing RD00 V10000 INVOIC



• Configuring Message Control: An Example

As an example of the required Message Control configuration, let’s consider the Distributed Contract scenario. As a

reminder, this scenario involved the creation of a contract at a central office which then sends it to distributed offices.

The local facilities can then create purchase orders referencing this contract.

We need the following configurations.

Note: Transaction codes given here are specific for the Distributed Contract scenario. Transaction codes for other

scenarios will be different, although the functioning of the programs is similar.

Remember that you must define new entries from the bottom of the hierarchy to the top.

� Define Access Sequences (M/52). Defines the fields of the condition tables used to determine output. Each access sequence corresponds to a different condition table.

o We use Access Sequence 0001, which will use condition table 26 (Purchasing by Document Type)

� Maintain Output Types (M/38). Defines which Access Sequence to use for each Output Type, as well as many options and parameters for the Output Type:

o The medium and timing, which may differ with different partner types.

o The program used to process and output the data, which in our example creates the IDocs from

the application document. o We will use Output Type VNEU, which represents Distributed Contracts.

� Message Schemes (M/68). Associates Output Types with Schemes. A scheme is simply a defined sequence

of output types. The Message control system creates each output type in the sequence specified here. Each output type may have a Requirement Routine - a business need that must be met before triggering

the output. A Requirement Routine consists of ABAP/4 code. If the routine's return code is successful, the

output occurs.

o We use scheme RMBEV1, which represents a purchasing agreement.



� Fine-Tuned Control of Output Types (OMQO). Defines which output type to use in different situations within a given scheme. For example, we can define a different Output Type for an added document than

we do for a changed document.

o We associate our Output Type VNEU to new contracts.

� Assignment of Scheme to Application (OMQT). Assigns a scheme to an application. o We assign the scheme RMBEV1 to application EV (Purchase Outline Agreement).

� Condition Records (MN07). Define the conditions that must be true to produce the output specified by the previous configurations.

o We defined our Access Sequence to use the Document Type Condition Table, so we will define

output for a quantity contract, which is document type MK.

� ALE Distribution Model (BD64). Defines the message flow between logical systems. o We will model the flow from our Sales system to our Warehouse system.

� Partner Profiles (WE20). Defines the message type, IDoc type, port, and other options for the IDoc distribution.

o We will generate the partner profile from the distribution model.



• Additional ALE Configuration for Message Control

There is some additional ALE configuration to enable the Output Proposal from the document to trigger an ALE

message.

We need to link the output determination message type to the ALE message type in the partner profile of the system.

Using transaction WE20, select your ALE message, and click on Message Control. Enter the message control output

type that will trigger your message and the outbound process code. You need two entries here for each output type:

one for creates to the transaction document and one for changes.



• Viewing Proposed Output

Most application programs allow you to determine what output was proposed for any document. You can see which

output types were proposed and the receiving party, if by EDI.

The status will have one of these values:

� YELLOW To be processed

� GREEN Successfully processed

� RED Incorrectly processed

To view how an output was proposed, use menu path Goto --> Determin analysis. When the status is RED, select

the line with a single click and use menu path Goto --> Processing log to see a description of the error.

You can drill down into these screens to see more details of each step.



• Re-Proposing Output from NAST

When the system determines output for an application document, it writes a record to the NAST table. This NAST

record can have one of three status values.

� 0 = awaiting output

� 1 = output successfully processed

� 2 = an error occurred during output processing

Once a NAST record has a successful status (1), and the ALE layer has sent the IDoc successfully, you cannot resend

the IDoc. If you need to resend the IDoc, you must go back to the application document and repeat the output. The

menu path varies, by program, but is usually something like Goto # Messages.

Re-proposing the application document will rerun the output programs and create a new IDoc. The new IDoc will

contain any changes in the application document made since the first IDoc was created.



• Batch Processing

• Reasons

We can configure most of the IDoc processing, both inbound and outbound, to happen immediately or in batch.

There are several reasons why the batch mode is generally preferable:

� Time Constraints. Sometimes the processing of a set of IDocs must happen within a specific window of

time. For example, purchase orders can be created and modified on the system over the course of the day and only sent out once a night. Until the time the Order IDoc is created, users can make changes to the

order. Once the IDoc is created, all subsequent changes will result in the creation of change orders.

� Transaction Sequence. A group of transactions may need to be sent out together. For example, if a billing program creates multiple invoices for the same customer, the customer may expect that all invoices

generated that day be sent in a single EDI interchange.

� Scheduling Dependencies. The processing of some IDocs may depend on the successful processing of a preceding batch job, or a later job may depend on the successful completion of IDoc processing. Either

case requires that the processing of all IDocs as a step in a batch process that can either trigger or be

triggered by another step.

� Transaction Volume/Load Balancing. Some SAP processes (e.g. post goods issue, delivery due list), as well as certain external systems (e.g. EDI, warehouse management systems) can create a high volume of

transactions in a short period of time. They can overwhelm the processing capabilities of the receiving

system if the interface is set up to process everything immediately.



• Batch Processing Programs

SAP supplies some ABAP programs to allow for batch processing of IDocs:

� RBDMIDOC -- Creates Master data IDocs from change pointers. You must specify a message type for which to create IDocs.

� RSNAST00 -- Reads records from the NAST table, creates IDocs, and submits the IDocs to the ALE layer for distribution. Create a variant with the following fields filled:

o Output application

o Output type

o Transmission medium

o Editing an outbound document that has been saved and posted is possible only until RSNAST00 creates the IDoc. After that, any changes to the document will trigger a separate IDoc.

� RSEOUT00 -- Sends IDocs stored in the database with partner profile entries indication Collect IDocs. •The

Output mode field of this program allows you to specify when the EDI translator (or subsystem) will run. Generally, you should use mode 3, which triggers the subsystem only once for each batch of IDocs.

� RBDAPP01 -- Processes inbound IDocs stored in the database with partner profile entries indication

Background processing.

� RSEINB00 -- Reads inbound IDocs from a disk file, whose name you specify and submits them for

processing.



• Distributing Control and Customizing Data

We can control the distribution of control or customizing data with ALE. In fact, certain customizing data must

remain consistent across all of the systems for ALE to function properly.

The Distribution Model defines the distribution of changes to customizing data, but we use CTS (Correction and

Transport System) to actually distribute the control data to the other systems.

• How to Distribute Control Data

There are two methods for configuring control data distribution:

� Using the CONDAT message type in a distribution model. This is the only method available in releases earlier than 4.6B.

� Creating a Customizing Data Distribution Group. This method replaces the old CONDAT method in release 4.6B, although the CONDAT method is still available. You cannot use both at the same time.

Since Control Data Distribution control with ALE is rarely used, we will not discuss it further. Consult online help if

you need more information.

• Exercise: Master Data Fetch

In this exercise, you will configure a master data fetch between two SAP systems using

ALE. You will distribute a customer record from one system to another.



1. On your Warehouse system, configure an RFC Destination pointing to your Sales

system.

2. Maintain your distribution model (on the Sales system). Configure a message type

DEBMAS from Sales to Warehouse, and a message type DEBFET from Warehouse to

Sales.

3. Distribute the model to Warehouse

4. Generate your model on both systems.

5. Create a customer (transaction V-09) on the Sales system.

6. From the Warehouse system, execute transaction BD13 to fetch your customer.

7. Look at the IDocs sent on both systems and check for successful processing.

8. Run transaction XD03 to see if your customer was created on your Warehouse system.

• Exercise: Configuring a Transactional Data Scenario

In this exercise, you will configure the distributed contracts transactional data scenario

described in the Overview chapter.

A. ALE Configuration

1. Add the following message flows to your distribution model:

a. BLAORD from Sales to Warehouse



b. BLAREL from Warehouse to Sales

2. If you didn’t configure vendor or material distribution in previous exercises, add

these as well:

a. CREMAS from Sales to Warehouse

b. MATMAS from Sales to Warehouse

3. Distribute your model and generate it on both systems. If you encounter errors, fix

them before proceeding!



B. Configure Message Control

Note: In this section, you will be looking at existing configuration, since this scenario

comes preconfigured with the R/3 system.

1. Go to the IMG. Transaction SPRO, then click on SAP Reference IMG.

2. Follow the menu path Materials Management # Purchasing # Messages # Output

Control.

Note: Normally, we would configure Message Control from the bottom of the hierarchy to

the top. However, since most of the configuration comes with the installed system, it will

be easier to understand from top to bottom.

3. Execute Partner Roles per Message Type for Outline Agreements.

a. Check that there is an entry for Distributed Contracts (output VNEU) for

ALE Distribution (medium A).

4. Execute Message Determination Schema for Outline Agreements, then select

Maintain Message Determination Schema: Outline Agreement.

a. What procedure (or schema) are we using for this scenario?

b. Select the procedure and double click on Control data. Check that the

output type VNEU is entered, and that the Manual only checkbox is turned

OFF.

5. Execute Message Types for Outline Agreements, then select Maintain Message

Types.

a. Double click on VNEU. Note the following entries:

i. The Access Sequence (list of Condition Table fields) is

DocType/PurchOrg/Vendor. These are the fields we can use as

keys in a condition table.

ii. The default medium (on the Default values tab) is ALE.

iii. Double click on Processing routines. This lists the ABAP program

that will actually produce the output. In this case, it is the FORM

routine called ALE_OUTPUT_BLANK_ORD in the program

RM06EALE.

b. Back out to the selection box, and then select Fine-Tuned Control. This lets

us select different output for different situations (for example, a new vs. a

changed document).

6. Execute Access Sequences for Outline Agreements.

a. What condition tables are available? (To find out, select the access

sequence and double click on Accesses.)

b. Which condition table would be most appropriate for our scenario?

c. What database field(s) does this condition table use?



C. Create Condition Records

On your Sales system, configure the output of quantity contract information:

1. From the main SAP menu (not the IMG), follow the menu path Logistics #

Materials Management # Purchasing # Master Data # Messages # Outline

Agreement # Create. Or you can use transaction MN07.

a. Enter the output type we are using (VNEU) and click on Key combination.

This selects the condition table we will use. Select the Document Type

condition table.

b. Create a record as follows:

i. Document type: MK (Quantity contract)

ii. Medium: A (ALE distribution)

iii. Timing 4 (Send immediately)

Leave the other fields blank.

On your Warehouse system, configure the output of purchase order (release) information:

2. From the main SAP menu (not the IMG), follow the menu path Logistics #

Materials Management # Purchasing # Master Data # Messages # Purchase

Order # Create. Or you can use transaction MN04.

a. The output type in this case is NEU, since we are creating a purchase order.

b. Select the Document Type condition table.

c. Create a record as follows:

i. Document type: MK (Quantity contract)

ii. Partner Function: VD (Vendor)

iii. Medium: A (ALE distribution)

iv. Timing 4 (Send immediately)

Leave the other fields blank.



D. Create Master Data

1. Create a vendor, using the guidelines distributed in class.

2. Create a material, using the guidelines distributed in class, with the following

additions:

a. Select the Basic Data and Accounting 1 views.

b. Set the Valuation class to 7920, the Price control to S, and put in a price in

Standard price.

3. Use BD14 to send the vendor to the warehouse system.

4. Use BD10 to send the material to the warehouse system.

E. Create a new Distributed Contract.

1. On your Sales system, execute transaction ME31K, or menu path Logistics #

Materials Management # Purchasing # Outline Agreement # Contract # Create

2. Enter data:

a. Vendor The vendor you create above

b. Agreement Type MK (Quantity contract)

c. Purchasing group 001

3. Enter, then add a line item for your material:

a. Material The material you created above

b. Targ. qty. The total contract quantity

c. Net price The price per unit

d. Matl group 01

4. Follow menu path Header # Messages to see if ALE output was created. If not,

troubleshoot and fix.

5. Save the contract. Make a note of the contract number.

6. Run WE05 on both systems. Is there a BLAORD IDoc sent? Did it post successfully

on your warehouse system? If not, fix any errors and repost using BD87.



F. Create a Purchase Order against the Contract.

1. On your Warehouse system, execute transaction ME21.

2. Click on the Ref. to contract button and enter your contract number.

3. In the line item for the material, fill in the quantity for this order and the plant

(0001), and click on Adopt + details,

4. Enter the order price and save.

5. Run WE05. Is there a BLAREL IDoc sent? Did it post successfully on your sales

system? If not, fix errors and repost using BD87.

7. On your sales system, execute transaction ME33K, or menu path Logistics #

Materials Management # Purchasing # Outline Agreement # Contract # Display.

8. Select your agreement, then select the material line item and click on Release

documentation. You should see the purchase order information, and quantity

release statistics.



11 Chapter 1 – ALE Monitoring

SAP provides a set of tools for monitoring the ALE installation, both of the IDoc

communications between the systems and the ALE configuration itself.

11.1.1 Consistency Check of the Distribution Model

Transaction: BDM5

This transaction performs a technical consistency check of the distribution model:

� Do the logical systems referenced exist?

� Are the partner profiles and ports correct?

� Are the filtering and conversion rules OK?

� Is the inbound processing properly configured?

The program checks the configuration in both the sending and receiving systems,

connecting to the other systems via RFC. Results are colour-coded.

11.1.2 Consistency Check for Application Number Ranges

Transaction: BD70

This consistency checks displays the number ranges in the distributed systems. When

selecting this check, you specify the number range object (i.e., AUFTRAG) and the

distributed system(s) for which the ranges are to be displayed. You use this information to

verify that the number ranges on the distributed system are consistent with the

distribution scenarios.

11.1.3 IDoc Lists

All IDocs, ALE and EDI, contain status records. Using transaction WE05, you can look at

any IDoc on the system, to see the current status of an IDoc, as well as the status history.

Remember that each step in the processing of an IDoc produces a status record.

We covered this function in detail in the IDoc intro chapter.

11.1.4 Mass IDoc Processing

Transaction: BD87

Menu Path: Tools I ALE I ALE Administration I Monitoring I Status Monitor for ALE

Messages

This transaction allows the manual processing of IDocs. It has a selection screen to select

IDocs to process, and then displays all of the IDocs selected sorted by their status codes.



You can then select which specific IDocs to process. Here are some situations in which this

program is useful:

� ALE configuration error -- Retry sending IDocs after fixing the problem that caused

the error.

� Ignoring the IDoc syntax check – Send IDocs that were not sent because of syntax

errors

� Dispatch -- Send any IDocs that are held because Collect IDocs is set in the

partner profiles.

� Posting -- Process any IDocs that were held because Background processing is set

in the partner profile.

� Resubmit an edited IDoc – Send or post IDocs you have edited manually.

� Try posting again -- Attempt to repost IDocs that encountered a logical error in the

posting transaction.

11.1.5 Check IDoc Dispatch

Transaction: BD75

Menu Path: Tools I ALE I ALE Administration I Services I Communication I

Transactional RFC I Convert IDoc status

Program: RBDMOIND

The program RBDMOIND checks to see if specified IDocs have actually been sent to the

receiving systems, that is, that the tRFC call was successful. If so, it changes the IDocs’

status from 03 (Data passed to port OK) to 12 (Dispatch OK).

The report only checks IDocs with a status of 03.

You can specify an IDoc creation start date and the number of IDocs to check before

committing the new status records to the database.

The serialization functions discussed in the ALE Processing Features chapter use this

program to be sure that serialized IDocs were successfully sent.

Note that this program does not check for successful processing of the IDocs on the

receiving system, only for the successful transfer.

11.1.6 tRFC Monitoring

Transaction: SM58

Menu Path: Tools I Administration I Monitor I Transactional RFC

This transaction checks the status of all transactional RFC calls according to selection

criteria. You can use it to check for failed tRFC calls.

Using the menu path Edit # Execute LUW or Edit # Execute LUWs you can retry any failed

calls.

11.1.7 Status Record Import

An external system that receives IDocs from an R/3 system can send status records for

the IDocs back to the R/3 system. This allows the tracking of the IDocs’ status from SAP.

The external system sends the status records by calling the RFC function module

EDI_STATUS_INCOMING. EDI_STATUS_INCOMING takes two parameters:

� The pathname of a file (on the application server) containing IDoc status records

� A file port pointing to a file containing IDoc status records. The specified port must

be valid, but the function doesn’t use it if you provide a pathname.

EDI_STATUS_INCOMING reads the inbound status records from the file and appends them

to the corresponding outbound IDocs. This is the single case where an outbound IDoc may

have status records with inbound status codes.



11.1.8 The IDoc Test Tool

Transaction: WE19

Menu Path: Tools I Business Communication I IDoc Basis I Test I Test Tool

The IDoc Test Tool is a very powerful tool for ALE testing and development, particularly

when developing inbound posting programs. Common uses of the test tool include:

� Taking a copy of a current IDoc, and modifying the data before attempting to post

it.

� Creating an IDoc from scratch to see what data is required in a particular posting

routine/transaction.

� Posting an IDoc in foreground (running the call transaction online) to investigate

why an IDoc is failing.

� Debugging posting routines.

The Test Tool allows us to create an IDoc manually, and then submit it for outbound or

inbound processing. We can create an IDoc in several ways:

� By copying an existing IDoc already on the system.

� Using an existing IDoc type or message type

� Using a template from a file

� With no starting point at all.

We can change any of the segments (including the control segment) or add or delete

segments, as we need. After creating a test IDoc, we can then submit it for processing in

several ways:

� Standard outbound processing using normal ALE configuration

� Standard inbound processing using normal ALE configuration

� Inbound processing using a specified function module

When using the IDoc test tool, always completely exit a posting transaction before creating

a new IDoc. This is because certain internal tables in the transaction are not cleared and

will lead to strange and misleading results when testing your processing.

11.1.9 The Turnaround Testing Tool

Transaction: WE19

Menu Path: Tools I Business Communication I IDoc Basis I Test I Test Tool

The turnaround testing tool takes an outbound IDoc in a disk file and converts it to an

inbound IDoc by changing the control record.



You can specify the following parameters:

� Input and output files

� Sender and receiver logical systems and ports

� Message type

� Target client

After doing the conversion, the program will submit the IDoc for inbound processing.

11.1.10 ALE Audit

You can configure the receiving system to generate ALE Audit messages for all incoming

ALE IDocs for certain message types, and to send these messages to the sending system,

where the ALE Audit toolset can use them to maintain a complete audit trail.

To enable ALE Audit:

� Set up the ALEAUD message type in the Customer Distribution Model and Partner

Profiles.

� Define a filter object in the distribution model to specify the message type that you

want to audit.

The data contained within the ALEAUD messages provides detailed status information on

the IDocs in the receiving system, as well as the links between the IDocs and the resulting

SAP application objects on the receiving system.

11.1.10.1 Program RBDSTATE

Transaction: BDM8

Menu Path: Tools I ALE I ALE Administration I Monitoring I ALE Audit I Send audit

confirmations

Program: RBDSTATE

Use the program RBDSTATE on the receiving system to send the audit messages to the

sending system, using ALE (I.e. asynchronously). You typically run this program as a

scheduled batch job. The parameters of RBDSTATE are:

� The sending system (of the original IDoc)

� The message type

� The date range the IDoc’s status was changed. Any IDoc having a status record in

this date range will be confirmed.

The audit messages contain:

� The current status of the inbound IDoc



� The id of the resulting SAP application object (if the IDoc was

successfully posted)

The system will confirm up to 500 IDocs in one ALEAUD message. If

there are more than 500 IDocs to be audited, then it will create multiple

audit IDocs.

NOTE: The RBDSTATE program looks at IDoc status records to determine which IDocs to

audit. If any status record was added to an IDoc during the specified date range, the

program will audit the IDoc.

11.1.10.2 Program RBDAUD01

Transaction: BDM7

Menu Path: Tools I ALE I ALE Administration I Monitoring I ALE Audit I Evaluate

audit statistics

Program: RBDAUD01

Use the program RBDAUD01 on the sending system to look at the ALE Audit IDoc statistics.

� “IDocs total” is the total number of IDocs audited

� “Queue Outbound” is the number of IDocs that have not yet been sent to the other

system

� “Queue Inbound” is the number of IDocs that are still being processed by the

receiving system



ALE Audit records may be selected by message type, date range, etc. You can drill down

into the report to see information on daily statistics, detailed information on IDocs, and

cross-system links for successfully processed IDocs:

11.1.10.3 Audit IDoc Structure

These are the segments in an ALEAUD01 IDoc, with the fields they contain:

� Segment E1ADHDR

o Message type

� Segment E1STATE

o Sender’s IDoc number

o Current status

o Message fields

� Segment E1PRTOB

o Receiver’s IDoc number

o Application object information

11.1.11 Batch Processing Programs

SAP supplies some ABAP programs to allow for batch monitoring of the ALE system:

� RBDCONCH -- Runs consistency checks for any message types or receiving

systems. You can specify which consistency checks to run. If the program finds

any errors, it creates a notification with Workflow.

� RBDMANIN -- Attempts to reprocess any IDocs with a specified error status code.

This is useful if IDoc processing fails because of record locking issues. No changes

are necessary; trying to post the IDocs again will usually work. This program can



automate this process. You can specify IDoc creation dates, sending systems,

message types, and status codes to selectively reprocess IDocs.

� RSEIDOCM -- Counts the number of IDocs on the system that have a specified

status code. If this number exceeds a specified maximum, the program generates

a Workflow notification. You would generally use this with error status codes to

detect a failure in the IDoc processing flow. If a piece of the ALE system is not

working correctly, IDocs with error status will build up in the system. This program

provides a way of detecting this condition.

� RBDMOIND -- Checks the tRFC dispatch for all IDocs with status 03 (Data passed

to port OK). The program checks the successful sending of these IDocs with the

receiving system and writes a status record of 12 (Dispatch OK) to all IDocs

successfully transferred.

� RBDSTATE -- Creates ALE Audit messages for the specified sending systems and

message types. See the discussion of ALE Audit for details.

11.2 Exercise: ALE Monitoring

In this exercise, you will explore some of the ALE Monitoring tools.

1. Run BDM5 (on your Sales system) to check the consistency of your distribution model.

a. Double click on the name of your Warehouse system to run the check.

b. After the check runs, all fields should be white (Check OK). If not, try to fix

the problem.

2. If you had any error IDocs in previous exercises, try to resend or repost them with

BD87.

a. NOTE: Specify your partner system on the BD87 selection screen to avoid

reprocessing other students’ IDocs!

3. Run BD75 (on your Sales system) to check the IDoc dispatch.

a. Select today’s date and execute.

b. Using WE05, verify that all successful outbound IDocs now have a status of

12 (Dispatch OK).

NOTE: Sending and receiving systems are not part of the BD75 selection screen.

This means that if someone else runs the program, it will check the dispatch of all

IDocs, including yours.

11.3 Exercise: Using the IDoc Test Tool

In this exercise, you will use the IDoc Test Tool to:

� create and submit an outbound material IDoc

� create and submit an inbound Purchasing Order Release IDoc

� create and process an inbound IDoc from an outbound IDoc

A. Outbound Testing

1. On your Sales system, execute the test tool (WE19).

2. Select Existing IDoc, then use the search help to locate one of your outbound

MATMAS IDocs from previous exercises. (You may find it easier to locate this IDoc

using WE05.)

3. Click on Create.

4. Delete all segments (if any) other than the required E1MARAM and E1MAKTM

segments. (Select a segment, then click Delete.)

5. Add a new text segment. Select the E1MAKTM segment and click Copy, then Insert.

Change the language keys (e.g. “D” and “DE”) and the description. Or you can use the

Create button to create a new E1MAKTM segment.

6. Click on Standard Outbound Processing to send the test IDoc.

7. Go to your Warehouse system and see if the IDoc was received and processed

successfully.



B. Inbound Testing

1. On your Sales system, execute the test tool (WE19).

2. Select Existing IDoc, then use the search help to locate your inbound BLAREL IDoc

from the Distributed Contracts exercise. (You may find it easier to locate this IDoc

using WE05.)

3. Click on Create.

4. Double click on the E1RDOCU segment. Change the Purchasing doc. field to a new

number and, if you wish, change the quantity and value fields.

5. Click on Standard inbound. The popup window should have a green light and a

message “Partner profile found”. If not, fix your inbound configuration and try again.

6. Click the green arrow to start processing.

7. Display your contract (ME33K). Is the new information reflected in the item release

statistics?

C. The Turnaround Testing Tool

In this exercise, you will read an inbound IDoc from the disk file you created in the

Communication Parameters exercise.

1. Execute the turnaround testing tool, transaction WE12. Set the following

parameters and execute:

i. Source: the file you created earlier (“/tmp/<username>”)

ii. Target: the output file. Use “/tmp/<username>.in”

iii. Sender Partner Number: your Sales Logical system

iv. Sender Partner Type: LS

v. Sender Port: SAPAL2

vi. Message Type: MATMAS

vii. Recipient Partner Number: your Warehouse Logical system

viii. Recipient Partner Type: LS

ix. Direction: 2 (inbound)

x. Client: your warehouse system client number

xi. Recipient Port SAPAL2

2. Run WE05 and see if your IDoc is there. It should have a status of 64 (Ready

to be transferred to application).

3. Use BD87 to submit the IDoc for processing.

NOTE: These activities are for testing only. You should never do this on a production

system!

11.4 Exercise: ALE Audit

In this exercise, you will configure ALE Audit between two SAP systems. You will distribute

a vendor record from one system to another, and acknowledge its receipt with ALE Audit.



1. Maintain your distribution model (on your Sales system). Configure a message type

CREMAS from Sales to Warehouse.

2. Configure a message type ALEAUD from Warehouse to Sales. Add a filter for logical

message type, value CREMAS, to this message.

3. Distribute the model to Warehouse

4. Generate your model on both systems.

5. Create a vendor (transaction MK01) on the Sales system.

6. Using BD14, send your vendor to your Warehouse system.



7. Run transaction MK03 to check that your vendor was created on your Warehouse

system.

8. On the Warehouse system, run transaction BDM8 to create an audit IDoc. Confirm to

your Sales system, message type CREMAS, and today's date.

9. Look at the IDocs sent on both systems and check for successful processing. You

should see a CREMAS IDoc and an ALEAUD IDoc on each system, with successful

status codes.

10. On your Sales system, run transaction BDM7 to look at the ALE Audit statistics.



12 Chapter 2 – Error Handling

12.1.1 What is Workflow?

SAP Business Workflow (which we will refer to as Workflow from now on) is SAP's tool that

manages business processes by sending email action items to specific people in an

organization. It comes delivered with the standard R/3 system.

Workflow uses the standard SAPOffice email programs to deliver a required work item to

the person or persons responsible for completing the work item. By using the email

interface, the users do not have to "look for" the work items; instead, they simply appear

in the user's inbox.

The routing of work items is completely configurable, and very flexible. For example, the

system can handle situations where an employee is on vacation or out sick and needs to

assign another person in the organization to handle her assigned tasks.

Modeling business processes with Workflow can be very complex, requiring much planning

and configuration. However, using Workflow for ALE error handling is comparatively simple,

and does not require a full Workflow implementation. Therefore, it is an excellent tool for

handling ALE errors.

12.1.1.1 Business Objects

A business object is a formal description of a piece of data on the system. Examples of

business objects include customers, materials, sales orders, and G/L accounts. A business

object includes all of the data passed in a single ALE IDoc and predefined methods, which

are ways of manipulating and accessing that data. It is similar to a class instantiation as

defined by C++ and other object-oriented programming languages.

12.1.1.2 Tasks

A task is a procedure that accomplishes an action in the system by executing a method of

a business object. SAP predefines a large number of tasks, including many that allow the

processing of various errors in IDoc handling. Users handle the errors by executing these

tasks, which appear as work items in their inboxes.

12.1.1.3 Organizational Plan

An organizational plan in SAP describes the organizational structure of a company. The

functions to create and maintain organizational plans are part of the Personnel Planning



and Development (PD) part of the SAP HR module, but we do not need to implement HR to

use them in Workflow.

Any organizational plan consists of five kinds of classifications:

� Organizational units. Each organizational unit represents a recognizable group in

the organization. This may be a department, a team, a building, etc.

Organizational units are hierarchical; that is, they can contain other organizational

units as subordinates. For example, a department may be made up of multiple

teams, or a company unit may have multiple departments.

o Generally, one organizational unit forms the “root” of the hierarchy and

contains all other organizational units as subordinates.

� Positions. A position represents a slot in an organizational unit filled by a single

person, or shared among two or more people. Two examples are “H/R Manager”

and “A/P Clerk”.

� Jobs. A job is a more general description of a position. A single job can describe

multiple positions across multiple organizational units. There is, therefore, a one-

to-many relationship between jobs and positions.

� Users. A user is an SAP logon user ID. It thus represents a single person.

� Persons. A person is a specific employee created in the HR module. In order for a

person to be usable in a Workflow scenario, we must assign the person to a user,

since only a user has access to the SAP mail system. This is configured as part of

the HR implementation.

We can assign a user or a person to any position. This is a many-to-many relationship,

since a user or person can hold more than one position, and we can fill a position with

more than one person.

12.1.1.4 Agents

An agent is simply a person who executes a Workflow work item.

We can assign a task to any of the five organizational objects (organizational unit, position,

job, user, or person). All users and persons that belong to the specified organizational

object then become possible agents of the task.

When an IDoc error occurs, the Workflow system turns the corresponding task into a work

item and sends it to the inbox of all possible agents defined for the task. These agents are

then known as selected agents. When one of these people executes the work item, that

person is then the actual agent for the work item, and the work item disappears from the

inbox of all other selected agents.

12.1.1.5 The Business Workplace

Transaction: SBWP

Menu Path: Office I Workplace

The business workplace is the SAP transaction that a user uses to view all received

work items. It is part of the SAPoffice email system. From the workplace a user can

directly execute work items, view attachments, and send email to other users. The

business workplace also has the capability of sending a work item to an alternate user if

the primary user is not available (because of vacation, sickness, etc.).

This is the initial screen of the business workplace, with the Inbox section expanded:



This example shows two work items waiting in the inbox.

Expanding the Workflow section brings up a list of the work items in the inbox:

To execute a work item double-click on the line of the desired work item. For IDoc errors,

this will bring up the IDoc error-processing screen:



From here, you have several options:

� Process will submit the IDoc for reprocessing

� Delete flag will mark the IDoc for deletion

� IDoc display lets you look at (and change) the data in the IDoc with the same

interface used in WE02 and WE05.

Once you successfully process the IDoc, or mark it for deletion, the work item will

disappear from your inbox.

12.1.2 Workflow Configuration

We need to make some basic configurations in order for the Workflow system to work

properly. These configurations are not related to the ALE system. The R/3 system can

perform most of these steps automatically.

12.1.2.1 Configuration Consistency Check

Transaction: SWU3

Men Path: SALE I Error Handling I Basic Workflow Settings

Workflow comes with a configuration consistency check to make sure that all of the

required steps are complete.

This consistency check uses a color-symbol key to show which configuration items are

complete. For ALE use, all of the items under Workflow runtime system should have a

green check.[3] In addition, if you are using Workflow for custom IDoc error handling, the

items under Workflow development environment should have a green check.

[3]

Note: Some releases of R/3 are reported to have a bug in this transaction that results in a green check

not being displayed for a configuration item even when the configuration was completed. This will not

prevent successful use of the Workflow system.



12.1.2.2 Automatic Customizing

The Automatic Customizing push-button attempts to make the Workflow configurations

automatically. It will update the icons next to each item based on the results. If the

Automatic Customizing fails to give a green check, you must perform the failed

customizing steps manually.

12.1.2.3 Testing the RFC Destination

The Automatic Customizing will set up the Workflow RFC destination, but will not test it.

You can test it manually with the Test RFC destination pushbutton. This check ensures that

the RFC destination is correct and that the Workflow user can log on to the system

properly. If this check fails, it generally means that the WF-BATCH user is not properly

configured, or the login information does not match the corresponding information in the

RFC destination.

12.1.3 Building an Organizational Plan

When you set up IDoc error handling with Workflow, you can assign a person, an SAP user,

a position, a job, or an organizational unit as a possible agent. While assigning an SAP

user is the easiest way, it is not the best, because you will not have the flexibility to make

changes to several error configurations at once.

For example, if the user designated as the Receiver of Notifications (defined later) in 500

partner profile entries leaves the company, someone must manually change all 500 of his

entries. It is better to create a position for these entries, so that if the person in the

position changes, you only need to make the change in one place.

The organization management capabilities are far too complex to discuss here. We will

show how to construct a simple organizational plan suitable for use in IDoc error handling.

Transaction: PPOCW

Men Path: ToolsI Business Workflow I Development I Definition tools I Organizational

Management I Organizational plan I Create

To build an organizational plan follow these steps:

1. Run the Organizational Plan transaction.

2. Enter a period of validity. Use 12/31/9999 to prevent expiration of the plan.

3. In the Basic Data tab, enter a name and a description.

4. You can now build your organizational hierarchy.

• The Goto button changes the screen view, letting you see only

organizational units, staff assignments, tasks, etc.



• The Create button lets you create new organizational objects. Select an

object, click the Create button, and the new object will be a child of the

selected object.

• To include an existing object, find it in the search window on the left, then

drag-and-drop onto the new structure.

5. Repeat this process until your plan is complete.

6. To assign a person to a position, find the person’s user ID in the search

window, then drag-and-drop the username onto the position. You can also

assign more than one person to any position by setting the Staffing percentage

of each.

7. You can also assign a Job to any position using the Job field.

Caution: In release 4.6D, the drag-and-drop interface is buggy. You may need to collapse

and reopen the display to get the destinations right.

When you set the possible agents for any IDoc error-handling task, you can use any of the

objects you have created:

� User. The work item will go to the specified SAP user. As explained above, this is

rarely a good idea.

� Position. The work item will go the holder or holders of that position.

� Job. The work item will go to all holders of all positions described by the specified

job.

� Organizational Unit. The work item will go to all members of the specified

organizational unit.

12.1.4 ALE Configuration

This section describes the configuration specific to ALE processing.

There are five places in the message transmission process where something can go wrong

in the transmission of a message with ALE:

1. Reading the outbound partner profile.



2. Sending the IDoc to the receiving system.

3. Reading the inbound partner profile. This may be a configuration problem or an

invalid received IDoc (syntax error or invalid control information)

4. Calling the application function.

5. Posting the record to the receiving database. This is generally a logical error,

involving a problem with configuration or with a process problem (such as a

customer on credit hold).

The first four possible errors are technical errors, involving the distribution of the IDoc

without regard to its business contents. An error in posting the IDoc is a logical or

functional error, involving a problem with the contents of the IDoc itself, rather than its

transfer. We will normally send technical and functional error notifications to different

people in an organization.

We can configure Workflow error handling in each of these five error situations. This table

lists the areas of Workflow configuration for each possible error situation:

Error situation Workflow configuration needed to handle the error

Reading the outbound

partner profile

Maintain the IDoc Administrator on the sending system

Sending the IDoc to

the receiving system

Define a Receiver of Notifications in the outbound

partner profile

Reading the inbound

partner profile

Maintain the IDoc Administrator on the receiving

system

Calling the application

function

Define a Receiver of Notifications in the inbound partner

profile

Posting the document

to the database

Configure processing of the corresponding Workflow

task

In each case, we can define one or more possible agents to execute the corresponding

error-handling task. We can use any of the organizational objects to do this. That is, we

can assign all of the members of an organizational unit, a position, or a job to the task, or

we can assign a single user or person.

The next sections describe these configurations in detail.

12.1.4.1 IDoc Administrator

Transaction: OYEA

Men Path: SALE I Error Handling I IDoc Administration

The IDoc administrator, called the EDI Administrator in earlier versions, is the agent

responsible for handling IDoc errors when no partner profile is available. We can set a

single organizational unit, position, job, user, or person as the IDoc administrator. On the

outbound system, this error generally indicates a misconfigured system, where a required

partner profile is missing. On the inbound system, this error probably indicates that the

system received an unexpected message type, or a message from an unknown partner.

The administrator will typically fix the configuration error, and then submit the IDoc for

reprocessing.



The following table describes each of the error-related fields on this screen:

Field Description

Recipient type The type of organizational object used to identify

the possible agents. This can be an

organizational unit, a job, a position, a person, or

a user.

Identification The organizational object (job, position, etc.)

whose members we want to notify of an error.

Max number of syntax errors The maximum number of IDoc syntax error

status records to write to the IDoc.

Suppress warnings for status

processing

If we select this checkbox, the system will not

trigger error handling for errors involving the

IDoc’s status records.

Note: You must maintain the IDoc administrator on each system involved in IDoc transfer.

You cannot use CTS to transport the settings.

12.1.4.2 Receiver of Notifications

A Receiver of Notifications is responsible for handling errors in using a partner profile. In

this case, the partner profile exists, and the system can read it properly, but there is a

problem in sending the IDoc (outbound) or passing it to the application (inbound).

There are four places to define a receiver of notifications:

� The partner profile overview screen

� Individual partner profile entries for Message Control

� Individual partner profile entries for Outbound Parameters

� Individual partner profile entries for Inbound Parameters

If an appropriate partner profile exists for the message, but it does not have an entry for

the message type in question, then the system will notify the receiver of notifications listed

on the overview screen. If the individual message type entry does exist, then the system

will notify the receiver of notifications configured for that message type.

To designate a receiver of notifications, use the partner profile maintenance transaction

WE20, on the Post processing: permitted agent tab.

The following table describes each of the error-related fields on this screen:



Field Description

Typ The type of organizational object used to identify

the possible agents. This can be an organizational

unit, a job, a position, a person, or a user.

Lang. The language to use for the message sent to the

receiver.

ID The organizational object (job, position, etc.)

whose members we want to notify of an error.

The screens for the individual message types (Message Control and In/Outbound

Parameters) have the same fields.

12.1.5 Application Processing Errors

An error in processing an inbound IDoc results in the creation of a work item. The task

used will generally be a foreground input method of a particular IDoc object. That is, each

IDoc type defined on the system has a corresponding IDoc business object. There are

methods defined for these objects to handle inbound processing of the corresponding

IDocs.

Here is an example, using Material Master records:

This is an SAP-supplied Workflow task, called “MATMAS input error”. It uses the business

object IDOCMATMAS and its method INPUTFOREGROUND.

To configure the error processing for this error, we must activate the event linkage for the

triggering event and designate the possible agents for the Workflow task. The possible

agents can be organizational units, positions, jobs, users, or persons.



12.1.5.1 Locating the Error Handling Task

Transaction: PFTC_DIS

Menu Path: Tools I Business Workflow I Development I Definition Tools I Tasks/Task

Groups I Change

First, you must locate the SAP-supplied task for handling errors in the IDoc type in which

you are interested.

1. Execute transaction PFTC_DIS.

2. Enter “Standard Task” under Task type. This indicates a standard single-step task (as

opposed to a multi-step workflow).

3. Put the cursor in the Task field and use the drop-down (or press F4) to activate the

search. Type the first few letters of the name of the task and press Enter. Most task

names begin with the message type they handle. For example, the material master

task is "MATMAS input error".

4. Alternatively, you can click on Structure search to bring up the Application Hierarchy.

Find the desired task in the hierarchy. Application error handling tasks are generally in

the corresponding hierarchy section, while ALE-specific tasks (e.g. Fetch messages)

are in the ALE section. For example, you will find the MATMAS error-handling task

under Logistics – General # Logistics Basic Data # Material Master # Standard task #

MATMAS input error. Double click on the task you want to copy it to the task

maintenance screen.

5. Click on Display to see the task.



12.1.5.2 Activating the Event Linkage

To activate the event linkage click on Triggering events, then click on the activation button

to the left of the event. This button will be green if the event is active, gray if not.

12.1.5.3 Assigning the Possible Agents

1. To assign possible agents, follow menu path Additional data # Agent assignment #

Maintain.

2. If the words “General task” appear next to the task name, turn off the general task

attribute. To do this, click on Attributes, change the properties to General forwarding

not allowed, and save. (General forwarding allowed will also work, but will allow a

selected agent to forward the work item to a user not designated as an agent for the

task.) This activates the distribution of the work item according to the possible agents

you specify.

3. To assign possible agents to the task, put the cursor on the task name and click on

Create (the left-most icon). Select an organizational object, such as a position, job,

etc., and specify the specific object to use.

4. Repeat to assign additional possible agents to the task. When done, the screen should

look like this:

That’s it! Inbound processing errors should now trigger the Workflow task.



13 Chapter 3 – Using ALE for Interfaces

13.1.1 Basic Idea

ALE can interface SAP with non-SAP systems. The basic idea is to use the SAP delivered

ALE functionality and to make use of the ALE infrastructure.

Here is an example: SAP supports a distribution scenario that allows the distribution of

material master data between SAP systems. If you want to implement an interface

between SAP and legacy for material master, you could use the existing ALE functionality

to extract the material master data based on changes made by the user, put the data into

an IDoc, and dispatch the IDoc to the target legacy system. From the sending system’s

(SAP) perspective, it doesn’t matter if the partner system is another SAP system or not.

Ideally, this interface wouldn’t require any coding on the SAP side. The ALE infrastructure

(Monitoring/Audit Trail/Exception handling) can be used for free!

The same works for inbound interfaces. Suppose the material master interface is inbound

to SAP. The ALE scenario for material master supports the processing of the inbound

material master IDoc. All that needs to be done if the sending partner system is a legacy

system is to fill the IDoc accordingly with legacy data. The receiving SAP system has all

the functionality to process that IDoc including ALE services for user notification and

exception handling.

13.1.2 Problem of Data Mapping

Conceptually, building interfaces is mainly a data mapping activity. The data elements of

the source system have to be mapped to data elements on the target system. However,

the underlying data structures of the two applications are almost always different.

In the ALE environment this gets even more complicated because in addition to the two

different application data structures we have to deal with a third one -- the IDoc.

The mapping of SAP’s data structures into the IDoc and vice versa is done by the IDoc

processing programs. Each SAP delivered IDoc comes with two programs: one to create

the IDoc and one to process the IDoc. The first program reads application data structures

and puts the data into the IDoc format; the second reads the IDoc data format and puts

the data into the application data structure.

On the legacy side the IDoc has to be translated into the legacy system’s application data

structures. We can write a custom program to do this. However, often load or extract

programs already exist, and they require a certain data structure layout. If this is the case,

we must translate the data from the IDoc to these special structures.



There is usually some cross-referencing between the data elements in the

IDoc and the legacy systems (e.g. material number in SAP to material number in legacy).

13.1.3 The ALE Converter

An ALE converter is an external program that bridges the gap between the SAP and the

legacy systems and their different data formats by mapping SAP IDocs to the application

specific format and vice versa. An ALE converter is therefore a data mapping tool.

In addition to data mapping the ALE converter usually has the ability to do lookups in

cross-reference tables by either keeping local lookup files or by connecting to relational

databases for the lookup.

SAP has a certification program for ALE converters. To be certified, a third-party ALE

converter must be able to:

� Map to and from an arbitrary IDoc into an arbitrary layout

� Import an IDoc type structure directly into the converter

� Communicate with SAP via tRFC.

The communication feature (direct communication with SAP through tRFC) in conjunction

with the ability to connect to legacy databases (e.g. ODBC connection) allows us to build

interfaces that completely eliminate the need for files (if desired). Therefore the ALE

converter partly fulfills the role of a communication middleware.

From the R/3 system’s perspective it is transparent if the receiving system is another R/3

system or an ALE converter.

13.1.3.1 Exporting an IDoc Type Structure

Transaction: WE63

Menu Path: Tools I Business Communication I IDoc I IDoc Basis I Documentation I

IDoc type (parser)

Transaction WE63 will output the structure of an IDoc Type in a text format. SAP-certified

interface tools must be able to read this format to import the IDoc Type. You can specify

the Control, Data, or Status record structure, or any combination of these.



13.1.4 ALE Interface Infrastructure

An ALE infrastructure consists of 3 components:

� External System

� ALE Converter

� SAP system

The SAP system communicates with other systems by creating and processing IDocs, while

the non-SAP application communicates with other systems in its application specific format.

The ALE converter translates the SAP IDocs to the application specific format and vice

versa.

The ALE converter communicates with SAP using tRFC or file based methods. Some ALE

converters are able to connect to external application databases (for example via ODBC).

If files are involved, we will need a subsystem for data transport (e.g. ftp shell scripts, NFS,

or messaging middleware).

The ALE converter is the centerpiece of an ALE-based interface infrastructure. It does

translation, cross-referencing and, to a certain degree, communication.

13.1.5 Benefits of Interfacing with ALE

The benefits of using ALE for interfaces include:

� SAP predelivers a complete interface infrastructure, including:

o Audit Trail/Status Management

o Error Handling with Workflow

o Secure Communication through tRFC

� Programming, if needed at all, is minimal, and compatibility between SAP releases

is guaranteed

� ALE may provide better performance than other techniques, because:

o IDoc programs usually use Direct Update to post the data in IDocs. This is

the fastest method available, because a function module directly adds the

data to the database tables without the overhead of a Batch Input process.

o The timing of IDoc processing is flexible. We can schedule IDoc processing

for times when the system load is low.

13.1.6 Data Export from ALE

There are at least two ways to send outbound IDocs to a legacy system:

� Configure the outbound partner profile to use a file port.

� Point the outbound port to an RFC destination that connects to a program that can

handle the IDoc data with an RFC interface



SAP provides a utility program called RFCEXEC to accept RFC calls from an R/3 system and

to run programs or shell scripts on the application server.

13.1.7

13.1.8 Data Import to ALE

When a legacy system sends IDoc into an SAP system, it can use one of two RFC-enabled

function modules. It calls these function modules with an RFC call.

� INBOUND_IDOC_PROCESS

o The function module that the ALE layer itself uses

o Takes IDocs as parameters and passes them in as part of the RFC call

� EDI_DATA_INCOMING

o Takes a filename and a file port as parameters

o Reads the IDocs from a file on the application server (I.e. not passed in

the call

SAP provides a utility program called STARTRFC to execute RFC function modules on any

R/3 system from an application or presentation server.

13.2 Using ALE with Middleware

13.2.1 What is Middleware?

The word middleware has several meanings. It can be any one of a confusing array of

message-queuing, application development environments, object development

environments, database access, distributed transaction processing, messaging

communications, or Remote Procedure Call (RPC)-based communications.

For the purposes of distributed applications, and Enterprise Application Integration (EAI)

we will be talking about Message-oriented Middleware (MOM).

MOM is a system or set of systems providing the services needed to manage the execution

of applications in a distributed environment.

According to the Gartner Group, 40% of the average IT budget is spent on systems

integration. This has two implications: that systems integration is important, and that it is

difficult.

The primary aim of middleware is to provide easy connectivity between different

applications.

Common characteristics of Message Oriented Middleware include:

� Real-time data transfer

� Messages are based on business rather than technical design considerations. An

example of a message might be “Create Sales Order”

� Although real-time, the applications are usually processed asynchronously, using

queues for data transfer. Once the sending process places a message on a queue,

then it can forget about it, and continue with other tasks. Similarly, the receiving

process only needs to pick up the message when it is ready to process it.

Some examples of products in the middleware area are NEON MQSI, MQ-Series, and

Mercator.



13.2.2 EAI Using a Message Broker

Central to the middleware architecture is a message broker, sometimes called a hub.

Each application connects only to the message broker, rather than to other applications.

Thus, we have fewer point-to-point links than we would need without the broker. The

message broker has two primary functions:

� Routing - to ensure each application receives messages it needs. For example,

perhaps both applications A and B should receive a Sales Order if its number

begins with a 1, otherwise only application B should receive it. The middleware

products support such complex data-based rules.

� Mapping/Transformation - to ensure that the business data contained in the

message makes sense to the application. For example, perhaps Sales Order

numbers created in application C need to be prefixed with a 6 before being sent to

application D. Most middleware products allow any complexity of mapping and

transformation, and may often use large database look-up tables.

All messages must be in a format that the receiving application can understand. In order

to accomplish this, each application that interfaces with the broker will need an adapter to

convert the data format. The adapter normally takes the data in an application specific

format, and places it on a queue in a format the message broker can understand. In the

reverse direction, the adapter reads the data from the message broker queue and converts

it to the application-specific format. There are commercially available adapters for common

products, but sometimes we may need to write a custom adapter.

13.2.3 Middleware and ALE

The communication container for ALE, the IDoc, is also a message containing a unit of

business data. Therefore, conceptually, ALE & IDocs provide SAP support for message-

oriented middleware.

Instead of communicating with other SAP systems, the SAP system sends and receives

IDocs only to and from the message broker, normally through an adapter. Examples of

commercial SAP adapters are NEON SAPLink and IBM Link for R/3.

These adapters accept IDocs, either using the IDoc file interface or (more commonly) tRFC.

The RFC connection is configured in a very similar way to the RFC for a remote SAP system,

so above this level, SAP has no knowledge of whether the IDoc sender/receiver is a SAP

system or the adapter.

13.2.4 Middleware Design Considerations

Here are some design considerations when building an interface to a middleware system

using ALE:



� Addition of new applications. A central message broker architecture provides a

robust and scalable architecture for distributed systems. This architecture makes it

easy to add new applications in the future with minimum work. Since the message

broker’s mapping, transformation, and routing abilities are far superior to those of

the SAP system, it is easier to reformat data in the broker's adapter and send it to

new systems.

� Processing time and throughput. There is additional overhead in the message

processing time between an application creating the message and an application

receiving a message. This can be a serious delay. With complex transformation,

database look-ups, and routing rules, it is important to ensure that the middleware

architecture can handle the transaction volumes. Similar design considerations

when choosing between ALE and ABAP also apply to middleware design. When a

high volume system-specific batch interface is required, a point-to-point ABAP may

be the best option.

� Data transformation. ALE rules provide some degree of data transformation and

routing. However, other applications may not have this degree of flexibility, and it

may be sensible to contain this information within one system - the message

broker -- rather than distribute these rules around the system

� Development time. Middleware development time is significant, and we need to

take it into account when planning interfaces. It is likely that both ALE and

middleware development might be needed, as well as custom programming for the

legacy application posting and extraction routines.

� Conciseness of specifications. Since field-by-field mappings and

transformations are an essential part of a middleware development, the

specifications must contain the detailed information required to build the specified

interface.

13.3 Interface Management

13.3.1 Development Time Estimates

These estimated development times come from previous PwC projects:

Complexity Description Functional

Specs

Construction/Testing

High Large Custom IDoc / Multiple

messages

10 – 12 days 30 days

Medium Enhanced Scenario / At most 2

messages

8 – 10 days 20 days

Low Standard Scenario 6 – 8 days 10 days

13.3.2

13.3.3 Data Conversions

Data conversions into SAP can have a very large impact on interface development. If the

data conversion team loads a lot of data at once, this may cause the system to create an

excessive number of outbound IDocs, most of which the receiving systems will not use.

Therefore, you should design ALE interfaces so that they can be easily turned off and on.

There are a number of different ways of doing this, and the method used will depend on

the interface.

13.3.4 Should we use ALE or ABAP?

Here are some considerations in the decision to use an ALE interface, or to develop an

ABAP-based interface:

� Existing interfaces. When an existing interface design is established then it

makes sense to maintain the design to minimize the development needed.

� SAP Standard Scenarios. If SAP supplies needed functionality then it makes

sense to use it.



o There are many standard upload programs available in SAP. This would

suggest an ABAP approach for the interface, since the program already

exists and there should be minimum effort to build the interface

o There are many standard ALE scenarios provided in the SAP system. SAP

supports these scenarios and enhancement is quick and easy. Where there

is a standard ALE scenario for an interface then this suggests that a

middleware solution may be best.

� Timing Requirements. Timeliness of data transfer to the sending or receiving

application. ALE supports real-time and near-real-time data distribution. A need for

immediate transfer suggests a real-time ALE/middleware approach. Periodic

processing (once or more per day) suggests a middleware batch processing option,

or an ABAP-based interface. Infrequent processing (weekly or monthly) suggests

an ABAP batch option.

� Transaction Volume. ALE is usually slower than an ABAP interface. If very high

transaction volumes are likely, then ABAP is probably a better choice.

� Number of senders or receivers for common sets of data. When similar data

is needed by many receiving systems, or sent by many sending systems, the use

of a middleware-based architecture makes more sense, since the message broker

can manage the distribution of data to multiple recipients.

� Complexity of SAP processing. In some instances the interface may have to

perform multiple transactions in SAP, including controlling the process between

these transactions. In these cases an ABAP solution is more appropriate in order to

maintain SAP integrity for restart or error management.

� Programmers' Skills. ABAP is generally better understood than ALE, and there

are more skilled practitioners.

13.4 Exercise: Reading IDocs from a Disk File

In this exercise, you will read an inbound IDoc from the disk file you created in the

Communication Parameters exercise.

The custom transaction ZCONV converts fields in your IDoc file to values appropriate for

input. It reads a file /tmp/<username> and writes a new file /tmp/<username>.in. It does

essentially the same thing as the turnaround test tool, but it leaves the converted IDoc in

a file without starting inbound processing.

1. Execute the transaction ZCONV. You will need to specify the client number of your

warehouse system, and then click on Execute.

2. Using transaction SE37 (Function Builder), execute the function module

EDI_DATA_INCOMING. This function module reads IDocs from a file.

i. Enter the function module name and click on Single test.

ii. Turn on the Upper/lower case checkbox.

iii. Type the name of your converted file (/tmp/<username>.in) in the

PATHNAME field.

iv. Type the name of your file port (FILE##) in the PORT field. The

function will not use this field, since the pathname field is specified, but it must

contain a valid value.

v. Click on Execute.

3. Run WE05 and see if your IDoc is there. It should have a status of 64 (Ready to

be transferred to application)