Ale Whitepaper
Ale Whitepaper
Ale Whitepaper
R/3'S
APPLICATION LINK ENABLING (ALE)
Written by Kevin Wilson
Material developed by Kevin Wilson with the assistance of Johan Delport
CONTENTS
Contents i
The Advanced Guide to Implementing SAP R/3's ALE Technology
Contents ii
The Advanced Guide to Implementing SAP R/3's ALE Technology
Contents iii
The Advanced Guide to Implementing SAP R/3's ALE Technology
Contents iv
The Advanced Guide to Implementing SAP R/3's ALE Technology
7 GENERAL................................................................................................................. 7-1
7.1 Glossary................................................................................................................ 7-1
7.2 ALE Diagrams of use...........................................................................................7-7
7.2.1 ALE Configuration setup diagram....................................................................7-7
7.2.2 ALE Message Type Flow Diagram...................................................................7-7
7.3 Setting up ALE to send messages from 1 client to itself..................................7-7
7.3.1 Setting up the dummy client logical system.....................................................7-9
7.3.2 Maintain Logical System..................................................................................7-9
7.3.3 Define RFC Destination...................................................................................7-9
7.3.4 Define RFC Port............................................................................................7-10
7.3.5 Setting up model messages...........................................................................7-11
7.3.6 Automatic Generation of Partner Profiles.......................................................7-11
7.3.7 Creation of Filter Messages...........................................................................7-12
7.3.8 Create Partner Profiles..................................................................................7-12
7.3.9 Standard ALE Client......................................................................................7-13
7.3.10 Dummy Client................................................................................................7-14
7.4 ALE User Guide..................................................................................................7-15
7.5 Solution Pack.....................................................................................................7-15
7.6 ALE Related SAP programs..............................................................................7-17
7.7 ALE Related Tables............................................................................................7-31
7.8 ALE Transaction Codes.....................................................................................7-38
INDEX........................................................................................................................ INDEX-X
FIGURES
Figure 1: ALE Outbound Processing.........................................................................1-3
Figure 2: ALE Inbound Processing...........................................................................1-5
Figure 3: ALE project team tasks during ALE Assessment phase...........................2-2
Contents v
The Advanced Guide to Implementing SAP R/3's ALE Technology
TABLES
Table 1: ALE team roles and time dependencies.....................................................2-1
Table 2 : ALE Performance Test Options..............................................................6-84
Table 3 : ALE Performance Test Rusults................................................................6-86
Contents vi
CHAPTER 1
AN INTRODUCTION TO
ALE
1 INTRODUCTION TO ALE
The purpose of this publication is to provide a SAP consultant with a methodology on
implementing SAP R/3's ALE technology. For the executive who is looking into
deploying ALE the first chapter will be of benefit as well as the summary for each of
the remaining chapters which will give a good indication as to the level of effort that
will be required in order to implement ALE.
It highlights the areas to look at; it gives example documentation and describes the
implementation process in detail. It is not an idiot’s guide to implementing ALE.
Detailed knowledge of the ALE functionality together with project management skills
will ensure a smooth ALE implementation.
The Guide is divided into the following chapters:
Introduction to ALE 1
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
Introduction to ALE 2
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
Create
Createmaster
master
IDoc M Determine
Determinereceiver
receiver
IDoc
Field
Fieldconversion
conversion
Version
Versionconversion
conversion
Control CC Sending CC
Database Control
data
Sending
control
data control
Introduction to ALE 3
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
General rules can be specified for field conversions; these are important for
converting data fields to exchange information between R/2 and R/3 Systems. For
example, the field "plant" can be converted from a 2-character field to a 4-character
field.
The conversion is done using general EIS conversion tools (Executive Information
System).
Version change
SAP ensures that ALE functions between different R/3 System releases. By
changing the IDoc format you can convert message types of different R/3 releases.
SAP Development use the following rules when converting existing message types:
Fields may be appended to a segment type;
Segments can be added;
ALE Customising keeps a record of which version of each message type is in use for
each receiver. The correct version of the communication IDoc is created in the ALE
output.
Dispatch control
The resulting IDocs (it is possible that several IDocs could be created in the receiver
determination) are referred to as communication IDocs and are stored in the
database. The dispatch control then decides which of these IDocs should be sent
immediately. These are passed to the communications layer and are sent either
using the transactional Remote Function Call (RFC) or via file interfaces (e.g. for
EDI).
Controlling the time of dispatch:
The IDocs can either be sent immediately or in the background processing.
This setting is made in the partner profile.
If the IDoc is to be dispatched in the background, a batch job has to be
scheduled. The dispatch cycle may be chosen at will (daily, weekly, etc.)
Controlling the amount of data sent:
The packet size can be defined. The packet size is the number of IDocs that are
sent in a single operation.
If an error occurs in the ALE layer, the IDoc containing the error is stored and a
workflow is created. The ALE administrator can use this workflow to process the
error.
Introduction to ALE 4
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
Version
Versionconversion
conversion
Segment
Segmentfiltering
filtering
Field
Fieldconversion
conversion
Delivery
Delivery
control
control
A
A Serialisation
Serialisation Process
ProcessIDoc
IDoc
Introduction to ALE 5
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
IDocs can be passed to the application either immediately on arrival or can follow in
batch.
You can post an inbound IDoc in three ways:
1. by calling a function module directly: A function is called that imports the IDoc
directly. An error workflow will be started only if an error occurs.
2. by starting a SAP Business Workflow. A workflow is the sequence of steps to
post an IDoc.
3. by starting a work item A single step performs the IDoc posting.
The standard inbound processing setting is that ALE calls a function module directly.
For information about SAP Business Workflow alternatives refer to the online help for
ALE programming.
1.1.3 Mass Processing Of IDocs
The option of performing mass processing is provided for reasons of performance.
This involves sending packets consisting of several IDocs to an application workflow.
The IDoc packets are put together using collective processing in the output
processing before dispatch takes place. Each packet contains IDocs of a single
message type intended for a single recipient.
These IDocs are then all communicated in a single step.
There are some scenarios that cannot deal with mass processing of incoming
documents. This is always the case if the application that imports the data has to
execute a batch input one batch at a time.
In such a case the packet size has to be set to 1 in the output processing.
1.1.4 Cross-System Document Trace (Audit)
The technique of using IDocs to distribute data guarantees the security of the data
transfer between systems, since the transfer is always repeated should a
transmission error occur or the connection get broken. The purpose of ALE Audit is
to check the cross-system IDoc flow and posting in the partner system.
ALE Audit provides an automatic and seamless tracing facility for individual
documents in distributed applications. Documents that have been sent from one
application to another can also be traced from start to finish. Another feature of ALE
Audit is that the processing status of a document can be queried from a central point.
ALE Audit periodically sends information on the processing status of messages in
the target system back to the sender system. This allows cross-references to be
created in the sending system. Based on this data, the following information can then
be ascertained for any application document communicated via ALE, even if the data
containers (IDocs) have been reorganised in the meantime:
the system to which the document was sent,
the processing status of the IDoc in the target system,
the ID of the application document in the target system, if known.
The second main component of ALE Audit is a statistics database for IDocs that is
maintained on the sending system. Key figures for the current status of the IDocs in
the sending system and recipient system are updated daily (based on the creation
Introduction to ALE 6
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
date of the IDocs) at the level of the message type, sending system and recipient
system of the IDocs.
Confirmations are sent asynchronously using an IDoc of the ALEAUD message type.
The recipient system is responsible for initiating confirmation messages, since the
time at which the update is made is of great importance. If the sending system were
to request a confirmation too soon, the error queue would quickly overflow with
IDocs in the target system that is waiting to be imported by the application. In order
to improve performance, the confirmation messages are sent as periodic batch jobs
rather than being sent immediately that the IDoc is imported by the application.
Therefore if the IDoc is part of a time-critical action, the batch job for this message
type should be scheduled with a suitably short repeat interval. The statistics
database is updated at the same time as the confirmation is sent.
The ALE distribution model is responsible for determining the sending systems to
which a confirmation should be sent and the message types for which a confirmation
is required.
Statistics reports can be called up with the IDoc monitor. The statistics are updated
using a push-button. If necessary, an RFC is started which fetches up-to-date
information from the target system. There is also the option of completely
regenerating all the statistics, which may be of use in "emergencies" - if changes to
the system time or date have rendered the existing statistics inconsistent, for
example.
ALE Audit supports all possible sender-recipient pairs of logical systems. In each
case, the recipient has to note the IDoc number of the sending system.
1.1.5 Error Handling
The following is a description of how an error that occurs during ALE processing is
handled:
The processing of the IDoc causing the error is terminated.
An event is triggered.
This event starts an error work item:
The employees responsible will find a work item in their workflow inboxes.
An error message is displayed when the work item is processed.
The error is corrected in another window and the IDoc can then be resubmitted for
processing.
If the error cannot be corrected, the IDoc can be marked for deletion.
Once the IDoc has been successfully imported, an event is triggered that terminates the
error work item. The work item then disappears from the inbox.
Introduction to ALE 7
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
The customer details his specific distribution in the customer distribution model.
Once the control data is distributed the control data cannot be changed on the
receiving systems. All changes are made to the central system and transported to
the receiving systems.
Introduction to ALE 8
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
maintain and distribute control data objects from a central system, thus
synchronizing important configuration data. This is important when trying to decentralize
functions, yet keep them integrated
couple R/2 and R/3 systems, in some instances,
couple SAP and external systems, via IDocs (Intermediate documents) and an
external translation mechanism.
ALE also provides you with tools that allow you to:
manage the ALE process seamlessly. These tools include the reprocessing of
communication errors, business process and technical error handling and routing via
workflow, archiving of data
keep audit trails of all the ALE communication
configure the ALE solution in many different ways in order to tailor make a
solution for the user
Introduction to ALE 9
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
Project Leader
Structure the Project Teams
Integrate the Team Findings and Decisions
Set Objectives
Develop Guiding Principles
Develop a Detailed Project Plan
Phase 2: Create As Is Picture
Analyze Current Business Processes
Map Business Processes into R/3
Identify Data and System Interfaces
Inventory Existing Hardware/Software
Install R/3
Begin Project Team Training
Phase 3: Create To Be Design
Develop High-Level Design
The R/3 Hierarchy
Gain User Acceptance
Detailed Design
Scenarios, Scripts, and Tables
Iterative Prototyping Using Tables
User Communications
Gain Final Acceptance
Phase 4: Construction and Testing
Develop a Comprehensive Configuration
Populate the Test Instance with Real Data
Build and Test Interface Programs
Write and Test Reports
Test the System
User Testing
Phase 5: Actual Implementation
Operation mode
After Implementation
Moving into the Future
Introduction to ALE 10
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 1
In terms of ALE there are basically 5 phases of the ALE project that need to be
completed sequentially:
1.3.1 Phase 1: The Assessment and Project strategy phase
Set up a small, skilled, project team, look at the business needs, map these to ALE,
determine gap and implications, prototype if necessary, agree and sign-off scope.
This equates to the setting the focus phase.
1.3.2 Phase 2: The Design phase
In this phase the overall system design needs to be planned and documented with
the following considerations: client strategies, naming standards, distribution
settings, future flexibility, audit requirements, technical impact, performance, DRP
and archiving strategies.
1.3.3 Phase 3: The Configuration phase
Take the design and confirm the business requirements, before commencing with
the basis configuration, functional configuration, QA and testing and sign-off.
1.3.4 Phase 4: The Development phase
Functional specifications need to be drawn up to cover any gaps discovered during
the design phase. These need to be developed by the ALE \ ABAP team making use
of technical specifications, These documents are then used to develop and configure
the new solution, followed by QA, testing and sign-off.
1.3.5 Phase 5: The Operations phase
Lots of considerations needs to be taken when moving your solution into production
including the following: Implement support organisation structure, define support
roles, capacity planning, job monitoring, failure recovery and problem resolution
processes.
Each of these phases is discussed in more detail in the following chapters.
Introduction to ALE 11
CHAPTER 2
THE ALE ASSESSMENT PHASE
2 ALE ASSESSMENT
This section describes how to plan and set up an ALE project.
The first thing that needs to be done is to set up a team that will perform the actions
required in this phase as well as subsequent phases.
Distributable functions;
Common master data;
Control data implications;
3 ALE DESIGN
3.1 Project team tasks
3.2 Deliverables
3.2.1 ALE Naming Standards
Set the standards for all configuration and development objects, including: Logical
system, Dummy Logical system, RFC Destinations, Global company codes, Global
business areas, Customer Distribution Model, Reduction of IDocs, Conversion rules,
Object types, Class types, ALE Background jobs: Housekeeping, Active monitoring,
IDoc jobs.
For development consider: Process codes, Function modules, Object types, IDoc
types and message types.
3.2.2 ALE Design Document
Details business process, functional impact, technical impact boundaries, workflow
requirements, timing of jobs, ...
3.2.3 ALE Change Management Procedure
Schematic diagram of up to date client configuration status, configuration change
request procedure, ALE configuration checksheet.
3.2.4 ALE Migration Strategy
How are you going to put the various clients into production, timing, implications on
business processes.
3.2.5 ALE Project Deliverables
Short description of the deliverables that the team must produce during the life cycle
of the project.
4 ALE CONFIGURATION
This section contains documents describing how to configure ALE. These documents
range from generic configuration guides to specific configuration Templates.
The details of configuring the basis area are described in section 4.2.
4.1.3 Functional configuration
Following the basis configuration is the functional configuration:
Create a Customer Distribution Model (CDM);
Add appropriate message types and filters to the CDM;
Generate outbound partner profiles;
Distribute the CDM to the receiving systems; and
Generate inbound partner profiles on each of the clients.
Keep your ALE configuration diagram up to date and follow change management
procedures rigorously, as you begin to configure. Areas you need to document well
include the finer details involved with an ALE implementation:
Listings / classes;
Object types / Workflow tasks;
Conversion rules;
Filters & Segment filters;
Change pointers / Fields activating change pointers;
Serialization;
Partner profiles: Immediate Vs Background;
Background job definition and scheduling;
Control data required to be in synch; and
...
See section 9 for the detail on how to configure each of these areas.
4.1.4 QA & testing
Demonstrate / workshop this solution with the business. Document and draw up
functional specifications (done by the business) of any extensions to existing scenarios
or additional scenarios required.
4.1.5 Sign-Off
Sign-off each client configuration with the business owners.
6. Choose Replace.
7. Save your entries.
8. Repeat steps 2-4 for the different clients.
4.2.4.1 Procedure
1. In the IMG, choose Cross-Application Components -> Distribution (ALE) -> Basic
Configuration -> Maintain number range for ports
2. Perform function. The screen for number range object maintenance appears. The
object name EDIPORT has already been pre-set.
3. Choose Goto -> Number ranges -> Interval -> Display. An interval must be entered
for number range number 01. If no interval is entered, proceed as follows:
4. Go Back and choose Interval -> Maintain.
5. Enter a number range for number range number 01
6. Choose Interval -> Check to check whether your entry is error-free.
7. Save your entry.
Notes on the transport
You transport number range objects as follows:
4.2.5.1 Procedure
Check first whether a number range exists in number range 01 for the number range
object EDIDOC. Proceed as follows:
1. Perform function for EDIDOC. The screen for number range object maintenance
appears. The object name EDIDOC has already been pre-set.
2. Choose Goto -> Number ranges -> Interval -> Display. An interval should be entered
for number range number 01. If no interval is entered, proceed as follows:
3. Go Back and choose Interval -> Maintain.
4. Enter a number range for number range number 01.
5. Choose Interval -> Check to check whether your entry is error-free.
6. Save your entry.
Notes on the transport
You transport number range objects as follows:
In the initial screen, choose "Interval - Transport".
Note that all intervals for the selected number range object are deleted in the target
system first. After the import, only the intervals you export are present. The number
statuses are imported with their values at the time of export.
Dependent tables are not transported or converted.
4.2.6 Maintain number ranges for IDoc types and segment version
Settings which are defined in the EDI area are to be maintained here.
For this merging, the EDI interface assigns numbers internally for Intermediate
Document types, for unique identification.
The system can only generate the numbers if a number range is entered for the
number range object EDIDOCTYP in number range 01.
4.2.6.2 Procedure
Check first whether a number range interval in the number range 01 exists for the
number range object EDIDOCTYP. Proceed as follows:
1. In the IMG, choose Cross-Application Components -> Distribution (ALE) -> Basic
Configuration -> Maintain number ranges for IDocs types and segment
2. Perform function.
3. The screen for number range object maintenance appears. The object name
EDIDOCTYP has already been pre-set.
4. Choose Goto -> Number ranges -> Interval -> Display. An interval must be entered
for the number range 01.
5. If no interval has been entered, proceed as follows:
6. Go back and choose Interval -> Maintain.
7. Enter a number range interval for the number range 01.
8. Choose Interval -> Check to check whether your entry is error-free.
9. Save your entry.
Notes on the transport
You transport number range objects as follows:
In the initial screen, choose "Interval - Transport".
Note that all intervals for the selected number range object are deleted in the target
system first. After the import, only the intervals you export are present. The number
statuses are imported with their values at the time of export.
Dependent tables are not transported or converted.
4.2.7 Maintain number range for change pointers
In this section, the number ranges are maintained for the change pointers.
The change pointers are needed to generate Intermediate Documents from the
application documents. For these pointers, internal numbers are assigned for unique
identification. The system can only generate the numbers if a number range is
maintained in number range 01.
Example
Number range From number To number
01 0000100000 1000000000
Standard settings
SAP delivers the number range for change pointers.
4.2.7.1 Procedure
If you must create number range 01, proceed as follows:
1. In the IMG, choose Cross-Application Components -> Distribution (ALE) -> Basic
Configuration -> Maintain number range for change pointers
2. Perform function. The screen for number range maintenance appears. With Interval
-> Display, you can see whether a number range was already maintained.
3. If no number range is maintained, choose Interval -> Maintain.
4. In the "Maintain Intervals" screen, choose Edit -> Insert interval.
5. Enter the number of interval 01 and a number range. Finish the entry with Insert.
6. Choose Interval -> Check to check whether your entry is error-free.
7. Save your entry.
Notes on the transport
You transport number range objects as follows:
In the initial screen, choose "Interval - Transport".
Note that all intervals for the selected number range object are deleted in the target
system first. After the import, only the intervals you export are present. The number
statuses are imported with their values at the time of export.
Dependent tables are not transported or converted.
4.2.8 Set up ISO codes
Currencies, units of measurement and country codes are held as international
standardised ISO codes so that all messages sent can be understood on any system.
This means that the ISO codes have to assigned to the SAP-internal units as
necessary.
Note that a functional team usually performs this procedure.
4.2.8.1 Procedure
Define the ISO codes for the units in use here.
Use the following IMG functions for this:
In the IMG, choose Cross-Application Components -> Distribution (ALE) -> Basic
Configuration -> Set up ISO codes
OR
Currencies:
Global Settings -> Currencies -> Check currency codes
Units of measurement:
Global Settings -> Check units of measurement
Countries:
Global Settings -> Set countries -> Define countries
4.2.9 Make basic settings for Workflow
The workflow runtime environment has to be set up in each client. Workflow will be
used for error handling in ALE. Technical errors are distinguished from application
errors and each type of error (technical/functional) can be sent to a different person/role
in the organisational structure.
The setting up of the workflow runtime environment will be covered in a procedure that
explains how to set up workflow on SAP. When the actual document becomes
available, it will be referenced from here.
4.2.10 Deleting change pointers copied from source client
When a client is created using a client copy, some open change pointers may be copied
from the source client that is actually not needed in the target client. These “unwanted”
change pointers can be deleted by running a program RBDCPCLR, or executing
transaction BD22.
4.2.11 Archiving Idocs copied from source client
Because Idocs are client dependent, they get copied to the target client from the source
client with a client copy. Whenever a client copy is done, these copied Idocs need to be
archived and deleted to remove them from the newly created client.
Refer to the Idoc archiving strategy and procedure for the procedure to archive Idocs.
When archiving and deleting Idocs in a newly copied client, all Idoc statuses must be
enabled for archiving (to ensure that all Idocs are archived and deleted), refer to section
2.2 of the Idoc archiving strategy and procedure document (transaction WE47).
4.2.12 Activating change pointers
If you want to be able to distribute changes to master data, you must write change
pointers at the same time as the change documents.
If you want change pointers to be written by the system, you must maintain a number
range for them. This can be done in the section Number ranges -> Maintain number
range for change pointer.
Once you’ve activated the change pointer for the particular message type then any
changes made to this master data will have an IDoc automatically generated and
forwarded according to the distribution model.
4.2.12.1 Procedure
In this section it is possible to activate the writing of change pointers . This activation
must be done at two levels (general, per message type).
4.2.13.1 Procedure
1. Execute SM59
2. Click on R/3 links and choose Edit -> Create;
3. The RFC destination name must be the same as the logical system name in order
for the port to be automatically generated.
4. The type of RFC destination is 3.
5. Enter the required parameters dependent on the type.
For an R/3 link, that is, for example, the name of the RFC destination, the name
of the partner machine, logon parameter ALE-BATCH with password init.
6. Select the Destination -> TRFC options function from the menu.
7. Enter the value 'X' into the 'Suppress backgr. job in case of comms. error' field.
8. Save and exit.
Notes on the transport
The maintenance of the RFC destination is not a part of the automatic transport and
correction system. Therefore the setting has to be made manually on all systems.
instability and various other issues. We will, instead, be using the transport and
correction system to keep the control data in sync between the various clients.
Use transaction BDM5 - Consistency check (Transaction scenarios) and the control
data section for your applicable ALE Message Type to determine what the applicable
control data objects are.
4.3.2 Reduction of IDocs (BD53) Client Independent
Maximal intermediate document types for master data are supplied in the standard SAP
System. The business would, in some cases, require that certain information not be
distributed, and in these cases the respective IDoc would need to be reduced. As part of
the reduction you can select the segments and fields of these intermediate document
types which you wish to distribute. To do this you must activate the segments and fields
that you require and generate a new message type, which satisfies your requirements.
Reduction is carried out for logical message types behind which an Intermediate
Document type exists.
Mandatory segments and mandatory fields cannot be deactivated.
4.3.2.1 Procedure
1. Enter Transaction SALE
2. Execute the function: Distribution Scenarios -> Master data distribution ->
Reduce IDoc types for master data.
3. To reduce a maximum message type, create a new logical message type. To do this,
enter a new name beginning with Z followed by 5 meaningful characters that will
allow the user to identify the initial IDoc. E.g.: MATMAS reduced to ZMATMS.
4. Enter the reference message type (for example, MATMAS).
You can use the following message types as reference message types for the
various master data objects:
Reference Master data objects
DEBMAS Customer master
CREMAS Vendor master
GLMAST G/L account master
MATMAS Material master
4. Enter a short text for the reduced message type.
5. The structure of the reference message type is copied to the new message type and
displayed.
6. Double clicking on it can explode the structure.
7. Activating a segment:
Place the cursor on the segments required.
4.3.3.1.1 Procedure:
1. Enter the IMG: Distribution Scenarios -> Global Organisational Units -> Set Up
Global Company Codes.
2. Choose (by double clicking) the Cross-system company codes option.
3. From the new screen click on the New Entries button.
4. Enter the relevant global company codes.
5. Save the global company codes by clicking the Save button.
6. Go back to the previous screen by clicking on the Back button.
7. Choose (by double clicking) the Assign company code -> chart of accts option
8. Enter CAEK next to each global company and save. Choose back
9. Choose (by double clicking) the Assign company code -> Cross-system company
code option.
4.3.4.1 Procedure
1. Log into the respective ALE reference client 4xx, as this is the reference client where
we maintain our customer model for that particular client series.
2. Perform SALE, and Distribution Customer Model
3. Perform the 'Maintain customer distribution model directly' function (BD64).
4. Specify the customer model you want to maintain and the logical system that is to be
the sender of the messages.
5. Choose the receiving systems to which the sending system must forward message
types.
6. For each receiving logical system allocate the message types necessary for
communication to the receiving systems.
Click your cursor on the logical system where the message type is to be sent. Start
with ALEyyyC4xx (where yyy is the system name).
Click on the Create Message Type button.
Type the required message type in the Log. Message type pull-down box.
Click on the Transfer button. The message type should then be added to the 4xx
logical system.
Repeat the above procedure for all the required logical systems.
Save the model by clicking the Save button.
7. Create filter objects (vendor number, customer number, global company code, and
so on) for the message types.
8. Save the entries.
You cannot maintain a message type between the same sender and receiver in more
than one customer distribution model.
Except for the 'SUBSYSTEMS' customer model, which serves to model the local
message flows for each customer distribution model as a system owner. Only the
owner is authorised to modify the model.
To transport the customer distribution model you should use the Distribute customer
model function of the IMG.
4.3.5 Changing the owner of the distribution model
4.3.5.1 Procedure
1. Choose the 'Maintain ownership of customer distribution model' function.
2. Change the owner logical system to the required one for the required customer
distribution model.
3. Make sure that all changes will be distributed to all systems that know the
corresponding model. To do so, you can use the correction and transport system.
4.3.6 Set up Filter Objects (BD64)
If filter objects are required then you need to set them up in the customer distribution
model. To create a filter objects see the section on Object types.
4.3.7 Procedure
1. Enter the IMG -> Distribution Customer Model -> Maintain Customer Distribution
Model Directly.
2. Choose (by double clicking) the Maintain message flow to subsystems option.
3. Select the sending system as the Logical and the required Customer model.
4. Click on the Change Icon. After expanding all the logical systems to see the
message types proceed as follows,
5. Click your cursor on the required message type in the logical system where the
message type is to be sent
6. Click on the Create Filter object button.
7. Type the required field or hit F4 for a lookup in the Object type pull-down box and
the required value for that specific field in the object box. (EG: BUKRS for
company code is the object type and GC3000 is the global company code object)
8. Click on the Transfer button. The filter object and the value should then be added to
the message type in the receiving logical system.
9. Repeat the above procedure for the other message types requiring filters for this
receiving system.
10. Save the model by clicking the Save button.
11. Repeat the above procedure for all the other logical systems’
models.
4.3.8.1 Procedure
1. Log into sending system client
2. Enter the IMG -> Cross-Application Components -> Distribution (ALE) ->
Communication -> Generate Partner Profiles. Execute the function (BD82)
3. Enter the required customer model
4. Enter the following for Receiver of notifications:
S as the type for position
XXXXX, where XXXXX is the number related to the ALE Administrator role. (Eg.
50000085)
5. Enter the output mode (background, immediately) and the package size for
outbound processing.
Recommendation:
Output mode = Collect IDocs
Package size = 50
6. Enter the output mode (Immediate processing) for inbound parameters
7. Click on the execute icon.
8. If the profiles were not generated successfully, follow the steps provided in the
guide to set up the respective areas that are highlighted as being faulty:
RFC destinations;
Generate sending partner profiles; and
Define logical systems (ALE Technical Configuration Procedure)
4.3.9.1 Procedure
1. Execute the transaction WE20 in the sending client. Enter the number of the
logical system as the partner number.
2. Use LS (logical system) as the partner type.
3. Choose the menu path Partner -> Create. If the partner already exists then choose
the outbound parameter button.
4. Make entries in the Partner class and Partner status fields.
5. The inbound or outbound parameters must be created according to the direction in
which communication takes place. Maintain outbound parameters for the respective
partner system in the sending system and inbound parameters for the respective
sender in the receiving system.
6. Inbound parameters:
Enter the message type appropriate to the scenario (see also Distribution
scenarios).
Enter the process code for the message type.
Enter the processing type. We suggest batch no override with express flag
unless volumes are extremely small in which case immediately can be used.
Enter the position of ALE Administrator in order to be informed in case of error.
7. Outbound parameters:
Enter the message type according to the scenario;
Enter the receiving port or create a new one;
Set output mode to Transfer IDoc immediately or Collect IDocs. See
performance section of this document to decide on what setting to make.
Default to immediately until further investigation.
Set package size (number of Intermediate Documents processed at any one
time). See performance section of this document to decide on what setting to
make. Default to 1, but set to 50.
4.3.10.1 Procedure
1. Enter the IMG: Distribution customer model -> Distribute customer model.
Execute the function. (BD71)
2. Double click on the Distribute customer model box.
3. Type the required distribution model into the Customer model box
4. Click on the execute icon.
5. The following screen should then indicate that the model data has been sent correctly
to the relevant clients.
6. If the model was not sent successfully to some of the systems, follow the steps
provided in the guide to set up the respective areas that are highlighted as being
faulty:
RFC destinations;
Generate sending partner profiles; and
Define logical systems (ALE Technical Configuration Procedure)
4.3.11 Maintain receiving system partner profile automatically (BD82)
Follow the same procedure as per Section: 4.3.8 on Page 14.
4.3.12 Maintain receiving system partner profile manually (WE20)
Follow the same procedure as per Section: 4.3.9 on Page 14.
4.3.13 ALE Audit
ALE Audit enables the sender system to monitor the processing status of dispatched
IDocs in the receiver system. This section describes what ALE Audit is and how it is
used.
ALE Audit enables the sender system to monitor the processing status of dispatched
IDocs in the receiver system. The receiver system periodically sends confirmations back
to the sender system, which are logged in IDoc status records and in individual audit
tables.
The R/3 sender system has an analysis program for the audit database, which provides
an overview of all dispatched messages and for any defective IDocs, details of current
status, IDoc number and error message on receiver system.
Status records generated from the confirmations contain the following values:
39 - IDocs in receiver system (ALE Service) and still being processed
40 - Application document processing not completed successfully in receiver system.
41 - Application document processed in the receiver system. Processing completed
independently of the processing status in the receiver system. The message in the
status record is the same as the corresponding message in the IDoc status record in
the receiver system.
4.3.13.2.1.1 Procedure
1. You can maintain various values for your variants:
logical sender system,
message type,
message variant,
message function,
Creation dates of the Intermediate Documents.
2. Create appropriate variants for the RBDSTATE report.
3. To do this, execute the function, enter "RBDSTATE", click on variants and choose
Change.
4. Enter a name for the variant and choose Create.
5. Maintain the attributes for the variant.
The logical sending system is the system to which Audit confirmation should be
sent.
Message type, message variant and message function specifies the messages
for which there should be confirmations.
If the fields are not maintained in the variant, then the system uses the possible
settings from the customer distribution model.
The creation date specifies the selection time range. If nothing is specified here,
then all messages since the last time the report was executed will be covered.
6. Save the variant.
7. Create as many variants as needed to take account of all message flows for which
ALE Audit should be performed.
4.3.13.2.2.1 Procedure
1. Define a job, as per naming standards, with the RBDSTATE step and a variant you
have created.
2. Schedule the job as a periodic job (daily).
3. Save the job.
4. Create a job for each of the previously defined variants.
Further notes
If possible arrange for there to be a small time buffer between the end of the selection
period of the variant and the time at which the job is executed. This should help prevent
the queue of Intermediate Documents not yet processed from overflowing.
E1STATE contains the IDoc number of the sender system (Field DOCNUM), the current
status in the receiver system and the message fields from the current status record. In a
remote system the DOCNUM value depends on how the IDocs were previously
dispatched to the R/3 System. The sending system IDoc number is the number
assigned when the INBOUND_IDOC_PROCESS in field EDI_DC-DOCNUM was called.
The R/3 System saves this number unless it is the initial value.
Note:
The DOCNUM field must contain a valid R/3 IDoc number. If there is not an IDoc for the
given number this entry is ignored. The Status field must contain a valid R/3 status
value for inbound IDocs.
Segment E1PRTOB
E1PRTOB contains the receiver's IDoc number and, if existing, the application object
generated in inbound processing. The application object is in the format of the BOR link
tools. I.e. it comprises a BOR object type, Object ID and logical owner system.
4.3.14 Conversion rules
There are various methods of field conversion:
Allocation of constants (=> SET),
Allocation of ranges in the sender field for target values in the receiver field (=>
GROUP),
Combination of various sender fields for target values in one receiver field (=>
COMBINE),
Specification for all non-defined GROUP or COMBINE cases (=> SET_R).
If no conversion rules have been defined for a given field then the default action is to
copy the contents of the sender field into the receiver field (=> MOVE).
NOTE
When referring to company codes or business areas in the rules you must specify the
global equivalent of the company code or business are.
This section defines the conversion rules.
This entails the following steps being performed:
1. Rule definition:
The rules are always defined per segment.
2. Rule maintenance:
Rule maintenance specifies the conversion on field level with defined rules.
3. Allocating rules to IDoc:
The allocation specifies when the rule should be applied. This is sender, receiver and
message type specific.
4.3.14.1.1 Procedure
1. Execute the transaction BD62.
2. In the menu, choose Edit -> New entries.
3. Enter a name for the conversion rule according to the naming standards.
4. Enter the segment type to which the conversion rule is to apply. To determine what
segments are in what IDocs use the IDoc documentation transaction WE60.
5. Save the entries.
You can assign a specific value for the recipient field in the case of a specific value or
value interval of the sender field.
That can, for example, be the conversion of a plant from the R/2 System (from 2
characters) to the R/3 format (plant 01 then becomes 0001).
Thus, storage locations 0001 to 0009 of plant 0001 in the sender system can be
converted to storage location 0100 in plant 0001 in the receiver system.
Note
You must define rules for each field that do not overlap.
In our example, for instance, it is not possible to convert storage locations of a
second plant to the same target storage location 0100.
14. You can also define an "Otherwise" case with the conversion rule
SET_R.
15. Save your maintenance.
Example SET_R
If you determined a GROUP or a COMBINE, a constant can be defined for all values,
which do not fall into the value interval.
Consider the GROUP example: you could for example define that the plant "0002"
should be specified for all values other than "01".
4.3.16.1 Procedure
1. Execute the transaction BD55. Enter the message type that is to be allocated to the
rule.
2. Enter the sender and receiver system with partner type. The partner type is LS for
almost all scenarios.
3. Enter the segment type and the conversion rule defined for it.
4. Repeat steps two and three for all further rules.
5. Save your allocations.
4.3.17 Setting up workflow
The workflow runtime environment has to be set up in each client before ALE will be
able to utilise workflow for error notifications. The setting up of the workflow runtime
environment will be detailed in a workflow set-up procedure.
ALE can use workflow to notify users/positions in the organisation structure about
errors. These errors can be put into two categories: technical- and application errors.
Currently both these types of errors will be monitored by the ALE administrator position
in the organisation, but it is possible to notify different positions of technical- and
application errors.
The following procedures will explain how to set up ALE so that the position/user gets
notified of firstly technical- and secondly application errors.
Since listings are used as classifications, they are maintained in the master data
transactions. A master data object can be added to a list by classifying it.
The listing groups together all the objects belonging to a single class, and this class
belongs to the ALE class type for the object.
Listings are maintained within the classification. To do this, the following steps have to
be taken:
For an object (for example, the table MARA for material), you must create a class
type, marked as a distribution class type.
You define the listings for the distribution class type.
Afterwards, the listings (with class type) are allocated for the logical systems.
The distribution via listings must be recorded in the customer distribution model.
4.3.18.1.1 Procedure
1. Perform transaction O02D. A list of the objects defined by SAP is displayed.
2. For the master data, you need the following objects:
Master data Object
Material MARA
Vendor LFA1
1. By double clicking on the object, you open up the suboptions for the object.
2. Go to the structure item Class Types and create a new class type. If the class already
exists, return to the menu and choose “Display/change class type parameters” or use
transaction O02E. Proceed to step 4.
3. Enter a description. (MAT for material & use 010 for Vendor)
4. Characterise it as a distribution class type. For each object, one class type can be
indicated as distributable.
5. Set the 'Multiple Classification allowed' indicator.
NB! The creation or modification of class types requires “Repository Access” which
should be arranged with the Basis/Environment Management team.
Further notes
If you have allocated listings, which belong to a distribution class, to a logical system,
you cannot transfer the distribution indicator to another class type, since otherwise
inconsistencies occur in the configurations.
Class types, which can be distributed, can be defined for all objects available in the R/3
classification. If such a class type is created, you can create listings for distribution of
this object.
4.3.18.2.1 Procedure
1. Select the object type for the class type:
MARA Material
LFA1 Vendors
2. Select the distribution class type for which you want to create the status.
3. Create the status 1.
4. Enter a text.
5. Select the following options for this status:
Maintenance is allowed for the class (Cl.Maintce.).
The classification of objects is allowed (Classif.).
Selections can be made for objects in the class (Sel. alwd.).
6. Make this status the default status (Default).
Example
The following status has been defined for MARA, class type MAT:
Status Text Cl.Maintce Classif Sel. alwd. Default
1 Released X X X X
The following statuses are defined for LFA1, class type 010:
4.3.18.3.1 Procedure
Create classification statuses according to your requirements.
You can also copy classification statuses to create new ones. You can copy from the
classification statuses of any class type.
To do this, proceed as follows:
1. Choose step Maintain classification statuses -> Copy classification status.
2. Select the object type you require.
3. Select the class type whose classification statuses you want to copy.
4. In the dialog box, enter the target class type for the classification statuses. You can
display the possible entries for the class type and select one.
5. Select Continue to edit your copy.
Note
For each status, you can only set one parameter.
You cannot use a parameter in more than one status - only in exactly one status.
There must be a status for which the parameter "incomplete" is set.
4.3.18.4.1 Procedure
1. Perform transaction CL01. Choose the distribution class type and enter a name
for the listing (Class).
2. In the detail screen, enter:
a listing description,
The class status, which describes whether a class may be managed.
A class group, if an allocation to a certain group is to be made.
You must define this group beforehand.
3. Save your settings.
Notes on the transport
Since listings cannot be distributed, you will have to create listings (classes) on all
systems. It is not possible to use the transport system.
4.3.18.5.1 Procedure
1. Execute the transaction BD68 and enter the logical system that is to receive the
listings.
2. In the menu, choose Edit -> New entries.
3. Enter the message type to be distributed.
4. Enter the listing (class) for this message type.
5. Set the Push/Pull value to '2' (Push).
6. Save your entries.
Further notes
The allocation of the master data to the listings is made in the ALE task level menu or in
master data maintenance.
4.3.18.6.1 Procedure
1. Maintain the Customer distribution model as described in the section earlier.
2. Add the object type 'LISTING' (filter) for the appropriate message and select the
object value 'YES' for the system connection that is to use a listing.
4.3.19 Schedule active monitoring
Active monitoring is usually scheduled as a periodic background job. The system
determines whether the number of IDocs in a status group exceeds a particular
threshold. If this is the case, a message is sent to the integrated inbox of the specified
receiver.
During selection, IDocs, which meet the selection criteria, are analysed. The possible
status values of the IDocs are assigned to status groups. If the current status value of
an IDoc is assigned to one of the status groups passed to the report via parameters, the
IDoc is regarded as critical. If the number of critical IDocs exceeds the specified value,
the system will regard this as a problem situation and sends a message to the specified
Workflow receiver.
You can schedule report RSEIDOCM to carry out the active monitoring periodically.
You must make valid entries for the receiver, receiver type, status group and number of
critical IDocs fields for the selection run to work. You can also limit the IDoc selection
further using additional parameters.
4.3.19.1.1 Procedure
1. Execute the transaction SE38 and enter "RSEIDOCM". Click on Variants and
choose Change
2. Enter a name for the variant and choose Create
3. Fill in the input fields as required
4. Choose the Continue button (or F6)
5. Maintain the variant attributes
6. Save the variant
4.3.19.1.3 Procedure
1. Define a job containing the step RSEIDOCM and your own variant.
2. Schedule the job to run periodically, specifying a period which suits your needs (ex.
hourly, daily etc.)
3. Save the job.
4. Create a job for each defined variant.
4.3.20 Change pointers
The following 2 steps need to be performed to get activate a change pointer for a
particular message type.
appropriately sized IDoc packets. The IDocs can be dispatched in batch or in the BALE
transaction code.
Some distribution scenarios cannot support mass processing of inbound IDoc packets.
This is especially true if the application sending the IDocs uses the ABAP/4 command
CALL TRANSACTION USING. In this case the outbound parameter PACKETSIZE must
be set to "1".
To get a list of function modules that can be mass processed, select Enhancements ->
Inbound -> specify inbound module in ALE Customising. INPUTTYP is "0".
4.3.22 Schedule IDoc dispatch
Some IDocs are not sent immediately, but are collected and then sent all together. The
report RSEOUT00 must be scheduled in order that these IDocs can be sent.
The following steps are necessary for this:
Define variants for the report.
Schedule jobs, each with the report and a variant as the step.
Further notes
Numbers are assigned internally for IDocs that have been sent. Number ranges have to
be maintained for this purpose. You do this under menu entry Basic settings -> Maintain
number ranges for IDocs.
4.3.22.1.1 Procedure
1. You can maintain different values for sending:
port,
partner type, partner role
partner number,
Message type.
2. SAP recommends variants with partner number and message type.
3. Create corresponding variants for the report RSEOUT00.
4. To do this, execute the transaction SE38 and enter "RSEOUT00", click on Variants
and choose Change.
5. Enter a name for the variant and choose Create.
6. Enter the message type (for example, MATMAS).
7. Maintain the attributes for the variant.
8. Save the variant.
9. Repeat the process until variants have been created for all message types.
4.3.22.2.1 Procedure
1. Define a job with the step RSEOUT00 and a variant that you have maintained.
2. Schedule the job as a periodic job, where the period must be adapted to your
requirements (for example, hourly, daily, and so on).
3. Save the job.
4. Create a job for every variant defined beforehand.
4.3.23 Schedule IDoc processing
Jobs for inbound processing are scheduled in this section. These jobs must be
scheduled for the following situations:
Processing the IDocs that are not imported immediately on arrival, but periodically in
the background (settings in partner profile). Use Report RBDAPP01.
Importing IDocs that are stored in the system, but which were not transferred to the
application due to exceptional situations. (Report RBDMANIN). With selected
parameters you can also schedule a job to collect IDocs that have not yet been
processed, for instance, because of a locking problem.
To do this, the following settings are necessary:
Define variants for a report.
Schedule jobs, with the report and a variant as the step.
Further notes
The report RBDMANIN allows intermediate documents which have already been
cancelled once with errors (e.g. Status: 51 error in transfer to application) to be read into
the application again. It is also possible to schedule a job with selected parameters, in
order to collect up intermediate documents which could not be processed, e.g. because
of a locking problem.
Numbers are assigned internally for intermediate documents that have been sent.
Number ranges have to be maintained for this purpose. You do this under menu entry
Number ranges -> Maintain number ranges for intermediate documents.
4.3.23.1.1 Procedure
1. Define variants with the following values or a subset:
logical message type
message variant
message function
partner type of the sender
partner number of the sender
partner role of the sender
2. SAP recommends the definition of variants with the logical message type and the
partner number. However, which IDocs are imported and how frequently depends on
your requirements.
3. For all partner and message types for which no immediate processing is carried out
you must create a variant of the report RBDAPP01.
4. SAP recommends that you define a variant without values in order to enter the
remaining IDocs.
4.3.23.2.1 Procedure
1. Define a job with the step RBDAPP01 or RBDMANIN and a variant maintained by
you.
2. Schedule the job as a periodic job where the period must be adapted to your
requirements (for example, hourly, daily, and so on).
3. Save the job.
4. Create a job for every variant defined beforehand.
5. Create a job with the variant without values to import the IDocs that were not
transferred to the application due to exceptional situations.
6. This job must have a period that is larger than the maximum period of the other
jobs.
4.3.24 Schedule Status conversion after successful RFC
When outbound IDocs have been successfully passed to the communication layer, they
are assigned the status "data passed to port OK".
This status does not, however, indicate that the communication via an transactional
RFC was successful. Therefore a report should regularly be started that checks whether
the communication was successfully completed and if so, changes the status of the
IDoc.
To schedule the RBDMOIND report, the following must be done:
Define variants for the job,
Schedule job, with the report and one variant in one step.
4.3.24.1.1 Procedure
1. Perform the transaction SE38 and enter "RBDMOIND"; Click on Variants and
choose Change
2. Enter a name for the variant and choose Create
3. Delete the date in the field 'IDoc creation date (from)'
4. Specify a value in the field 'IDocs per Commit Work'
5. (SAP recommends the number 100)
6. Maintain the attributes for the variant
7. Save the variant
4.3.24.2.1 Procedure
1. Define a job with the step RBDMOIND and the variant you have maintained.
2. Schedule the job as a periodic job; adapt the period to meet your requirements (e.g.
hourly, daily etc.).
3. Save the job.
4.3.25 Serialisation (BD57) Client Independent
With maintenance of the serialisation types, the system can check whether overtaking
occurred during arrival of the IDoc types. This way, it is recognised if an older purchase
order change arrives before a current change arrives, for example.
4.3.25.1 Procedure
1. Execute transaction BD57
2. When making an assignment to a new message type, you should use the switch new
entries.
3. For each of your new message types you should enter an ALE object type as a link
type and also as a serialisation type.
4. If you change the assignment, then you should overwrite the entries for the
corresponding message type.
5. Save your entries
4.3.26 Object types
An ALE object type specifies the field of an IDoc in which an object, for example, plant,
is stored. An ALE object type specifies the field of an IDoc in which an object, for
example, plant, is stored.
The ALE objects are used to create links between IDocs and applications objects, to
control the serialisation, to filter messages in the customer model and to use listings.
4.3.26.2 Assign object types (Links and serialisation) (BD57) Client Independent
If you have developed your own message types and/or IDocs then you must maintain
object types for the links.
If you want to check the serialisation for a message type, then you must maintain
object types for the serialisation. If no serialisation object has been maintained for a
given message type, then the serialisation will not be checked for this message type.
4.3.27.1.1 Procedure
1. Perform function BD56. Enter the message type.
2. Generate new entries for the respective partner system.
3. Save your work.
Further notes
You cannot filter any required segments out.
You must ensure that all segments, which are in the hierarchy under a segment, are
also filtered out if you filter the "parent segment".
4.3.28 Transaction scenarios (BDM5)
The functional expert in this area would typically do this section.
If the ALE scenario is considered to be a transaction scenario then the consistency
check for that scenario needs to be run against the respective message type. All errors
in this consistency check needs to be resolved functionally.
Requirements
The message types for the transaction need to have been maintained in the customer
distribution model.
4.3.28.1 Procedure
1. Run transaction BDM5
2. Click on consistency of application
3. Double click on the require message type for the transaction scenario you need to set
up
4. Correct the red lines indicating errors.
4.4 Deliverables
4.4.1 ALE Configuration Sign-Off Procedure
Agree on the process to follow during QA and Production phases of the project. During
production, transactions cannot be posted to test the correctness of the solution...
ZMATMS,ZMATMC,ZMATSM ZMATMS,ZMATMC,ZMATSM
ALEAUD
Reference Client ALEAUD
4xx
ALEAUD
ALEAUD
ZMATMS,ZMATMC,ZMATSM ZMATMS,ZMATMC,ZMATSM
E1MAKTM Segment:
Language Key
Material Short Description
E1MTXHM Segment:
Function
Texts: application object
Text Name
Text Id
Language Key
SAPScript: Format of a text
E1MTXLM Segment:
Function
Tag Column
Text Line
ZMATMC
This Message Type is used to distribute the changes to Material master items to the
group clients, 5xx to 8xx, and contains the following fields:
E1MARAM Segment:
Material Number
Creation Date
Name of user who created the object
Date of last change
Name of user who changed record
Maintenance status
Material Type
Industry Sector
Material Group
Old Material Number
Base Unit of Measure (deactivate)
E1MAKTM Segment:
Language Key
Material Short Description
ZMATSM
This Message Type is used to distribute the Material \ services used in the internal
charges solution, to the group clients, 5xx to 8xx, and contains the following fields:
E1MARAM Segment:
Function
Material Number
Creation Date
Name of user who created the object
Date of last change
Name of user who changed record
Maintenance status
Deletion flag for all material data
Material Type
Industry Sector
Material Group
Base Unit of Measure
E1MAKTM Segment:
Language Key
Material Description
E1MARCM Segment:
Plant
Delete flag
Purchasing Group
E1MVKEM Segment:
Sales Organisation
Distribution Channel
Delete flag for material data of Sales Org. / Distr. Channel
Material Statistics Group
Item category group
Delivering Plant
Account Assignment group for this material
E1MLANM Segment:
Departure Country
Tax Category 1
Tax Classification 1
Tax Category 2
Tax Classification 2
E1MTXHM Segment:
All fields in the long text header segment.
E1MTXLM Segment:
All fields in the long text line segment.
3. Filter objects
ZMATMS
Client: 5xx Client: 6xx Client: 7xx Client : 8xx
LISTINGS YES LISTINGS YES LISTINGS YES LISTINGS YES
ZMATMC
Client: 5xx Client: 6xx Client: 7xx Client : 8xx
LISTINGS YES LISTINGS YES LISTINGS YES LISTINGS YES
ZMATSM
Client: 5xx Client: 6xx Client: 7xx Client : 8xx
MATKL INTCHARGE MATKL INTCHARGE MATKL INTCHARGE MATKL INTCHARGE
VKORG 1000 VKORG 3000 VKORG 4000 VKORG 5000
WERKS 1130 WERKS 3110 WERKS 4600 WERKS 5150
4. Partner profiles
Sending system
ZMATMS & ZMATMC
The following settings need to be set in the outbound partner profile for ZMATMS
and ZMATMC:
Collect IDocs
Packet size: 50
Receiving systems
ZMATMS & ZMATMC
The following settings need to be set in the inbound partner profile for ZMATMS
and ZMATMC:
ZMATMC
DMAKT KEY
DMAKT MAKTX
DMAKT SPRAS
MARA AENAM
MARA BISMT
MARA KEY
MARA LAEDA
MARA MATNR
9. ALE Audit
ALEAUD is to be enabled for each of the group clients, 5xx to 8xx as follows:
Message Type: ALEAUD; Filter Object: MESTYP; Filter Object value: ZMATMS
10. Jobs
The following jobs need to be set up for of the clients 4xx to 8xx. As described.
Outbound
The following jobs are scheduled on the ALE reference client, 4xx.
Z_ALE_ZMATMS_OUT_4xx:
Step 1: RBDMIDOC; Variant: Z_ZMATMS (All IDocs created this month of type
ZMATMS)
Step 2: RSEOUT00; Variant: Z_ZMATMS (All Idocs of type ZMATMS)
Step 3: External program, Name: /bin/sleep; parameter: 60; Target host:
system name in which the job is being scheduled.
Step 4: If Maestro is NOT to be used: Raise event ZA145xx (Where xx is client
series where the event must be raised); Name: /bin/remsh; Parameter:
recmach -l zzzadm -n ./sapevt ZA145xx -p ZMATMS pf=./profile; Target host:
Machine you are running job on. (zzz: target host name; recmach: Receiving
machine name)
Step 5 - 7: As above for each client.
Periodically: 5 minutes, Job class: B
Inbound
The following job is to be scheduled on each of the group clients, 5xx to 8xx.
Z_ALE_ZMATMS_IN_xxx:
Step 1: RBDAPP01; Variant: Z_ZMATMS (All IDocs of type ZMATMS)
Periodically: Raised on event ZA14xxx (As above)
4.4.4 ALE Basis Configuration Procedure
Details how to perform the basis configuration for ALE. Used by the Basis team.
4.4.5 ALE Workflow Configuration Procedure
Details how to configure the workflow error message handling for ALE.
imply inconsistencies across clients. Eg. Cost centers can be deleted, yet there are
transactions posted against them.
4.5.5 Information Distributed
The business needs to indicate clearly what data is required to be distributed and what
data is not. The ALE administrator needs to ensure that all the fields that are required to
be distributed are available for distribution in the applicable IDoc for that ALE scenario.
If this is not the case then an extension is required for that ALE scenario. (For any ALE
development or extension please follow the ALE Scenario Development Procedure)
PS: This is not a trivial exercise. Allow for at least 2 weeks to complete. See
development section for the detail.
4.5.6 Field conversion
Do any of the fields need to assume different values when being distributed? This
needs to be clearly documented by the user.
If so the ALE administrator needs to identify where the applicable rule would be most
suited, on the inbound or the outbound side. He also needs to be aware of the
conversion rule functionality to ensure that the requirement is within the bounds of the
functionality provided for.
4.5.7 Conditions of distribution
Does the required data need to go to a certain client based on certain information
contained in the IDoc? If so, filters need to be defined and documented. The users need
to specify this requirement in detail.
The ALE administrator needs to ensure that that particular field is available, as a filter
object, for the ALE scenario in question, otherwise he will need to add it.
4.5.8 Transfer Initiation Strategy
2 options are available for certain of the ALE scenarios:
Automatic creation of IDocs through change pointers; and
Manual creation of IDocs done by the user.
The ALE administrator needs to check that change pointers exist for the required ALE
scenario, as all of them are not available. If a change pointer is not available then one
needs to be developed (Not documented anywhere - Would require SAP specialist help)
4.5.9 Mass processing
The number of IDocs that are to be created influences the settings made in the partner
profiles for the various message types. The users need to give a clear indication of the
volumes, frequency and timings of these bulk creations.
Various jobs need to be scheduled to process IDocs collected on the outbound side as
well as to process them in the background on the inbound side. These settings will be
defined in a separate document detailing the ALE performance tuning options and
settings.
4.5.10 Serialization
Is there a need to implement this feature? Does it matter if an IDoc that was created
after 1 IDoc is processed on the receiving side before the first one? If so, the ALE
administrator needs to implement this feature. Areas where this may be important is for
the transaction scenarios, where the ORDERS message must get to the receiving
system prior to an ORDCHG coming through for that same order.
4.5.11 ALE performance
IDocs are fundamental to Application Link Enabling; optimal performance in ALE
processing is synonymous with optimal performance of IDocs.
In ALE processing IDocs are:
created in the R/3 sender system
transferred to the communication layer in the R/3 sender system
Used when R/3 sender and receiver systems communicate.
updated in the receiver system
You can optimize IDoc handling in one or more of the following ways:
Controlling IDoc Events
Processing IDocs in Parallel
Packet Processing
Managing IDoc Communication
These settings will be defined in a separate document detailing the ALE performance
tuning options and settings. They are also documented in the Detailed ALE
Configuration Guide.
4.5.12 Error notifications
Who is going to receive the error notifications of each of the scenarios, if at all? By
default we suggest the ALE administrator, but if an applicable person, in the business,
has the required skills and is willing to assume the role, the functional errors can be split
and forwarded to that person.
The ALE administrator would then need to set up the applicable tasks and positions, as
well as perform the required configuration to enable it.
If it is decided not to implement the workflow error notification functionality the ALE
administrator would need to continuously monitor WE05 for errors on each of the
applicable clients.
2 Neat ways of implementing more proactive fault reporting would be to implement
either of the following:
Implement SAP workflow integrated to your MS Mailbox. This will allow all your
error messages to be routed to one central mailbox. This stops the ALE
administrator from having to log into every client.
Redevelop the inbound ALEAUD function module to extract errors and either
send a SAP mail message or initiate an external fault reporting system with the
relevant details.
Configuration of ALE is a relatively simple task but the implications of doing it incorrectly
will have a vast impact on a production system. It therefore needs careful attention to
detail and well trained and competent ALE support staff available to correct any issues
that may arise.
5 ALE DEVELOPMENT
This section contains all generic documents related to ALE custom scenario
development.
going to be many of these segments in each IDoc. IE. When line items are
passed via IDocs), click on Segment editor
Enter a description for your segment type and create
Enter a description for your segment, enter each field required in your IDoc, in
our case type LIFNR across for Field name, DE structure and DE
documentation, repeat for XBLNR and press enter to validate.
Save and generate, press back
To release the segment choose Goto, Release from the menu
Check the box on the line of your new segment
Save, back and enter
Your IDoc type structure should be displayed with your new segment
Save and back
To release the IDoc type choose Extras, Release type from the menu and Yes
Your IDoc is now ready for use. If you need to add fields or segments to your IDoc
type, you will need to cancel the release of the IDoc type as well as the segment
release using a similar procedure followed above (except now you uncheck the
release box for the segment and you choose cancel release for the IDoc type).
5.2.2.3.3 Link message to IDoc type (WE82 & BD69) Client independent
To link the message type to the IDoc type follow these next few steps:
Enter transaction WE82 (ALE -> Extensions -> IDoc types -> Maintain message
type for intermed. Structure -> EDI: Message Types and Assignment to IDoc
Types)
Click on change icon to enter change mode
Click on New entries to create the link
Enter the message type ZINVRV and the BasicIDoc type as ZINVRV01
5.2.2.3.4 Maintain object type for message type (BD59) Client independent
The ALE objects are used to create links between IDocs and applications objects, to
control the serialisation, to filter messages in the customer model and to use
listings.
For our own message type and IDoc you must maintain object types for the links.
If you want to check the serialisation for the message type, then you must maintain
object types for the serialisation. If no serialisation object has been maintained for
a given message type, then the serialisation will not be checked for this message
type.
To add an object type to our message type, follow these next few steps:
Enter transaction BD59 (ALE -> Extensions -> ALE object maintenance ->
Maintain object types)
Type in your message type ZINVRV and press enter
Click on New entries
Enter your object type, LIFNR (We need to use the vendor as a filter object),
the segment name where LIFNR resides, Z1INVRV, a number 1 for the
sequence followed by the actual field name LIFNR
Save and exit.
You have now created an object that we’ll use as a filter object in the customer
model to direct the flow of messages to the various logical systems based on the
vendors in the filter of the message type ZINVRV.
We now need to add our new message type to the distribution model.
Choose the receiving systems to which the sending system must forward
message type ZINVRV to.
For each receiving logical system allocate the message type necessary for
communication to the receiving systems as per ALE configuration procedure.
Create filter objects (in our case LIFNR as the object type with the associated
vendor number, 0000018001 with leading zeros, in the object area) for the
message types.
Save the entries.
NOTES:
You cannot maintain a message type between the same sender and receiver in
more than one customer distribution model.
Only the owner is authorised to modify the model.
To change the owner of a model, choose the 'Maintain ownership of customer
distribution model' function. Make sure that all changes will be distributed to all
systems that know the corresponding model. To do so, you can use the correction
and transport system.
To transport the customer distribution model you should use the Distribute customer
model function of the IMG as described below.
After you have defined and distributed the customer model, you will have to maintain
the partner profiles locally. To do this read the ALE configuration procedure.
Enter the output mode (background, immediately) and the package size for
outbound processing.
Requirements
The customer model must be maintained.
RFC destinations must be maintained.
The customer model must be distributed.
To ensure that the appropriate persons in charge are informed if a processing
error occurs, you must make settings in: Error processing Maintain organisational
units.
*--- Populate the IDoc segment’s field with the required data
CLEAR Z1INVRV.
Z1INVRV-LIFNR = DOC_ITEM-LIFNR. “Store vendor number for filter
Z1INVRV-XBLNR = DOC_HEAD-XBLNR. “Billing number
IDOC_DATA-SEGNAM = C_INVREV_SEGNAME. “Segment name
IDOC_DATA-SDATA = Z1INVRV. “Segment data
APPEND IDOC_DATA. “Populate IDoc internal table
*--- Move the control data info required for the distribution
IDOC_CONTROL-MESTYP = C_INVREV_MESTYPE.
IDOC_CONTROL-DOCTYP = C_INVREV_IDOC_TYPE.
INPUT_METHOD BDWFAP_PAR-INPUTMETHD N
MASS_PROCESSING BDWFAP_PAR-MASS_PROC N
Exceptions
WRONG_FUNCTION_CALLED
ENDCASE.
PERFORM REV_INV.
ENDLOOP.
PERFORM UPDATE_IDOC_STATUS.
ENDLOOP.
*--- Now we can build the bdc table to call the reversal transaction start of screen 109
CLEAR BDC_TAB.
BDC_TAB-PROGRAM = 'SAPMV60A'.
BDC_TAB-DYNPRO = '109'.
BDC_TAB-DYNBEGIN = 'X'.
APPEND BDC_TAB.
*--- Document number
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'KOMFK-VBELN(01)'.
BDC_TAB-FVAL = IT_Z1INVRV-XBLNR. "Billing document number
APPEND BDC_TAB.
*--- OK Code for screen 109
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'BDC_OKCODE'.
BDC_TAB-FVAL = 'SICH'.
APPEND BDC_TAB.
*--- Now we can call transaction 'VF11' with the populated bdc table. The transaction is called inside the idoc-
contrl loop, so a transaction will be called for every idoc (journal). the transaction is called in no-display mode
('N') because this code runs in background as it is called by ale. The update is specified to be synchronous
('S') because we have to wait for the result to update the idoc status correctly.
CALL TRANSACTION C_TCODE USING BDC_TAB MODE 'N' UPDATE 'S'.
*--- Store the return code for use in another form (status update)
RETURN_CODE = SY-SUBRC.
*--- Here we check the return code, if there was an error, we put the transaction in a bdc session for the user
to review and correct.
IF SY-SUBRC NE 0.
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING
CLIENT = SY-MANDT
GROUP = 'ZINVRV'
USER = C_ALE_USER
KEEP = 'X'.
CALL FUNCTION 'BDC_INSERT'
EXPORTING
TCODE = C_TCODE
TABLES
DYNPROTAB = BDC_TAB.
CALL FUNCTION 'BDC_CLOSE_GROUP'
EXCEPTIONS
NOT_OPEN =1
QUEUE_ERROR = 2
OTHERS = 3.
ELSE. "No problems
C_EXISTS = 'N'.
* Select from the billing document table to get sales doc number
SELECT * FROM VBRP WHERE VBELN = IT_Z1INVRV-XBLNR.
* Select from the sales document table to get user status number
SELECT SINGLE * FROM VBAP WHERE VBELN = VBRP-AUBEL AND
POSNR = VBRP-AUPOS.
* Select from the status table to change the user status to pending
SELECT * FROM JEST WHERE OBJNR = VBAP-OBJNR AND
STAT LIKE C_USER_STATUS.
IF JEST-STAT = C_US_PENDING. "User status is pending
JEST-INACT = C_UNCHECKED. "Make pending the active
status
UPDATE JEST.
C_EXISTS = 'Y'. "I.E. An entry is already in table
ELSEIF JEST-INACT = C_UNCHECKED AND JEST-STAT NE
C_US_PENDING.
JEST-INACT = C_CHECKED. "Make everything else inactive
UPDATE JEST.
ENDIF.
ENDSELECT.
IF C_EXISTS = 'N'. "I.E. Pending has never been a status before
JEST-OBJNR = VBAP-OBJNR.
JEST-STAT = C_US_PENDING.
JEST-INACT = C_UNCHECKED. "Make pending the active status
INSERT JEST.
ENDIF.
ENDSELECT. "Select from VBRP (Billing document table)
ENDIF.
ENDFORM. " REV_INV
FORM UPDATE_IDOC_STATUS.
*--- Now we check the CALL TRANSACTION return code and set IDOC status
CLEAR IDOC_STATUS.
IF RETURN_CODE = 0.
WORKFLOW_RESULT = '0'.
IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
IDOC_STATUS-STATUS = '53'.
IDOC_STATUS-UNAME = SY-UNAME.
IDOC_STATUS-REPID = SY-REPID.
IDOC_STATUS-MSGTY = SY-MSGTY.
IDOC_STATUS-MSGID = SY-MSGID.
IDOC_STATUS-MSGNO = SY-MSGNO.
IDOC_STATUS-MSGV1 = SY-MSGV1.
IDOC_STATUS-MSGV2 = SY-MSGV2.
IDOC_STATUS-MSGV3 = SY-MSGV3.
IDOC_STATUS-MSGV4 = SY-MSGV4.
RETURN_VARIABLES-WF_PARAM = 'Processed_IDOCs'.
RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
APPEND RETURN_VARIABLES.
ELSE.
WORKFLOW_RESULT = '99999'.
IDOC_STATUS-DOCNUM = IDOC_CONTRL-DOCNUM.
IDOC_STATUS-STATUS = '51'.
IDOC_STATUS-UNAME = SY-UNAME.
IDOC_STATUS-REPID = SY-REPID.
IDOC_STATUS-MSGTY = SY-MSGTY.
IDOC_STATUS-MSGID = SY-MSGID.
IDOC_STATUS-MSGNO = SY-MSGNO.
IDOC_STATUS-MSGV1 = SY-MSGV1.
IDOC_STATUS-MSGV2 = SY-MSGV2.
IDOC_STATUS-MSGV3 = SY-MSGV3.
IDOC_STATUS-MSGV4 = SY-MSGV4.
RETURN_VARIABLES-WF_PARAM = 'ERROR_IDOCS'.
RETURN_VARIABLES-DOC_NUMBER = IDOC_CONTRL-DOCNUM.
APPEND RETURN_VARIABLES.
ENDIF.
APPEND IDOC_STATUS.
ENDFORM. " UPDATE_IDOC_STATUS
5.2.2.4.5 Test
Once the inbound function module has been debugged the scenario should be ready
to test in its entirety. If problems occur, read through the relevant areas of this
document to check your configuration or code.
Figure 16: ALE project team tasks during ALE Operations phase
Various areas, pertaining to the Operations / Production environment need to be
addressed BEFORE you go live:
6.1.1 ALE Administrator role
ALE Administrator role defined and sourced. Responsible for ALE configuration and
issue resolution.
6.1.2 Capacity plan
Capacity plan including ALE IDoc archiving strategy - Consider the growth of the
ALE solution, procedures the archiving of IDocs while considering the legal
implications.
6.1.3 ALE Operations role
ALE Operations role defined and sourced. Responsible for ALE archiving,
background job scheduling and monitoring.
6.1.4 ALE Failure recovery
ALE failure recovery procedure - When a soft failure occurs (I.E. When a system is
restored to a previous point in time) a recovery procedure needs to be
implemented... How?
6.3 Deliverables
6.3.1 ALE Administrator Troubleshooting Procedure
What to do when the unexpected happens... An example of what to produce follows:
6.3.1.1 Introduction
The purpose of this document is to provide a guideline for the ALE administrator to
perform the following tasks:
perform the technical ALE configuration;
monitor and detect errors occurring in the master data ALE process; and
6.3.1.5 Administration
1 Grant the ALE administrator role the necessary rights as per the ALE
6.3.1.6 monitoring
1 IDoc overview monitoring (Transaction WE05) RED = Error
1.1.. Follow the procedure in housekeeping to correct
6.3.1.7 housekeeping
status. Correct the error in the application and reprocess the IDoc (See section
6.3.1.7.1.4)
If the IDoc is white showing that your application document has been posted
then the IDoc has been transferred from 400 to this client successfully and has
been posted correctly.
This refers to the client where the Purchase order was created, the invoice was
created or the journal was created… The person needs to be a member of the ALE
administrator position.
IDoc number
Using the Error number, the IDoc number and the transaction BD88 , with
the required message type you can resend the IDoc. Match the error number
with this transaction and execute the function for the IDocs incorrectly
processed.
If your IDoc is still not correctly processed redo the first 3 steps.
The error is corrected in another window and the IDoc can then be resubmitted
for processing.
If the error cannot be corrected, the IDoc can be marked for deletion.
Once the IDoc has been successfully imported, an event is triggered that
terminates the error workitem. The workitem then disappears from the inbox.
6.3.2 ALE Archiving strategy and procedure
When and how are you going to archive the IDocs. Remember the legal implications.
The following document can serve as an example:
6.3.2.1 Introduction
The purpose of this document is to describe the ALE Idoc archiving strategy and to
provide a procedure to perform the archiving of Idocs.
Whenever information gets sent from one SAP system to another using ALE, Idocs
are created. These Idocs act as the conveyors of the information that is sent
between systems. An Idoc is filled with the information and then physically sent from
the sending SAP system to the receiving SAP system. In both the sending and
receiving SAP systems, the Idoc gets stored in the SAP database. These Idoc
tables can get large after a while and start affecting system performance (especially
in the ALE environment). Therefore these Idoc tables need to be cleared of old
Idocs periodically.
The way in which these tables will be cleared of old Idocs, is to archive and then
delete the Idocs.
6.3.2.1.1 Troubleshooting
Error: Could not create Archive file XXXXX. Check tables ARCH_NUM (Next
number for the archive index) and table ADMI_RUN (list of archive run). Check
that ADMI_RUN does not have an entry for the number contained in
ARCH_NUM. SOLUTION: Delete entries from ADMI_RUN until ARCH_NUM is
reached (also including the ARCH_NUM number).
ensures that Idocs are only deleted after they have successfully been written to an
archive file.
Optionally the archive file can then be backed up onto a backup device or using
SAP’s optical archiving facility.
Archiving
Program
1
R/3
Database
Delete Archive
2 3 Backup
Program File Device
Idoc Description
status
12 Dispatch OK
These Idoc statuses have to be configured before the archiving program will archive
the Idocs in the specified statuses. The transaction where the Idoc statuses are
updated is WE47. The menu path from the SAP main menu is: Tools-
>Administration->Administration->Process technology->Idoc->Idoc basis-
>Control->Status maintenance. The Idoc statuses are client independent and
have to be maintained on each physical SAP system. The changes can be put in a
change request and transported to other environments.
The status maintenance lists all Idoc statuses, and each status can be edited by
double clicking on the status, or selecting the status and choosing Goto->Details
from the menu structure.
By default only status 40 and 41 are set up to be archived. Status 40 (Application
document not created in target system) should be set up to suppress archiving, and
the statuses mentioned above (12, 41 and 53) should be set up to enable archiving.
This set up will ensure that all Idocs that are in statuses that were enabled for
archiving, will be archived.
5. Select the start date button to set up when the archiving job will be scheduled.
For archiving purposes, the job can be scheduled to run immediately. Save the
job parameters to go back to the archiving screen.
6. Select the Spool parameters button to set up the background printing for the
archive job. A valid printer has to be specified. Deselect the print immediately
option and ensure that the delete after print option is selected.
7. Select the Customizing button to set up customising options. Select
ARCHIVE_DATA_FILE as the logical file name (if a specific physical location
for the archive file needs to be selected, the basis setup for archiving needs to
be changed using transactions FILE and SF01. These transactions can also be
accessed through the Reference IMG under: Basis Components->System
Administration->Platform-independant File Names->Client-independent
maintenance of file names and paths or Additional client-dependent file name
maintenance). Select start automatically for the Settings for delete program
(this will automatically start the delete program after successful archiving of the
Idocs). All other settings can be left at the default settings:
8. These settings are client independent and can be transported to other
environments. The customising settings need to be configured once only.
9. Click on the generate job ( ) button to generate the archiving job. After the
archiving job has been generated, the job can be monitored by clicking on the
Job overview button. After the archiving job has completed, the delete job will
execute and delete all successfully archived Idocs. The spool lists for all jobs
can be checked for the details of the archiving and delete jobs.
7. Click on the generate job ( ) button to generate the reload job. After the
reload job has been generated, the job can be monitored by clicking on the Job
overview button. After the reload job has completed, the Idocs in the selected
archive(s) will be reloaded in status “Idoc reloaded from archive”. The spool
lists for the job can be checked for the details of the reload job.
6.3.2.3.3 Housekeeping
When archiving Idocs, certain files and jobs need to be maintained on a regular
basis. When archiving Idocs, a file gets created on Unix level for every archiving
session. These files have to be backed up if the Idocs archived were for transaction
data but don’t need to be backed up for master data Idocs. The archive files at Unix
level also need to be deleted periodically to recover disk space.
Any archiving, deletion and reloading session, creates job(s) on SAP. These jobs
also need to be deleted from the job log periodically.
All change pointers are also copied from the source client to the target. These
“unwanted” change pointers must also be deleted as part of creating a new client.
This procedure will be described in detail in the client copy procedure.
Archiving of Idocs need to happen periodically once a client is being used in a
development, quality assurance or production environment. Currently the proposal
is that the archiving happens twice a month, during periods when the system is not
too busy i.t.o. running other batch jobs (proposed to run on the 5 th and 20th of each
month).
During this archive run all master data Idocs older than the current date can be
archived and deleted. This can be achieved by setting up the archive variant in such
a way that the date in the variant is set up as a variable of the current date minus 1
day. All message types that are for master data scenarios should be selected as
part of the master data variant (CHRMAS, CLFMAS, CLSMAS, COELEM, COGRP1,
COGRP2, COGRP6, COSMAS, PRCMAS, ZCREIC, ZCRENE, ZDEBIC, ZDEBMS,
ZGLMAS, ZMATMC, ZMATMS, ZMATSM).
All Idocs for transaction scenarios older than a month can be archived and deleted.
This can be achieved by setting up the archive variant in such a way that the date in
the variant is set up as a variable of the current date minus 30 days. All message
types that are for transaction data scenarios should be selected as part of the
transaction data variant (FIDCMT, ZFIREV, ORDERS, ORDRSP, INVOIC, ZINVRV,
DESADV). The archive file that is created by the transaction data archiving
session must be backed up as part of the basis backup procedure for auditing
purposes.
If the number of Idocs in an archive session are more than the maximum number of
documents in the archiving customising settings (see step 7 of the archiving
procedure), the archiving date or message type in the variant can be changed to limit
the number of Idocs, or the customising settings can be changed to allow for more
Idocs to be archived in one session.
6.3.3.1 Introduction
The aim of this document is to provide some guidelines when doing system capacity
planning. This document will look at the ALE area and describe the impact of ALE
data on capacity planning.
These guidelines can be used as part of the larger system wide capacity planning.
6.3.3.2.2 Idocs
ALE uses Idocs to transfer data from one system to another. The Idocs are created
and stored in the database in the sending system, before being sent to the receiving
system. In the receiving system the Idocs are stored in the database before being
processed.
The size of the Idocs will vary according to the type of information that is sent in the
Idoc.
The ALE Archive Procedure explains how to archive and delete these Idocs, but
there is still some disk space needed to store the Idocs before they are archived and
deleted. Depending on whether the Idocs that were archived have to be stored,
some archive space will also be needed (e.g. backup tape or CD).
6.3.4 ALE Failure and recovery procedure
In case a system needs to be restored to a point back in time, how do you recover?
An example document follows:
6.3.4.1 Introduction
The aim of this document is to provide a strategy and detailed procedure for
recovering ALE communications from a system failure. The various kinds of failures
that can occur will be described and the procedures to recover from these failures
will be described.
All outbound messages from the involved system will not be sent until the recovery is
complete and the system becomes available again.
All inbound messages from other systems will be kept in the ALE queue of the
sending system until the receiving system becomes available again.
No user intervention is therefore needed to ensure consistency across distributed
systems for hardware failures.
t1 t2 t3
Error
Error
Discovered
A soft error occurs when an error takes place at time t2 that makes data useless
(e.g. a user deletes all orders). The error is only recognised at time t3 and the
system is halted, after the state of the database has changed from t2 to t3. The error
that occurred at t2 is of such a nature that the system has to be restored to a point in
time (t1) before the error occurred.
All “useful” transactions between time t1 and t3 will have to be repeated. External
interactions between systems will have to be synchronised with the state of the
external systems.
System A System B
After Recovery:
n n+x
n
A: Idoc S: + x
t0 t1
B: Idoc R: + x Idoc R: + x
n+x n+x
System A applies delta + x to n. This information is sent using the sending Idoc on
System A to the receiving system on System B, and the delta (+ x) is applied in
System B. After the recovery, System A is restored to time t0. The delta change on
System A is lost, but have been applied on System B.
After Recovery:
n n'
n
A: Idoc S: n'
t0 t1
B: Idoc R: n' Idoc R: n'
n' n'
All master data objects that have been changed after time t0 in System A, will have a
newer version in System B than in System A. These master data objects have to be
determined and sent again from System A to get the systems in synchronisation. All
changes to objects in System A after time t0 will have to be re-applied.
After Recovery:
n
n
Idoc S: n
A: Idoc S: n
Status 30
t0 Idoc R: n t1
B: Idoc R: n
n n
All Idocs that have been created in System A before time t0, but sent after time t0,
may not be resent. After the recovery, these Idocs will be in status 30 (Idoc ready to
be sent), so the Idocs’ statuses have to be changed corresponding to what
happened on System B.
After Recovery:
x y
-
Idoc S: x Idoc R: y
A:
Idoc R: x
t0 Idoc R: x Idoc S: y t1
B: Idoc S: y
x y x
y
Idocs that depend on messages, which are dependent on other messages sent after
time t0, may not be sent/resent. These Idocs have to get a status that can be
deleted (e.g. status 31) and have to be deleted from the TRFC queue id needed.
System 1 RCYFET
5. The button will give a list of all Idocs that were exchanged between
system 1 and system x after the time and date specified in transaction BDRC
that was run on system 1. These Idocs will be listed and can be looked at
individually.
6. The button will list all Idocs that are in system x, but have been lost
in system 1 due to the restore. The Idocs can be inspected (Idoc Anzeigen),
The following items needs to be checked from a technical ALE point of view, after a
system has been restored from a soft error:
The ALE distribution model needs to be checked (all message flows and filters
in the model needs to be checked as well as the partner profiles). The model
on the recovered system may be out of synchronisation with the source system
of the model. If the recovered system is the source system of an ALE model,
the target systems of the model may have a later version of the model. The
ALE documentation can be used for this.
ALE conversion rules have to be checked to ensure that these rules are the
latest version. The ALE documentation can be used for this.
ALE classes and the linking of the classes to logical systems. The ALE
documentation can be used for this.
ALE jobs need to be checked to see that all jobs are running after the system
has been recovered. The ALE documentation can be used for this.
6.3.5 ALE Foreground Processing - By the user
6.3.5.1 introduction
6.3.5.1.1 Purpose
The purpose of this document is to give the ALE users (I.e. People who distribute
master data records via ALE) the correct procedure to follow in order to minimise
frustration through the understanding of the process.
2
Mes Type Mes Type
3 3
Client 7XX Client 8XX
CC2000 CC2010 CC2020 CC2000 CC2010 CC2020
ALE related master data is added and changed in the 4XX range of reference
clients
Any additions or changes to the following master data records (I.e. Change
pointers are created for each master record that is changed) are automatically
distributed for the user (no user intervention is required):
Cost element & Hierarchy
Cost Centre & Hierarchy
Material Master (Create & Change) (Not internal charges materials)
Debtor Master (Not internal charges customers)
Vendor Master (Not internal charges vendors)
Any additions or changes to the following master data records are not
automatically distributed for the user and need to be manually sent:
Profit centers & Hierarchies
Material Master (Internal Charge Material \ Services)
Debtor Master (Internal charges customers)
Vendor Master (Internal charges vendors)
2
Once the master data has been changed \ added or manually sent, an IDoc
will be created for each master data record. In the case of the automatic
processing, this will only happen after hours when a batch job creates the
IDocs from the change pointers.
If the user requires a particular master data record urgently then he may
process that IDoc manually from the reference client, which will then send
the IDoc to the receiving system \ s.
3
Once the master data has been received by the receiving system \ s, it is
queued until it is automatically processed after hours.
If the user requires a particular master data record urgently then he may
process that IDoc manually from the receiving group client \ s, which will
then process the IDoc on the receiving system \ s in order to create an
application IDoc.
NB: Do NOT process more than 20 records manually, due to the fact that it will
affect the performance of all other users logged into the system during the
time it takes to process all the IDocs.
following morning, without performing any further tasks, the master data records will
be reflected in the respective group clients.
This document details how you would process master data immediately in such an
environment.
6.3.5.2.4.1 Generate IDoc Type From Change Pointers (On Reference Client 4XX)
Start transaction BD21 (Generate IDoc Type From Change Pointers)
Select the required message type for required scenario. (See Appendix 1)
Execute the function. A popup window will display how many master IDocs
were created and how many communication IDocs were created.
6.3.6.2 Assumptions
The following assumptions are made when applying this procedure:
Unless otherwise stated all IMG activities are performed at the SALE transaction
level;
The person applying this procedure is the ALE Administrator and has detailed
knowledge of SAP job scheduling;
The ALE basis environment is configured between the various clients. If this is not
the case please follow the procedure documented in “ALE Technical
Configuration Section”; and
The outbound job has the following 2 programs as steps, shown in Figure 20:
RBDMIDOC – Change pointer leads to creation of IDocs
RSEOUT00 – Some IDocs are not sent immediately, but are collected and then
sent all together. The report RSEOUT00 must be scheduled in order that these
IDocs can be sent.
These 2 steps will be described in more detail below.
Requirements
Variants for each message type must be maintained.
1. Run transaction SM36
2. Type in the name of the job: Z_ALE_MESTYP_OUT_4XX
3. Enter it as job class B
4. Goto STEPS and enter 2 steps:
5. RBDMIDOC and a variant that you have maintained according to the MESTYP
you are now defining a job for.
6. RSEOUT00 and a variant that you have maintained according to the MESTYP
you are now defining a job for. Username: ALE-BATCH.
7. Schedule the job as a periodic job, where the period must be adapted to your
requirements (see Detailed Configuration Guide).
8. Save the job.
9. Create a job for every variant defined beforehand.
1. Perform the transaction SE38 and enter "RBDMANIN"; Click on Variants and
choose Change
2. Enter a name for the variant and choose Create. Choose Z_ALL as your name.
3. Leave attributes blank
4. Save the variant
6.3.7.1 GENERAL
6.3.7.1.1 Introduction
There are various ALE configuration settings that can be “tuned” to optimise ALE
performance for high volumes of master data / transactions. These settings will be
explained in this document and some recommendations will be made regarding
these settings and configuring them optimally for performance.
There are some scenarios that cannot deal with mass processing of incoming
documents. This is always the case if the application that imports the data has to
execute a batch input.
In such a case the packet size has to be set to 1 in the output processing.
The following test cases were conducted using a GLMAST message type.
Outbound Inbound
No Message Number of Collect Imm Packet Imm Bckgd
Type IDocs IDocs size
1 GLMAST 921 No Yes 1 Yes No
2 GLMAST 921 No Yes 50 Yes No
3 GLMAST 921 No Yes 200 Yes No
4 GLMAST 921 Yes No 200 Yes No
5 GLMAST 921 Yes No 1 Yes No
6 GLMAST 921 Yes No 200 No Yes
7 GLMAST 921 Yes No 200 No Yes X 5 jobs
8 GLMAST 921 Yes X change No 200 No Yes
pointers
6.3.7.3.3 Comments
No Comments
1 Captured all available dialog processes on the receiving side to process the IDocs.
Very limited number of dialog processes used on the sending system for very short
periods of time to make RFC calls. CPU utilisation was unnoticeable.
2 Captured all available dialog processes on the receiving side to process the IDocs.
Very limited number of dialog processes used on the sending system for very short
periods of time to make RFC calls. CPU utilisation was unnoticeable.
3 Captured all available dialog processes on the receiving side to process the IDocs.
Very limited number of dialog processes used on the sending system for very short
periods of time to make RFC calls. CPU utilisation was unnoticeable.
4 1 dialog process used to collect the IDocs. 1 background process to send the IDocs.
The bottleneck is on the inbound processing side. The IDocs collected up waiting to be
processed on the inbound side.
5 1 dialog process used to collect the IDocs. 1 background process to send the IDocs.
The bottleneck is on the outbound as well as the inbound processing side. As fast as
the sending side could send the IDocs the receiving side could process them.
6 On outbound side 1 dialog process used to collect the IDocs. On outbound side only 1
batch process is used to process the IDocs and send. On inbound side a few (2-3)
dialog processes were used to update the IDoc table. (Not a continuous process like
when processing IDocs in the foreground). 1 batch process was used to process the
IDocs.
7 On outbound side 1 dialog process used to collect the IDocs. On outbound side only 1
batch process is used to process the IDocs and send. On inbound side a few (2-3)
dialog processes were used to update the IDoc table. (Not a continuous process like
when processing IDocs in the foreground). 5 batch process was used to process the
IDocs.
8 On outbound side 1 dialog process used to collect the IDocs. On outbound side only 1
batch process is used to process the IDocs and send. On inbound side a few (2-3)
dialog processes were used to update the IDoc table. (Not a continuous process like
when processing IDocs in the foreground). 1 batch process was used to process the
IDocs.
6.3.7.4.3 Other
Change pointer job needs to run before the job to dispatch the IDocs is run.
6.3.8.1 Introduction
The aim of this section is to describe the procedure for preparing a production client
for ALE. This section will not describe the full ALE configuration process, but will
only describe the general tasks that need to be performed after the client has been
copied to remove all unwanted data.
This document will not provide detailed descriptions of all the procedures involved,
but will mention the menu paths and transaction codes applicable for each area.
The detailed procedures can be found in the ALE configuration procedure
documentation.
Rule assignments can be found under the ALE IMG in Functions for Idoc
processing->Conversion->Define settings for Idocs conversion (BD55).
7 GENERAL
This section contains all general documents and presentations related to ALE.
The following documents belong in this section:
7.1 Glossary
Application link enabling (ALE)
Refers to the creation and operation of distributed SAP systems. The concept is to
guarantee a distributed, yet integrated solution, through the use of business
application messages and consistent data across loosely coupled systems.
Basic IDoc type
A basic IDoc type can be used on its own or in combination with an extension type.
The combination of a basic IDoc type and an extension type forms an IDoc type.
Control record
One of the three record types of the IDoc. The control record contains data
identifying the sender, the receiver, and the data structure.
Communication idoc
An IDoc contains the business data in the format required for ALE to operate. It
consists of segment types, where each segment type holds the required fields for
that segment. There are 2 types of IDocs we deal with:
Basic IDoc: This IDoc is used internally by the function modules creating the IDoc
to establish the data that is required for distribution. A basic IDoc is created per
business object. E.g. Per material master record.
Communication IDoc: For each basic IDoc that is created on the sending system
the relevant number of communication IDocs are created based on the customer
model and how many systems are to receive this IDoc. This is then the IDoc that
is sent to the receiving systems and can be viewed by transaction WE05.
Conversion rules
These are used to convert the field contents of a sender field for use in a receiver
field. This allows conversions of organisational units, of units of measurement and
customer-specific conversions from one system to another to be performed.
Customer distribution model (CDM)
The customer distribution model specifies which applications can communicate with
each other in your distributed systems. The customer distribution model contains all
the cross-system message flows in your company.
Filter object type
A filter object type is a selection criterion in the distribution reference model that
specifies the criteria that determine whether a function type can be used several
times in a distributed system. EG. Use it to specify the logical systems that are to
receive a message (GLMAST) by stating the company code BUKRS as a filter object
with 2000 as the value. This implies that only GL master records with 2000 as the
ALE in general 1
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
company code will be distributed to the logical system with BUKRS = 2000 set as a
filter object of GLMAST in the distribution model.
Function module
Function modules are external subroutines that are stored centrally in the Function
Library and can be called from any ABAP/4 program.
In contrast to normal subroutines, function modules have a uniquely defined
interface.
IDoc outbound processing
Usage of programs and subprograms which control the processing of application
data up to the point of transferral as an IDoc to the ALE communication layer.
IDoc type
The IDoc type indicates the SAP format that is to be used to interpret the data of a
business transaction.
An IDoc type consists of the following components:
a control record
This is identical for each IDoc type.
several data records
One data record consists of a fixed key part and a variable data part. The data
part is interpreted using segments, which differ depending on the IDoc type
selected.
several status records
These are identical for each IDoc type and describe the statuses an IDoc has
already passed through or the status an IDoc has attained.
Listings
Listings are used in master data management when distribution rules cannot be
modelled using organisational units only. Listings exist for material, customer and
vendor master data.
For each object type a (customer-defined) class type can be specified as ALE-
relevant. All classes belonging to this class type can be used in the listings.
Since listings are used as classifications, they are maintained in the master data
transactions. A master data object can be added to a list by classifying it.
The listing groups together all the objects belonging to a single class, and this class
belongs to the ALE class type for the object.
Logical system
A system on which applications integrated on a common data basis run.
In SAP terms, this is a client in a database.
Messages are exchanged between the logical systems.
Message type
ALE in general 2
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
The messages exchanged between systems are of various message types. The
message type depends on the data contained and the process involved. It
determines the technical structure of the message, the IDoc type. For example, the
FIDCMT message type is used for journal messages.
Partner profile
Definition of parameters for the message exchange of data with an ALE enabled
partner via the ALE interface.
Port
Logical description of the system that communicates with the SAP System during
ALE message interchange.
In the case of outbound processing, this system receives the Intermediate
Documents, processes them, and sends status records. In the case of inbound
processing, it sends the Intermediate Documents to the SAP System, which then
forwards them to the respective application.
Reference Client
The reference client refers to the client that is used as the master data repository for
that data that is to be distributed. I.E. If you are going to distribute the material
master to 2 production systems then the reference client is that client which holds
the material master data that was loaded directly by the user. The 2 production
clients will receive the data via ALE and are referred to as destination clients. We
suggest you separate the reference client from the production clients.
Remote function call (RFC)
RFCs allow you to call and process predefined procedures (functions) in a remote
SAP System.
RFCs manage communication control, parameter transfer and error handling.
SerialiSation
If several IDocs are sent within a short period of time then "overtaking" can occur, so
that later changes arrive sooner than changes that were actually made earlier. In
order to avoid incorrect updates being made, a serialisation mechanism must be
used that can spot "overtaking" and report it.
ALE in general 3
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
system is able to transfer information (IDocs) within one system in the same way as
it would between physically different systems.
Logical Dummy
System 1 System 1
Physical
System 1
ALE in general 4
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
For example, if the client is yyy, and a logical system DUMxxxCyyy has been created
in the previous step, the following data should have been entered:
7.3.4 Define RFC Port
This should be done as part of the dummy client configuration on the reference client
as well the group client being configured. The BASIS administration team will not
do this.
Distribution Communication Manual Maintenance of Partner Profiles define
Port
Ports Transactional RFC
Create a new port definition in this structure, using the fields Port , Description,
Logical destination.
For example, for dummy system DUMxxxCyyy, enter the following:
Receiver Port Description Logical System
A000000032 Dummy Client yyy DUMxxxCyyy
7.3.5 Setting up model messages
The standard messages for the scenario should be set up in the model, using
transaction SALE. The procedure can be found in the ALE configuration section.
Unfortunately, due to the non-standard nature of this configuration, both automatic
as well as manual generation of partner profiles is required.
7.3.6 Automatic Generation of Partner Profiles
The following messages should be added to the 4xx-ORDR model for
ALExxxCyyy to DUMxxxCyyy on the reference client:
ORDERS
ORDCHG
ZINVRV
ORDRSP
INVOIC
FIDCMT
The partner profiles should first be generated using the standard auto-
generation procedure on the reference client (for SYNCH messages to be
created).
This model should now be distributed to the both ALExxxCyyy and
DUMxxxCyyy.
The partner profiles should now be generated on the client being configured
(i.e. yyy) using the auto-generation procedure defined in the standard ALE
configuration procedures.
ALE in general 5
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 6
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
Outbound
The outbound parameters for partner: DUMF01C700 and partner type LS are
detailed below. The receiver port should be selected as the dummy system. As
mentioned previously, the default IDoc packet size should be determined from the
official ALE configuration guide.
Message IDoc
FIDCMT ZFIDCM02
INVOIC INVOIC01
ORDCHG ORDERS02
ORDERS ORDERS02
ORDRSP ORDERS02
SYNCH SYNCHRON
ZINVRV ZINVRV01
Notes
Check Transaction WE57 and ensure Z_IDOC_INPUT_ZINVRV has an entry
against object BKPF
Configuration guide
This guide details how to configure the applicable scenario.
If development was required then the following documents are needed in addition to
the above-mentioned ones:
Functional specification
Any changes to standard scenarios are specified by the business.
Technical specification
The functional specification is converted into technical specifications.
Quality assurance
ALE in general 7
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
Document ensuring that someone has assured the quality of the documentation, design and
coding.
Package sign-off
Form signing off the development work, once all the above documents have been completed.
ALE in general 8
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 9
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 10
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 11
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 12
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 13
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 14
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 15
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 16
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 17
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 18
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 19
The Advanced Guide to Implementing SAP R/3's ALE Technology Chapter 7
ALE in general 20
Index
INDEX
Index i
The Advanced Guide to Implementing SAP R/3's ALE Technology
6-23, 6-24, 6-40, 6-41, 7-2, 7-3, 7-4, 7-5, 7-6, 7-16, 7- RBDMIDOC, 4-37, 4-51, 6-2, 6-30, 6-31, 6-34, 7-9
20 RBDMOIND, 4-41, 6-20, 6-33, 6-34, 7-10
Logical System, 4-1, 4-50, 7-4, 7-5 RBDSTATE, 4-18, 4-19, 4-20, 4-21, 6-2, 6-35, 7-10
Logical systems, 6-41, 7-8 Receiver determination, 1-3
reference model. See Customer model
Remote Function Call (RFC), 1-2, 1-4, 1-7, 3-2, 4-1, 4-2,
M 4-9, 4-10, 4-15, 4-16, 4-18, 4-37, 4-41, 5-9, 6-3, 6-15,
Mass processing, 4-37, 4-54, 6-35, 6-36 6-16, 6-33, 6-36, 6-39, 7-3, 7-4, 7-5, 7-10, 7-18
Mass Processing, 1-6 TRFC Failures, 4-10, 6-3, 6-15, 6-20
Master data, 1-2, 1-8, 4-9, 4-11, 4-30, 4-36, 6-4, 6-17, 6- RSARFCEX, 6-15, 6-33, 6-34, 7-19
39, 6-41 RSEIDOCM, 4-35, 4-36, 7-12
Message control, 7-6, 7-20 RSEOUT00, 4-38, 4-39, 4-51, 6-30, 6-31, 6-32, 6-34, 6-
message type, 1-6, 1-7, 4-2, 4-9, 4-11, 4-12, 4-13, 4-14, 37, 7-12, 7-19
4-15, 4-16, 4-17, 4-18, 4-19, 4-20, 4-21, 4-22, 4-23, 4-
27, 4-28, 4-29, 4-34, 4-36, 4-37, 4-38, 4-39, 4-40, 4- S
42, 4-43, 4-44, 5-2, 5-3, 5-6, 5-7, 5-8, 5-10, 5-11, 5-
15, 5-16, 5-17, 6-4, 6-5, 6-6, 6-7, 6-10, 6-13, 6-26, 6- Segment filtering, 1-3, 1-5
27, 6-28, 6-29, 6-30, 6-31, 6-32, 6-34, 6-35, 6-36, 6- Segment type, 1-4
37, 6-38, 7-3, 7-16, 7-17, 7-19, 7-20 Serialisation, 4-42, 4-43, 5-7, 7-3
Message type, 1-4, 3-1, 4-10, 4-13, 4-20, 4-38, 4-45, 4- Serialization, 3-1, 4-2, 4-54, 7-14
46, 4-47, 4-48, 4-51, 5-2, 5-15, 6-28, 6-31, 7-3, 7-8, 7- Stakeholder management, 2-1
10, 7-16, 7-20
Migration, 3-2
T
N Technical
configuration, 2-2
Naming standards, 3-1 impact assessment, 2-2
number range, 4-4, 4-5, 4-6, 4-7, 4-8, 4-9, 4-16 Technical architect, 2-1
Number ranges, 4-5, 4-6, 4-9, 4-38, 4-39, 6-37, 6-38 Technical Architect, 2-2
Technical Impact Analysis, 2-4
Technical specification, 7-8
O the distribution reference model. See Customer model
Operations, 1-11 Tranaction
Outbound processing, 1-2 WE05, 4-55, 5-11, 5-15, 6-4, 6-5, 6-7, 6-10, 6-11, 6-
18, 6-19, 6-21, 6-23, 6-28, 7-1, 7-18
Transaction
P BD21, 6-26, 7-17
Packet size, 1-4, 1-6, 4-37, 6-36, 6-37, 7-7 BD55, 4-27, 4-28, 6-41, 7-22
Partner profile, 1-4, 4-15, 4-16, 4-18, 4-28, 4-29, 4-37, 4- BD62, 4-23, 6-41, 7-22
39, 4-49, 4-50, 5-9, 5-15, 5-17, 6-32, 6-36, 6-37, 6-41, BD68, 4-34, 6-41, 7-20
7-6, 7-15, 7-20, 7-21 BD79, 4-24, 6-41, 7-22
partner profiles, 4-2, 4-15, 4-16, 4-18, 4-28, 4-54, 5-2, 5- BD87, 6-5, 6-6, 6-7, 6-27, 7-19
3, 5-9, 5-16, 5-17, 6-24, 6-35, 6-40, 6-41, 7-5, 7-6, 7- BD88, 6-5, 6-7, 6-26, 6-27, 7-19
8, 7-15, 7-20 O02D, 4-30
Partner profiles, 4-15, 6-41, 7-5, 7-6, 7-11, 7-12, 7-13, 7- O02I, 4-32
21 SE38, 4-35, 4-37, 4-38, 4-40, 4-41, 6-30, 6-31, 6-32,
Performance, 1-6, 1-7, 1-11, 2-3, 2-4, 4-17, 4-18, 4-37, 4- 6-33, 6-34
54, 6-3, 6-8, 6-25, 6-35, 6-36, 6-38, 6-39 SM36, 4-36, 4-37, 4-39, 4-40, 4-41, 6-31, 6-32, 6-34,
Port, 6-28, 7-3, 7-5, 7-20, 7-21 6-35
Process specialist, 2-1, 2-2 WE20, 4-16, 4-18, 4-28, 5-9, 5-17, 6-41, 7-21
Process Specialist, 2-2 Transaction data, 1-8
Project management, 1-1, 2-1
Project team, 2-1 V
Version change, 1-4
Q
Quality assurance, 5-2, 7-8 W
workflow, 1-4, 1-6, 1-7, 1-9, 3-2, 4-3, 4-8, 4-28, 4-29, 4-
R 51, 4-55, 5-14, 5-15, 5-16, 5-17, 6-4, 6-8, 6-36, 7-10,
RBDAPP01, 4-39, 4-40, 4-51, 6-2, 6-32, 6-33, 6-35, 6- 7-22
37, 7-8, 7-18 event, 1-7
RBDMANIN, 4-39, 4-40, 6-2, 6-7, 6-34, 6-35, 6-37, 7-9, work item, 1-6, 1-7, 1-8
7-18 Workflow
Error notification, 4-28, 4-29, 4-55
Index ii