ALE Training

PricewaterhouseCoopers LLP
SAP ALE Training Program
PwC Consulting SAP ALE Training Program SAP Release 4.6C

Summary Table Of Contents
Chapter 1 ALE Overview 1 Chapter 2 Introduction to IDocs 11 Chapter 3 Modeling ALE Distribution 25 Chapter 4 Communication Parameters Chapter 5 ALE Architecture Chapter 6 Data Distribution Methods Chapter 7 ALE Monitoring Chapter 8 Error Handling Chapter 9 Using ALE for Interfaces Chapter 10 IDoc Processing Features Chapter 11 ALE Performance Chapter 12 IDoc Reduction Chapter 13 IDoc Extension Chapter 14 IDoc Creation Chapter 15 IDoc Processing
This is PricewaterhouseCoopers PROPRIETARY MATERIAL
1 1.1.1
Chapter 1 ALE Overview Review of SAP System Terminology
From a System Infrastructure view, an SAP system consists of three layers: The Database Layer stores and retrieves all data. The database contains all of the data related to the SAP system, including the ABAP programs, the configuration data, the master data, and the transaction data. The Application Layer executes the SAP programs and processes requests from users. The Presentation Layer contains the SAP Graphical User Interface (GUI), and handles all user input and output. Together, the three layers make up the three-tiered client-server architecture of SAP. We can distribute the three layers over any number of physical computers. However, there may only be one database server. From a Database or Configuration view, the SAP system consists of: Client-Independent data, such as ABAP programs, client-independent tables, etc. One or more Clients. Each client contains its own client-dependent configuration (company hierarchy, process configurations, etc.), master data (customer, material, vendor, etc.), and transaction data.
1.1.2
Logical Systems We define all communication in ALE as links between logical systems. A logical system is a system containing applications that are coordinated to work with one set of data. A logical system can be: A specific client on a specific SAP system A non-SAP system A file-based interface Since logical systems are the basis of all ALE configurations, the ability to define them should be restricted to as few people as possible.
1.1.3
What is ALE? Application Link Enabling (ALE) is the set of tools, programs, and data definitions that provides the mechanism for distributing SAP functionality and data across multiple systems. ALE enables the construction and operation of distributed applications. The Basic Ideas of ALE
1.1.3.1
ALE is a technology introduced by SAP with its 3.0 release. Its purpose was to overcome the limitations of a single SAP system. A single SAP system that runs on top of one database often does not fulfill the needs of larger corporations, either from a business or a technical perspective. ALE allows the implementation of loosely coupled SAP systems; each of the SAP systems has its own database and is essentially independent from the other systems. ALE allows us to distribute data between different systems and different business processes. The distribution of data happens at the application server level (Hence, Application Link Enabling). SAP supports a number of distribution scenarios, which define how different SAP systems can interact. The scenarios define what messages are sent back and forth between the systems (for example, Contract information needs to be exchanged between systems that run central purchasing and systems that run decentral purchasing). The data container that carries the message is the Intermediate Document, or IDoc. SAP delivers over 100 IDoc types to support its distribution scenarios; along with the IDocs come the associated programs to generate (on the outbound side) or to process (on the inbound side) IDocs. Part of ALE is a communication infrastructure; specifically ALE uses the transactional RFC technology to ensure the transaction consistency across system boundaries. ALE also ties into SAP workflow to handle errors in the data transfer process
1.1.4
Why use ALE? ALE provides for the integration of distributed applications, but why would we distribute applications in the first place? There are several technical and business reasons: System Performance: The transaction load is too heavy for a single SAP system. High Availability Requirements: The company cannot afford downtime due to backups, maintenance, upgrades, etc. SAP Release Coordination: Different units of the organization may require different releases of the SAP software. Very Large Database: Companies with very large databases may need to distribute the data across multiple SAP systems. Business Structure: Business units may require independence and autonomy for day-to-day operations, and yet still need to share some data and functionality with other units in the enterprise. Interfacing with non-SAP systems: The company may wish to maintain certain applications on non-SAP systems, while at the same time integrate these applications and their data with the SAP system. Keep development system data in sync with production data: An organization may wish to keep the data on a development system the same as on a production system. Maintain configuration and master data across clients: Organizations using multiple clients may wish to maintain certain data on a client-independent basis.
1.1.5
What can we distribute with ALE? We can distribute all types of data with ALE: Control or Customizing Data: Control data includes all configuration objects that define how the SAP system is organized. This includes the enterprise structure configurations, global settings, etc. Master Data: Master data objects that can ALE can distribute include: o Material Master o Customer Master o Vendor Master o Cost Centers o Activity Types o G/L Accounts o Characteristics/Classes/Classifications o and many others Transaction Data: Transaction data is data related to specific business transactions or processes (e.g. sales orders, credit memos, invoices). SAP delivers several hundred predefined distribution scenarios. If a standard solution is not provided, then we can develop a custom scenario to distribute any data required by the business. The number of supported business scenarios increases with each SAP release. Example distribution scenario: Sales and Distribution
1.1.5.1
The sales system provides only the logistics data that the warehouse requires to fill an order. Summary information is reported into the central sales information system. All of the data sent references a single order document.
1.1.5.2
Example distribution scenario: Blanket Purchasing
The central purchasing system sends the local purchasing system the data required to carry out an individual transaction. Summary release statistics are reported to the central purchasing information system. As with SD scenarios, there is a single document reference.
1.1.6
What is EDI?
Electronic Data Interchange (EDI) is an industry standard for data exchange between business partners (customers, vendors, etc.). This is the distinction between EDI and ALE: ALE is primarily for data exchange between systems within the same organization, where EDI is primarily for data exchange between companies. SAP uses the ALE services to implement EDI functions from within the R/3 system. Conceptually, EDI functionality is layered on top of ALE functionality.
1.1.7
ALE Components SAP provides ALE services for distributing applications, and the tools to tailor these services to the organizations specific requirements. The three ALE services form a layered architecture, where each layer depends on the layers below it. The ALE Services are: Application Services: This is where the SAP applications (SD, FI, MM, etc.) generate their data and documents. This is not specific to ALE, but is part of the standard processing in SAP (i.e.. posting an invoice). Existing SAP programs are ALE-enabled to allow them to work with ALE. Distribution (or ALE) Services: This is where the distribution of the data and documents occurs. This layer determines the recipients, formats and filters the data, and creates the ALE Intermediate Documents (IDocs). Communication Services: This layer provides the vehicle for actually moving the data and documents (the ALE IDoc) from one logical system to another. This layer employs communication techniques such as X.400/X.500, TCP/IP, EDI, Asynchronous RFC, etc. SAP also provides a set of tools for configuring and customizing the ALE implementation: Customizing Tools: The customizing tools provided by SAP define what is to be distributed, and how the distribution is to occur. These tools include the following. o Model Maintenance Tool: A tool used for configuring the flow of data between systems o Shared Master Data (SMD) Tools: Tools within SAP used for distributing master data o Customization parameters within SAP for IDoc filtering and conversion Development Tools: Tools for creating and modifying IDocs. These tools allow for the maintenance of IDoc types, as well as the individual segments that make up the IDocs.
1.1.8
The Future of ALE ALE (meant as IDocs and associated function modules for extract and update) is so completely embedded in all SAP offerings that eliminating it would be difficult. In particular: Most mySAP.com components use ALE SAP is still facing major scalability issues in terms of putting tens of thousands of users on one database. Therefore ALE remains the closest thing they can offer to a distributed processing environment. Many clients are using ALE, so the absence of ALE support would cause problems ALE is important to many processes within the R/3 system Most third party complementary software uses IDocs as the main means of communication In the future, SAP will continue providing more standard scenarios and enhance the customizing and development features.
2 2.1.1
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 SAPs data repository. Codes for coded fields are taken from international standards where the standard applies.
2.1.2
IDoc Types and Message Types
We need to make a distinction between an IDoc and an IDoc type: An IDoc type is the definition of a specific data structure. An IDoc is an actual instance of data based on an IDoc type. Therefore, there can be many IDocs created from a single IDoc type. The structure of IDoc types is very similar to the structure of EDI messages. In fact, SAP loosely based its IDoc structures on the EDIFACT standards. We also need to distinguish between an IDoc type and a message type: An IDoc type specifies the structure of the data. A message type specifies the meaning of the data. An IDoc type can support multiple message types. For example, the IDoc type ORDERS01 supports purchase orders, change orders, quotes, and confirmations, each using a different message type. A given message type may not use all of the data defined in an IDoc type. The IDoc structure does not change with direction. That is, the structure is exactly the same for inbound and outbound IDocs.
2.1.3
IDoc Structure
An IDoc consists of three record types: Control Record: Contains the data that uniquely identifies the IDoc. Data Records: Contain the application data related to the message type. An IDoc may have multiple data records, called segments. A data segment is made up of a key section and a data section. The key section uniquely identifies its respective data segment. Status Records: Contain the information relative to the various statuses that the IDoc encounters, such as IDoc created, document posted, etc. The IDoc is data stored in a structured format. It is a medium for data transfer. An IDoc is not a process nor executable code. SAP originally developed IDocs for EDI, and then adopted the IDoc concept and structure for its ALE interface.
2.1.4
The IDoc Control Record The Control Record stores the characteristics of the IDoc. Some of the more important fields are: IDoc ID Number (DOCNUM) IDoc type (DOCTYP) Direction (In or Out) (DIRECT) Name of Sender (SNDPRN) Name of Receiver (RCVPRN) Processing Status (STATUS) EDI Message Type (if EDI) (STDMES) Control Records are stored in the R/3 transparent table EDIDC, keyed by IDoc ID number. This ID number is assigned by SAP for all IDocs.
2.1.5
The IDoc Data Records The Data Records contain the actual application data. Some of the more important fields are: 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
2.1.6
Information that relates to the object as a whole is stored in the main segment. Hierarchical information is stored in separate segments. Each segment typically corresponds to a different database table. Attributes of a segment: The fields of the segment. Each field is assigned a length and a data element from the ABAP dictionary. Whether the segment is required or optional in a valid IDoc. The minimum and maximum number of instances of the segment.
2.1.6.1
Example Material Master
2.1.6.2
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).
2.1.7
IDoc Status Record The status records are stored in table EDIDS, keyed by IDoc ID Number and date/time. Some of the more important fields are: IDoc ID Number (DOCNUM) IDoc Status (STATUS) Date/Time Status was generated (CREDAT, CRETIM) Status Text (STATXT) The STATUS field is: 1 - 49 for Outbound Messages 50 - 99 for Inbound Messages The possible values for the status are stored in table TEDS2. A list is in the Appendix. As the IDoc undergoes processing (both in and out), a status record is added to it at each step.
2.1.8
IDoc Structure Utility To view the structure of a specific IDoc, use the IDoc Structure Utility. Enter the IDoc type and execute. You can expand each segment to look at its child segments or its data fields. Transaction: WE60 Menu Path: Tools IDoc types Business Communication IDoc IDoc Basis Documentation
2.1.9
Maximized vs. Reduced IDocs A maximized IDoc contains all the data available in the master data record. This IDoc contains all the fields available whether those input fields are needed by the distributed systems or not. In the SAP-standard delivered maximized IDoc, not all the fields are activated. The user needs to go into the message type to activate all the fields for transfer. Reduced IDocs are maximized IDocs that have been modified to only include the data that is valuable to the distributed systems. The reduction excludes those fields that the distributed system does not need and therefore makes the IDoc easier to use. Reducing an IDoc does not reduce network traffic. The entire maximized IDoc is still sent to the partner system, we just cant see it all. Reduced IDocs are created for a specific message type. This has two implications: A reduced IDoc can be created for multiple distributed systems or specifically for one distributed system, but either way, the reduced IDoc type becomes a new IDoc type and must be treated as such. In other words, the maximized and reduced IDoc types are not interchangeable. Reduced IDocs cannot be used with many third-party mapping tools, such as Mercator.
2.1.10
Viewing IDocs on the System Transaction: WE05 Menu Path: Tools 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. 2.1 Exercise: IDoc Structure This exercise will give you practice in reading and understanding the structure of an IDoc. Run the IDoc Structure Utility (WE60). Answer the following questions. What are the required segments in the IDoc type MATMAS02 (Material Master)?
In IDoc type DEBMAS01 (Customer Master), what is the parent segment of segment E1KNVPM? List the data fields of segment E1WYTTM in IDoc type CREMAS01 (Vendor Master)?
What data element is assigned to field NTGEW of segment E1EDP09 in IDoc type DESADV01 (Shipping Notification)? What is the maximum number of Document Header Partner Information Additional Data segments in a Purchasing/Sales IDoc (type ORDERS02)? In an ORDERS02 IDoc, what does the field DATUM represent in segment E1EDK03 if the value of the field IDDAT is 010?
3 3.1.1
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.
3.1.2
Model Views
3.1.3
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.
3.1.4
Model Ownership Each model view is owned by one logical system We maintain the model on its owner logical system, and then distribute the model view to all of the other systems. ALE provides the distribute function to send a model view to the other logical systems. The other systems then have display-only access to the model.
3.1.5
Defining Logical Systems Transaction: BD54 Menu Path: SALE 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.
3.1.6
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 dont need to allocate every logical system to a client.
3.1.7
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.
3.1.8
Filter Objects You can use a filter object to limit the content of a message in the model. For example, you can configure a Customer message to be sent only if the company code is equal to 0001.[1] Multiple filter objects are linked with an OR if they are the same object, AND otherwise. For example, if you define the following filter objects: Plant 001 Plant 002 Division 01 Division 02 The resulting filter will be (Plant 001 OR Plant 002) AND (Division 01 OR Division 02).
[1]
Note: A filter object actually filters out IDoc segments, not entire IDocs. Here is how it works, for those interested: Each segment of the IDoc containing a field of the specified object type with a value different than any filter value is deleted from the IDoc, along with its child segments, if it has any. If the deleted segment is mandatory in the IDoc, then its parent segment is also deleted. If the highestlevel segment is deleted, than the entire IDoc is not sent.
To define a filter object: Navigate to the model view/message type that you want to filter, and expand the tree to show filter groups. Double click on "No filter set", (or "Data filter active", if one exists). Click on Create filter group Select the field that you want to use in the filter. Enter the value to filter by. Save the model. 3.2 Exercise: Model Maintenance In this exercise you will create a new distribution model view and assign a message flow between two SAP systems. Goal: On the system designated as your "Sales system set up the customer model MODEL## (where ## is the last two digits of your SAP logon ID) with the message MATMAS sent to the system designated as your "Warehouse system. Caution: Only one person at a time can perform shaded steps. Please work quickly so that others will not be locked out for too long! A. Define a logical system Define the logical systems that you will use: 1. Log into your Sales system. You will define communication parameters between this system and your Warehouse system. Execute the ALE configuration IMG with transaction code SALE. 2. Create a logical system name for your Sales system. a. b. c. d. Execute BD54. Click New Entries. Enter your Sales system's logical system name and a short description. Click Save.
3. Create a logical system name for your Warehouse system using the same process. 4. Log into your Warehouse system, and repeat the creation of the logical system names. Notes: 1. The logical system table is client-independent. This means that if your Sales and Warehouse systems are different clients on the same physical system, you only need to create the logical system names once. 2. Since class participants are sharing senders and receivers, one or both of your logical system names may already exist. If so, just verify that they exist and move on.
B. Allocate logical systems to clients Each client on a system must have a logical system name, so that it will know what modeled messages apply to it. 1. From your Sales system, execute SCC4. 2. Double click on the client assigned as your Sales system. 3. Enter the sender's logical system name in the Logical system field and save. 4. Repeat this process for your Warehouse system. Note: Since participants are sharing Sales and Warehouse systems, one or both of your logical systems may already be allocated. If so, just verify that they are correct and move on. C. Maintain the Communications Model The customer distribution model defines what messages are permitted between the systems. You will model a material message flow. The message type you will use is MATMAS. 1. Log into your Sales system. This system will "own" your model view, and you should perform ALL model maintenance on this system. 2. Execute BD64 3. Click on Switch between display and edit mode to go into edit mode. 4. Click on Create Model view to create a new model view. Enter the model name (MODEL##) and a description and save. 5. Add a message type under your model view. Enter your Sales system as the sender, your Warehouse system as the receiver, and the message type (MATMAS), and save. 6. MATMAS now appears in the model hierarchy as a supported message to send to your Warehouse system. Click on Save to save the model. D. Add a filter object. Add the following filter constraints to your model: Plant: 2000 or 4000 Division: 01 1. Go to Model maintenance on your Sales system 2. Position the cursor on the MATMAS message flow you defined earlier, and double click on "No filter set". 3. Select Create filter group. Expand the values and double click on Plant. 4. Enter 2000 as the Object value, and save. 5. Repeat this procedure to add the other two filter objects. 6. Using the menu path Edit future exercises Delete, delete your filter group, since it will interfere with
Chapter 1 IDoc Processing Features

There are a number of processing features in ALE that permit you to further refine what information is sent to what logical systems in the ALE constellation. These features include: Filtering out segments of an IDoc that shouldnt be sent to a particular logical system Converting the values or formats of certain fields in the IDoc Using classes to freely define which master data records are sent to which logical system
4.1.1 Segment Filtering
Segment filtering prevents pre-defined segments of an IDoc from being sent to a particular receiving system. The filtering is dependent on the message type and the receiver. This prevents unnecessary data from being sent to a system that does not need that data. In general, it is more efficient to perform filtering on the outbound side, thus reducing unnecessary network traffic. However, SAP also provides segment-filtering capabilities on the inbound side. For example, material master records may be maintained centrally at headquarters. This information must be distributed to all manufacturing facilities, but those facilities may not be interested in the accounting view of materials. In that case, the accounting view may be filtered out when the IDoc is sent to the manufacturing facility. Other distributed systems that are interested in the accounting view may still receive that view. To use filtering, you must first determine which functional information is required on each system. Then you must identify the appropriate segments to filter out.
Transaction: BD56 Menu Path: SALE Master Data DistributionModeling and Implementing Business Processes Filter IDoc Segments Scope of Data for Distribution
In transaction BD56, enter the appropriate message type. Then click on New Entries, and enter the sending system, the receiving system, and the segment to filter out. The system types will be LS for logical system. You can add multiple entries for the same sending and receiving systems to filter out multiple segments. Note: Although the menu path for this program goes through "Master Data Distribution", filtering will work for any message type, not just those for master data. Note: If you filter out a segment, you must ensure that the segment's child segments are also filtered out.
4.1.2 Field Conversions
In some cases, we may need to convert the values that belong to certain fields when sending data between systems. For example, material master type codes for material type may be different on a legacy system than they are in SAP. A material type of ROH (for raw material) in SAP may correspond to a numeric code (such as 01) in the legacy system. ALE has the ability to convert field values when sending data between systems. We can use this capability instead of external translation programs. We can convert data on either the inbound or the outbound side (or both). We specify conversion rules at the field level, along with selection criteria that govern when the rule will take effect (for example, set the moving average price equal to the standard price only if the moving average field is blank). Here are the steps for defining a field conversion: Step 1: Define the rule.
Transaction: BD62 Menu Path: SALE Converting Data Between Sender andModeling and Implementing Business Processes Receiver Define Rules for IDoc Segment Names
o o
Click on Change. Enter the information onto a blank line: Name of the rule Description Segment that the rule applies to
Save your entries
Step 2: Maintain the rule.
Transaction: BD79
Menu Path: SALE Converting Data Between Sender andModeling and Implementing Business Processes Receiver Maintain Rules
Enter the rule name and click on Change.
o o
Double-click on a field you want to convert. Enter the conversion rule and save. There are several possible rules you can use: Copy a field unchanged. Convert a field in some way. Set the field to a constant. Set the field to the value of a system variable.
Step 3: Assign the rule to a message flow.
Transaction: BD55
Menu Path: SALE Converting Data Between Sender andModeling and Implementing Business Processes Receiver Assign Rule to Message Type
Enter the message type and enter.
Click on New entries and enter the information: Sending system (type is LS) Receiving system Segment to apply the rule on Name of the rule
Save your entries.
4.1.3 Distributing Master Data with Classes
If standard filter objects are not sufficient to specify how to distribute master records to the various ALE systems, SAP permits you to create freely definable classes of master data records to be distributed together. You implement classes using the standard classification functionality of SAP. We only have time here for a quick overview. You can use classes only with customers, vendors, and materials. You can distribute your classes as master data using ALE or by CTS. You must send the class to each individual system that will use it. Note: Classes were called Lists in previous versions. Also, the meaning of the word "class" here is different from the meaning in ABAP Objects programming. Directions for setting up distribution with classes:
Transaction: CL02 Menu Path: Logistics Central Functions Classification Master Data Classes
Transaction CL02 will maintain classes. You must specify the class name and the type. You select the type from the class type hierarchy. You must use a classification type that is configured for use with ALE. These types are usually called ALM(material), ALV (vendor), etc.
Transaction: CL24N Menu Path: Logistics Central Functions Classification Assignment Assign Objects/Classes to Class
Transaction CL24N lets you assign objects to your class. To send all of the members of one or more classes, specify the names of the classes in the BD10 Listing field. This procedure will not send the actual classification information, unless you check the Send material in full checkbox. If you do this, make sure that you send the actual classes to the other systems first (or at the same time, using serialized messages).
4.1.4 Controlling Distribution Using Classes
Transaction: BD68 Menu Path: SALE Modeling and Implementing Business Processes Assign Classes to Receiving Logical System Master Data Distribution
Distribution Using Object Classes
You can limit master data distribution between two logical systems to members of a certain class. This requires two steps: Transaction BD68. This tells the ALE system what classes you want to enable distribution for, for a given logical system and message type. Add a filter object to the distribution model for the proper systems and messages, selecting Distribution via classes. Thats it! Now if you try to send a master data record not in the specified class, the ALE layer will not create a communication IDoc.
4.1.5 4.1.5.1 Serialization IDoc Level
For some IDoc types it might be a problem if one IDoc is overtaken by another IDoc, because later updates would be overwritten by earlier ones. Since this is dependent on the IDoc type this serialization function is not built into the ALE layer. It must be coded within the application function module. Well discuss this more in the IDoc programming part of the course.
4.1.5.2 Message Level
Sometimes, two message types are interrelated, and must be processed in the right order. Examples: Material Master and Classification Master. o If we create a material, classify it, and want to send it to another system with the classification information, we must use two message types: MATMAS and CLFMAS. But the receiving system cannot process the CLFMAS message until it adds the material from the MATMAS message! Purchase Orders o If we send a purchase order (ORDERS) with a new vendor (CREMAS) or a new material (MATMAS), we need to send the vendor or material along with the PO. The receiving system then needs to process the vendor and the material before the purchase order. Beginning with R/3 release 4.0, SAP provides functionality to ensure the correct processing order of messages. These are the steps you must follow to use the serialization functions: Create the serialization group and assign message types to it. Maintain the proper message flow configuration in the distribution model and the partner profiles. Schedule the programs to perform the distribution.
4.1.6 Configuring Message Serialization
First, we define a serialization group. By defining a serialization group, we can specify that certain message types must be processed in a predetermined order.
Transaction: BD44 Menu Path: SALE Modeling and Implementing Business Processes Master Data Distribution Receiving Data Serialization Using Message Types Define Serialization Groups Serialization for Sending and
Note: Although the menu paths for the Serialization programs go through "Master Data Distribution", serialization will work for any message type, not just those for master data. There are two steps in defining a serialization group: Create the serialization group. o o Click on New entries, enter your groups name and a description, and save. Assign message types to the serialization group: Click the selection button next to your group, and then double-click on "Assignment of logical messages to serial. group". o Click on New entries, and add a line for each message type you want in the group. Indicate the proper processing order by setting the sequence number for each message. o Save.
You must create the serialization group on both the sending and receiving systems.
4.1.6.1 Distribution Model and Partner Profile Configuration
To use the serialization functions, you need to configure a message type SERDAT in addition to the master data message types. You must also configure the message flows in the model and partner profiles correctly: Outbound: o o Inbound: o o Master data messages: Processing type Background, no override with express flag. SERDAT message: Processing type Immediate processing. Master data messages: Collect IDocs. SERDAT message: Transfer immediately.
Finally, you must define the settings for inbound processing:
Transaction: BD44 Menu Path: SALE Modeling and Implementing Business Processes Master Data Distribution Receiving Data Serialization Using Message Types Define Inbound Processing
Serialization for Sending and
Click on New entries, and enter the information: Your serialization group name The message types in the group The sending logical system name The packet size (number of IDocs) transferred to the application at a time. Whether parallel processing is permitted The server group to use. Well discuss parallel processing and server groups in the Performance chapter.
4.1.6.2 Scheduling ABAP Programs
To use the serialization features, you must schedule the following two programs to run at appropriate times: RBDSER01 o This program does the same thing as RBDMIDOC: it reads the system change pointers and creates IDocs for any master data records that have changed (or been added). It differs from RBDMIDOC in that it only creates IDocs for master data messages that are members of a specified serialization group. RBDSER02 o This program does two things: It sends the IDocs created by RBDSER01. It schedules program RBDSER03 at a time interval you specify in the selection screen. The program RBDSER03 uses the program RBDMOIND (discussed in the next chapter) to check for successful IDoc dispatch for all IDocs sent by RBDSER02. If all IDocs were successfully sent, then it sends a message of type SERDAT to start the inbound processing. The receiving side then processes the SERDAT message, which triggers the processing of the other messages in the correct order.
4.2
Exercise: Filtering Out an IDoc Segment

Remember: Only one person at a time can perform shaded steps! 1. 2. 3. For IDoc type MATMAS03, find the segment that contains material valuation data. Using BD56, filter out the material valuation data segment for message type MATMAS for your Sales and Warehouse systems. On your Sales system, create a new material master record (transaction MM01). a. b. c. 4. Use Material group and Industry sector as specified in the guide handed out in class. Select the Basic Data 1 and the Accounting 1 views. Specify 0001 as the plant.
Use BD10 to send your material master record to your Warehouse system. (Note: If you have not fully configured MATMAS message flow between your systems, you will have to complete that configuration (Model, RFC destination, port, and partner profiles) before you can complete this step.) Check the IDoc overview to examine the data records for your IDoc to see if the material valuation segment was filtered out. Log in to your Warehouse system to see if your material came through and if the valuation data was filtered out.
5. 6.
4.3
Exercise: Converting a Field Value

Only one person at a time can perform shaded steps. The Material Master table has a field (in the Basic Data view) called Drawing Document. Determine the segment and field used for the Drawing Document in IDoc type MATMAS03. Define a conversion rule RULE## for MATMAS for sending materials from your Sales system to your Warehouse system. Configure your rule to effect the following conversions: a. b. c. If the drawing document number is between 255 and 300, change it to 37. If the drawing document number is equal to 254, change it to 129. Leave any other drawing document number unchanged.
Activate IDoc conversion for MATMAS when sending from your Sales system to your Warehouse system. Create and send enough materials to test your conversion rules thoroughly.
4.4
Exercise: Distribution Using Classes

Only one person at a time can perform shaded steps.
A. Create and use a class to send material master data.

1. 2. 3. Create a class CLASS## for material master data. Use the class type predefined for ALE. Add at least two materials to your class. Send the materials from your Sales system to your Warehouse system using your class.
PricewaterhouseCoopers LLP 4. Check that the correct materials were sent.
B. Restrict material master distribution to members of your class.

5. 6. 7. Add Distribution via Classes as a filter object to your distribution model. On your Sales system, assign your class when sending to your Warehouse system. Try to send a range of materials, some in your class and some not, and verify that only the materials in your class are sent.
Chapter 2 ALE Performance

The performance of an ALE implementation depends on many factors: Programs Hardware Database Application Data volume Message type Size of the IDoc Usually if there is a performance bottleneck, it is in the processing of inbound IDocs. This generally takes much longer than creating the outbound IDoc. Here are some sample performance statistics (measured on a PwC project) to give an idea of the time required. Remember that actual performance depends on all of the factors above, so your performance may be very different. Outbound Processing
(IDocs / second)
Inbound Receiving
(IDocs / second)
Inbound Posting
(IDocs / second)
10
<1
This chapter makes some suggestions for improving and controlling the performance of ALE IDoc processing, on both the outbound and inbound systems.
5.1.1 5.1.1.1 Timing of IDoc Processing IDoc creation We cant control the timing of transaction data.
Use change pointers to keep track of master data that needs to be sent. Schedule the master data send at a time when system load is low. 5.1.1.2 Transfer to Communication Layer For master data, specify Collect IDocs in the partner profiles, then schedule program RSEOUT00 to send the IDocs at an appropriate time. You can do the same thing with any transaction data that does not need to be sent immediately. 5.1.1.3 Inbound IDoc Processing Specify Background processing in the partner profiles, then schedule program RBDAPP01 to process the inbound IDocs at a slower time.
5.1.2 Processing IDocs in Parallel
Transaction: RZ12 Menu Path: SM59 RFC RFC Groups
5.1.2.1
Creating IDocs If you have more than one application server available, you can process IDocs in parallel. To do this, you need to define a server group, using transaction RZ12. Parallel creation only works for manual master data send, which uses all available dialog processes. The program RBDMIDOC cannot handle parallel execution, and runs in a single dialog process. There is no reason to create transaction data IDocs in parallel, since transactions are single events.
5.1.2.2
Sending The sending of IDocs with tRFC communication automatically uses all available dialog processes.
5.1.2.3
Processing IDocs grouped into a packet are processed in one dialog process. IDocs not in packets will use all available dialog processes. When processing IDocs in the background, you can specify a server group for parallel processing. If you select Parallel posting in the RBDAPP01 program, the IDoc processing will use a separate dialog process for each IDoc packet. If you do not, the system will use all available dialog processes in the local server. Caution: Processing inbound IDocs in parallel is inherently asynchronous, since the system uses RFC calls to communicate with other servers in the group. Do not use parallel processing for processing inbound IDocs in an interface that needs to be real-time.
5.1.3 Processing IDocs in Packets
Processing IDocs in packets improves system performance by reducing the number of function module calls, and by using fewer dialog processes. 5.1.3.1 Creation For a manual master data send, you can specify a packet size. 5.1.3.2 Sending If you select Collect IDocs in the sending partner profile, you must use the program RSEOUT00 to send the IDocs. You would normally schedule this to run at an appropriate time. You can send IDocs in packets by setting the Pack.size field in the partner profiles. The smaller the size of an IDoc, the larger the packet size can be. A general guideline is a packet size between 10 and 200 IDocs. 5.1.3.3 Processing: Some processing function modules can process multiple IDocs with a single call. These function modules process many IDocs within one LUW, which improves database performance. Grouping IDocs into packets is good even for function modules that do not support mass processing, because the system processes the IDocs within one dialog process, which reduces system load. You need to carefully balance packet processing and parallel processing. If your packets are too large, you will reduce the ability to process in parallel.
5.1.4 Managing Communication
Normally, the system will start a batch job to restart a failed RFC connection. This can result in blocking of batch jobs. To stop this, select DestinationTRFC Options from SM59 (RFC Destination maintenance). Select the Suppress background job if conn.error checkbox. You can restart unsuccessful connections with the program RSARFCEX. Program RBDOIND will check that outbound IDocs have successfully connected to the receiving system. 5.1.5 IDoc Archiving
Transaction: SARA
Although IDoc archiving is the responsibility of the Basis team, the ALE developer should have a basic understanding of it. Using transaction SARA - the object type is IDOC. This creates a backup of the IDoc database tables. Once the tables have filled the space available, the system will stop writing IDocs to the database. There is no message to indicate this, so the Basis team needs to monitor it.
Chapter 3 IDoc Reduction

SAP supplies maximized IDocs containing all segments and fields required for the basic requirements of the message type. A customer implementation may use a certain message type, but may only need to populate a subset of the segments/fields. We can reduce this IDoc to simplify the communication. Reduced IDocs are IDocs modified to only include the data that is valuable to the receiving systems. The reduction excludes those fields that the receiving system does not need and therefore makes the IDoc easier to use. Reducing an IDoc does not necessarily reduce network traffic. It can remove segments that would otherwise have been sent (as can segment filtering in the distribution model), but for those segments still sent, the entire segment is transmitted. The ALE layer will put a NODATA character a "/" into each field removed from the segment. The receiving system will ignore fields that have this value. For example, suppose that Business A and Business B each want to assign their own material group to a material. We can reduce the MATMAS03 IDoc to create a new message type that does not transmit the material group. We can then transmit other changes to the material without overwriting the material group. Note: We can only reduce IDocs for master data.
6.1.1
Steps in IDoc Reduction Here are the steps you must follow to create a reduced IDoc: Create a new message type Choose the segments and fields you want to include Activate the new message type Turn on/off change pointers Transport the new message type to other systems Configure the new message flow (Model, Partner Profiles)
6.1.2 Creating a Reduced Message Type
Transaction: BD53 Menu Path: SALE --> Modeling and Implementing Business Processes --> Master Data Distribution Message Reduction Create Reduced Message Type.
Scope of Data for Distribution
To create a reduced message type, use transaction BD53. You must base your new reduced message type on a message type that SAP supplies. After activating the required fields and segments (see the following section), save the reduced message type. If you want to use change pointers to trigger the reduced messages, click on Activate change pointers. This adds entries in the change pointer tables (BD50 and BD52) to configure change pointer use. The new message type is client independent. However, change pointer activation is not. You must activate change pointers in each client in which you want to use them.
6.1.3 Setting the Segment Structure
In essence you are creating a copy of the SAP-supplied message type. Your new message type inherits the same IDoc type as the SAP supplied message type, therefore the same segments and fields. All segments possible for reduction are displayed here. Segments that are required have a (*) following them, not selected a (-), and selected a (+). For a complete key, use menu option Color/characterUtilities keyInitially all segments that are not required are not selected. To select a segment place your cursor on the segment and press the Select pushbutton. You must select a segment before selecting any fields in that segment. Once a segment is active, you can access the fields in the segment by double-clicking on that segment. As with the segments, required fields are marked with (*), non-selected with (-), and selected by (+) (see key from previous slide). To select a field or fields, place a check mark beside them and press the Select button. This changes the indicator from (-) to (+) and selects the field. Caution: Double-clicking on a field or putting a checkmark in the box next to it and pressing enter is not sufficient to select it! If you do this and simply return to the previous screen you will lose your changes! When all segment/field selections are complete, click Save to save your segment structure.
6.1.4 Transporting the Reduced Message Type
Transaction: BD63 Menu Path: SALE --> Modeling and Implementing Business Processes --> Master Data Distribution Message Reduction Generate Transport Request for Message Type
Scope of Data for Distribution
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 dont want transported, you can put the message type in a separate correction for transport. Use transaction BD63. Enter your reduced message. The system will ask you for a change request number to use. Remember: This is an optional step. If the transport assigned when the message type was created is valid for transporting, then you can skip this step.
6.2
Exercise: IDoc Reductions

Shading indicates one person per system at a time. Others will be "locked out"!
A. Creating a Reduced Message Type.

8. Log into your Sales system and create a reduced message type named ZMATMASR## where ## is the last two digits of your logon ID. Base your reduced message type on the SAP supplied message type MATMAS. Choose and activate the segments and fields of your choice. Note: Make note of what segments and fields you chose for verification later!
a. Note: Normally you would transport your newly created message type to the other systems in your ALE constellation using a CTS request. However, since reduced IDoc types are clientindependent, this is not necessary here.
9.
B. Sending an IDoc using your Reduced Message Type.

10. On your Sales system, modify your customer distribution model MODEL##. Add an entry from your Sales system to your Warehouse system for your reduced message type. 11. Distribute the model and generate it on both systems. 12. Return to your Sales system. Create a material with MM01. Go to transaction BD10 and send your material to your Warehouse system. (See chapter 8 exercises for step-by-step instructions. Remember: Replace the message type with your reduced message type!) 13. Check your IDoc statistics on the Sales system. Do you see your outbound IDoc (filter by your Warehouse partner)? Look at your data records. Which fields are being sent and which are not (the character '/' indicates an empty field)? 14. Check your IDoc statistics on the Warehouse system. Do you see your inbound IDoc (filter by your Sales partner)? Did it process successfully?
C. Using Change Pointers

15. From the main BD53 screen, activate change pointers for your reduced message type. 16. Add a new material, or change an existing one. 17. Run the ABAP program RBDMIDOC, specify your reduced message type ZMATMASR##, and execute. The program should create at least one IDoc from your material. Question: When you run RBDMIDOC, you may create more than one master IDoc. Why might this happen?
Chapter 4 IDoc Extension

Customer requirements may require more segments or fields than what an SAP supplied IDoc supplies. You can extend this SAP IDoc to add the needed information. An extended IDoc is based on an SAP supplied IDoc. The extension type inherits the segments associated with the SAP supplied IDoc, and those segments are available in the extended IDoc. To extend an IDoc, add customer-defined segments to existing IDocs. You cannot add fields to existing SAP segments!
7.1.1 Create The Extension Segment
Transaction: WE31 Menu Path: Tools 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: o o o 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.
7.1.2 Create the Extension IDoc Type
Transaction: WE30 Menu Path: Tools or: WE31 Business Communication IDoc type editor IDoc IDoc Basis Development IDoc types
Goto
After you create the segments to be added to the extension type, you can create the extension type itself. Execute transaction WE30, enter the extension name, select Extension type, and click Create. You now have three options: Create new type: Does not refer to other extension types Create copy: Copies info from an extension type that already exists Create successor: Extends an extension type from a previous release of R/3. You can only have one version of an extension type for each release. Enter the Basic IDoc type that this extension type will extend. The screen now shows the structure of the IDoc type you used as a reference. Position the cursor on one of the segments and click Create. This will insert an extension segment as a child of the selected segment. NOTE: A segment cannot appear more than once in an IDoc type! You must control the use of duplicate segments with the segment attributes (the next screen). The segment attribute screen appears. Enter the information and save. Extension segments should not be mandatory (for future upgrades), and will need to have minimum and maximum number of instances defined. This answers the question, for each instance of the parent segment, how many instances of the child segment may we have? You can press the Segment Editor pushbutton to view or change the segment definition.
7.1.3 Create the new Message Type
You can only use an extension IDoc type by assigning it to a message type. You can create a new message type for this. First the message type itself needs to be created.
Transaction: WE81 Menu Path: Tools or: WE30 Business Communication Message types IDoc IDoc Basis Development Message types
Environment
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 or: WE30 Business Communication IDoc IDoc Basis Development IDoc type/message
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.
7.1.4 Check the Extension Type After creating a new extension type, its a good idea to test it.
From the main Develop IDoc Types screen select the IDoc type you want to check and select CheckDevelopment Object. This check will try to verify all objects related to the object you selected for validity and consistency. All return codes should be zero (RC =0), except "Extension type is not released (RC =4)". Do not release the extension type until you have tested it. The extension type can be unreleased, but it is fairly complicated to do. A segments release, however, can be canceled without much difficulty. Once you have tested your extension type, and everything works right, you can release the extension. To do that, go to transaction WE30, and select the menu option Set Edit release. Changes to released types are not allowed. You have to do Edit Cancel release to enable modifications.
7.1.5 Communication Parameters
Remember that all ALE configuration is based on the message type. Since you have created a new message type, you must properly configure the ALE layer to process your new message. This includes: Adding your new message type to the distribution model. Creating partner profiles. NOTE: You must create the inbound partner profile manually. The generation function will not work because the system does not know how to process your new message type. More on this later.
7.1.6 Master Data Outbound Configuration If your extension is to handle master data, there is more configuration to do:
If distribution is to be done automatically through change pointers, then you must activate them for the extended message type. The system must know which fields should trigger the creation of change pointers. When creating the extension, the system needs to know which function module to use. 7.1.6.1 Activate Change Pointer for Message Type If your extension type will handle master data using change pointers, you need to activate the change pointers. When creating a reduced IDoc type, the system does this automatically, but when creating an extension you must enter it yourself, using transaction BD50. See the Distribution Methods chapter for details. 7.1.6.2 Activate Change Document Items
Transaction: BD52 Menu Path: Tools 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.
7.1.7 7.1.7.1 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 its 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 its much easier and safer to copy the entry from the message you based your extension type on. 7.1.7.2 Inbound
Transaction: WE57 Menu Path: Tools type ALE ALE Development IDocs Inbound Processing Function module Assign IDoc type and message
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. Its much easier and safer to copy the entry from the message you based your extension type on.
7.1.8 Filling and Extracting Extension Segments
Although the segments are now defined to be sent or received, there is no current way to manipulate the data in the segments. We need to make some source code changes! To post and extract data to and from an IDoc extension, we need to find a user exit in the application code. User exits are found in the function modules, which are tied to the process codes used by ALE. The ABAP code to process an IDoc extension is added within an INCLUDE statement in the user exit. We'll discuss how to program IDoc segments in the next two chapters.
7.2
Exercise: Creating an IDoc Extension

Only one person at a time can perform shaded steps. Others will be "locked out"! This exercise has two objectives: 18. Create an extension of the SAP supplied IDoc MATMAS03. 19. Configure the distribution of Master data using Change Pointers. IMPORTANT: Use the object names given in these directions! If you use different names, the supplied user exit will not work!
Scenario: Springfield Nuclear Power, Inc. is implementing SAP for its three nuclear power plants. They need to configure Material Master transfer using ALE, but the SAP-supplied material tables do not have the proper fields for radioactive materials. Therefore, they have created a custom table, called ZMARANUC, to store extra information for the few materials that are radioactive. This table stores two extra pieces of information for each material that is radioactive: the Half-Life and the Half-Life Unit. Note that most materials are not radioactive, so they will not have an entry in this table. In order to transfer these radioactive materials using ALE, we need to build an extension to IDoc type MATMAS03 to store the extra information. We also need to write user exit code on the Sales system to populate this segment from table ZMARANUC, and read the data on the Warehouse system into table ZMARANUC. This is your task.
Summary of steps needed to build this scenario:

1. 2. 3. 4. 5. 6. 7. 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)
20. Create a development class called ZAL##, where ## is your user number. (Use SE80 to do this.) Create a new change request when prompted. 21. In the segment editor (WE31) create an extension segment named Z1SEGNUC#### where #### is your logon ID. It should have the following fields:
Field Name MATNR HALFLIFE UNIT Data Element MATNR ZHL ZHLU
22. Check and release the segment.
Step 2: Create an extended IDoc type to merge this segment with MATMAS03 (both sending and receiving systems)
23. In the IDoc type editor (WE30) create an extension type named ZEXTNUC#### where #### is your logon ID. Use the SAP IDoc type MATMAS03 as your reference type. 24. Add your segment Z1SEGNUC#### to the IDoc as a child of E1MARAM. Make the segment optional, with minimum and maximum number equal to 1.
Step 3: Create and configure a new message type for your extended IDoc type (both sending and receiving systems)
25. Create a new message type called ZMESNUC#### where ## is your logon ID. (WE81) 26. Associate your new message type to your Extension Type and SAP supplied Basic IDoc Type MATMAS03. (WE82) 27. Check and release your extended IDoc type
Step 4: Configure the creation of IDocs using change pointers (sending system)
28. Make sure that Change Pointers are activated generally. BD61 29. Activate Change Pointer creation for your new message type. BD50. 30. Configure the change document items for your extended message type. Add an entry for object MATERIAL, table name MARA, field name "KEY". This will cause the creation of change pointers when creating a material. BD52.
Step 5: Perform outbound configuration (sending system)

31. Maintain the function module to create your extended message type. BD60. Copy the entry for message type MATMAS. You only need to change the message type to your extended message type and enter. 32. Modify your customer distribution model MODEL##. Add an entry from your Sales system to your Warehouse system for your extended message type. 33. Generate the outbound partner profile. 34. Distribute the model to your Warehouse system.
Step 6: Perform inbound configuration (receiving system)

35. Configure the function module to process your extended message type. Run WE57 and copy the entry for function module IDOC_INPUT_MATMAS01 / Basic IDoc MATMAS03 / Message type MATMAS.
a. b. c. Enter your extension type. Replace message type MATMAS with your extended message type Enter.
36. Generate the inbound partner profile. Important: Set the inbound parameters to Trigger by background program!
Step 7: Test the scenario

On your Sales system: 37. Run transaction MM01 and create a new material. Be sure to write down the material number created! 38. Run custom transaction ZNUC to add the extension information to table ZMARANUC for this material. Use any number for the Half-Life, and H (hours) for the Half-Life Unit. 39. Run the program RBDMIDOC (or transaction BD21). This program creates IDocs from change pointers that have been created for the message type you specify. In this case specify your extended message type. If all is set up correctly, you should receive a message that at least one master IDoc and communication IDoc were created. 40. Check your IDoc statistics. Do you see your outbound IDoc? On your Warehouse system: 41. Run APAB program RBDAPP01 (or use transaction BD87) to process your IDocs. 42. Check your IDoc statistics. Do you see your inbound IDoc? Did it process successfully? 43. Run SE16 to look at table ZMARANUC. Was the extension data posted properly? Question: Why was it necessary to use RBDAPP01 to process the inbound IDocs?
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 RFCNetwork 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 PortIDoc Basis Definition
Ports establish the linkage between the partner profiles (discussed in detail later in this chapter) and the RFC destinations for outbound transfers. They also indicate if the transfer is file based or tRFC (or R/2, etc.). To create a port, use transaction WE21.There are several types of port. Some of the more important ones are: Transactional RFC File R/2 system XML The system can automatically generate a transactional RFC port if the logical system name is the same as its corresponding RFC destination (between R/3 systems only!). You need to create ports manually for all other system types.
Transactional RFC Ports

Transactional RFC ports point to an RFC destination, which must exist before creating the port. Simply create a new entry and associate it to a pre-created RFC destination (field Logical destination). tRFC ports merely function as a pointer to an RFC destination. We define the actual connection parameters in the RFC destination itself. Define a tRFC port for R/3 to R/3 connections and for any R/3 to external system connections that use a remote function call interface.
File Ports
File ports can contain configuration for any or all of the following: Outbound file: A file to receive outbound IDocs. Inbound file: A file to supply inbound IDocs. Status file: A file to store IDoc status records.
To configure a file name for one of these files you need to supply
the following: The directory (on the application server) where the file is found. End this entry with a / character. The name of the file. You have two options: o Specify the actual file name. o Choose a function module that generates a filename from timely information, such as date, time, message type, or user id.
XML Ports
An XML port is similar to a File port, with these differences: Only outbound transmission is supported. The file will be written in XML format, rather than IDoc text. You also have the option of including a Document Type Definition (DTD) in the XML file created.
Partner Profiles Transaction: WE20 Menu Path: Tools Business Communication IDoc PartnerIDoc Basis Profile
The partner profiles tell the ALE layer how to send messages between systems. Given a message type and a communication partner system, the partner profile specifies information that the ALE layer needs to properly create or process the IDocs. This information is different for senders and receivers. The partner profile configures the ALE layer, while the RFC destinations and ports configure the communication layer.
The Partner number is the logical system name of the other system: In the sending system profiles, the Partner number is the receiving system. In the receiving system profiles, the Partner number is the sending system. The Partner type is always LS (logical system) for ALE. Partner class is a free text field that lets you classify partners. Receiver of notifications is a Workflow configuration for error handling. After you create the profile, then assign parameters to it as follows. Message Control parameters control the sending of messages from an application that uses Message Control (also called Output Determination) - Separation of Sales and Distribution, for example. We'll look at this configuration in detail in a later chapter.
Partner Profile Outbound Parameters
The outbound parameters provide information for creating outbound IDocs: The receiver port to use. This port can point to an RFC destination or to a file, as discussed earlier. Whether to send the IDocs immediately or to collect them for sending in batches. If IDocs are collected for batch sending, the package size to use. The IDoc type to use for the message. Workflow configuration for handling errors. Well 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. Well discuss the processing of IDocs in the background in a later chapter.
Partner Profile Generation Transaction: BD82 Menu Path: BD64 GenerateEnvironment 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. 1. Run SM59. If the RFC Destination for your Warehouse system does not exist, create it. If it does exist, proceed to Partner Profile Generation, below. 2. Enter the information: a. b. c. d. e. f. g. h. 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
3. Click Save. 4. You can click on Test Connection to test the connection to the other system, or Remote Login to log into it.
B. Generate the Outbound Partner Profile You will now create a partner profile, which combines your logical system with the message types defined and associates it with a port to the physical system. 1. Environment Generate partner profiles from the Model Maintenance (BD64). 2. Enter your model name (MODEL##) and click on Execute. 3. The system automatically creates the appropriate partner profile and generates colorcoded status messages about what it did. If any of your messages are red, this indicates an error, which you should correct before proceeding. 4. Go to Environment Change partner profile (or WE20) to see what the automatic generation did. (Created a port and a partner profile.) C. Distribute the Customer Model You will now distribute the distribution model you created earlier to the other system. 1. Run BD64. (Distribution Model Maintenance). 2. Highlight your distribution model and follow menu path Edit Enter your model name and enter. Model View Distribute.
3. Select the proper system to receive the model and execute. You should see a message indicating successful transfer. D. Generate the Inbound Partner Profile 1. Repeat the partner profile generation (Step B above) on your Warehouse system to create the partner profile on that system. Note: Ignore any errors listed involving an RFC destination for your Sales system. This will not affect inbound processing.
E. Send a Material 1. Test your configuration by sending a material from your Sales system to your Warehouse system. 2. Log back into your Sales system. 3. Create a new material using transaction MM01. Use the information on the sheet handed out in class to create the material. Make note of the material number assigned! 4. Execute transaction BD10. This is the ALE Material Master Data Distribution program. 5. Enter the number of the material you created, the message type to use (MATMAS), and your Warehouse system name, and then click Execute. 6. You should see message boxes saying that 1 master IDoc was set up and 1 communication IDoc was sent. 7. Run transaction WE05 to look at the status of your message. The status should be 03 Data passed to port OK. 8. Drill down into the IDoc to look at the control, data, and status records. 9. Log into your Warehouse system and use WE05 to look at the received message. Its status should be 53 Application document posted. 10. Drill down into the IDoc to look at the control, data, and status records. How are they different from the outbound records in the Sales system? 11. Run transaction MM03 to see if your material was successfully added to the receiving database. Exercise: Using a File Port In this exercise, you will configure material output to a file port, then read input from this port. A. Configure Outbound File Port 1. On your Sales system, run transaction WE21. 2. Highlight File, then click on Create. 3. Name your port PORT##, where ## is the last two digits of your logon ID. 4. Enter a short description, and make sure that release 4.x record types is checked. 5. On the Outbound file tab, change the Physical directory to /tmp/ (note a / at both the beginning and the end), and select the function module EDI_PATH_CREATE_USERNAME. Leave the Outbound file field blank. 6. Save. B. Configure Outbound Processing 2. Create a new logical system (BD54) called FILE##. Do not allocate this logical system to any client. 3. Change your distribution model (BD64) to add a message: a. b. c. Sending System: Message Type: Your Sales system MATMAS Receiving System: Your FILE## logical system
4. Save your model. 5. You will not be able to generate the partner profile automatically (Why not?). Run WE20 to enter it manually. Click Create and enter the information: a. b. a. b. c. Partner Number: Partner Type: Message Type: Receiver Port: Output mode: FILE## LS MATMAS FILE## Transfer IDoc immediately
6. Save, and then click on Create outbound parameter. Enter the information:
d. 7. Save.
Basic Type:
MATMAS03
C. Send a Material 1. Run MM01 to create a new material. Follow the guidelines on the sheet given out in class. 2. Use BD10 to send this material to your logical system FILE##. You should get one Master IDoc and one Communication IDoc. 3. Run AL11, and double click on the /tmp directory. 4. Double click on the file named with your username to look at the IDoc. D. Using an XML port. 1. Create a new XML port called XML##. Use the same outbound parameters as in step A above. 2. Change your partner profile entry for the FILE## logical system to use the XML## port instead of the FILE## port. 3. Resend your material to the FILE## logical system. 4. Use AL11 to look at the resulting XML file. (Note: The system does not put newlines into the XML file, so you will not be able to see the entire file. If you want to look at the entire file, ask the instructor for help.)
Chapter 5 ALE Architecture Outbound Processing
Application Transaction
Create the application document o Outbound processing begins with the SAP application transaction. This transaction creates a document that needs to be sent to another system with ALE. o The application does not post its data yet. Instead, it waits until the ALE layer creates the outbound IDocs.
Read the Distribution Model o When the SAP application is ready to post the document to the database, it queries the ALE distribution model to determine whether it needs to send the data somewhere with ALE. o Some transactions may also check the distribution model for filter objects. These filters specify certain pieces of data that the receivers do not need, and determine which objects the application will include in the IDoc. If the transaction does not look at the filter objects, then the ALE layer will do the filtering. o If no ALE IDoc is needed, the SAP application posts the application data in its normal manner. o Alternatively, the application can use Message Control to determine if it needs to create an IDoc. We will discuss Message Control in a later chapter. Create the Master IDoc o If the model indicates that the application program needs to create an IDoc, then it does so by calling a function module appropriate for the message type. o The application passes this Master IDoc to the Distribution Layer in an SAP internal table.
Distribution (ALE) Layer

Read the Distribution Model. o If the SAP application did not specify a receiver for the message, the ALE layer reads the distribution model to determine the receiver(s). It also processes any filter objects (from the model) associated with the message flow. Create the Communication IDocs o The ALE layer then creates a separate copy of the Master IDoc, called a Communication IDoc, for each receiver. o If there are no receivers defined in the model, processing stops and the application posts its data to the database.
ALE Layer IDoc Processing o Next, the ALE Layer performs a series of IDoc conversions, if needed: Segment filtering. The ALE layer can remove any segments that the receiver does not need. These segment filters are dependent on the message type and the receiver.[2] Field Value Conversion. The ALE layer can perform some simple conversion of values in the IDocs fields. The conversion of field values is dependent on the message type and the receiver. Examples of field value conversions might include converting a 10digit 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 IDocs control record to a different R/3 release version. We specify the version of control record that a logical system uses in the port configuration. This feature lets us distribute applications across multiple SAP releases, and is the reason SAP guarantees that ALE will work between different releases. o IDoc Creation After the ALE layer completes the IDoc processing, it stores the Communication IDocs in the sending systems database (in EDIDC, EDID4, and EDIDS). The system creates links (in the control record) to the application document and to the tRFC transaction id for the call to the other system After the call to the ALE layer completes, the application will post its data to the database and commit work. This ensures that the application document creation and the IDoc creation occur in the same logical unit of work.
[2]
Note that there are two levels of filtering: IDoc level and segment level. The filter objects defined in the model primarily filter entire IDocs. The ALE layer can also filter out specific segments, which is what were talking about here. Well discuss this in more detail in a later chapter.
Communication Layer
Once the ALE layer has created the IDoc, it sends it to Dispatch Control, which controls how the IDoc is sent (file interface or tRFC) and when the IDoc is sent (immediately or periodically in batches). Dispatch Control uses the technical communication parameters that we set in the partner profile. When the ALE IDoc is complete and Dispatch Control has determined when and how to send it, the Communications Service actually transmits the message. Sending the outbound IDocs in batch reduces the communications overhead.
Inbound Processing
Communication Layer
The Communication layer receives an IDoc by tRFC, EDI, or some other method, and passes it to the Distribution (ALE) Layer.
Distribution (ALE) Layer

The ALE Layer performs the same IDoc processing as on the outbound side: Segment Filtering The segment filter removes any segments that the receiving system does not need for this message type. Field Value Conversion. The ALE layer can provide simple data mapping and conversion. Version Conversion. The ALE layer can convert the control record to the required version. Following this pre-processing, the ALE layer writes the resulting IDoc to the SAP database, and creates a link to the IDoc in the source system. After the ALE layer stores the pre-processed IDoc in the database, it reads the inbound configuration to determine: What type of input processing is required (Function Module or Workflow) When the IDoc is processed by the SAP application (immediately or periodically in batches) Which users to notify if there is an error in processing The ALE Layer then passes the IDoc data directly to the appropriate SAP application.
Application Layer
The SAP application reads and processes the information in the IDoc and creates an application document for posting to the SAP database. Once the application document is ready for posting, the application posts it to the database and updates the IDocs status records in the same Logical Unit of Work. The ORDERS and ORDCHG IDocs are exceptions to this timing. In both cases, the application executes a CALL TRANSACTION first, and then updates the status records. When the SAP application processes the IDoc, it can check the serialization. Using the timestamp of the IDoc, the application can determine if it has already received a more recent IDoc for the same inbound document. If it has, it may wish to avoid posting the data in the overtaken IDoc. Not all of the SAP applications use this serialization capability.
Outbound Processing for EDI
This is the normal process flow for creation of outbound EDI IDocs. An EDI scenario may or may not use all of these elements. The application program creates its document (purchase order, etc), and calls the Message Control system. Message Control (also called Output Determination) determines where to send the document. This may include printing a hard copy or sending by ALE or EDI. If out by ALE or EDI (that is, by IDoc) is required, then Message Control writes a record to the NAST table. ABAP program RSNAST00 (which is scheduled to run on a periodic basis) reads the NAST records and creates outbound IDocs for each one, based on the ALE configuration. It writes these IDocs to the IDoc tables (EDIDC, EDID4, EDIDS). If the partner profile is set to "Send immediately", then the ALE layer will send the IDocs at this time. If the partner profile is set to "Collect IDocs", then the ALE layer will not send the IDocs until the ABAP program RSEOUT00 (also scheduled for periodic execution) runs. This program calls the ALE layer to send all collected IDocs of any specified message types. The ALE layer does two things in sending an IDoc, whether it is directly from RSNAST00, or by the running of RSEOUT00: Writes the IDocs to the file specified in the file port. Executes the program RFCEXEC. This program is not an ABAP program, but rather an SAP-supplied program that runs on the operating system. RFCEXEC, in turn, executes a shell script or other program that activates the EDI translator. In general, this script will run the translator, passing it the name of the file containing the IDocs, which the translator then reads. The EDI translator vendor will generally supply the shell script that RFCEXEC uses to start the translator running.
10
Chapter 6 Data Distribution Methods Configuring Master Data Fetch

We can trigger the distribution of Master Data from either the source system or the destination system. Use a send when you create or maintain a master data record on a central system and push it out to multiple distributed systems. If the data does not exist on the receiving system, then the receiving system creates it. If the data DOES exist on the receiving system, then the receiving system changes the record. It only changes the information that is different from the record on the receiving system. You can send any of the types of master data available to ALE. Use a fetch when you create or maintain a master data record on a distributed system and pull it in to the central system. If the data does not exist on the fetching system, then the fetching system creates it. If the data DOES exist on the fetching system, then the fetching system changes the record. It only changes the information that is different from the record on the fetching system. You cannot fetch all master data types. You can only fetch those master data types that have a fetch message type defined. Currently, these are: material, customer, vendor, general ledger, profit center, cost center, and activity type information. To configure a fetch, simply define a fetch message type in the direction opposite from the master data message type in the distribution model, then use the appropriate master data fetch program.
Triggering Methods
The methods we can use to trigger ALE distribution vary by the data type.
Master data
Manual Program o We can send data directly from an ABAP program. SAP provides such programs for most kinds of master data. You can access these programs with menu path Tools ALE Master Data Distribution. o Enter the appropriate data on the master data send/fetch screen, which includes the master data to be sent, the message type, and the logical system of the receiving system (send only). o If you do not enter a logical system, then any logical system that has the pertinent message type in the distribution model will be included in the ALE transmission. This is useful when there is one central system where the data is created and then transmitted out to multiple distributed systems via ALE. Automatic Send o We can use Change Pointers to automatically distribute the data. o If a user creates, changes, blocks, or deletes a master record, the Shared Master Data (SMD) system will send the record automatically. o If multiple changes are made to a master record between distributions, the system will incorporate all of the changes into one change document for that master record. o Automatic distribution will work for all the master data types available to ALE. o IDoc distribution using the SMD is generally a batch (not real-time) process. The system does not send IDocs at once, but rather waits for the next scheduled send. However, with customization of the tool, you can achieve near-real-time distribution.
Transaction data
Direct ALE Call o The transaction program may contain a call to the ALE layer to send the IDoc directly. Message Control o We can use Message Control to automatically distribute the data. The message control system allows the sending of data in real-time.
Automatic Master Data Send with Change Pointers
SMD outbound processing begins with the SAP application transaction that changes master data that needs to be sent to another system with ALE. The application does not post its data yet. Instead, it waits until the change document and change pointers are written. The change document service examines which fields have been changed. If the field that is changed is one that receiving systems are interested in, the program writes a change pointer to the database. Change pointers are the mechanism by which the SMD tool operates. The change pointers are message type specific, and also indicate which part of the master data record changed (that is, which database table was modified). The ALE-relevant fields are configurable by message type. A standalone program (RBDMIDOC) analyzes the unprocessed change pointers. Normally this program is scheduled to run periodically for different message types. When it finds a change pointer for a particular object, it creates a master IDoc for the object referenced by the change pointer. The ALE layer reads the distribution model and generates communication IDocs as usual, including filtering, version change, ALE rules, etc.
Configuring the SMD Tool

These are the steps needed to configure an automatic master data send:
Transaction: BD61 Menu Path: SALE Modeling and Implementing Master data DistributionBusiness Processes 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 Master data DistributionBusiness Processes 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 IDocsALE Development Management Define Change-Relevant Fields Engineering Change
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 twocharacter ID. o Example: Sales Scheme -- In general, the application document created. May also be called Procedure. A scheme defines a set of possible output types for an application. Although several can be configured, only one is active. This is the set of possible outputs for an application. This does not mean they will all be generated. Using transaction VOFM it is possible to add requirements to an output type in the scheme. A requirement is a special ABAP program used to implement complex business logic. For example, an order is not created unless data meets certain validations. o Examples: Order, Quotation Output Type -- The type of message created. May also be called Message Type (but this is not the same as an ALE message type). The output type defines the characteristics of the output, such as medium, timing, etc. o Examples: Order confirmation, internal order message
Access Sequence -- Defines the fields used to look up condition tables. This identifies the business rules to check before proposing output, and the order in which to check them. You can chose exclusive or inclusive rules. An exclusive rule means that when the first rule evaluates to true, the system proposes the output ignoring the remaining rules in the access sequence. With inclusive rules, all rules must be true before the output is proposed. It is also possible to add ABAP requirements through VOFM to check specific business rules based on the fields in the condition table. o Examples: Order type, Sales org/customer Conditions -- A list of outputs to create under certain conditions. These are the actual values checked in the business rule. The system will only propose an output when the values match the records in the condition table. A large set of standard tables is available, or you can create new ones. o Example: EDI for customers in sales organization 0001, printed output for all others
Configuring Message Control
The R/3 system comes with a set of default message control configurations, which we can add to or change. These include all of the application areas, as well as most schemes you will ever need. In general, you should define these components from the bottom up. That is, you should create the condition tables, then the access sequences, and so on to finish with the scheme. SAP considers schemes, output types, and access sequences to be configuration data. You will find the programs to maintain them in the IMG. For example, the IMG path for Sales Documents is: Sales and Distribution --> Basic Functions --> Output Control --> Output Determination --> Output Determination Using the Condition Technique --> Maintain Output Determination for Sales Documents Condition records are application data. You find the programs to create them as part of the application menu path. For example, the menu path to create condition records for Sales Documents is: Logistics --> Sales and distribution -> Master data --> Output --> Sales document --> Create.
Here are some common configuration hierarchies: Materials Management: Condition Type Procedure RMBEF1 RMBEF1 RMBEA1
Logical Message Type ORDERS ORDCHG REQOTE
Application/Transaction
EF/Purchase Order EF/P.O. Change EA/Request for Quote NEU NEU (with change flag) NEU
Sales and Distribution: Application/Transaction V1/Sales Orders V1/Quotations V2/Delivery Notes V3/Invoicing Condition Type BA00 AN00 LAVA RD00 Procedure V10000 V06000 V10000 V10000 Logical Message Type ORDRSP QUOTES DESADV INVOIC
Configuring Message Control: An Example

As an example of the required Message Control configuration, lets consider the Distributed Contract scenario. As a reminder, this scenario involved the creation of a contract at a central office which then sends it to distributed offices. The local facilities can then create purchase orders referencing this contract. We need the following configurations. Note: Transaction codes given here are specific for the Distributed Contract scenario. Transaction codes for other scenarios will be different, although the functioning of the programs is similar. Remember that you must define new entries from the bottom of the hierarchy to the top. Define Access Sequences (M/52). Defines the fields of the condition tables used to determine output. Each access sequence corresponds to a different condition table. o We use Access Sequence 0001, which will use condition table 26 (Purchasing by Document Type) Maintain Output Types (M/38). Defines which Access Sequence to use for each Output Type, as well as many options and parameters for the Output Type: o The medium and timing, which may differ with different partner types. o The program used to process and output the data, which in our example creates the IDocs from the application document. o We will use Output Type VNEU, which represents Distributed Contracts. Message Schemes (M/68). Associates Output Types with Schemes. A scheme is simply a defined sequence of output types. The Message control system creates each output type in the sequence specified here. Each output type may have a Requirement Routine - a business need that must be met before triggering the output. A Requirement Routine consists of ABAP/4 code. If the routine's return code is successful, the output occurs. o We use scheme RMBEV1, which represents a purchasing agreement.
Fine-Tuned Control of Output Types (OMQO). Defines which output type to use in different situations within a given scheme. For example, we can define a different Output Type for an added document than we do for a changed document. o We associate our Output Type VNEU to new contracts. Assignment of Scheme to Application (OMQT). Assigns a scheme to an application. o We assign the scheme RMBEV1 to application EV (Purchase Outline Agreement). Condition Records (MN07). Define the conditions that must be true to produce the output specified by the previous configurations. o We defined our Access Sequence to use the Document Type Condition Table, so we will define output for a quantity contract, which is document type MK. ALE Distribution Model (BD64). Defines the message flow between logical systems. o We will model the flow from our Sales system to our Warehouse system. Partner Profiles (WE20). Defines the message type, IDoc type, port, and other options for the IDoc distribution. o We will generate the partner profile from the distribution model.
Additional ALE Configuration for Message Control

There is some additional ALE configuration to enable the Output Proposal from the document to trigger an ALE message. We need to link the output determination message type to the ALE message type in the partner profile of the system. Using transaction WE20, select your ALE message, and click on Message Control. Enter the message control output type that will trigger your message and the outbound process code. You need two entries here for each output type: one for creates to the transaction document and one for changes.
Viewing Proposed Output
Most application programs allow you to determine what output was proposed for any document. You can see which output types were proposed and the receiving party, if by EDI. The status will have one of these values: YELLOW To be processed GREEN Successfully processed RED Incorrectly processed
To view how an output was proposed, use menu path Goto --> Determin analysis. When the status is RED, select the line with a single click and use menu path Goto --> Processing log to see a description of the error. You can drill down into these screens to see more details of each step.
Re-Proposing Output from NAST

When the system determines output for an application document, it writes a record to the NAST table. This NAST record can have one of three status values. 0 = awaiting output 1 = output successfully processed 2 = an error occurred during output processing Once a NAST record has a successful status (1), and the ALE layer has sent the IDoc successfully, you cannot resend the IDoc. If you need to resend the IDoc, you must go back to the application document and repeat the output. The menu path varies, by program, but is usually something like Goto Messages.
Re-proposing the application document will rerun the output programs and create a new IDoc. The new IDoc will contain any changes in the application document made since the first IDoc was created.
Batch Processing Reasons

We can configure most of the IDoc processing, both inbound and outbound, to happen immediately or in batch. There are several reasons why the batch mode is generally preferable: Time Constraints. Sometimes the processing of a set of IDocs must happen within a specific window of time. For example, purchase orders can be created and modified on the system over the course of the day and only sent out once a night. Until the time the Order IDoc is created, users can make changes to the order. Once the IDoc is created, all subsequent changes will result in the creation of change orders. Transaction Sequence. A group of transactions may need to be sent out together. For example, if a billing program creates multiple invoices for the same customer, the customer may expect that all invoices generated that day be sent in a single EDI interchange. Scheduling Dependencies. The processing of some IDocs may depend on the successful processing of a preceding batch job, or a later job may depend on the successful completion of IDoc processing. Either case requires that the processing of all IDocs as a step in a batch process that can either trigger or be triggered by another step. Transaction Volume/Load Balancing. Some SAP processes (e.g. post goods issue, delivery due list), as well as certain external systems (e.g. EDI, warehouse management systems) can create a high volume of transactions in a short period of time. They can overwhelm the processing capabilities of the receiving system if the interface is set up to process everything immediately.
Batch Processing Programs

SAP supplies some ABAP programs to allow for batch processing of IDocs: RBDMIDOC -- Creates Master data IDocs from change pointers. You must specify a message type for which to create IDocs. RSNAST00 -- Reads records from the NAST table, creates IDocs, and submits the IDocs to the ALE layer for distribution. Create a variant with the following fields filled: o Output application o Output type o Transmission medium o Editing an outbound document that has been saved and posted is possible only until RSNAST00 creates the IDoc. After that, any changes to the document will trigger a separate IDoc. RSEOUT00 -- Sends IDocs stored in the database with partner profile entries indication Collect IDocs. The Output mode field of this program allows you to specify when the EDI translator (or subsystem) will run. Generally, you should use mode 3, which triggers the subsystem only once for each batch of IDocs. RBDAPP01 -- Processes inbound IDocs stored in the database with partner profile entries indication Background processing. RSEINB00 -- Reads inbound IDocs from a disk file, whose name you specify and submits them for processing.
Distributing Control and Customizing Data

We can control the distribution of control or customizing data with ALE. In fact, certain customizing data must remain consistent across all of the systems for ALE to function properly. The Distribution Model defines the distribution of changes to customizing data, but we use CTS (Correction and Transport System) to actually distribute the control data to the other systems.
How to Distribute Control Data
There are two methods for configuring control data distribution: Using the CONDAT message type in a distribution model. This is the only method available in releases earlier than 4.6B. Creating a Customizing Data Distribution Group. This method replaces the old CONDAT method in release 4.6B, although the CONDAT method is still available. You cannot use both at the same time. Since Control Data Distribution control with ALE is rarely used, we will not discuss it further. Consult online help if you need more information.
Exercise: Master Data Fetch
In this exercise, you will configure a master data fetch between two SAP systems using ALE. You will distribute a customer record from one system to another. Caution: Only one person at a time can perform shaded steps. Please work quickly so that others will not be locked out for too long! 1. On your Warehouse system, configure an RFC Destination pointing to your Sales system. 2. Maintain your distribution model (on the Sales system). Configure a message type DEBMAS from Sales to Warehouse, and a message type DEBFET from Warehouse to Sales. 3. Distribute the model to Warehouse 4. Generate your model on both systems. 5. Create a customer (transaction V-09) on the Sales system. 6. From the Warehouse system, execute transaction BD13 to fetch your customer. 7. Look at the IDocs sent on both systems and check for successful processing. 8. Run transaction XD03 to see if your customer was created on your Warehouse system. Exercise: Configuring a Transactional Data Scenario In this exercise, you will configure the distributed contracts transactional data scenario described in the Overview chapter. A. ALE Configuration 1. Add the following message flows to your distribution model: a. BLAORD from Sales to Warehouse
b.
BLAREL from Warehouse to Sales
2. If you didnt configure vendor or material distribution in previous exercises, add these as well: a. b. CREMAS from Sales to Warehouse MATMAS from Sales to Warehouse
3. Distribute your model and generate it on both systems. If you encounter errors, fix them before proceeding!
B. Configure Message Control Note: In this section, you will be looking at existing configuration, since this scenario comes preconfigured with the R/3 system. 1. Go to the IMG. Transaction SPRO, then click on SAP Reference IMG. 2. Follow the menu path Materials Management Control. Purchasing Messages Output
Note: Normally, we would configure Message Control from the bottom of the hierarchy to the top. However, since most of the configuration comes with the installed system, it will be easier to understand from top to bottom. 3. Execute Partner Roles per Message Type for Outline Agreements. a. Check that there is an entry for Distributed Contracts (output VNEU) for ALE Distribution (medium A).
4. Execute Message Determination Schema for Outline Agreements, then select Maintain Message Determination Schema: Outline Agreement. a. b. 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.
5. Execute Message Types for Outline Agreements, then select Maintain Message Types. a. Double click on VNEU. Note the following entries: i. The Access Sequence (list of Condition Table fields) is DocType/PurchOrg/Vendor. These are the fields we can use as keys in a condition table. ii. The default medium (on the Default values tab) is ALE. iii. Double click on Processing routines. This lists the ABAP program that will actually produce the output. In this case, it is the FORM routine called ALE_OUTPUT_BLANK_ORD in the program RM06EALE. b. Back out to the selection box, and then select Fine-Tuned Control. This lets us select different output for different situations (for example, a new vs. a changed document). 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?
6. Execute Access Sequences for Outline Agreements. a. b. c.
C. Create Condition Records On your Sales system, configure the output of quantity contract information: 1. From the main SAP menu (not the IMG), follow the menu path Logistics Materials Management Purchasing Master Data Messages Outline Agreement Create. Or you can use transaction MN07. a. Enter the output type we are using (VNEU) and click on Key combination. This selects the condition table we will use. Select the Document Type condition table. Create a record as follows: i. Document type: ii. Medium: iii. Timing MK (Quantity contract) A (ALE distribution) 4 (Send immediately)
b.
Leave the other fields blank. On your Warehouse system, configure the output of purchase order (release) information: 2. From the main SAP menu (not the IMG), follow the menu path Logistics Materials Management Purchasing Master Data Messages Purchase Order Create. Or you can use transaction MN04. a. b. c. 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: i. Document type: iii. Medium: iv. Timing MK (Quantity contract) A (ALE distribution) 4 (Send immediately) ii. Partner Function: VD (Vendor)
Leave the other fields blank.
D. Create Master Data 1. Create a vendor, using the guidelines distributed in class. 2. Create a material, using the guidelines distributed in class, with the following additions: a. b. 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.
3. Use BD14 to send the vendor to the warehouse system. 4. Use BD10 to send the material to the warehouse system.
E. Create a new Distributed Contract. 1. On your Sales system, execute transaction ME31K, or menu path Logistics Materials Management Purchasing Outline Agreement Contract Create 2. Enter data: a. b. c. a. b. c. d. Vendor The vendor you create above MK (Quantity contract) 001 The material you created above The total contract quantity The price per unit 01 Messages to see if ALE output was created. If not, Agreement Type Purchasing group Material Targ. qty. Net price Matl group
3. Enter, then add a line item for your material:
4. Follow menu path Header troubleshoot and fix.
5. Save the contract. Make a note of the contract number. 6. Run WE05 on both systems. Is there a BLAORD IDoc sent? Did it post successfully on your warehouse system? If not, fix any errors and repost using BD87.
F. Create a Purchase Order against the Contract. 1. On your Warehouse system, execute transaction ME21. 2. Click on the Ref. to contract button and enter your contract number. 3. In the line item for the material, fill in the quantity for this order and the plant (0001), and click on Adopt + details, 4. Enter the order price and save. 5. Run WE05. Is there a BLAREL IDoc sent? Did it post successfully on your sales system? If not, fix errors and repost using BD87. 7. On your sales system, execute transaction ME33K, or menu path Logistics Materials Management Purchasing Outline Agreement Contract Display. 8. Select your agreement, then select the material line item and click on Release documentation. You should see the purchase order information, and quantity release statistics.
11
Chapter 1 ALE Monitoring SAP provides a set of tools for monitoring the ALE installation, both of the IDoc communications between the systems and the ALE configuration itself. Consistency Check of the Distribution Model Transaction: BDM5 This transaction performs a technical consistency check of the distribution model: Do the logical systems referenced exist? Are the partner profiles and ports correct? Are the filtering and conversion rules OK? Is the inbound processing properly configured? The program checks the configuration in both the sending and receiving systems, connecting to the other systems via RFC. Results are colour-coded. Consistency Check for Application Number Ranges Transaction: BD70 This consistency checks displays the number ranges in the distributed systems. When selecting this check, you specify the number range object (i.e., AUFTRAG) and the distributed system(s) for which the ranges are to be displayed. You use this information to verify that the number ranges on the distributed system are consistent with the distribution scenarios. 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 Messages ALE ALE Administration Monitoring Status Monitor for ALE
11.1.1
11.1.2
11.1.3
11.1.4
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.
11.1.5
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 Transactional RFC ALE ALE Administration Convert IDoc status Services Communication
11.1.6
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 doesnt use it if you provide a pathname. EDI_STATUS_INCOMING reads the inbound status records from the file and appends them to the corresponding outbound IDocs. This is the single case where an outbound IDoc may have status records with inbound status codes.
11.1.7
11.1.8
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.
11.1.9
11.1.10
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
11.1.10.1
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 confirmations ALE ALE Administration Monitoring ALE Audit Send audit
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 IDocs 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
11.1.10.2
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 audit statistics ALE ALE Administration Monitoring ALE Audit Evaluate
Program: RBDAUD01
Use the program RBDAUD01 on the sending system to look at the ALE Audit IDoc statistics. IDocs total is the total number of IDocs audited Queue Outbound is the number of IDocs that have not yet been sent to the other system Queue Inbound is the number of IDocs that are still being processed by the receiving system
ALE Audit records may be selected by message type, date range, etc. You can drill down into the report to see information on daily statistics, detailed information on IDocs, and cross-system links for successfully processed IDocs:
11.1.10.3
Audit IDoc Structure
11.1.11
These are the segments in an ALEAUD01 IDoc, with the fields they contain: Segment E1ADHDR o Message type Segment E1STATE o Senders IDoc number o Current status o Message fields Segment E1PRTOB o Receivers IDoc number o 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. 11.2 Exercise: ALE Monitoring In this exercise, you will explore some of the ALE Monitoring tools. 1. Run BDM5 (on your Sales system) to check the consistency of your distribution model. a. b. 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.
2. If you had any error IDocs in previous exercises, try to resend or repost them with BD87. a. NOTE: Specify your partner system on the BD87 selection screen to avoid reprocessing other students IDocs! Select todays date and execute. Using WE05, verify that all successful outbound IDocs now have a status of 12 (Dispatch OK).
3. Run BD75 (on your Sales system) to check the IDoc dispatch. a. b.
NOTE: Sending and receiving systems are not part of the BD75 selection screen. This means that if someone else runs the program, it will check the dispatch of all IDocs, including yours. 11.3 Exercise: Using the IDoc Test Tool In this exercise, you will use the IDoc Test Tool to: create and submit an outbound material IDoc create and submit an inbound Purchasing Order Release IDoc create and process an inbound IDoc from an outbound IDoc A. Outbound Testing 1. 2. 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.
3. 4. 5.
6. 7.
B. Inbound Testing 1. 2. 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?
3. 4. 5. 6. 7.
C. The Turnaround Testing Tool In this exercise, you will read an inbound IDoc from the disk file you created in the Communication Parameters exercise. 1. Execute the turnaround testing tool, transaction WE12. Set the following parameters and execute: i. ii. iii. iv. v. vi. vii. viii. ix. x. xi. 2. 3. Source: Target: Sender Partner Type: Sender Port: Message Type: the file you created earlier (/tmp/<username>) the output file. Use /tmp/<username>.in your Sales Logical system LS SAPAL2 MATMAS LS
Sender Partner Number:
Recipient Partner Number: your Warehouse Logical system Recipient Partner Type: Direction: Client: Recipient Port 2 (inbound) your warehouse system client number SAPAL2
Run WE05 and see if your IDoc is there. It should have a status of 64 (Ready to be transferred to application). Use BD87 to submit the IDoc for processing.
NOTE: These activities are for testing only. You should never do this on a production system! 11.4 Exercise: ALE Audit In this exercise, you will configure ALE Audit between two SAP systems. You will distribute a vendor record from one system to another, and acknowledge its receipt with ALE Audit. Caution: Only one person at a time can perform shaded steps. Please work quickly so that others will not be locked out for too long! 1. Maintain your distribution model (on your Sales system). Configure a message type CREMAS from Sales to Warehouse. 2. Configure a message type ALEAUD from Warehouse to Sales. Add a filter for logical message type, value CREMAS, to this message. 3. Distribute the model to Warehouse 4. Generate your model on both systems. 5. Create a vendor (transaction MK01) on the Sales system. 6. Using BD14, send your vendor to your Warehouse system.
7. Run transaction MK03 to check that your vendor was created on your Warehouse system. 8. On the Warehouse system, run transaction BDM8 to create an audit IDoc. Confirm to your Sales system, message type CREMAS, and today's date. 9. Look at the IDocs sent on both systems and check for successful processing. You should see a CREMAS IDoc and an ALEAUD IDoc on each system, with successful status codes. 10. On your Sales system, run transaction BDM7 to look at the ALE Audit statistics.
12 12.1.1
Chapter 2 Error Handling What is Workflow? SAP Business Workflow (which we will refer to as Workflow from now on) is SAP's tool that manages business processes by sending email action items to specific people in an organization. It comes delivered with the standard R/3 system. Workflow uses the standard SAPOffice email programs to deliver a required work item to the person or persons responsible for completing the work item. By using the email interface, the users do not have to "look for" the work items; instead, they simply appear in the user's inbox. The routing of work items is completely configurable, and very flexible. For example, the system can handle situations where an employee is on vacation or out sick and needs to assign another person in the organization to handle her assigned tasks. Modeling business processes with Workflow can be very complex, requiring much planning and configuration. However, using Workflow for ALE error handling is comparatively simple, and does not require a full Workflow implementation. Therefore, it is an excellent tool for handling ALE errors.
12.1.1.1
Business Objects A business object is a formal description of a piece of data on the system. Examples of business objects include customers, materials, sales orders, and G/L accounts. A business object includes all of the data passed in a single ALE IDoc and predefined methods, which are ways of manipulating and accessing that data. It is similar to a class instantiation as defined by C++ and other object-oriented programming languages. Tasks A task is a procedure that accomplishes an action in the system by executing a method of a business object. SAP predefines a large number of tasks, including many that allow the processing of various errors in IDoc handling. Users handle the errors by executing these tasks, which appear as work items in their inboxes. Organizational Plan An organizational plan in SAP describes the organizational structure of a company. The functions to create and maintain organizational plans are part of the Personnel Planning
12.1.1.2
12.1.1.3
12.1.1.4
and Development (PD) part of the SAP HR module, but we do not need to implement HR to use them in Workflow. Any organizational plan consists of five kinds of classifications: Organizational units. Each organizational unit represents a recognizable group in the organization. This may be a department, a team, a building, etc. Organizational units are hierarchical; that is, they can contain other organizational units as subordinates. For example, a department may be made up of multiple teams, or a company unit may have multiple departments. o Generally, one organizational unit forms the root of the hierarchy and contains all other organizational units as subordinates. Positions. A position represents a slot in an organizational unit filled by a single person, or shared among two or more people. Two examples are H/R Manager and A/P Clerk. Jobs. A job is a more general description of a position. A single job can describe multiple positions across multiple organizational units. There is, therefore, a oneto-many relationship between jobs and positions. Users. A user is an SAP logon user ID. It thus represents a single person. Persons. A person is a specific employee created in the HR module. In order for a person to be usable in a Workflow scenario, we must assign the person to a user, since only a user has access to the SAP mail system. This is configured as part of the HR implementation. We can assign a user or a person to any position. This is a many-to-many relationship, since a user or person can hold more than one position, and we can fill a position with more than one person. Agents An agent is simply a person who executes a Workflow work item. We can assign a task to any of the five organizational objects (organizational unit, position, job, user, or person). All users and persons that belong to the specified organizational object then become possible agents of the task. When an IDoc error occurs, the Workflow system turns the corresponding task into a work item and sends it to the inbox of all possible agents defined for the task. These agents are then known as selected agents. When one of these people executes the work item, that person is then the actual agent for the work item, and the work item disappears from the inbox of all other selected agents. The Business Workplace Transaction: SBWP Menu Path: Office Workplace The business workplace is the SAP transaction that a user uses to view all received work items. It is part of the SAPoffice email system. From the workplace a user can directly execute work items, view attachments, and send email to other users. The business workplace also has the capability of sending a work item to an alternate user if the primary user is not available (because of vacation, sickness, etc.). This is the initial screen of the business workplace, with the Inbox section expanded:
12.1.1.5
This example shows two work items waiting in the inbox. Expanding the Workflow section brings up a list of the work items in the inbox:
To execute a work item double-click on the line of the desired work item. For IDoc errors, this will bring up the IDoc error-processing screen:
12.1.2
From here, you have several options: Process will submit the IDoc for reprocessing Delete flag will mark the IDoc for deletion IDoc display lets you look at (and change) the data in the IDoc with the same interface used in WE02 and WE05. Once you successfully process the IDoc, or mark it for deletion, the work item will disappear from your inbox. Workflow Configuration We need to make some basic configurations in order for the Workflow system to work properly. These configurations are not related to the ALE system. The R/3 system can perform most of these steps automatically. Configuration Consistency Check Transaction: SWU3 Men Path: SALE Error Handling Basic Workflow Settings Workflow comes with a configuration consistency check to make sure that all of the required steps are complete. This consistency check uses a color-symbol key to show which configuration items are complete. For ALE use, all of the items under Workflow runtime system should have a green check.[3] In addition, if you are using Workflow for custom IDoc error handling, the items under Workflow development environment should have a green check.
12.1.2.1
Note: Some releases of R/3 are reported to have a bug in this transaction that results in a green check not being displayed for a configuration item even when the configuration was completed. This will not prevent successful use of the Workflow system.
[3]
12.1.2.2
Automatic Customizing The Automatic Customizing push-button attempts to make the Workflow configurations automatically. It will update the icons next to each item based on the results. If the Automatic Customizing fails to give a green check, you must perform the failed customizing steps manually. Testing the RFC Destination The Automatic Customizing will set up the Workflow RFC destination, but will not test it. You can test it manually with the Test RFC destination pushbutton. This check ensures that the RFC destination is correct and that the Workflow user can log on to the system properly. If this check fails, it generally means that the WF-BATCH user is not properly configured, or the login information does not match the corresponding information in the RFC destination. Building an Organizational Plan When you set up IDoc error handling with Workflow, you can assign a person, an SAP user, a position, a job, or an organizational unit as a possible agent. While assigning an SAP user is the easiest way, it is not the best, because you will not have the flexibility to make changes to several error configurations at once. For example, if the user designated as the Receiver of Notifications (defined later) in 500 partner profile entries leaves the company, someone must manually change all 500 of his entries. It is better to create a position for these entries, so that if the person in the position changes, you only need to make the change in one place. The organization management capabilities are far too complex to discuss here. We will show how to construct a simple organizational plan suitable for use in IDoc error handling. Transaction: PPOCW Men Path: Tools Business Workflow Development Definition tools Organizational Management Organizational plan Create To build an organizational plan follow these steps: 1. Run the Organizational Plan transaction. 2. Enter a period of validity. Use 12/31/9999 to prevent expiration of the plan. 3. In the Basic Data tab, enter a name and a description. 4. You can now build your organizational hierarchy. The Goto button changes the screen view, letting you see only organizational units, staff assignments, tasks, etc.
12.1.2.3
12.1.3
The Create button lets you create new organizational objects. Select an object, click the Create button, and the new object will be a child of the selected object. To include an existing object, find it in the search window on the left, then drag-and-drop onto the new structure.
12.1.4
5. Repeat this process until your plan is complete. 6. To assign a person to a position, find the persons user ID in the search window, then drag-and-drop the username onto the position. You can also assign more than one person to any position by setting the Staffing percentage of each. 7. You can also assign a Job to any position using the Job field. Caution: In release 4.6D, the drag-and-drop interface is buggy. You may need to collapse and reopen the display to get the destinations right. When you set the possible agents for any IDoc error-handling task, you can use any of the objects you have created: User. The work item will go to the specified SAP user. As explained above, this is rarely a good idea. Position. The work item will go the holder or holders of that position. Job. The work item will go to all holders of all positions described by the specified job. Organizational Unit. The work item will go to all members of the specified organizational unit. ALE Configuration This section describes the configuration specific to ALE processing. There are five places in the message transmission process where something can go wrong in the transmission of a message with ALE: 1. Reading the outbound partner profile.
2. Sending the IDoc to the receiving system. 3. Reading the inbound partner profile. This may be a configuration problem or an invalid received IDoc (syntax error or invalid control information) 4. Calling the application function. 5. Posting the record to the receiving database. This is generally a logical error, involving a problem with configuration or with a process problem (such as a customer on credit hold). The first four possible errors are technical errors, involving the distribution of the IDoc without regard to its business contents. An error in posting the IDoc is a logical or functional error, involving a problem with the contents of the IDoc itself, rather than its transfer. We will normally send technical and functional error notifications to different people in an organization. We can configure Workflow error handling in each of these five error situations. This table lists the areas of Workflow configuration for each possible error situation: Error situation Reading the outbound partner profile Sending the IDoc to the receiving system Reading the inbound partner profile Calling the application function Posting the document to the database Workflow configuration needed to handle the error Maintain the IDoc Administrator on the sending system Define a Receiver of Notifications in the outbound partner profile Maintain the IDoc Administrator on the receiving system Define a Receiver of Notifications in the inbound partner profile Configure processing of the corresponding Workflow task
12.1.4.1
In each case, we can define one or more possible agents to execute the corresponding error-handling task. We can use any of the organizational objects to do this. That is, we can assign all of the members of an organizational unit, a position, or a job to the task, or we can assign a single user or person. The next sections describe these configurations in detail. IDoc Administrator Transaction: OYEA Men Path: SALE Error Handling IDoc Administration The IDoc administrator, called the EDI Administrator in earlier versions, is the agent responsible for handling IDoc errors when no partner profile is available. We can set a single organizational unit, position, job, user, or person as the IDoc administrator. On the outbound system, this error generally indicates a misconfigured system, where a required partner profile is missing. On the inbound system, this error probably indicates that the system received an unexpected message type, or a message from an unknown partner. The administrator will typically fix the configuration error, and then submit the IDoc for reprocessing.
The following table describes each of the error-related fields on this screen: Field Recipient type Description The type of organizational object used to identify the possible agents. This can be an organizational unit, a job, a position, a person, or a user. The organizational object (job, position, etc.) whose members we want to notify of an error. The maximum number of IDoc syntax error status records to write to the IDoc. If we select this checkbox, the system will not trigger error handling for errors involving the IDocs status records.
Identification Max number of syntax errors Suppress warnings for status processing
12.1.4.2
Note: You must maintain the IDoc administrator on each system involved in IDoc transfer. You cannot use CTS to transport the settings. Receiver of Notifications A Receiver of Notifications is responsible for handling errors in using a partner profile. In this case, the partner profile exists, and the system can read it properly, but there is a problem in sending the IDoc (outbound) or passing it to the application (inbound). There are four places to define a receiver of notifications: The partner profile overview screen Individual partner profile entries for Message Control Individual partner profile entries for Outbound Parameters Individual partner profile entries for Inbound Parameters If an appropriate partner profile exists for the message, but it does not have an entry for the message type in question, then the system will notify the receiver of notifications listed on the overview screen. If the individual message type entry does exist, then the system will notify the receiver of notifications configured for that message type. To designate a receiver of notifications, use the partner profile maintenance transaction WE20, on the Post processing: permitted agent tab.
The following table describes each of the error-related fields on this screen:
Field Typ
Description The type of organizational object used to identify the possible agents. This can be an organizational unit, a job, a position, a person, or a user. The language to use for the message sent to the receiver. The organizational object (job, position, etc.) whose members we want to notify of an error.
Lang. ID
12.1.5
The screens for the individual message types (Message Control and In/Outbound Parameters) have the same fields. Application Processing Errors An error in processing an inbound IDoc results in the creation of a work item. The task used will generally be a foreground input method of a particular IDoc object. That is, each IDoc type defined on the system has a corresponding IDoc business object. There are methods defined for these objects to handle inbound processing of the corresponding IDocs. Here is an example, using Material Master records:
This is an SAP-supplied Workflow task, called MATMAS input error. It uses the business object IDOCMATMAS and its method INPUTFOREGROUND. To configure the error processing for this error, we must activate the event linkage for the triggering event and designate the possible agents for the Workflow task. The possible agents can be organizational units, positions, jobs, users, or persons.
12.1.5.1
Locating the Error Handling Task Transaction: PFTC_DIS Menu Path: Tools Business Workflow Development Definition Tools Tasks/Task Groups Change First, you must locate the SAP-supplied task for handling errors in the IDoc type in which you are interested. 1. Execute transaction PFTC_DIS. 2. Enter Standard Task under Task type. This indicates a standard single-step task (as opposed to a multi-step workflow). 3. Put the cursor in the Task field and use the drop-down (or press F4) to activate the search. Type the first few letters of the name of the task and press Enter. Most task names begin with the message type they handle. For example, the material master task is "MATMAS input error". 4. Alternatively, you can click on Structure search to bring up the Application Hierarchy. Find the desired task in the hierarchy. Application error handling tasks are generally in the corresponding hierarchy section, while ALE-specific tasks (e.g. Fetch messages) are in the ALE section. For example, you will find the MATMAS error-handling task under Logistics General Logistics Basic Data Material Master Standard task MATMAS input error. Double click on the task you want to copy it to the task maintenance screen.
5. Click on Display to see the task.
12.1.5.2
Activating the Event Linkage
12.1.5.3
To activate the event linkage click on Triggering events, then click on the activation button to the left of the event. This button will be green if the event is active, gray if not. Assigning the Possible Agents 1. To assign possible agents, follow menu path Additional data Agent assignment Maintain. 2. If the words General task appear next to the task name, turn off the general task attribute. To do this, click on Attributes, change the properties to General forwarding not allowed, and save. (General forwarding allowed will also work, but will allow a selected agent to forward the work item to a user not designated as an agent for the task.) This activates the distribution of the work item according to the possible agents you specify. 3. To assign possible agents to the task, put the cursor on the task name and click on Create (the left-most icon). Select an organizational object, such as a position, job, etc., and specify the specific object to use. 4. Repeat to assign additional possible agents to the task. When done, the screen should look like this:
Thats it! Inbound processing errors should now trigger the Workflow task.
13 13.1.1
Chapter 3 Using ALE for Interfaces Basic Idea
13.1.2
ALE can interface SAP with non-SAP systems. The basic idea is to use the SAP delivered ALE functionality and to make use of the ALE infrastructure. Here is an example: SAP supports a distribution scenario that allows the distribution of material master data between SAP systems. If you want to implement an interface between SAP and legacy for material master, you could use the existing ALE functionality to extract the material master data based on changes made by the user, put the data into an IDoc, and dispatch the IDoc to the target legacy system. From the sending systems (SAP) perspective, it doesnt matter if the partner system is another SAP system or not. Ideally, this interface wouldnt require any coding on the SAP side. The ALE infrastructure (Monitoring/Audit Trail/Exception handling) can be used for free! The same works for inbound interfaces. Suppose the material master interface is inbound to SAP. The ALE scenario for material master supports the processing of the inbound material master IDoc. All that needs to be done if the sending partner system is a legacy system is to fill the IDoc accordingly with legacy data. The receiving SAP system has all the functionality to process that IDoc including ALE services for user notification and exception handling. Problem of Data Mapping Conceptually, building interfaces is mainly a data mapping activity. The data elements of the source system have to be mapped to data elements on the target system. However, the underlying data structures of the two applications are almost always different. In the ALE environment this gets even more complicated because in addition to the two different application data structures we have to deal with a third one -- the IDoc. The mapping of SAPs data structures into the IDoc and vice versa is done by the IDoc processing programs. Each SAP delivered IDoc comes with two programs: one to create the IDoc and one to process the IDoc. The first program reads application data structures and puts the data into the IDoc format; the second reads the IDoc data format and puts the data into the application data structure. On the legacy side the IDoc has to be translated into the legacy systems application data structures. We can write a custom program to do this. However, often load or extract programs already exist, and they require a certain data structure layout. If this is the case, we must translate the data from the IDoc to these special structures.
13.1.3
There is usually some cross-referencing between the data elements in the IDoc and the legacy systems (e.g. material number in SAP to material number in legacy). The ALE Converter An ALE converter is an external program that bridges the gap between the SAP and the legacy systems and their different data formats by mapping SAP IDocs to the application specific format and vice versa. An ALE converter is therefore a data mapping tool. In addition to data mapping the ALE converter usually has the ability to do lookups in cross-reference tables by either keeping local lookup files or by connecting to relational databases for the lookup. SAP has a certification program for ALE converters. To be certified, a third-party ALE converter must be able to: Map to and from an arbitrary IDoc into an arbitrary layout Import an IDoc type structure directly into the converter Communicate with SAP via tRFC. The communication feature (direct communication with SAP through tRFC) in conjunction with the ability to connect to legacy databases (e.g. ODBC connection) allows us to build interfaces that completely eliminate the need for files (if desired). Therefore the ALE converter partly fulfills the role of a communication middleware. From the R/3 systems perspective it is transparent if the receiving system is another R/3 system or an ALE converter. Exporting an IDoc Type Structure Transaction: WE63 Menu Path: Tools Business Communication IDoc IDoc Basis Documentation IDoc type (parser) Transaction WE63 will output the structure of an IDoc Type in a text format. SAP-certified interface tools must be able to read this format to import the IDoc Type. You can specify the Control, Data, or Status record structure, or any combination of these.
13.1.3.1
13.1.4
ALE Interface Infrastructure
13.1.5
An ALE infrastructure consists of 3 components: External System ALE Converter SAP system The SAP system communicates with other systems by creating and processing IDocs, while the non-SAP application communicates with other systems in its application specific format. The ALE converter translates the SAP IDocs to the application specific format and vice versa. The ALE converter communicates with SAP using tRFC or file based methods. Some ALE converters are able to connect to external application databases (for example via ODBC). If files are involved, we will need a subsystem for data transport (e.g. ftp shell scripts, NFS, or messaging middleware). The ALE converter is the centerpiece of an ALE-based interface infrastructure. It does translation, cross-referencing and, to a certain degree, communication. Benefits of Interfacing with ALE The benefits of using ALE for interfaces include: SAP predelivers a complete interface infrastructure, including: o Audit Trail/Status Management o Error Handling with Workflow o Secure Communication through tRFC Programming, if needed at all, is minimal, and compatibility between SAP releases is guaranteed ALE may provide better performance than other techniques, because: o IDoc programs usually use Direct Update to post the data in IDocs. This is the fastest method available, because a function module directly adds the data to the database tables without the overhead of a Batch Input process. o The timing of IDoc processing is flexible. We can schedule IDoc processing for times when the system load is low. Data Export from ALE There are at least two ways to send outbound IDocs to a legacy system: Configure the outbound partner profile to use a file port. Point the outbound port to an RFC destination that connects to a program that can handle the IDoc data with an RFC interface
13.1.6
SAP provides a utility program called RFCEXEC to accept RFC calls from an R/3 system and to run programs or shell scripts on the application server. 13.1.7 13.1.8 Data Import to ALE When a legacy system sends IDoc into an SAP system, it can use one of two RFC-enabled function modules. It calls these function modules with an RFC call. INBOUND_IDOC_PROCESS o The function module that the ALE layer itself uses o Takes IDocs as parameters and passes them in as part of the RFC call EDI_DATA_INCOMING o Takes a filename and a file port as parameters o Reads the IDocs from a file on the application server (I.e. not passed in the call SAP provides a utility program called STARTRFC to execute RFC function modules on any R/3 system from an application or presentation server. 13.2 13.2.1 Using ALE with Middleware What is Middleware? The word middleware has several meanings. It can be any one of a confusing array of message-queuing, application development environments, object development environments, database access, distributed transaction processing, messaging communications, or Remote Procedure Call (RPC)-based communications. For the purposes of distributed applications, and Enterprise Application Integration (EAI) we will be talking about Message-oriented Middleware (MOM). MOM is a system or set of systems providing the services needed to manage the execution of applications in a distributed environment. According to the Gartner Group, 40% of the average IT budget is spent on systems integration. This has two implications: that systems integration is important, and that it is difficult.
The primary aim of middleware is to provide easy connectivity between different applications. Common characteristics of Message Oriented Middleware include: Real-time data transfer Messages are based on business rather than technical design considerations. An example of a message might be Create Sales Order Although real-time, the applications are usually processed asynchronously, using queues for data transfer. Once the sending process places a message on a queue, then it can forget about it, and continue with other tasks. Similarly, the receiving process only needs to pick up the message when it is ready to process it. Some examples of products in the middleware area are NEON MQSI, MQ-Series, and Mercator.
13.2.2
EAI Using a Message Broker
13.2.3
Central to the middleware architecture is a message broker, sometimes called a hub. Each application connects only to the message broker, rather than to other applications. Thus, we have fewer point-to-point links than we would need without the broker. The message broker has two primary functions: Routing - to ensure each application receives messages it needs. For example, perhaps both applications A and B should receive a Sales Order if its number begins with a 1, otherwise only application B should receive it. The middleware products support such complex data-based rules. Mapping/Transformation - to ensure that the business data contained in the message makes sense to the application. For example, perhaps Sales Order numbers created in application C need to be prefixed with a 6 before being sent to application D. Most middleware products allow any complexity of mapping and transformation, and may often use large database look-up tables. All messages must be in a format that the receiving application can understand. In order to accomplish this, each application that interfaces with the broker will need an adapter to convert the data format. The adapter normally takes the data in an application specific format, and places it on a queue in a format the message broker can understand. In the reverse direction, the adapter reads the data from the message broker queue and converts it to the application-specific format. There are commercially available adapters for common products, but sometimes we may need to write a custom adapter. Middleware and ALE The communication container for ALE, the IDoc, is also a message containing a unit of business data. Therefore, conceptually, ALE & IDocs provide SAP support for messageoriented middleware. Instead of communicating with other SAP systems, the SAP system sends and receives IDocs only to and from the message broker, normally through an adapter. Examples of commercial SAP adapters are NEON SAPLink and IBM Link for R/3. These adapters accept IDocs, either using the IDoc file interface or (more commonly) tRFC. The RFC connection is configured in a very similar way to the RFC for a remote SAP system, so above this level, SAP has no knowledge of whether the IDoc sender/receiver is a SAP system or the adapter. Middleware Design Considerations Here are some design considerations when building an interface to a middleware system using ALE:
13.2.4
Addition of new applications. A central message broker architecture provides a robust and scalable architecture for distributed systems. This architecture makes it easy to add new applications in the future with minimum work. Since the message brokers mapping, transformation, and routing abilities are far superior to those of the SAP system, it is easier to reformat data in the broker's adapter and send it to new systems. Processing time and throughput. There is additional overhead in the message processing time between an application creating the message and an application receiving a message. This can be a serious delay. With complex transformation, database look-ups, and routing rules, it is important to ensure that the middleware architecture can handle the transaction volumes. Similar design considerations when choosing between ALE and ABAP also apply to middleware design. When a high volume system-specific batch interface is required, a point-to-point ABAP may be the best option. Data transformation. ALE rules provide some degree of data transformation and routing. However, other applications may not have this degree of flexibility, and it may be sensible to contain this information within one system - the message broker -- rather than distribute these rules around the system Development time. Middleware development time is significant, and we need to take it into account when planning interfaces. It is likely that both ALE and middleware development might be needed, as well as custom programming for the legacy application posting and extraction routines. Conciseness of specifications. Since field-by-field mappings and transformations are an essential part of a middleware development, the specifications must contain the detailed information required to build the specified interface. 13.3 13.3.1 Interface Management Development Time Estimates These estimated development times come from previous PwC projects: Complexity High Medium Low 13.3.2 13.3.3 Data Conversions Data conversions into SAP can have a very large impact on interface development. If the data conversion team loads a lot of data at once, this may cause the system to create an excessive number of outbound IDocs, most of which the receiving systems will not use. Therefore, you should design ALE interfaces so that they can be easily turned off and on. There are a number of different ways of doing this, and the method used will depend on the interface. Should we use ALE or ABAP? Here are some considerations in the decision to use an ALE interface, or to develop an ABAP-based interface: Existing interfaces. When an existing interface design is established then it makes sense to maintain the design to minimize the development needed. SAP Standard Scenarios. If SAP supplies needed functionality then it makes sense to use it. Description Large Custom IDoc / Multiple messages Enhanced Scenario / At most 2 messages Standard Scenario Functional Specs 10 12 days 8 10 days 6 8 days Construction/Testing 30 days 20 days 10 days
13.3.4
There are many standard upload programs available in SAP. This would suggest an ABAP approach for the interface, since the program already exists and there should be minimum effort to build the interface o There are many standard ALE scenarios provided in the SAP system. SAP supports these scenarios and enhancement is quick and easy. Where there is a standard ALE scenario for an interface then this suggests that a middleware solution may be best. Timing Requirements. Timeliness of data transfer to the sending or receiving application. ALE supports real-time and near-real-time data distribution. A need for immediate transfer suggests a real-time ALE/middleware approach. Periodic processing (once or more per day) suggests a middleware batch processing option, or an ABAP-based interface. Infrequent processing (weekly or monthly) suggests an ABAP batch option. Transaction Volume. ALE is usually slower than an ABAP interface. If very high transaction volumes are likely, then ABAP is probably a better choice. Number of senders or receivers for common sets of data. When similar data is needed by many receiving systems, or sent by many sending systems, the use of a middleware-based architecture makes more sense, since the message broker can manage the distribution of data to multiple recipients. Complexity of SAP processing. In some instances the interface may have to perform multiple transactions in SAP, including controlling the process between these transactions. In these cases an ABAP solution is more appropriate in order to maintain SAP integrity for restart or error management. Programmers' Skills. ABAP is generally better understood than ALE, and there are more skilled practitioners. o 13.4 Exercise: Reading IDocs from a Disk File In this exercise, you will read an inbound IDoc from the disk file you created in the Communication Parameters exercise. The custom transaction ZCONV converts fields in your IDoc file to values appropriate for input. It reads a file /tmp/<username> and writes a new file /tmp/<username>.in. It does essentially the same thing as the turnaround test tool, but it leaves the converted IDoc in a file without starting inbound processing. 1. 2. Execute the transaction ZCONV. You will need to specify the client number of your warehouse system, and then click on Execute. Using transaction SE37 (Function Builder), execute the function module EDI_DATA_INCOMING. This function module reads IDocs from a file. i. ii. iii. iv. Enter the function module name and click on Single test. Turn on the Upper/lower case checkbox. Type the name of your converted file (/tmp/<username>.in) in the PATHNAME field. Type the name of your file port (FILE##) in the PORT field. The function will not use this field, since the pathname field is specified, but it must contain a valid value. Click on Execute.
v. 3.
Run WE05 and see if your IDoc is there. It should have a status of 64 (Ready to be transferred to application)

ALE Training

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ALE Training

Uploaded by

Copyright:

Available Formats

PricewaterhouseCoopers LLP

SAP ALE Training Program

PwC Consulting SAP ALE Training Program SAP Release 4.6C

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

Chapter 1 ALE Overview Review of SAP System Terminology

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

Example distribution scenario: Blanket Purchasing

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

IDoc Types and Message Types

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

Example Material Master

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

Chapter 3 Modeling ALE Distribution Distribution Models

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL

SAP ALE Training Program

This is PricewaterhouseCoopers PROPRIETARY MATERIAL