ALE Overview

Introduction

ALE Monitoring Introduction

ALE Processing ALE Configuration

2
 What is ALE?
• Application Link Enabling
– Inter-system communication
• Tight integration of loosely coupled systems
– tight integration = guaranteed delivery
– loosely coupled = not (necessarily) real time
• SAP to SAP links
– SAP to legacy (and vice versa) is EDI, not ALE
• 3 types of ALE messages
– Master data replication
– Control data (customising)
– Transactional links

3
 Loose vs Tight Coupling

Loosely coupled Tightly coupled

• time-wise: asynchronous • time-wise: synchronous
• message-based • RFC-based
• data consistency is • data consistency and
important timeliness is important
• “90% of distributed • “10-20 times more
applications do not need expensive than loosely
traditional coupling.” coupled”
Source: Meta Group Source: Forrester Research, Inc.

Use
Useloose
loosecoupling
coupling whenever
whenever possible,
possible,
but
but communicate
communicatefrequently!
frequently!

4
 Why is ALE needed?
• Distribution of business functions
– Head Office
– Sales
– Production
• Distribution of systems environments
– Development
– Test
– Production
• International Enterprise with National Subsidiaries

5
 Distributed Business Processes

 Financials
 Central controlling
 Central SOP
 Information Systems:
 Inventory
 Purchasing  Sales, shipping and
 Sales
 PP billing
 Inventory  Central purchasing  Purchasing of
management  Reference system for trading goods
 Internal sales, Master Data and  Inventory
shipping and billing Control Data management
 Local purchasing  Local controlling
 PM
 Local SOP

6
 ALE Configuration

ALE Monitoring Introduction

ALE Processing ALE Configuration

7
ALE Configuration

Logical Systems
Distribution Model
Partner Profiles
Ports
Message Types
IDocs
IDoc Types

8
 Logical Systems
• Every system has a logical system name.
• Usually <system name>CLNT<client number>
• You link logical systems together in a distribution
model.

System 1 System 2

Application IDoc IDoc Application

R/3,
R/3 non-SAP

9
 Distribution Model
• Consists of Model Views
• Each model view defines:
– between which sending
– and which receiving logical system(s)
– which message types are to be communicated
– and any message filtering required.
• Model defined using transaction BD64.
• Distribution model normally maintained in one
central system.
• Model views distributed (or transported) to the
relevant logical systems.
• Generate partner profiles from model view.
10
 Partner Profiles
• Generate from distribution model.
• Maintain using WE20.
• Defines detail of how each message type is to be
processed.
• Each model view will generate two partner profiles
– inbound
– outbound
• Inbound profile specifies process code.
• Outbound profile must specify a port.
• RFC destinations defined in SM59.

11
 Ports
• The conduit between two logical systems
• Currently two types:
– tRFC - Transactional Remote Function Call
• SAP technology
• Ensures document arrives only once at recipient
• Automatic retries at configurable intervals
– file port
• IDocs stored in a sequential file
• file port defines the file system path
• file can be FTP’d to target system
• Define using WE21

12
 Message Types
• Define the semantics of a message.
• A logical entity.
• Do not define structure.
• Example MATMAS, the material master data
message type.

13
 IDocs
• Intermediate Documents.
• The SAP standard electronic document is an IDoc.
• Contains structured data.
• Structure defined by the IDoc Type.
• Two types:
– Master IDocs
– Communication IDocs

14
 IDoc Types
• An instance of a Message Type.
• Generally valid for a specific SAP release.
• Defines the application data needed for the
message.
• Defines the structure of the message.
– Segments
– Fields
• IDoc types supplied by SAP are Basic Types.
• Examples: MATMAS01, MATMAS02, MATMAS03.

15
 IDoc Types Structure
Message
Type
new IDOC types created as
message type is developed
IDOC Type IDOC Type (release specific IDOC types)

Segment 1 Segment 2 Segment 3

field 1 field 2 field 3 field 4 field 5

16
 Master IDocs
• One only per message.
• Contain the structured message data.
• Exist only as an internal table entry.
• May have any number of rows.

17
 Communication IDocs
• One per recipient logical system as defined in the
distribution model.
• Each contains:
– one control record
– multiple data records (one per row in master IDoc)
– a number of status records.

18
 Communication IDoc Structure

IDoc

Control Data Status

Record Records Records

•IDOC number •IDOC number •IDOC number

•Sender •segment id •direction
•receiver •segment seq # •status
•ALE Message type •higher segment # •message
•IDOC type •hierarchy # •date/time
•Current status •segment details

19
 IDoc Definition Tools

IDoc Type Editor

WE30

Segment editor E1HDDOC

WE31

20
 Transaction Reference
BD64 Distribution Models
WE20 Partner Profiles
WE21 Ports
SM59 RFC Destinations
WE30 IDoc Types
WE31 IDoc Segments

• All these can be found via SALE

21
 ALE Processing

ALE Monitoring Introduction

ALE Processing ALE Configuration

22
 Conceptual View

System 1 System 2
Document Document

IDoc

• Message based
• Asynchronous

23
 Overview

Master Data Replication

IDocS
Communications
Layer
Application created IDoc
(eg FI)
Create
Master
Message Control IDoc tRFC
(e.g. SD/MM) IDocS (or file)
Determine
transaction code
Application calls ALE and inbound
for BAPI module

ALE
Outbound Layer
Partner
Determine
Profile Inbound
recipient Partner
Profile

Create
Inbound Function Module
Communication
IDoc Determine
port type
ALE
Layer
Application

Convert IDoc
to port format
Distribution
Communications
Model Layer
Outbound Inbound

24
 Master IDoc Creation
• Four mechanisms for
production of master IDocs.
Master Data Replication
• Created as an internal table
in ABAP program.
Application created IDoc • Only exists during program
(e.g. FI)
Create
runtime.
Master • Transferred to ALE layer for
IDoc
Message Control routing.
(e.g. SD/MM)

Application calls ALE

for BAPI

25
 Master IDoc Structure
• Control Section • A Master IDoc is an internal
– MANDT client
table with line structure EDIDD
– DOCNUM IDoc number
– SEGNUM row number
that can have any number of
– SEGNAM segment type rows.
– PSGNUM row no of parent • Each row has a control part
– HLEVEL hierarchy level
containing meta information for
• Data part
the row, and an actual data part.
– DTINT2 length of data part
– SDATA data, type CHAR • Data part has maximum 1000
bytes per row.

26
 Communication IDoc Creation

Application

1. 3.
The application The application
creates change pointers creates a message entry
for deferred processing 2. for deferred processing

The application creates

IDOC’s directly

IDOC
DB
27
 Master Data Replication

Application
Change pointers
for Master Data
written directly
to table

BDCP App Data

RBDMIDOC

IDOC
DB
28
 Master Data Replication
• Driven by change pointers.
• Change pointers activated
generally, and specifically
Application
Application
Process
Change by application document.
Document Document
• Stored in BDCP (BDCPV).
• Schedule RBDMIDOC to
process change pointers.
Change
Pointers
active
generally?

Yes

… for
application
Yes
Change
RBDMIDOC
document? Pointer (BD21)

29
Application Created IDoc

Application

Appl. data
is written directly
to IDOC

IDOC
DB

30
 Application Created IDoc
• Some apps directly trigger IDoc creation, by one of
two methods:
– The app fills an internal table in IDoc format and transfers
this to an ALE service
– The app uses a BAPI with an ALE interface

31
 Application Created IDoc
SAP Application

IDoc
Master IDoc
Master
IDoc Interface / ALE Services

Comm.
Comm. IDoc
IDoc Comm.
Comm. IDoc
IDoc Comm.
Comm. IDoc
IDoc

External System

32
Message Control

Application Control Data

written directly
to table NAST

App Data NAST

NAST

No
RSNAST00 Immediate
?

Yes
IDOC
DB 33
 Message Control
• In many apps, message sending is included in
standard scenarios
– e.g. creating on order.
• For this reason there is a generic service known as
message control.
• System settings determine whether the message is
to be sent to a printer or EDI format.

34
 Message Control

SAP Application

Document
Document

Message Control (MC)

MC
MC
record
record

IDoc Interface / ALE Services

IDoc
IDoc

External System
35
 Communication IDoc Structure

Control record (EDIDC) IDoc ID

Partner
IDoc type and logical message
External structure

Data records (EDID4)

Control part Application data

Status records (EDIDS) IDoc ID

Status information

36
 Communication IDoc Structure

Control record

Data records, represented as a segment tree

E1MARAM
M 2
E1MAKTM E1ITDOC
E1MARCM E1MBEWM
M 3 Elternsegment
O 3 O 3

E1ITSCH
E1MARDM
O O 4

Status records

37
 Communication IDoc Outbound
• ALE Layer passed a Master IDoc.
• Uses customising settings to determine which
technology to use for sending an IDoc.
• Technology is specified using a port type, which can
be determined separately in each partner profile.
• Uses distribution model to determine recipients for
the message type.
• Creates a communication IDoc for each recipient.
• IDocs are saved to the database.
• IDocs may be:
– sent immediately, or
– sent via background jobs using RSEOUT00

38
 Communication IDoc Inbound
• The IDoc is first saved to the database.
• Process code determines the inbound module
(from partner profile)
• Two processing modes:
– Immediate (not recommended)
– background (via RBDAPP01)
• RBDMANIN reprocesses errors.

39
 ALE Monitoring

ALE Monitoring Introduction

ALE Processing ALE Configuration

40
 Monitoring
• Transactions:
– WE02 lists IDocs by date and time
– WE05 lists IDocs by direction and status
– WE07 shows IDoc statistics
– BD87 is the main IDoc monitoring transaction
– WE09 can be used to search on IDoc content
• IDoc failures can be ALE layer errors or application
specific errors.
• Failures should be corrected and reprocessed ASAP.
• Workflow is strongly recommended for ALE error
handling (topic not covered here).

41
 tRFC Reporting
• tRFC is asynchronous.
– ALE does not wait for result.
• RBDMOIND can be scheduled to check comms.
• Successful comms change status 03 to 12.
• Manual transaction BD75 refers.

42
 Auditing
• Default behaviour is NOT to audit IDocs.
• ALEAUD message must be modelled.
• RBDSTATE reports status of incoming IDocs to
sending system.
• RBDAUD01 analyses the audit log and reports.
• Status codes:
– 53 (Application document posted) reported as 41
– 41 (Error: application document not posted) reported as 39
– 68 (Error: No further processing reported) as 40

43
 Error Handling
• Workflow is recommended.
• Use SE19 to debug IDocs.
– allows data edit.
– allows single stepping.
• BD87 also allows foreground reprocessing of error
IDocs.

44
 Outbound Points of Failure
• Outbound failures are rare, and usually
configuration or comms.
• IDoc creation:
– Error in message processing.
• Error creating outbound document.
• Error in output type proposal.
• Error in NAST processing.
• Error in output type processing.
– Error in change pointer process.
– Error in stand-alone program.
• IDoc processing:
– Error in ALE/EDI interface layer.
– Error in IDoc (syntax, conversion, etc).
– Error sending IDoc.

45
 Inbound Points of Failure
• Message processing:
– Error triggering SAP from tRFC call.
– Error creating IDoc.
– Error in ALE/EDI interface layer.
• IDoc processing:
– Error in posting function module.

… application errors by far the most common.

46
 Resolving Application Errors
• Execute failed processes in foreground (BD87).
– Applicable if posting via call transaction; see BD51.
• Edit failed IDocs.
– Quick fix.
– Addresses symptoms, not causes.

47
 Archiving
• Archiving should be performed regularly.
• Performance benefits.
• For ALE archiving is essentially deletion.
• RSEXARCA/RSEXERCB perform archive.
• Transaction SARA refers.

48
 ALE Development

ALE Monitoring Introduction

BONUS!
ALE
Development
ALE Processing ALE Configuration

49
 Extending IDocs
• Extend basic IDoc type:
– Create custom segment.
– Create IDoc extension tying custom segment to SAP segment to
be extended.
– Tie extension to basic IDoc type to create new Idoc type.
• Create new basic IDoc type:
– Create data elements.
– Create segments.
– Create basic IDoc type.
– Release segments and basic IDoc type.
• Need ABAP programs to process custom IDocs!
– Outbound and outbound.
– User exits available.
• Create message type (WE81) and link to IDoc type (WE82).
• Create new process code (WE41).
• Configure ALE (BD64, WE20, BD61, BD50, BD60).

50
 IDoc Data Manipulation
• Filtering.
– IDoc segments can be removed by segment filtering.
– BAPI parameters are checked for specific object values.
• Reduction.
– reduced IDocs can be created to meet requirements.
• Field Conversion.
– general rules can be specified for field conversions.
• Serialisation.
– serialised distribution of message types enables IDocs to
be created, sent and posted in a specified order.

51
 Segment Filtering
• IDoc segments which are not required can be
filtered by the ALE layer. These segments will not
be sent.
• Data independent.
• Filters are receiver- and message type- specific.

• Customising procedure:
– For a specific message type and corresponding
sender/receiver system, define the segments that should
be filtered.

52
 Field Conversion
• The contents of IDoc fields are adapted to the
requirements of the receiver.
• In some IDocs, fields can be suppressed.

• Customising procedure:
– Define a conversion rule for a specific segment type.
– Assign a type of conversion and selection conditions to a
field.
– Allocate the conversion rule to a message type, segment
type and sending/receiving system.

53
 Serialisation
• Some master data have dependent objects and should be distributed
together.
– e.g. material and classification.
• During inbound processing at the recipient system, these objects should
be processed sequentially.
– i.e. material followed by classification.
• Serialised distribution ensures that message types are processed in the
correct order.
– Dependent message types are joined in serialisation groups.
– The messages in a serialisation group are numbered.
– Message types will be processed in sequential order.

• Customising procedure:
– Create serialisation group.
– Assign message types to be used in the serialisation group.
– Maintain distribution model.
• Must include the message type SERDAT.
– Define inbound processing.
– Define the inbound processing.

54
 Extras

ALE Monitoring Introduction

… and there’s
more!

ALE Processing ALE Configuration

55
 Useful Transactions
Area Menus
ALE Folder under Tools in SAP Menu
Transaction WEDI
Transaction SALE

Use Transaction… Table… If you want to…

WE30, WE60 View an IDoc type’s structure and/or documentation
WE82 EDIMSG Find IDoc type’s relation with Message types and/or extensions
WE81 EDIMSGT View an Message type ’s structure description
WE82 EDIMSG Establish if there is a relevant IDoc extension
BD60 Find the outbound function module for SMD process
(*Remember that IDocs can also be triggered though transactions and via scheduled prgms)
(*Could also search in transaction SE37 for *MASTERIDOC*<Message type>*)
SALE Check if change pointers is set on globally for the client
SALE TBDA2 Check if change pointers is set on for the message
SCDO BDCP,BDCPV Establish what Change document drives the Chg. ptr. process
WE20 EDP21 Find Inbound Process code
WE42 Find link between Inbound process code and Update function
TBDBA Find which update function is called for BAPI process code
WE57 Find link between Message type / IDoc type & update function
SMOD, CMOD Find if user-exits have been implemented in standard Inbound / outbound processes.
(* Also search code for string ‘userexit’ and ‘call customer-function’)
BD51 Establish whether call transaction / Direct Input has been used
(*This transaction should only be used as a guide, the best method of determining whether call transaction has been used is to scan the Update function for the command ‘call transaction’).
BD64 TBD05/06 View distribution model
SM58 View failed tRFC’s.
(*Double click on the User name to view the data content of the message and establish what message type it is)
WE19 IDoc Test Tool

Other related SAP Areas, Useful transactions:

SCDO – Change Documents – sets out which table fields are logged for changes. The change history is stored in table CDHDR and CDPOS.
SM35, SHDB – Batch Input Recording and Session Management. Fundamental to understanding ‘Call transaction’.
SE80 – ABAP Workbench. It’s all in here… See Performance Examples
SE30 – Runtime analysis
SE11, SE16 – Data Dictionary and Table contents Viewer

56
 Status Codes
• Outbound:
– 01 Created
– 30 IDoc ready for dispatch (ALE service)
– 03 Data passed to port OK
• Inbound:
– 50 IDoc added
– 64 IDoc ready to be transferred to application
– 62 IDoc passed to application
– 53 Application document posted
– 68 Error - no further processing
• Others - see WE47.

57
 Batch processing
RSEOUT00 ALE outbound processing
RBDAPP01 ALE inbound processing
RBDMANI2 ALE inbound error reprocessing
RSNAST00 Creation of IDocs via message determination
RBDMIDOC Creation of IDocs from change pointers
RBDMOIND Status conversion for successful RFC Execution
RBDCPCLR Reorganization of change pointer table (BDCP) to
delete all records transferred to IDoc

58
BD64 (© SAP AG)

59
WE20 (© SAP AG)

60
SM59 (© SAP AG)

61
SM59 (© SAP AG)

62
WE21 (© SAP AG)

63