ALE Overview Too Good

ALE Overview

2

Introduction

ALE Configuration

ALE Monitoring

ALE Processing

Introduction

3

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

4

Loose vs Tight Coupling

Loosely coupled• time-wise: asynchronous• message-based• data consistency is important• “90% of distributed applications do not need traditional coupling.”Source: Meta Group

Tightly coupled• time-wise: synchronous• RFC-based• data consistency and timeliness is important• “10-20 times more expensive than loosely coupled”Source: Forrester Research, Inc.

Use loose coupling whenever possible, but communicate frequently!

Use loose coupling whenever possible, but communicate frequently!

5

Why is ALE needed?

• Distribution of business functions– Head Office– Sales– Production

• Distribution of systems environments– Development– Test– Production

• International Enterprise with National Subsidiaries

6

Distributed Business Processes

PP Inventory

management Internal sales,

shipping and billing Local purchasing PM Local SOP

Financials Central controlling Central SOP Information Systems:

Inventory Purchasing Sales

Central purchasing Reference system for

Master Data and Control Data

Sales, shipping and billing

Purchasing of trading goods

Inventory management

Local controlling

7

ALE Configuration

ALE Configuration

IntroductionALE Monitoring

ALE Processing

8

ALE Configuration

Logical SystemsDistribution Model

Partner ProfilesPorts

Message TypesIDocs

IDoc Types

9

Logical Systems

• Every system has a logical system name.• Usually <system name>CLNT<client number>

• You link logical systems together in a distribution model.

ApplicationApplicationApplicationApplication

System 1

R/3

System 2

R/3,non-SAP

IDocIDocIDocIDoc

10

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.

11

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.

12

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

13

Message Types

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

message type.

14

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

15

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.

16

IDoc Types StructureMessage Type

IDOC Type

Segment 1 Segment 2 Segment 3

field 1 field 2 field 3 field 4 field 5

IDOC Type

new IDOC types created asmessage type is developed(release specific IDOC types)

17

Master IDocs

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

18

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.

19

Communication IDoc Structure

IDoc

ControlRecord

StatusRecords

•IDOC number•Sender•receiver•ALE Message type•IDOC type•Current status

•IDOC number•segment id•segment seq #•higher segment #•hierarchy #•segment details

•IDOC number•direction•status•message•date/time

DataRecords

20

IDoc Definition Tools

IDoc Type Editor

WE30

E1HDDOCSegment editor

WE31

21

Transaction Reference

BD64 Distribution ModelsWE20 Partner ProfilesWE21 PortsSM59 RFC DestinationsWE30 IDoc TypesWE31 IDoc Segments

• All these can be found via SALE

22

ALE Processing

Introduction

ALE Configuration

ALE Monitoring

ALE Processing

23

Conceptual View

• Message based• Asynchronous

System 2System 1

IDocIDoc

Document Document

24

InboundPartnerProfile

CommunicationsLayer

OutboundPartnerProfile

Distribution Model

Create Master

IDoc

Master Data Replication

Application created IDoc(eg FI)

Message Control(e.g. SD/MM)

Application calls ALEfor BAPI

ALELayer

Determinerecipient

CreateCommunication

IDoc

CommunicationsLayer

Determineport type

Convert IDocto port format

IDocS

ALELayer

Determine transaction code

and inbound module

Application

Inbound Function Module

Outbound Inbound

tRFC(or file)

IDocS

Overview

25

Create Master

IDoc


Application created IDoc(e.g. FI)

Message Control(e.g. SD/MM)

Application calls ALEfor BAPI

Master IDoc Creation

• Four mechanisms for production of master IDocs.

• Created as an internal table in ABAP program.

• Only exists during program runtime.

• Transferred to ALE layer for routing.

26

Master IDoc Structure• Control Section

– MANDT client– DOCNUM IDoc number– SEGNUM row number– SEGNAM segment type– PSGNUM row no of parent– HLEVEL hierarchy level

• Data part– DTINT2 length of data part– SDATA data, type CHAR

• A Master IDoc is an internal table with line structure EDIDD that can have any number of rows.

• Each row has a control part containing meta information for the row, and an actual data part.

• Data part has maximum 1000 bytes per row.

27

Communication IDoc Creation

Application

IDOCDB

The application createsThe application createsIDOC’s directlyIDOC’s directly

2.

The applicationThe applicationcreates change pointerscreates change pointersfor deferred processingfor deferred processing

1.

The applicationThe applicationcreates a message entrycreates a message entryfor deferred processingfor deferred processing

3.

28


Application

IDOCIDOCDBDB

BDCPBDCP

RBDMIDOCRBDMIDOC

Change pointers Change pointers for Master Data for Master Data written directlywritten directly

to tableto table

App DataApp Data

29

Application Document

Application Process

Change Document

Change Pointers active

generally?

… for application document?

Change Pointer

RBDMIDOC (BD21)

Yes

Yes


• Driven by change pointers.• Change pointers activated

generally, and specifically by application document.

• Stored in BDCP (BDCPV). • Schedule RBDMIDOC to

process change pointers.

30

Application Created IDoc

Application

IDOCDB

Appl. data Appl. data is written directlyis written directly

to IDOCto IDOC

31


• 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

32


Comm. IDocComm. IDocComm. IDocComm. IDocComm. IDocComm. IDocComm. IDocComm. IDoc Comm. IDocComm. IDocComm. IDocComm. IDoc

Ma

ste

r ID

oc

Ma

ste

r ID

oc

Ma

ste

r ID

oc

Ma

ste

r ID

oc

SAP Application

External System

IDoc Interface / ALE Services

33

App DataApp Data

Message Control

Application

IDOCDB

NAST

Control Data Control Data written directlywritten directlyto table NASTto table NAST

NAST

RSNAST00RSNAST00 ImmediateImmediate??

NoNo

YesYes

34

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.

35

Message Control

IDocIDocIDocIDoc

MCMCrecordrecord

MCMCrecordrecord

DocumentDocumentDocumentDocument

SAP Application

Message Control (MC)

External System

IDoc Interface / ALE Services

36


Control record (EDIDC)

Data records (EDID4)

IDoc IDPartnerIDoc type and logical messageExternal structure

Control part Application data

Status records (EDIDS) IDoc IDStatus information

37


Control record

Status records

E1MBEWM

Data records, represented as a segment tree

E1MAKTM

E1ITSCH

E1MARAM

E1ITDOC

Elternsegment

E1MARDM

O 4

E1MARCM

O 3

O

M 2

M 3 O 3

38

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

39

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.

40

ALE Monitoring

Introduction

ALE ConfigurationALE Processing

ALE Monitoring

41

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

42

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.

43

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

44

Error Handling

• Workflow is recommended.• Use SE19 to debug IDocs.

– allows data edit.– allows single stepping.

• BD87 also allows foreground reprocessing of error IDocs.

45

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.

46

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.

47

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.

48

Archiving

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

49

ALE Development

Introduction

ALE Configuration

ALE Monitoring

ALE Processing

BONUS!ALE

Development

50

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

51

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.

52

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.

53

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.

54

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.

55

Extras

Introduction

ALE Configuration

ALE Monitoring

ALE Processing

… and there’s more!

56

Useful TransactionsArea Menus

ALE Folder under Tools in SAP MenuTransaction WEDI Transaction SALE

Use Transaction… Table… If you want to…WE30, WE60 View an IDoc type’s structure and/or documentationWE82 EDIMSG Find IDoc type’s relation with Message types and/or extensionsWE81 EDIMSGT View an Message type ’s structure descriptionWE82 EDIMSG Establish if there is a relevant IDoc extensionBD60 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 clientSALE TBDA2 Check if change pointers is set on for the messageSCDO BDCP,BDCPV Establish what Change document drives the Chg. ptr. processWE20 EDP21 Find Inbound Process codeWE42 Find link between Inbound process code and Update function TBDBA Find which update function is called for BAPI process codeWE57 Find link between Message type / IDoc type & update functionSMOD, 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 modelSM58 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 ExamplesSE30 – Runtime analysisSE11, SE16 – Data Dictionary and Table contents Viewer

57

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.

58

Batch processing

RSEOUT00ALE outbound processingRBDAPP01 ALE inbound processingRBDMANI2ALE inbound error reprocessingRSNAST00 Creation of IDocs via message determinationRBDMIDOC Creation of IDocs from change pointersRBDMOIND Status conversion for successful RFC ExecutionRBDCPCLRReorganization of change pointer table (BDCP) to

delete all records transferred to IDoc

ALE Overview Too Good

Documents

Transcript of ALE Overview Too Good