Logical System

A Logical System (LS) is the representation of an R/3 or external system in SAP R/3
for the distribution of data to and from the R/3 System.
Every R/3 client used for ALE or EDI has to have a base LS associated with the
client.
This LS becomes the �sender� for outbound messages and a �receiver� for inbound
messages.
In addition to the base LS, a second LS should be created within that R/3 system
for each R/3 or external system used for ALE interfaces.
In an inbound ALE interface, this second LS represents the sender (another R/3 or
external system) with respect to the base LS (receiver).
In an outbound ALE interface, this second LS is the receiver on behalf of the R/3
or external system with respect to the base LS (sender).

Message Type
A message type represents the application message exchanged between R/3 systems and
R/3 and an external system.
A message type characterizes the data sent across systems and relates to the
structure of the data called an IDOC type (see below).
For example, MATMAS is a message type for Material Master, and INVOIC is a message
type for an Invoice (Billing Document).
ALE supports over 200 message types in R/3 and about 200 application areas.

Customer Distribution Model

Customer Distribution Model. In an R/3 system, the Customer Distribution Model is a
tool that stores information about the flow of messages across various systems.
The Customer Distribution Model uses an SAP-delivered Distribution Reference Model
as its basis (the Customer Distribution Model can have distribution scenarios other
than ones stored in the Distribution Reference Model.)
The Customer Distribution Model stores data that dictates which messages (message
types) flow to which Logical Systems.
Many messages can flow to one Logical System, and one message can flow to several
systems.
With the use of filter objects and listings (which I�ll describe shortly), it is
also possible to specify in a model the criteria for filtering information for a
specific system.
A Customer Distribution Model can be created in an R/3 system with that client�s
base Logical System as the �sender� Logical System.

Ports
A port is a logical representation of a communication channel in SAP, with the data
communicated being IDOCs.
There are four types of ports that can be defined in R/3: tRFC, File, R/2, and
Internet.
ALE can use all port types to distribute IDOCs, while EDI typically uses a file-
based port.
tRFC and File ports can link to RFC destinations connected to R/3-to-R/3 or TCP/IP.

By linking ports to RFC destinations, the port can also trigger scripts to invoke
EDI subsystems, IDOC mapping software, and FTP.
You can maintain ports by executing transaction WE21 or WEDI, or selecting IDOC ->
Port Definition.
RFC destinations can be maintained using transaction SM59.

The communication ports determine the type of data communication that must occur
between systems.
When the communication is to use the RFC protocol, transactional RFC ports must be
created specifying the RFC destinations of the partner systems.
Use transaction WE21 for this purpose.
RFC Destination
An RFC destination may be seen as a set of settings necessary to connect to a
system using the RFC protocol.
These settings include the address and type of the partner system along with
connection information such as the user ID and password to use.
The RFC destinations of all partners systems must be defined on all systems to
include in the distribution model.
The transaction to use for this purpose is SM59.

Partner Profile
A partner profile is an identifier for a system used for communicating messages.
There are four types of partner profiles:
KU for Customer,
LI for Vendor,
B for Bank, and
LS for Logical System.
KU, LI, and B are used for EDI partners, while LS is used for ALE
communications
Every partner profile used for ALE must be based on an existing LS.
A partner profile brings together several ALE and EDI elements to define the
parameters of communication between two or more systems.
Other than general information, you have to maintain
-inbound parameters, outbound parameters, and message control.
The main parameters are message types, IDOC types, process codes, partner
functions, application identifiers, message functions, output types, and ports.
Other parameters also determine the mode of processing and error handling.
A partner profile plays a major role and can be viewed as a gateway for ALE and EDI
communications.
It routes the specified messages through defined IDOC types to a given port after
invoking the appropriate function modules for outbound processing.
It receives IDOCs of a specific type, and it identifies modules to post data to the
application databases in the case of inbound interfaces.

Process codes.
Process codes are used in ALE and EDI to identify the function module or API to be
invoked for subsequent processing. A
n inbound interface uses a process code to determine the application module that
will process the inbound IDOC to an SAP application object such as a sales
(Customer) order (process code � ORDE), Material Master record (MATM), or a
shipment (SHIP). An outbound interface uses process codes only in the case of
applications that use message control (which I�ll get to shortly). In this case,
the process code identifies the application module that populates the IDOC with
application data. Each process code is associated with a message type. Outbound
process codes are stored in table TEDE1, while inbound process codes are stored in
TEDE2