ALE Training
-
Upload
rakesh16061986 -
Category
Documents
-
view
470 -
download
5
Transcript of 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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
2.1.5 The IDoc Data Records
The Data Records contain the actual application data. Some of the more important fields
are:
� IDoc ID Number (DOCNUM)
� 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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).
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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 ID Number (DOCNUM)
� 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
This list depicts the drill-down on MATMAS IDocs with status 03. Note that several IDocs
are listed.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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’?
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� Step 2: Maintain the rule.
Transaction: BD79
Menu Path: SALE I Converting Data Between Sender and→Modeling and Implementing Business Processes
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� Step 3: Assign the rule to a message flow.
Transaction: BD55
Menu Path: SALE I Converting Data Between Sender and→Modeling and Implementing Business Processes
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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).
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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)
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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?
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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!
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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!
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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?
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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!
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• ALE Configuration Summary
• Inbound
Configuration requirements are similar for all inbound transactions, regardless
of type.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
d. Basic Type: MATMAS03
7. Save.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.)
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� 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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
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!
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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!
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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?
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� 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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
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!
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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:
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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:
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
• 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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:
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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:
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
� 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.
PricewaterhouseCoopers LLP SAP ALE Training Program
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
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)