ALE: Overview

ALE: Overview

 Overview of SAP Terminology

 What is ALE?
 Why use ALE?
 What can be distributed with ALE?
 What business scenarios does ALE support?
 ALE Components.

2
 Overview of SAP Terminology

SAP System SAP System

Client-Independent Data
(ABAP, DDIC, client-
Database
independent tables, etc.)
Database Server

Client XXX
• client-dependent
configuration
• master data
• transaction data
Application Server Application Server Application Server

Client YYY

Presentation Server Presentation Server Presentation Server

System Infrastructure View Database/Configuration View

3
 What is ALE?
Application
Link Enabling
???

4
 Why Distributed Applications?

MM-
GL
PUR
PS

PP
CO
SD-
MM- SHP
INV
SD-
ORD

MM-
INV
 One central system is not always optimal for unifying
business processes with integrated applications
5
 Why Use ALE?

 System Performance
 High Availability Requirements
 SAP Release Co-ordination
 Very Large Database
 Business Structure
 Interfaces with legacy systems Headquarter
Sales
System

Production
6 System
 Why not distributed databases?

 Mirroring tables using two-phase commits has a high

performance penalty
 Replicating tables bypasses application consistency checks
 Control of distribution is difficult:

Distribution needs to be managed at the table level, not at
the application level
 ALE supports distributing business integration using business
(application) links, not technical (table) links
 Business messages are exchanged between systems using
message types

7
 Messaging with ALE

Transaction Data Messages

BLAORD,
HEAD QUARTERS
BLAOCH  Financials
 Central purchasing
BLAREL  Purchasing info.
EKSEKS system

FIDCMT

FIROLL

BLAOR.. Blanket order/changes

PRODUCTION BLAREL Release statistics
EKSEKS Purchasing information
Local purchasing, invoice verification FIDCMT A/C receivable
FIROLL G/L rollup

8
 What Can Be Distributed with ALE?

 What is distributed ?  Scenarios:


Transaction Data

R/3 and R/3


R/2 and R/3

Master Data

SAP and non-SAP

Control Data systems

Support for different application releases

9
 What Business Scenarios does
ALE Support?
 Master Data Distribution
 Control Data Distribution
 Financial Accounting
 Cost Accounting
 Sales and Shipping
 Purchasing - Distributed
Contracts
 Profitability Analysis
 Logistics Information
Systems
 Sales and Operations
Planning (SOP)
 Warehouse Management
 Personnel Cost Planning
 Payroll Accounting

SAP R/3 Release 3.0

10
 Application integration

ALE ALE

HEAD QUARTERS
 Reference System for
Master Data and Control
Tables
 Financials
PRODUCTION  Central controlling SALES
 Local SOP  Central SOP  Sales, shipping and
 PP  Information Systems: billing
 Local purchasing, invoice  Inventory  Purchasing of
verification  Purchasing trading goods
 Inventory Management  Sales  Inventory
 Internal sales, shipping  Central Purchasing Management
and billing  Local controlling
 PM ALE
11
 Technical integration

 Change documents

Change pointers are written for ALE-relevant field changes
notified by the change document tool

ALE modules use the pointers to fill IDOCs with application
tables' contents
 No difference between EDI & ALE processing from
application point of view

Applications using the EDI option in message control can also
transmit via ALE.

IDOCs passed to ALE can be transmitted directly or via an
EDI-subsystem (assuming EDI message exists)

12
 Integration Is The Key

Application A

Application A

Application B
Application A
Application B Application D
Application C Application B
Application C Application D Application C

Application D

distributed integrated distributed Time

not integrated integrated

13
 Distribution Scenario
Example: Separate Financial & Logistics Systems

Accounts payable
+ rollup accounts

MM, PP

Accounts
receivable +
rollup accounts
FI, CO
SD
Central Accounts system, local Logistics
14
 Distribution Scenario
Example: Sales & Distribution

1. Order
4. Order Acknowledgement
8. Invoice
Sales
nt Office
r e
rde m
O dge
rn al le
Customer
nt e n ow
I ck
2. r A ce
de v i
s. ship
. Or h Ad
3 atc ic e
p o
. Dis l Inv
6
e rna
. Int
7

Headquarters
15
 Distribution Scenario
Example: Blanket Purchasing

1. Blanket Order

Supplier
r
r de
Headquarters 2. Co seO
4.
py
elea nt
o fB . R e
R ele 3 ipm
lan h
as ke S
e tO 5.
St rd
at er
i st
i cs

Plant
16
 Distribution Scenario
Example: MRP

Production Production
Plan Plan

Division
Division

Production Plan

Plant
Plant Reporting Plant
Plant
17
 ALE-Tools make distribution easier

 Used to implement the 3.0 scenarios, and are available to


Enhance existing scenarios

Add new messages and/or scenarios
 Customizing tools:

Distributed Architect for modelling and controlling ALE

Shared Master Data (SMD) tool

IDOC filtering and conversion
 Development tools:

IDOC tool for modifying/creating messages

API's for output and input

18
 ALE Components

Application Distribution / ALE Communication

Layer Layer Layer

R/3
R/3 System
System 11
Master
Master
IDOC
Master Determine
Determine Filter/Convert
Filter/Convert Comm.
IDOC
Application
Application Receipients
Receipients Data,
Data,Create
Create IDOC
IDOC IDOC
IDOC

Carrier
Carrier

R/3
R/3 System
System 22

Application Application
Data
Application Filter/Convert
Filter/Convert Comm.
Functions
Functions
Data
Data IDOC

19
 Messaging needs

 Messages must have a structure that is


easy to manage technically (a simple 'data container')

no problems with binary representations

easy to connect to non-SAP systems

able to contain complex data structures

extendible without reprogramming interfaces

well documented

based on EDI standards where possible
 Solution: Intermediate Documents (IDOCs)

20
 IDOC Overview

Intermediate Document

Control Record

Data Records

Status Records

21
 Structure of an IDOC

IDOC IDOC structure

Control record
HEADER
HEADER ACCUM
ACCUM
Sender
Sender Receiver
Receiver MsgType
MsgType IDOC-type
IDOC-typeStatus
Status
M
M 11 M
M 11
HEADER
HEADER xxxxxxxx
xxxxxxxx
ITEM
ITEM xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
SUBITEM xxxx Data
SUBITEM xxxx
SUBITEM xxxx records
SUBITEM xxxx ITEM
ITEM
TEXT
TEXT xxxxxxx
xxxxxxx
ITEM
ITEM xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx M 9999
M 9999
SUBITEM
SUBITEM xxxx
xxxx
SUBITEM
SUBITEM xxxx
xxxx
ACCUM
ACCUM xxxxxxxx
xxxxxxxx
SUBITEM
SUBITEM TEXT
TEXT
Status records
"Ready
"Ready for
forprocessing"
processing" 16:22:34
16:22:34 M
M 99
99 O
O 9999
9999
"Successfully
"Successfullyprocessed"
processed" 16:22:42
16:22:42

22
 Extensions to IDOCs

 SAP may...  The customer may....


insert new fields in existing 
insert new segments in the
segments IDOC

insert new segments

.... remembering that:

 IDOCs must be downwards-compatible
 Hence no new mandatory fields may be
added, unless rules are available to fill
them when empty, as is the case when
receiving from older releases

23
 Features

 Output processing (direct, message control)

 Input processing
 Miscellaneous features
 Ensuring data consistency
 Open & flexible IDOC interface

24
 Output processing: direct

Application ALE layer Comm. layer

posting

Need to Customer
create IDOC? Distribution Model
Asynch. RFC
Create master or
M Receiver determination
IDOC EDI
Segment filter

Field value conversion

Application document
posted simultaneously Version change
with IDOCs
Dispatch
Links
C control C
Database

25
 Types of receivers

 Recipients determined by ALE are termed logical systems


A client on an R/3 installation has a unique logical system
name

The partner type is 'LS' (logical system)
 EDI applications know who the message is going to

Customer, Vendor, Consignee, Invoicee etc.

The partner types are

'KU' Debitor

'LI' Creditor

26
 Output processing: message control

 Applications that support EDI via message control can also

distribute via ALE

The output medium is '6' (EDI)

Dispatch control merely needs to be set up for ALE and
aRFC transmission rather than transmission via EDI-
subsystem

The receivers are those known to the application (creditor,
debitor)

27
 Input processing

Comm. layer ALE layer Application

posting
C
Version change

Asynch. RFC Segment filter

or
Field value conversion
EDI

Input
control A
A Serialization Process IDOC

Simultaneously update
IDOC's status
Post application
Database document

28
 Mass processing

 Sending IDOCs via batch job allows dispatch control to send

packets of IDOCs

Communication overhead reduced
 Some application input interfaces support IDOC-packets:
they are posted in one step

Database load is reduced

Comm. Comm. Comm. Comm. Comm. Comm.

IDOC IDOC IDOC IDOC IDOC IDOC

29
 Database monitoring

 Application document and IDOC are posted to database in

same LUW (logical unit of work)

Recovery ensured by database
 ALE tools monitor both outbound and inbound IDOC status
across systems.

Three main status types:

'ready to be processed'

'successfully processed'

'error'

30
 Cross-system application links

Sending system "DC" System "HQ"

Application ALE layer Application

posting

4711 9876
"DC" "HQ"

IDOC "DC"
C
4711 4711

Source Link made by ALE Resultant

application application
document, document, No.
No. 4711 9876, can be
4711 "HQ" found by referring
to "DC", 4711

31
 Technical links

 The following technical links are also made:


In sending system:

Outbound-IDOC -> Communication layer's "Transaction ID"
 allows checking whether IDOC successfully transmitted

In receiving system:

Inbound-IDOC -> Outbound-IDOC from sending system

Inbound-IDOC -> processed application object in receiving
system

32
 Serialization

Sender Comm. Layer Receiver

Object X, First IDOC Input from IDOC 1

changed twice: overtaken must be prevented
in order not to lose
information from
1 IDOC 2

2 2

1 !?
!?

33
 Error processing Workflow

Application ALE layer Comm. layer

posting

Outbound !?
!?
M C
asynch. RFC
or
EDI
Error-processing
Workflow

Inbound !?
!?
A C

34
 Error processing

 Errors are processed locally, in the system in which the

error occurred

The responsible person obtains a Workitem in their inbox

Error message attached to IDOC is displayed

IDOC can be resubmitted
 If an error occurs in the receiving system, the sender is not
informed

If an "application acknowledge" is required, the application
must send an acknowledge IDOC

The only example in 3.0 is ORDRSP, the message that confirms
a sales order

35
 Limitations

 Most errors will occur because customizing data is missing or

incorrect in the receiving system; however...
 It is possible to make certain changes in a central system
that cannot be posted decentrally

If a central system has no stock, and the material's base
unit of measure is changed, the changes will fail decentrally
if the decentral systems have stock.

The only option here is to centrally undo the change
manually

36
Modelling/Controlling
ALE
 Requirements

 It is very important that the configuring of distribution

scenarios be easy and reliable

The possible scenarios must be described thoroughly and
comprehensibly

The customer-specific setup must be easy to define

The definition tool must include consistency checks

The data must be maintained uniquely, ensuring system-wide
consistency
 Actual dataflow must be made visible and easily
comprehensible

38
 Solution

 SAP supplies a distribution reference model, which

documents what is possible
 The "Distributed Architect" PC-tool allows easy modelling
 The customer reference model, defined using the
Distributed Architect, is stored in one R/3 system and
distributed via ALE to the other systems

39
 Distribution Reference Model

Filter Material
Material Division
Division BusArea
BusArea Plant
Plant
object type

Application type Inventory

Inventory Inventory
Inventory
control
control management
management

Evaluate Carry out

Function type
inventory change inventory change

Message type
INVCON
INVCON

40
 Customer model with filter objects

Paris London
Inventory
Inventory Inventory
Inventory
control
control control
control
01
Division 1000
Division
BusArea
BusArea

Lyon INVCON Rome INVCON Brussels INVCON

Inventory
Inventory Inventory
Inventory Inventory
Inventory
management
management management
management management
management

41
 PC-Tool 'Distributed Architect'

 Data is downloaded from R/3 to PC:


Reference model (supplied by SAP)

Organizational units, e.g. company codes, plants (defined by
customer)
 The customer model is built on the PC

Consistency checks are built in to prevent 'impossible'
constellations
 The final model is uploaded from the PC to R/3

Tables entries are then generated that directly control
distribution: "if it's not in the model, it won't be distributed".

At present the EDI messages between debitors and creditors
are not controlled directly by the model

42
 Distributed Architect model

43
 Master data replication

 Replicas of master data records must be available to local

systems

Local access ensures high performance

Communication failure not critical
 In a distributed environment, not all views of a master data
object (e.g. material) are maintained centrally

e.g. engineering & accounting views maintained centrally

purchasing view maintained in each purchasing system
 Database replication does not ensure consistent data

ALE mechanisms necessary

44
 Customizing master data IDOCs

 Each customer has their own set of fields to be distributed

for each master data object (e.g. material, vendor)

Customers want to be able to define which fields are to
transmitted

ALE supports this by allowing customizing of pre-defined
messages

The pre-defined message contains all possible segments and
fields

Customers can choose segments and fields from the references
when creating their own messages

45
 Master data distribution with 3.0

 Material
 Customer
 Vendor
 Cost center
 Cost element
 Activity type
 Tarif
 General Ledger account

46
 Integration with change documents

 The Shared Master Data (SMD) tool has been integrated

with the change document service

Whenever change documents are written, the ALE customer
model is consulted

If necessary, change pointers are written to enable
distribution

47
 Example scenarios (1)

Maintenance & reference Maintenance

A,B,C A,B C, D

Reference A,B,C,D

A,B B, C A,B,D B,C A,D

Client systems Client systems

48
 Example scenarios (2)

Maintenance Eng. BU1 Eng. BU2 Accounting

of material
master views A,B C,D A,B,C,D

M1 M1
M1 M2
BU = Business Unit
Reference M1, M2, M3 are
A,B,C,D
customized
messages
M3 M3 M3

Client systems A,B,D B,C A,D

49
 Original & copy systems

Original
Original Maintenance A,B C, D
maint.
maint.

distribute fetch

Copy
Copy Reference A,B,C,D
admin.
admin.

distribute fetch

Copy
Copy Client A,B,D B,C A,D
admin.
admin. systems

50
 Reference model

Msg.Type(View)
Msg.Type(View) Plant
Plant SalOrg
SalOrg DistCh
DistCh Listing
Listing

Company
Company Sector
Sector MatGrp
MatGrp etc.
etc.

Material
Materialmaster
master
Material
Materialmaster
master Material
Material master
master
Copy
Copy Admin.
Admin.
Original
Original Copy
CopyAdmin.
Admin.

Process Send Receive Demand Send Process

demand master data master data master data master data demand

MATMAS MATMAS
MATMAS MATMAS
MATFET MATFET
MATFET MATFET

51
 Simple customer model

Paris Example:
Material engineering and accounting
Materialmaster
master views maintained centrally
Original
Original for both companies
MATMAS

0001 0002
Company
Company Company
Company

Site 1 only gets data for Site 2 only gets data for
company 0001 company 0002

Lyon Rome

Material
Materialmaster
master Material
Materialmaster
master
Copy
Copyadmin.
admin. Copy
Copyadmin.
admin.

52
 Listings

 A listing contains an explicit list of object-IDs (e.g. material

numbers) to be distributed

Listings are not distributed - only known locally
 A listing is implemented as a special class type for
distributed objects

The listing-ID is a class in this class type, administered
directly as a list

An object is added to a listing by classifying it

Integrated in object maintenance
 Listings are possible for materials, customers and vendors

53
 Maximum and Core IDOCs

 Maximum-IDOC supplied by SAP


Contains all segments and fields necessary to distribute the
SAP master data object

Structure based on table structure in R/3
 Core-IDOC supplied by SAP

Contains minimal number of fields

Not used by applications in 3.0

Potential use: distribute to all systems, to allow them to see
what objects exist (e.g. customers) over all systems - "maybe
lists"

54
 Limitations

 Beware of loops in above scenario:


The filter objects must be set up to ensure that objects
created in e.g. system 1 are not retransmitted to system
1.

'Source system' is not a master data field, so cannot be
used as a filter object

Reference A,B,C

A A,B
B A,C
B,C C
Original: A 1 B 2 C 3
Copy: B,C A,C A,B

55
 SMD Tool - Change pointers

Application Change document ALE layer

posting service
SMD
customizing
Create/change
master data SMD tool
Create change
document
ALE fields? Standard ALE
output

Write pointers

Batch job / manual

Create IDOCs M C

Master data Change docs. Change pointers

56
 SMD Tool - IDOC customizing

Request screen
Request screen At creation a new message
type is linked with the
New Mesg.Type ________
Ref.Mesg.Type ________ IDOC type.

Stucture description
MATMAS01
E1MARAM general Data
Structure description
E1MAKTM short text Segments of the IDOC can
Fieldfaktors
E1MARMM Conversion list E1MARAM be deactivated.
_ MATNR Material n
E1MARCM Plant data
_ MTART Material t
_ MBRSH Industry S
_ MATKL Material g Fieldlist
_ WRKST Basic mat Fields of a segment can be
...
deactivated.
 Mandatory-Segments/Fields cannot be removed
 Link to change documents is automatically updated

57
 Distributing Control Data: Overview

 In order to ensure that messages can be processed by the

receiving system, certain control (customizing) data must be
identical in both systems

e.g. organization units (plant, sales org.)
 The database views that need to be matched between
systems are documented in the ALE handbook

When setting up a new system, customizing data will be
transported from the reference system using transport tools

When changes are made, the tool descibed next is used

58
 Distributing control data

Maintenance ALE Communica-

tion
Release
Release correction
correction
containing
containing changes
changes Keys of changed views
Comm.-
Filter/ IDoc
Comm.-
Determine Comm.-
IDoc
Master- convert data IDoc
IDoc recipients
Control Create IDOC
data

Carrier

Control data
import Workflow 'input'
Standard view transactions
Comm.-
Control Compare & IDoc
data Workitem
import data

59
 Basis side of ALE

 Promote-to-Production strategies for distributed SAP

implementations
 Identifying transportable and non-transportable objects
 Client copy - what gets copie and what is not
 Switching to Production - ??? - LS names
 Security
 Monitoring tools - who should be responsible?
 Upgrades of SAP software - special testing environment
 Performance/stress testing
 Error handling
 Disaster recovery

60