ale

[Former Member]

Hi all,

Please provide some information abount ale's how to write ale's in real time.

pls providesome example code.

[Former Member]

Hi Pavan,

Check this matter.This may be helpful to you.

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.

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.

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.

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

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.

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:

Material Master

Customer Master

Vendor Master

Cost Centers

Activity Types

G/L Accounts

Characteristics/Classes/Classifications

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.

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.

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.

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.

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.

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

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

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.

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.

Chapter 2 – Introduction to IDocs

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.

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.

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.

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.

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.

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.

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).

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).

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.

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 à Business Communication à IDoc à IDoc Basis à Documentation à IDoc types

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.

Viewing IDocs on the System

Transaction: WE05

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

You can display a list of IDocs in the system with the IDoc Lists transaction. Specify IDoc criteria such as date/time created, message type, partner, etc. to limit the results.

The resulting screen lists IDocs by direction (inbound/outbound), status, and message type. You can “drill down” into the IDoc list to see detailed information such as control records, status records, and data records.

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

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

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

Single click on any data record to see its fields.

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

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

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’?

Chapter 3 – Modeling ALE Distribution

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.

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.

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.

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.

Defining Logical Systems

Transaction: BD54

Menu Path: SALE à Sending and Receiving Systems à Logical Systems à 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.

Assigning a Logical System Name to the Client

Transaction: SCC4

Menu Path: SALE à Sending and Receiving Systems à Logical Systems à 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.

Model Maintenance

Transaction: BD64

Menu Path: SALE à Modeling and Implementing Business Processes à 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.

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).

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.

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:

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.

Create a logical system name for your Sales system.

Execute BD54.

Click New Entries.

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

Click Save.

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

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

Notes:

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.

Since class participants are sharing senders and receivers, one or both of your logical system names may already exist. If so, just verify that they exist and move on.

B. Allocate logical systems to clients

Each client on a system must have a logical system name, so that it will know what modeled messages apply to it.

From your Sales system, execute SCC4.

Double click on the client assigned as your Sales system.

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

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.

Log into your Sales system. This system will "own" your model view, and you should perform ALL model maintenance on this system.

Execute BD64

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

Click on Create Model view to create a new model view. Enter the model name (MODEL##) and a description and save.

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.

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

Go to Model maintenance on your Sales system

Position the cursor on the MATMAS message flow you defined earlier, and double click on "No filter set".

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

Enter 2000 as the Object value, and save.

Repeat this procedure to add the other two filter objects.

Using the menu path Edit à Delete, delete your filter group, since it will interfere with future exercises.

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 à Administration → Administration à Network → RFC destinations

An RFC (Remote Function Call) destination defines the connection parameters to another system. There are many types of RFC destination, with the most common being R/3 and TCP/IP connections.

RFC Destination configuration is required for SAP-to-SAP ALE distribution, but is not needed for inbound distribution, or outbound distribution using a file interface (such as a legacy system interface or a file-based EDI scenario).

RFC destinations should “map” to the desired logical system. In fact, if the RFC destination has the same name as its corresponding logical system, configuration is easier because we can automatically generate the partner profiles (described later).

The maintenance of the RFC destinations is not a part of the automatic transport and correction system. We need to make the settings manually on all systems.

To create or maintain RFC destinations, use transaction SM59.

For R/3 connections for SAP-to-SAP distribution, indicate the target machine and instance along with necessary login information. The Test connection function checks the connection with the external system and allows you to check the performance times for making this connection. The Remote logon function allows you to logon to the remote system and start a session.

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

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

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

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

Ports

Transaction: WE21

Menu Path: Tools à Business Communication → IDoc à IDoc Basis → Port Definition

Ports establish the linkage between the partner profiles (discussed in detail later in this chapter) and the RFC destinations for outbound transfers. They also indicate if the transfer is file based or tRFC (or R/2, etc.).

To create a port, use transaction WE21.

There are several types of port. Some of the more important ones are:

Transactional RFC

File

R/2 system

XML

The system can automatically generate a transactional RFC port if the logical system name is the same as its corresponding RFC destination (between R/3 systems only!). You need to create ports manually for all other system types.

Transactional RFC Ports

Transactional RFC ports point to an RFC destination, which must exist before creating the port. Simply create a new entry and associate it to a pre-created RFC destination (field Logical destination).

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

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

File Ports

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

Outbound file: A file to receive outbound IDocs.

Inbound file: A file to supply inbound IDocs.

Status file: A file to store IDoc status records.

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

the following:

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

The name of the file. You have two options:

Specify the actual file name.

Choose a function module that generates a filename from timely information, such as date, time, message type, or user id.

XML Ports

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

Only outbound transmission is supported.

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

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

Partner Profiles

Transaction: WE20

Menu Path: Tools à Business Communication → IDoc à IDoc Basis → Partner Profile

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

Given a message type and a communication partner system, the partner profile specifies information that the ALE layer needs to properly create or process the IDocs. This information is different for senders and receivers.

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

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

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

In the receiving system profiles, the Partner number is the

sending system.

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

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

Receiver of notifications is a Workflow configuration for error handling.

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

Message Control parameters control the sending of messages from an application that uses Message Control (also called Output Determination) - Separation of Sales and Distribution, for example.

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

Partner Profile Outbound Parameters

The outbound parameters provide information for creating outbound IDocs:

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

Whether to send the IDocs immediately or to collect them for sending

in batches.

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

The IDoc type to use for the message.

Workflow configuration for handling errors.

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

Partner Profile Outbound Parameters

The inbound parameters provide information for processing inbound IDocs:

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

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

Workflow configuration for handling errors.

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

Partner Profile Generation

Transaction: BD82

Menu Path: BD64 à Environment → Generate partner profiles

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

Restrictions on generation:

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

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

Normally, you maintain the distribution model on one system, distribute it to the other systems, and generate the partner profiles on each system from the model.

Parameters for the program:

The model view or views from which to generate profiles

Workflow configuration for errors

Outbound IDoc packaging options

Inbound IDoc background processing options

The results are color-coded:

Green: The generation was successful

White: The profile or parameter already exists

Red: an error occurred during generation

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

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

Model Distribution

Menu Path: BD64 à Edit à Model view → Distribute

Typically, you maintain the distribution model on the one system designated as the owner of the model. Then you distribute it to the other remote SAP systems.

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

configured an RFC destination for that system.

the SYNCH message type configured in the partner profile for that system. The profile generation program will automatically create this profile parameter for all systems represented in any model that you generate. Therefore, you should generate your model on its owner system before distributing it to other systems.

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

To distribute a model:

Enter the name of the model view you want to send

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

Execute.

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

ALE Configuration Summary

Inbound

Configuration requirements are similar for all inbound transactions, regardless

of type.

Outbound

Outbound ALE messages require configuration of all pieces (logical systems, RFC destinations, ports, partner profiles, and distribution model).

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

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

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

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

R/3 to Legacy File based with RFC uses a TCP/IP type destination pointing to RFCEXEC and a File type port with a command file parameter pointing to a server executable that receives and processes the IDoc.

Exercise: ALE Communication Parameters

In this exercise, you will configure message flow between two SAP systems using ALE. You will distribute a material record from one client to another

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

A. Define the RFC Destination

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

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.

Enter the information:

RFC Destination: your Warehouse logical system name. CAUTION: This field is case-sensitive!

Connection Type: 3

Description: descriptive text

Client: your Warehouse system's client number

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

Password: your logon password

Target host: your Warehouse system's host name

System number: your Warehouse system's system number

Click Save.

You can click on Test Connection to test the connection to the other system, or Remote Login to log into it.

B. Generate the Outbound Partner Profile

You will now create a partner profile, which combines your logical system with the message types defined and associates it with a port to the physical system.

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

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

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.

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.

Run BD64. (Distribution Model Maintenance).

Highlight your distribution model and follow menu path Edit à Model View à Distribute. Enter your model name and enter.

Select the proper system to receive the model and execute. You should see a message indicating successful transfer.

D. Generate the Inbound Partner Profile

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

Note: Ignore any errors listed involving an RFC destination for your Sales system. This will not affect inbound processing.

E. Send a Material

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

Log back into your Sales system.

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!

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

Enter the number of the material you created, the message type to use (MATMAS), and your Warehouse system name, and then click Execute.

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

Run transaction WE05 to look at the status of your message. The status should be 03 “Data passed to port OK”.

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

Log into your Warehouse system and use WE05 to look at the received message. Its status should be 53 “Application document posted”.

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?

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

On your Sales system, run transaction WE21.

Highlight File, then click on Create.

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

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

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.

Save.

B. Configure Outbound Processing

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

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

Sending System: Your Sales system

Receiving System: Your FILE## logical system

Message Type: MATMAS

Save your model.

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:

Partner Number: FILE##

Partner Type: LS

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

Message Type: MATMAS

Receiver Port: FILE##

Output mode: Transfer IDoc immediately

Basic Type: MATMAS03

Save.

C. Send a Material

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

Use BD10 to send this material to your logical system FILE##. You should get one Master IDoc and one Communication IDoc.

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

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

D. Using an XML port.

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

Change your partner profile entry for the FILE## logical system to use the XML## port instead of the FILE## port.

Resend your material to the FILE## logical system.

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.)

Chapter 5 – ALE Architecture

Outbound Processing

Application Transaction

Create the application document

Outbound processing begins with the SAP application transaction. This transaction creates a document that needs to be sent to another system with ALE.

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

Read the Distribution Model

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.

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.

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

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

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.

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

Distribution (ALE) Layer

Read the Distribution Model.

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

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

If there are no receivers defined in the model, processing stops and the application posts its data to the database.

ALE Layer IDoc Processing

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.

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.

Communication Layer

Once the ALE layer has created the IDoc, it sends it to Dispatch Control, which controls how the IDoc is sent (file interface or tRFC) and when the IDoc is sent (immediately or periodically in batches). Dispatch Control uses the technical communication parameters that we set in the partner profile.

When the ALE IDoc is complete and Dispatch Control has determined when and how to send it, the Communications Service actually transmits the message.

Sending the outbound IDocs in batch reduces the communications overhead.

Inbound Processing

Communication Layer

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

Distribution (ALE) Layer

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

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

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

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

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

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

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

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

Which users to notify if there is an error in processing

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

Application Layer

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

Once the application document is ready for posting, the application posts it to the database and updates the IDoc’s status records in the same Logical Unit of Work.

The ORDERS and ORDCHG IDocs are exceptions to this timing. In both cases, the application executes a CALL TRANSACTION first, and then updates the status records.

When the SAP application processes the IDoc, it can check the serialization. Using the timestamp of the IDoc, the application can determine if it has already received a more recent IDoc for the same inbound document. If it has, it may wish to avoid posting the data in the overtaken IDoc.

Not all of the SAP applications use this serialization capability.

Outbound Processing for EDI

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

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

Message Control (also called Output Determination) determines where to send the document. This may include printing a hard copy or sending by ALE or EDI. If out by ALE or EDI (that is, by IDoc) is required, then Message Control writes a record to the NAST table.

ABAP program RSNAST00 (which is scheduled to run on a periodic basis) reads the NAST records and creates outbound IDocs for each one, based on the ALE configuration. It writes these IDocs to the IDoc tables (EDIDC, EDID4, EDIDS). If the partner profile is set to "Send immediately", then the ALE layer will send the IDocs at this time.

If the partner profile is set to "Collect IDocs", then the ALE layer will not send the IDocs until the ABAP program RSEOUT00 (also scheduled for periodic execution) runs. This program calls the ALE layer to send all collected IDocs of any specified message types.

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

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

Executes the program RFCEXEC. This program is not an ABAP program, but rather an SAP-supplied program that runs on the operating system.

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

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

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

Chapter 6 – Data Distribution Methods

Configuring Master Data Fetch

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

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

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

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

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

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

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

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

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

To configure a fetch, simply define a fetch message type in the direction opposite from the master data message type in the distribution model, then use the appropriate master data fetch program.

Triggering Methods

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

Master data

Manual Program

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.

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).

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

We can use Change Pointers to automatically distribute the data.

If a user creates, changes, blocks, or deletes a master record, the Shared Master Data (SMD) system will send the record automatically.

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.

Automatic distribution will work for all the master data types available to ALE.

IDoc distribution using the SMD is generally a batch (not real-time) process. The system does not send IDocs at once, but rather waits for the next scheduled send. However, with customization of the tool, you can achieve near-real-time distribution.

Transaction data

Direct ALE Call

The transaction program may contain a call to the ALE layer to send the IDoc directly.

Message Control

We can use Message Control to automatically distribute the data. The message control system allows the sending of data in real-time.

Automatic Master Data Send with Change Pointers

SMD outbound processing begins with the SAP application transaction that changes master data that needs to be sent to another system with ALE. The application does not post its data yet. Instead, it waits until the change document and change pointers are written.

The change document service examines which fields have been changed. If the field that is changed is one that receiving systems are interested in, the program writes a change pointer to the database. Change pointers are the mechanism by which the SMD tool operates. The change pointers are message type specific, and also indicate which part of the master data record changed (that is, which database table was modified). The ALE-relevant fields are configurable by message type.

A standalone program (RBDMIDOC) analyzes the unprocessed change pointers. Normally this program is scheduled to run periodically for different message types. When it finds a change pointer for a particular object, it creates a master IDoc for the object referenced by the change pointer.

The ALE layer reads the distribution model and generates communication IDocs as usual, including filtering, version change, ALE rules, etc.

Configuring the SMD Tool

These are the steps needed to configure an automatic master data send:

Transaction: BD61

Menu Path: SALE à Modeling and Implementing Business Processes → Master data Distribution à Replication of Modified Data à 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 à Modeling and Implementing Business Processes → Master data Distribution à Replication of Modified Data à 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 à ALE à ALE Development ® IDocs à Engineering Change Management à Define Change-Relevant Fields

Define change-relevant fields. Use BD52.This allows you to set which fields in the master data record should trigger the writing of a change pointer. SAP proposes a default set, which usually, but not always, includes every field in the table. This is optional – if you want to use SAP's default set of fields, you do not need to configure this.

Schedule IDoc creation job. This program (RBDMIDOC) will look for records that have changed, and send them to the appropriate receiving systems, based on the distribution model.

Message Control

Message Control (also called Output Determination) is a part of the functional configuration that determines what output types to use when creating a transaction document.

We can configure a document to produce many kinds of output:

Printed forms on a printer

Fax output

EDI output

ALE output

The methods for configuring message control differ in each functional area, and message control is not available for all functional areas. Specifically, only MM and SD applications can use it.

Hierarchy of Message Control Components

The configuration of Message Control involves many layers of components. These components are as follows, with examples for configuration of sales orders:

Application -- The application area. Each application capable of message control has a unique two-character ID.

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.

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.

Examples: Order confirmation, internal order message

Access Sequence -- Defines the fields used to look up condition tables. This identifies the business rules to check before proposing output, and the order in which to check them. You can chose exclusive or inclusive rules. An exclusive rule means that when the first rule evaluates to true, the system proposes the output ignoring the remaining rules in the access sequence. With inclusive rules, all rules must be true before the output is proposed. It is also possible to add ABAP requirements through VOFM to check specific business rules based on the fields in the condition table.

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.

Example: EDI for customers in sales organization 0001, printed output for all others

Configuring Message Control

The R/3 system comes with a set of default message control configurations, which we can add to or change. These include all of the application areas, as well as most schemes you will ever need.

In general, you should define these components from the bottom up. That is, you should create the condition tables, then the access sequences, and so on to finish with the scheme.

SAP considers schemes, output types, and access sequences to be configuration data. You will find the programs to maintain them in the IMG. For example, the IMG path for Sales Documents is: Sales and Distribution --> Basic Functions --> Output Control --> Output Determination --> Output Determination Using the Condition Technique --> Maintain Output Determination for Sales Documents

Condition records are application data. You find the programs to create them as part of the application menu path. For example, the menu path to create condition records for Sales Documents is: Logistics --> Sales and distribution --> Master data --> Output --> Sales document --> Create.

Here are some common configuration hierarchies:

Materials Management:

Application/Transaction Condition Type Procedure Logical Message Type

EF/Purchase Order NEU RMBEF1 ORDERS

EF/P.O. Change NEU (with change flag) RMBEF1 ORDCHG

EA/Request for Quote NEU RMBEA1 REQOTE

Sales and Distribution:

Application/Transaction Condition Type Procedure Logical Message Type

V1/Sales Orders BA00

V10000

ORDRSP

V1/Quotations

AN00

V06000

QUOTES

V2/Delivery Notes

LAVA

V10000

DESADV

V3/Invoicing

RD00 V10000

INVOIC

Configuring Message Control: An Example

As an example of the required Message Control configuration, let’s consider the Distributed Contract scenario. As a reminder, this scenario involved the creation of a contract at a central office which then sends it to distributed offices. The local facilities can then create purchase orders referencing this contract.

We need the following configurations.

Note: Transaction codes given here are specific for the Distributed Contract scenario. Transaction codes for other scenarios will be different, although the functioning of the programs is similar.

Remember that you must define new entries from the bottom of the hierarchy to the top.

Define Access Sequences (M/52). Defines the fields of the condition tables used to determine output. Each access sequence corresponds to a different condition table.

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:

The medium and timing, which may differ with different partner types.

The program used to process and output the data, which in our example creates the IDocs from the application document.

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.

We use scheme RMBEV1, which represents a purchasing agreement.

Fine-Tuned Control of Output Types (OMQO). Defines which output type to use in different situations within a given scheme. For example, we can define a different Output Type for an added document than we do for a changed document.

We associate our Output Type VNEU to new contracts.

Assignment of Scheme to Application (OMQT). Assigns a scheme to an application.

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.

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.

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.

We will generate the partner profile from the distribution model.

Additional ALE Configuration for Message Control

There is some additional ALE configuration to enable the Output Proposal from the document to trigger an ALE message.

We need to link the output determination message type to the ALE message type in the partner profile of the system. Using transaction WE20, select your ALE message, and click on Message Control. Enter the message control output type that will trigger your message and the outbound process code. You need two entries here for each output type: one for creates to the transaction document and one for changes.

Viewing Proposed Output

Most application programs allow you to determine what output was proposed for any document. You can see which output types were proposed and the receiving party, if by EDI.

The status will have one of these values:

YELLOW To be processed

GREEN Successfully processed

RED Incorrectly processed

To view how an output was proposed, use menu path Goto --> Determin analysis.

When the status is RED, select the line with a single click and use menu path Goto --> Processing log to see a description of the error.

You can drill down into these screens to see more details of each step.

Re-Proposing Output from NAST

When the system determines output for an application document, it writes a record to the NAST table. This NAST record can have one of three status values.

0 = awaiting output

1 = output successfully processed

2 = an error occurred during output processing

Once a NAST record has a successful status (1), and the ALE layer has sent the IDoc successfully, you cannot resend the IDoc. If you need to resend the IDoc, you must go back to the application document and repeat the output. The menu path varies, by program, but is usually something like Goto à Messages.

Re-proposing the application document will rerun the output programs and create a new IDoc. The new IDoc will contain any changes in the application document made since the first IDoc was created.

Batch Processing

Reasons

We can configure most of the IDoc processing, both inbound and outbound, to happen immediately or in batch. There are several reasons why the batch mode is generally preferable:

Time Constraints. Sometimes the processing of a set of IDocs must happen within a specific window of time. For example, purchase orders can be created and modified on the system over the course of the day and only sent out once a night. Until the time the Order IDoc is created, users can make changes to the order. Once the IDoc is created, all subsequent changes will result in the creation of change orders.

Transaction Sequence. A group of transactions may need to be sent out together. For example, if a billing program creates multiple invoices for the same customer, the customer may expect that all invoices generated that day be sent in a single EDI interchange.

Scheduling Dependencies. The processing of some IDocs may depend on the successful processing of a preceding batch job, or a later job may depend on the successful completion of IDoc processing. Either case requires that the processing of all IDocs as a step in a batch process that can either trigger or be triggered by another step.

Transaction Volume/Load Balancing. Some SAP processes (e.g. post goods issue, delivery due list), as well as certain external systems (e.g. EDI, warehouse management systems) can create a high volume of transactions in a short period of time. They can overwhelm the processing capabilities of the receiving system if the interface is set up to process everything immediately.

Batch Processing Programs

SAP supplies some ABAP programs to allow for batch processing of IDocs:

RBDMIDOC -- Creates Master data IDocs from change pointers. You must specify a message type for which to create IDocs.

RSNAST00 -- Reads records from the NAST table, creates IDocs, and submits the IDocs to the ALE layer for distribution. Create a variant with the following fields filled:

Output application

Output type

Transmission medium

Editing an outbound document that has been saved and posted is possible only until RSNAST00 creates the IDoc. After that, any changes to the document will trigger a separate IDoc.

RSEOUT00 -- Sends IDocs stored in the database with partner profile entries indication Collect IDocs. •The Output mode field of this program allows you to specify when the EDI translator (or subsystem) will run. Generally, you should use mode 3, which triggers the subsystem only once for each batch of IDocs.

RBDAPP01 -- Processes inbound IDocs stored in the database with partner profile entries indication Background processing.

RSEINB00 -- Reads inbound IDocs from a disk file, whose name you specify and submits them for processing.

Distributing Control and Customizing Data

We can control the distribution of control or customizing data with ALE. In fact, certain customizing data must remain consistent across all of the systems for ALE to function properly.

The Distribution Model defines the distribution of changes to customizing data, but we use CTS (Correction and Transport System) to actually distribute the control data to the other systems.

How to Distribute Control Data

There are two methods for configuring control data distribution:

Using the CONDAT message type in a distribution model. This is the only method available in releases earlier than 4.6B.

Creating a Customizing Data Distribution Group. This method replaces the old CONDAT method in release 4.6B, although the CONDAT method is still available. You cannot use both at the same time.

Since Control Data Distribution control with ALE is rarely used, we will not discuss it further. Consult online help if you need more information.

Exercise: Master Data Fetch

In this exercise, you will configure a master data fetch between two SAP systems using ALE. You will distribute a customer record from one system to another.

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!

On your Warehouse system, configure an RFC Destination pointing to your Sales system.

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.

Distribute the model to Warehouse

Generate your model on both systems.

Create a customer (transaction V-09) on the Sales system.

From the Warehouse system, execute transaction BD13 to fetch your customer.

Look at the IDocs sent on both systems and check for successful processing.

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

Add the following message flows to your distribution model:

BLAORD from Sales to Warehouse

BLAREL from Warehouse to Sales

If you didn’t configure vendor or material distribution in previous exercises, add these as well:

CREMAS from Sales to Warehouse

MATMAS from Sales to Warehouse

Distribute your model and generate it on both systems. If you encounter errors, fix them before proceeding!

B. Configure Message Control

Note: In this section, you will be looking at existing configuration, since this scenario comes preconfigured with the R/3 system.

Go to the IMG. Transaction SPRO, then click on SAP Reference IMG.

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.

Execute Partner Roles per Message Type for Outline Agreements.

Check that there is an entry for Distributed Contracts (output VNEU) for ALE Distribution (medium A).

Execute Message Determination Schema for Outline Agreements, then select Maintain Message Determination Schema: Outline Agreement.

What procedure (or schema) are we using for this scenario?

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.

Execute Message Types for Outline Agreements, then select Maintain Message Types.

Double click on VNEU. Note the following entries:

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.

The default medium (on the Default values tab) is ALE.

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.

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).

Execute Access Sequences for Outline Agreements.

What condition tables are available? (To find out, select the access sequence and double click on Accesses.)

Which condition table would be most appropriate for our scenario?

What database field(s) does this condition table use?

C. Create Condition Records

On your Sales system, configure the output of quantity contract information:

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.

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.

Create a record as follows:

Document type: MK (Quantity contract)

Medium: A (ALE distribution)

Timing 4 (Send immediately)

Leave the other fields blank.

On your Warehouse system, configure the output of purchase order (release) information:

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.

The output type in this case is NEU, since we are creating a purchase order.

Select the Document Type condition table.

Create a record as follows:

Document type: MK (Quantity contract)

Partner Function: VN (Vendor)

Medium: A (ALE distribution)

Timing 4 (Send immediately)

Leave the other fields blank.

D. Create Master Data

Create a vendor, using the guidelines distributed in class.

Create a material, using the guidelines distributed in class, with the following additions:

Select the Basic Data and Accounting 1 views.

Set the Valuation class to 7920, the Price control to S, and put in a price in Standard price.

Use BD14 to send the vendor to the warehouse system.

Use BD10 to send the material to the warehouse system.

E. Create a new Distributed Contract.

On your Sales system, execute transaction ME31K, or menu path Logistics à Materials Management à Purchasing à Outline Agreement à Contract à Create

Enter data:

Vendor The vendor you create above

Agreement Type MK (Quantity contract)

Purchasing group 001

Enter, then add a line item for your material:

Material The material you created above

Targ. qty. The total contract quantity

Net price The price per unit

Matl group 01

Follow menu path Header à Messages to see if ALE output was created. If not, troubleshoot and fix.

Save the contract. Make a note of the contract number.

Run WE05 on both systems. Is there a BLAORD IDoc sent? Did it post successfully on your warehouse system? If not, fix any errors and repost using BD87.

F. Create a Purchase Order against the Contract.

On your Warehouse system, execute transaction ME21.

Click on the Ref. to contract button and enter your contract number.

In the line item for the material, fill in the quantity for this order and the plant (0001), and click on Adopt + details,

Enter the order price and save.

Run WE05. Is there a BLAREL IDoc sent? Did it post successfully on your sales system? If not, fix errors and repost using BD87.

On your sales system, execute transaction ME33K, or menu path Logistics à Materials Management à Purchasing à Outline Agreement à Contract à Display.

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.

Chapter 7 – 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.

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 color-coded.

Consistency Check for Application Number Ranges

Transaction: BD70

This consistency check 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.

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.

Mass IDoc Processing

Transaction: BD87

Menu Path: Tools à ALE à ALE Administration à Monitoring à Status Monitor for ALE Messages

This transaction allows the manual processing of IDocs. It has a selection screen to select IDocs to process, and then displays all of the IDocs selected sorted by their status codes. You can then select which specific IDocs to process. Here are some situations in which this program is useful:

ALE configuration error -- Retry sending IDocs after fixing the problem that caused the error.

Ignoring the IDoc syntax check – Send IDocs that were not sent because of syntax errors

Dispatch -- Send any IDocs that are held because Collect IDocs is set in the partner profiles.

Posting -- Process any IDocs that were held because Background processing is set in the partner profile.

Resubmit an edited IDoc – Send or post IDocs you have edited manually.

Try posting again -- Attempt to repost IDocs that encountered a logical error in the posting transaction.

Check IDoc Dispatch

Transaction: BD75

Menu Path: Tools à ALE à ALE Administration à Services à Communication à Transactional RFC à 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.

tRFC Monitoring

Transaction: SM58

Menu Path: Tools à Administration à Monitor à 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.

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.

The IDoc Test Tool

Transaction: WE19

Menu Path: Tools à Business Communication à IDoc Basis à Test à 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.

The Turnaround Testing Tool

Transaction: WE19

Menu Path: Tools à Business Communication à IDoc Basis à Test à Test Tool

The turnaround testing tool takes an outbound IDoc in a disk file and converts it to an inbound IDoc by changing the control record.

You can specify the following parameters:

Input and output files

Sender and receiver logical systems and ports

Message type

Target client

After doing the conversion, the program will submit the IDoc for inbound processing.

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.

Program RBDSTATE

Transaction: BDM8

Menu Path: Tools à ALE à ALE Administration à Monitoring à ALE Audit à Send audit confirmations

Program: RBDSTATE

Use the program RBDSTATE on the receiving system to send the audit messages to the sending system, using ALE (I.e. asynchronously). You typically run this program as a scheduled batch job. The parameters of RBDSTATE are:

The sending system (of the original IDoc)

The message type

The date range the IDoc’s status was changed. Any IDoc having a status record in this date range will be confirmed.

The audit messages contain:

The current status of the inbound IDoc

The id of the resulting SAP application object (if the IDoc was

successfully posted)

The system will confirm up to 500 IDocs in one ALEAUD message. If

there are more than 500 IDocs to be audited, then it will create multiple

audit IDocs.

NOTE: The RBDSTATE program looks at IDoc status records to determine which IDocs to audit. If any status record was added to an IDoc during the specified date range, the program will audit the IDoc.

Program RBDAUD01

Transaction: BDM7

Menu Path: Tools à ALE à ALE Administration à Monitoring à ALE Audit à Evaluate audit statistics

Program: RBDAUD01

Use the program RBDAUD01 on the sending system to look at the ALE Audit IDoc statistics.

“IDocs total” is the total number of IDocs audited

“Queue Outbound” is the number of IDocs that have not yet been sent to the other system

“Queue Inbound” is the number of IDocs that are still being processed by the receiving system

ALE Audit records may be selected by message type, date range, etc. You can drill down into the report to see information on daily statistics, detailed information on IDocs, and cross-system links for successfully processed IDocs:

Audit IDoc Structure

These are the segments in an ALEAUD01 IDoc, with the fields they contain:

Segment E1ADHDR

Message type

Segment E1STATE

Sender’s IDoc number

Current status

Message fields

Segment E1PRTOB

Receiver’s IDoc number

Application object information

Batch Processing Programs

SAP supplies some ABAP programs to allow for batch monitoring of the ALE system:

RBDCONCH -- Runs consistency checks for any message types or receiving systems. You can specify which consistency checks to run. If the program finds any errors, it creates a notification with Workflow.

RBDMANIN -- Attempts to reprocess any IDocs with a specified error status code. This is useful if IDoc processing fails because of record locking issues. No changes are necessary; trying to post the IDocs again will usually work. This program can automate this process. You can specify IDoc creation dates, sending systems, message types, and status codes to selectively reprocess IDocs.

RSEIDOCM -- Counts the number of IDocs on the system that have a specified status code. If this number exceeds a specified maximum, the program generates a Workflow notification. You would generally use this with error status codes to detect a failure in the IDoc processing flow. If a piece of the ALE system is not working correctly, IDocs with error status will build up in the system. This program provides a way of detecting this condition.

RBDMOIND -- Checks the tRFC dispatch for all IDocs with status 03 (Data passed to port OK). The program checks the successful sending of these IDocs with the receiving system and writes a status record of 12 (Dispatch OK) to all IDocs successfully transferred.

RBDSTATE -- Creates ALE Audit messages for the specified sending systems and message types. See the discussion of ALE Audit for details.

Exercise: ALE Monitoring

In this exercise, you will explore some of the ALE Monitoring tools.

Run BDM5 (on your Sales system) to check the consistency of your distribution model.

Double click on the name of your Warehouse system to run the check.

After the check runs, all fields should be white (Check OK). If not, try to fix the problem.

If you had any error IDocs in previous exercises, try to resend or repost them with BD87.

NOTE: Specify your partner system on the BD87 selection screen to avoid reprocessing other students’ IDocs!

Run BD75 (on your Sales system) to check the IDoc dispatch.

Select today’s date and execute.

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.

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

On your Sales system, execute the test tool (WE19).

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.)

Click on Create.

Delete all segments (if any) other than the required E1MARAM and E1MAKTM segments. (Select a segment, then click Delete.)

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.

Click on Standard Outbound Processing to send the test IDoc.

Go to your Warehouse system and see if the IDoc was received and processed successfully.

B. Inbound Testing

On your Sales system, execute the test tool (WE19).

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.)

Click on Create.

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.

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.

Click the green arrow to start processing.

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.

Execute the turnaround testing tool, transaction WE12. Set the following parameters and execute:

Source: the file you created earlier (“/tmp/ Master Data Distribution à Scope of Data for Distribution à Message Reduction à 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.

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 Utilities→Color/character key

Initially 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.

Transporting the Reduced Message Type

Transaction: BD63

Menu Path: SALE --> Modeling and Implementing Business Processes --> Master Data Distribution à Scope of Data for Distribution à Message Reduction à 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.

Exercise: IDoc Reductions

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

A. Creating a Reduced Message Type.

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.

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

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.

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.

Distribute the model and generate it on both systems.

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!)

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)?

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

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

Add a new material, or change an existing one.

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?

Chapter 13 – 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!

Create The Extension Segment

Transaction: WE31

Menu Path: Tools à Business Communication à IDoc à IDoc Basis à Development à 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:

Field name

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

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.

Create the Extension IDoc Type

Transaction: WE30

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

or: WE31 à Goto à 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.

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 à Business Communication à IDoc à IDoc Basis à Development à Message types

or: WE30 à Environment à 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 à Business Communication à IDoc à IDoc Basis à Development à IDoc type/message

or: WE30 à Environment à 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.

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 Development Object→Check. 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 Edit → Set release.

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

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.

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.

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.

Activate Change Document Items

Transaction: BD52

Menu Path: Tools à ALE à ALE Development à IDocs à Change à 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.

Assign Function Modules to Message Type

Outbound

Transaction: BD60

Menu Path: Tools à ALE à ALE Development à IDocs à Change à 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 à Business Communication à IDoc Basis à Control à 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.

Inbound

Transaction: WE57

Menu Path: Tools à ALE à ALE Development à IDocs à Inbound Processing à Function module à 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.

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.

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:

Create an extension of the SAP supplied IDoc MATMAS03.

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:

Create an extension segment

Create an extended IDoc type to merge this segment with MATMAS03

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

Configure the creation of IDocs using change pointers

Perform outbound configuration

Perform inbound configuration

Test the scenario

Detailed instructions:

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

Create a development class called ZAL##, where ## is your user number. (Use SE80 to do this.) Create a new change request when prompted.

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

Check and release the segment.

Step 2: Create an extended IDoc type to merge this segment with MATMAS03 (both sending and receiving systems)

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.

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)

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

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

Check and release your extended IDoc type

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

Make sure that Change Pointers are activated generally. BD61

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

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)

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.

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

Generate the outbound partner profile.

Distribute the model to your Warehouse system.

Step 6: Perform inbound configuration (receiving system)

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.

Enter your extension type.

Replace message type MATMAS with your extended message type

Enter.

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

Step 7: Test the scenario

On your Sales system:

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

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.

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.

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

On your Warehouse system:

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

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

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?

Chapter 14 – IDoc Creation

Developing Your Own ALE Scenario

SAP delivers a large number of distribution scenarios. They have committed to further develop and deliver ALE scenarios with their upcoming releases. However, a client that implements SAP may need to implement a distribution scenario that is not currently available. This chapter and the next describe the steps needed to develop your own ALE scenarios.

You will learn:

How to create the data container (IDoc) for the scenario.

How to develop an ALE program that creates and sends the IDoc.

How to develop an ALE program that processes the incoming IDoc.

How to setup the necessary ALE configuration for these new pieces.

Scenario Analysis

The first step in creating our own ALE scenario is to do a scenario analysis. We have to understand the structure of the data, how to extract it, and to process it. We need to consider the following questions:

How should we structure the IDoc?

Which data fields do we need to transfer?

How many logical groups of data (header vs. line item) do we have?

Do we have hierarchical structures?

What are the optional and mandatory groups?

How long are the data fields? In general, the structure of an IDoc should match the structure of the underlying database tables for the object you will be using the IDoc for.

When should the data be sent?

How does the triggering work?

From where will we extract the data?

What will the receiver do with the data?

Good IDoc Design

Here are some suggestions for creating efficient, reusable IDoc structures:

Do not create a custom segment if you can use an existing segment for your purposes, even if many fields go unused.

Each segment should contain data that logically goes together.

Design your segments so that they may be reused in other IDoc types.

Make sure your fields are long enough to contain the maximum possible length of SAP data.

If two segments will always be used together, combine them into one. But remember that the maximum length of a segment is 1000 bytes.

A qualifier is a field that indicates how the segment is to be used. Using qualifiers adds confusion and difficulty in programming. It’s better to create separate segments for each purpose.

If your IDoc may be used for EDI in the future, make sure it’s compatible with the EDI standard.

Use as few hierarchy levels as possible. They just add confusion to programming.

IDoc Type Creation

Once you have done your analysis you should have a clear understanding about the IDoc structure. After you have designed the layout of your IDoc it is fairly simple and straightforward to define that IDoc type in SAP with the IDoc type definition tools.

There are 4 main steps involved in creating the IDoc Type:

Create segments

Create IDoc type

Create message type

Link message type with IDoc type

Create New Segments

First you need to create the segments that you will use in your new IDoc type.

Follow the same procedure used to create segments for extension types. Refer to the IDoc extensions chapter for detailed information.

Create IDoc Type

The next step is to create the IDoc type by “assembling” all the necessary segments. Part of your scenario analysis was to define the layout of the IDoc. You should have addressed the following questions. You’ll need the answers now in order to define the IDoc structure:

Which segments will you use?

What is the hierarchy of the segments?

Which segments are mandatory and which are optional?

How often may a segment be repeated?

You should create the IDoc structures as flat as possible. Usually each level of segment hierarchy results in a looping structure in the corresponding program. Therefore it’s easier to deal with flat structures.

Conceptually, the IDoc type describes the technical structure of the message.

Here is how to create a new IDoc type by assembling previously defined segments:

Go to the IDoc Type maintenance, transaction WE30.

Type the name of the new IDoc type and click Create.

Put segments into the IDoc:

Segment à Create

Enter segment name

Enter attributes (Mandatory/Minimum/Maximum)

Create New Message Type

A message type determines how the system will process the data in the IDoc. This allows you to use the same IDoc in different scenarios but process the data differently in different situations.

Transaction: WE81

Menu Path: Tools à Business Communication à IDocs à IDoc Basis à Development à Message types

or: WE30 à Environment à Message types

Click on Change, then New entries, add your new message type (with a description), and Save.

Customer message types must be in the customer name range (starting

with Z).

Link Message Type with IDoc Type

The last step of the IDoc creation process is to link the new IDoc type with the new message type. You link the message type to the outbound and inbound programs. These configurations determine how the system will process the IDoc.

The relationship between IDoc type and message type is a 1-to-many relationship. That means an IDoc can be associated with multiple message types, but a message type uses exactly one IDoc type.

Transaction: WE82

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

or: WE30 à Environment à IDoc type/message

Enter your message type, your IDoc type, and the SAP release under which you created the IDoc.

Exercise: IDoc Type Creation

In this exercise, you will create a custom IDoc type. You will use this IDoc type in the next two exercises.

Scenario:

Springfield Nuclear Power, Inc. is continuing its implementation of SAP for its three nuclear power plants. The Nuclear Regulatory Commission requires that they perform periodic calibration of their radiation detection instruments. They must maintain records of these calibrations in a central place. They are required to test each instrument at several settings: low, moderate, high, and critical levels.

The SAP tables do not meet these requirements, so they have created two custom tables: ZCALHDR, which stores information about each calibration test, and ZCALENT, which stores information about the results at each instrument setting.

In order to transfer these calibration records using ALE, we need to build a custom IDoc type to store the information. We also need to write a program code on the Sales system to populate this IDoc, and an inbound function module on the Warehouse system to read the data into tables ZCALHDR and ZCALENT.

This is your task.

A. Create a Header segment

Go to the Segment Editor (WE31) and create a new segment Z1CALHDR## (where ## is your login number). Use the following fields in your segment:

Field Name Data Element

SERIAL ZSERIAL

DATUM DATUM

UNAME ZUNAME

METHOD ZCALMETHOD

Check your segment

Release your segment

Check your segment again

B. Create a Detail segment

In the same way, create a segment Z1CALENT## as follows:

Field Name Data Element

SETTING ZSETTING

RESULTS ZRESULT

C. Create a new IDoc type

Go to the maintenance of IDoc types (WE30)

Create new Basic IDoc type ZCAL## (where ## is your group number)

Put the segment Z1CALHDR## into the IDoc, using the following attributes for the segment:

Mandatory

Min. number: 1

Max. number: 1

Put the segment Z1CALENT## into the IDoc, as a child of Z1CALHDR##, using the following attributes for the segment:

Optional

Min. number: 1

Max. number: 10

D. Create a new Message type

WE30 à Environment à Message types

Define a new message type ZMES## (where ## is your number)

E. Link your Message type with your IDoc type

WE30 à Environment à IDoc type / message

Link Message type ZMES## with ZCAL##

F. Release your IDoc type

Check IDoc type

Release IDoc type

Check IDoc type again

Outbound Program Development

In implementing an outbound program we have to deal with two issues:

Designing the program logic

Defining a trigger mechanism for the program

The program logic defines how the data gets extracted from the application tables and how the IDoc is created. The trigger mechanism defines how the interface (and an ALE scenario is nothing else than a SAP-to-SAP interface) gets kicked off. We will first focus on program logic and then explore our options to trigger the outbound IDoc creation.

Overview of Outbound Program Logic

The fundamental logic of an outbound IDoc program is fairly simple. We can divide it into 4 steps:

Select the data from the application tables

Fill the data into the IDoc

Pass the IDoc to the ALE layer

Commit work

Compared to a traditional interface program the main difference is that the data is selected into the IDoc format and sent to the ALE layer as opposed to writing the data out to a flat file. The selection logic itself is the pretty much the same.

The entry point into the ALE layer is the function module MASTER_IDOC_DISTRIBUTE. All ALE functionality that was introduced earlier (Receiver determination, Segment filtering, Version Control, Dispatch Control) is buried in that function module. This functionality is totally transparent to a programmer -- all we need to do is call MASTER_IDOC_DISTRIBUTE with the appropriate parameters.

Querying the Distribution Model

The function module ALE_MODEL_DETERMINE_IF_TO_SEND takes a message type and an optional receiver name and returns an ‘X’ in the export parameter IDOC_MUST_BE_SENT if the model has the message and receiver modeled. If no receiver is specified in the function call, it returns ‘X’ if the message is modeled for any receiver. An ‘X’ return indicates that an IDoc must be created. If ‘ ‘ is returned, then you do not need to create an IDoc.

The function module ALE_MODEL_INFO_GET returns detailed information about a model for a given message type, including receivers modeled for the message type and any filter objects defined. A normal return indicates that an IDoc must be created. If an IDoc is not needed, the function will raise the exception NO_MODEL_INFO_FOUND.

Using these function modules can allow you to avoid creating IDocs when they are not needed, thus improving performance.

MASTER_IDOC_DISTRIBUTE

Let’s take a closer look at the function module MASTER_IDOC_DISTRIBUTE.

FUNCTION MASTER_IDOC_DISTRIBUTE

IMPORTING

VALUE(MASTER_IDOC_CONTROL) LIKE EDIDC STRUCTURE EDIDC

VALUE(OBJ_TYPE) LIKE SERIAL-OBJ_TYPE DEFAULT ''

VALUE(CHNUM) LIKE SERIAL-CHNUM DEFAULT ''

TABLES

COMMUNICATION_IDOC_CONTROL STRUCTURE EDIDC

MASTER_IDOC_DATA STRUCTURE EDIDD

EXCEPTIONS

ERROR_IN_IDOC_CONTROL

ERROR_WRITING_IDOC_STATUS

ERROR_IN_IDOC_DATA

SENDING_LOGICAL_SYSTEM_UNKNOWN

MASTER_IDOC_DISTRIBUTE accepts as an import parameter exactly one IDoc. That IDoc is passed in the two parameters MASTER_IDOC_CONTROL and MASTER_IDOC_DATA.

MASTER_IDOC_CONTROL is a one-dimensional data structure that holds the IDoc control record. We will soon see what information that needs to go into the control record.

MASTER_IDOC_DATA is an internal table that holds all the data records of the IDoc to be sent out. We will soon see what information needs to go into the data records.

COMMUNICATION_IDOC_CONTROL is an internal table that returns additional control record information of the IDoc that was created. The most important information passed back is the IDoc number. This data structure does not have to be filled before MASTER_IDOC_DISTRIBUTE is called.

Control Record Information

The Control Record has the structure EDIDC. The required fields are:

MESTYP -- The message type

IDOCTP -- The IDoc type

The optional fields are:

RCVPRN -- The logical system name of the receiver

RCVPRT -- The partner type of the receiver. ‘LS’ for logical system

Note that you have to use uppercase literals when you fill these fields.

Leave the other fields with their initial values.

The receiver information is optional. If you specify a receiver, the ALE layer checks the Distribution Model to see if the receiver is valid. If so, it creates an IDoc; otherwise it will not. If you don’t specify a receiver, the ALE layer will determine all valid receivers in the distribution model for that message type and create an IDoc for each receiver.

RCVPRN and RCVPRT must either both be filled or both be initial. If you fill one, fill both!

The ALE layer automatically fills the sender information -- along with additional information -- in function module MASTER_IDOC_DISTRIBUTE).

Careful: An outbound IDoc is only created if the distribution model is maintained!

Data Record Information

The IDoc data records contain the data of the message. The data records are passed in an internal table and they must match the structure of the IDoc (sequence of segments, min/max, hierarchy etc.).

EDIDD is a generic structure used for all IDoc segments. The required

fields are:

SEGNAM identifies the segment type

SDATA is a 1000-byte character field that contains the actual data of the segment

Leave the other fields with their initial values.

Filling an EDIDD Structure

Since the EDIDD structure is used for all different types of IDocs containing all different kinds of Segments, filling the EDIDD structure is a bit tricky.

First, fill the SEGNAM field with the Segment name.

Second, fill the 1000-byte SDATA field. This is a two-step process:

First, put the data into a structure of the segment type you want to fill.

Second, move the whole field string into the SDATA field.

The receiver of the IDoc needs to execute the reverse logic. It uses the SEGNAM information to parse out the SDATA field by moving SDATA into a structure that matches the layout of the segment type specified in the SEGNAM field.

Note that all segment types defined in ALE are stored as structures in the ABAP Data Dictionary. So you don’t need to manually declare the segment fields.

IDoc Data Rules

SAP does not use SAP-specific codes in IDocs. Instead they recommend the use of ISO codes. Therefore, there are some general rules that you should follow when writing the IDoc program:

Convert all currency amounts

Convert SAP codes into ISO codes. SAP codes that you need to convert are currency keys, country keys, units of measure and shipping instructions.

Left-justify the fields.

Note: These conversions are a relic from the EDI world. In an SAP-to-SAP scenario they don’t make sense, because the receiving program has to do the conversion back into the SAP codes! As long as the sender and receiver have the same assumptions about the codes, there is really no reason to do code conversions.

Currency and Code Conversions

SAP delivers a set of function modules to do code conversions:

Currency amounts: CURRENCY_AMOUNT_SAP_TO_IDOC

Currency keys: CURRENCY_CODE_SAP_TO_ISO

Country keys: COUNTRY_CODE_SAP_TO_ISO

Units of measure: UNIT_OF_MEASURE_SAP_TO_ISO

Shipping instructions: SAP_TO_ISO_PACKAGE_TYPE_CODE

Note: There is a similar set of function modules to do the conversion in the opposite directions (from ISO to SAP), which you use on the receiving side to convert the data back to SAP format.

Left-Justified Filling

All fields in an IDoc have a data type of ‘CHAR’. SAP chose that approach to ensure independency of any internal binary representations. But it means that you must left-justify all IDoc fields.

ABAP automatically converts different data types into each other. However, this automatic conversion doesn’t produce the desired left-justification for all data types.

In the data dictionary, look at the IDoc type documentation. This is a structure named the same as the IDoc segment type, with ‘E1’ replaced with ‘E3’. For example, the documentation for the segment type E1MARAM is E3MARAM. The documentation structure shows the data type for each field.

Automatic left-justification works for data types ACCP, CHAR, CLNT,

CUKY, DATS, NUMC, TIMS, and UNIT. You must left-justify all other data types manually.

The easiest way to left-justify the fields is to use the CONDENSE statement.

Note: If a field needs conversion and left-justification, convert first, then

left-justify.

Triggering IDoc Creation

So far we have only looked at the necessary steps involved to create an IDoc. We wrote a sample stand-alone program that, when executed, created an IDoc. However, this is only one way to create an IDoc. In a real-world environment this approach might not fulfill the functional requirements.

Now, we take a closer look at the mechanisms SAP uses to trigger the IDoc creation process and we talk about their use when creating custom ALE scenarios.

Triggering Options

SAP uses different approaches to trigger IDocs. To understand these approaches better, we have to understand SAP’s underlying design assumptions.

For transaction data, SAP requires that an IDoc be posted within the same logical unit of work (LUW) as the application document. This ensures transactional integrity. The application document and the IDoc together make up the transaction, with the application document representing the piece that is being executed in the originating system, and the IDoc representing the piece that is being executed in the receiving system. Non-creation or double-creation of IDocs leads to an inconsistent state.

This is accomplished by either hardcoding the call to the ALE layer in the posting routine (in the same LUW) or by using Message Control. Message Control is called as part of the posting routine and therefore is executed within the same LUW.

For master data, there is no such thing as transactional integrity. Master data can be sent multiple times to a receiving system without affecting data integrity. It is also possible to simply send changes. Typically, master data propagation is less time-critical than transaction data. Therefore SAP doesn’t create IDocs immediately when master data is changed or created.

A master data send program is a “stand-alone” program that selects all the master data information and creates an IDoc. This program can decide which records to send by reading change pointers, or by other criteria.

Hardcoded ALE-Layer Call

We usually use a hardcoded ALE layer call technique for transaction data in areas where output determination is not supported. It simply means that the logic to create an IDoc is hardcoded within the actual transaction that generates the application document.

Let’s give an example: In an FI posting transaction -- right after the FI document has been created -- there is code that checks the ALE distribution model to determine if the data in that newly created FI document has to be distributed. If so, the program transfers the FI document data into an IDoc and calls the function module MASTER_IDOC_DISTRIBUTE to create the IDoc.

This option is pretty inflexible as far as creating new scenarios goes. If we want to embed our call to MASTER_IDOC_DISTRIBUTE then we can only do it if we have a user-exit available. The user-exit has to be in the update module after the application document has been created and has to give us full access to the application document data. We are lucky if all these requirements are fulfilled.

Message Control

Message Control, also called Output Determination, is a functional configuration that determines what to do with an application document after creating it.

Unfortunately there is not enough time to show all the details of creating IDoc programs based on Message Control. The following lists the highlights and the main differences as well as necessary configuration.

You must implement the IDoc creation program as a function module, with the interface that the Message Control layer expects. The naming convention for the function module is IDOC_OUTPUT_ Process code, inbound option.

Click New entries

Enter your logical message and your process code and save.

Make sure you have distributed your distribution model, and generated the Partner Profiles on your Warehouse system.

D. Send data

Run your outbound program on your Sales system. This puts the data into an IDoc and sends it to your Warehouse system.

On your Warehouse system, use the IDoc overview transaction to check that your IDoc has arrived.

If the IDoc has been processed successfully, look at tables ZCALHDR and ZCALENT to see your entries. You can also use transaction ZCALP to list the calibration entries in the tables.

Use this Checklist (with WE05 and SE16 on your Warehouse system) to see if your inbound function module is correct:

IDoc has a single parent segment E1CALHDR##

IDoc has segments E1CALENT## as children of E1CALHDR##

IDoc status is 53 (Application document posted)

IDoc has only one status record 53

The status message (if you created one) is correct

Data is added to tables ZCALHDR and ZCALENT properly

The fields SERIAL and DATUM are filled in the detail table (ZCALENT)

"EXTRA CREDIT"

If you have additional time, code your function module to process more than one IDoc.

Code the function module to handle more than one IDoc in the control record and data record tables.

Change the sending partner profile to send IDocs in "batch", i.e. Collect IDocs.

Change your function module attributes to "Mass Processing".

Run your outbound program several times to create several IDocs (or modify it to create several IDocs by itself)

Run the program RSEOUT00 (on your Sales system) to send your IDocs and see if they are correctly processed.

Appendix

IDoc Status Codes – Outbound

00 Not used, only R/2

01 IDoc created

02 Error passing data to port

03 Data passed to port OK

04 Error within control information of EDI subsystem

05 Error during translation

06 Translation OK

07 Error during syntax check

08 Syntax check OK

09 Error during interchange handling

10 Interchange handling OK

11 Error during dispatch

12 Dispatch OK

13 Retransmission OK

14 Interchange Acknowledgement positive

15 Interchange Acknowledgement negative

16 Functional Acknowledgement positive

17 Functional Acknowledgement negative

18 Triggering EDI subsystem OK

19 Data transfer for test OK

20 Error triggering EDI subsystem

21 Error passing data for test

22 Dispatch OK, acknowledgement still due

23 Error during retransmission

24 Control information of EDI subsystem OK

25 Processing despite syntax error (outbound)

26 Error during syntax check of IDoc (outbound)

27 Error in dispatch level (ALE service)

28 Not used

29 Error in ALE service

30 IDoc ready for dispatch (ALE service)

31 Error - no further processing

32 IDoc was edited

33 Original of an IDoc which was edited

34 Error in control record of IDoc

35 IDoc reloaded from archive

36 Electronic signature not performed (timeout)

37 IDoc added incorrectly

38 IDoc archived

39 IDoc is in the receiving system (ALE service)

40 Application document not created in receiving system

41 Application document created in receiving system

42 IDoc was created by test transaction

IDoc Status Codes – Inbound

50 IDoc added

51 Error: Application document not posted

52 Application document not fully posted

53 Application document posted

54 Error during formal application check

55 Formal application check OK

56 IDoc with errors added

57 Test IDoc: Error during application check

58 IDoc-Copy from an R/2 connection

59 Not used

60 Error during syntax check of IDoc (inbound)

61 Processing despite syntax error (inbound)

62 IDoc passed to application

63 Error passing IDoc to application

64 IDoc ready to be passed to application

65 Error in ALE service

66 IDoc is waiting for predecessor IDoc (serialization)

67 Not used

68 Error - no further processing

69 IDoc was edited

70 Original of an IDoc which was edited

71 IDoc reloaded from archive

72 Not used, only R/2

73 IDoc archived

74 IDoc was created by test transaction

Other Useful Transactions

This section describes some useful transactions not covered elsewhere in the course.

IDoc Statistics

Transaction: WE07

Menu Path: Tools à Business Communication à IDoc à IDoc Basis à IDoc à IDoc Statistics

Description: Summarizes all of the IDocs on the system for a specified date range, according to their status codes.

IDoc Segment Documentation

Transaction: WE62

Menu Path: Tools à Business Communication à IDoc à IDoc Basis à Documentation à IDoc Segments

Description: Similar to WE60, but gives information about single segments, whether or not they are part of an IDoc type.

Process Code Summary

Transaction: WE64

Menu Path: Tools à Business Communication à IDoc à IDoc Basis à IDoc à Process Codes

Description: Provides information about process codes, sorted by message type.

IDoc Search Utility

Transaction: WE09

Menu Path: Tools à Business Communication à IDoc à IDoc Basis à IDoc à Find IDoc à In Database

Description: Searches the database for IDocs that meet specified search criteria and displays the IDocs found.

Hope this will resolve your query.

Reward all the helpful answers.

Regards

[Former Member]

Hi Pavan,

Go through the following link.

/people/kevin.wilson2/blog/2006/11/13/ale-scenario-development-guide

I tried to copy it and paste it here for your convenience but some diagrams are not getting pasted here so i'm providing you with the link. Hope it will help you. Please reward points accordingly.

Regards,

Ravi