Post on 26-Mar-2015
transcript
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
Master Data Replication
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
Master Data Replication
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
Master Data Replication
• 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
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
32
Application Created IDoc
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
Communication IDoc Structure
Control record (EDIDC)
Data records (EDID4)
IDoc IDPartnerIDoc type and logical messageExternal structure
Control part Application data
Status records (EDIDS) IDoc IDStatus information
37
Communication IDoc Structure
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
59
BD64 (© SAP AG)
60
WE20 (© SAP AG)
61
SM59 (© SAP AG)
62
SM59 (© SAP AG)
63
WE21 (© SAP AG)