about some concepts.

[Former Member]

can anybody describs definition and relation in detail about business object,idoc type,message type,segment type.,filter object type and so on?

thanks a lot.

[Former Member]

hi joy,

What is ALE

ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP systems. ALE provides intelligent mechanisms whereby clients can achieve integration as well as distribution of applications and data. ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time. The ALE components are inherently integrated with SAP applications and are robust, leading to a highly reliable system. ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running.

The message-based architecture of ALE comprises three layers:

Application layer. This layer provides ALE with an interface to R/3 to originate or receive messages containing data to or from external (or other R/3) systems.

Distribution layer. The distribution layer filters and converts messages containing data based on predefined or custom-defined rule sets. These conversions may occur to ensure compatibility between different releases of R/3 and R/2.

Communications layer. ALE communications are carried out both synchronously and asynchronously. Synchronous message transmissions are typically used for the direct reading of control data, while asynchronous message transmissions are used for transmitting or receiving application data. It is also possible to achieve a pseudo-real-time exchange of application data using transactional Remote Function Calls (tRFC), which I’ll detail later in this article series.

ALE scenarios fall into three categories: master data, transactional data, and control data distribution. Although the underlying principles are the same for the different categories, there are differences in their functions and configurations. SAP delivers over 200 ALE scenarios; and by extension there are approximately 200 application areas that can leverage ALE technology for data distribution or communication. A subset of these scenarios is supported by R/3 for Electronic Data Interchange (EDI).

There are several advantages to using ALE technology:

• SAP ensures release independence.

• Robust mechanisms capture changes to master data or transactional data.

• ALE offers better inbound interface performance compared to traditional techniques such as Batch Data Communications (BDC) or Call Transactions. ALE does not use screen-based batch input.

• ALE provides black-box technology, so the user is at a higher level.

• Most ALE interfaces can be prototyped in a couple of days, resulting in smaller implementation timelines.

• There is little or no ABAP program development. In most cases, the SAP-delivered ALE functionality meets the requirements.

• ALE offers a systematic and organized approach to custom enhancements and extensions.

• An ALE interface is easy to maintain due to the structured approach and minimal number of development objects.

• ALE is the strategic architecture for R/3 “loose coupling” with legacy and third-party applications and is a Business Framework key element. It provides a message-based architecture for asynchronous integration of Business Framework components, including Business Components, Business Objects, and BAPIs.

ALE Building Blocks and Concepts

The following building blocks are fundamental to ALE functionality:

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.

IDOC type and IDOC. An Intermediate Document (IDOC) type represents the structure of the data associated with a message type (DEBMAS02 for message type DEBMAS — Customer Master, and WMMBID02 for message type WMMBXY— Goods Movements), while an IDOC is an object containing the data of a particular message type. IDOCs are data containers with intelligence built in. Each IDOC contains one and only one business object. For example, an IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment Document. Generally, the architecture of an IDOC is independent of the message type by virtue of ALE’s ability to redefine it for any message type.

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.

Use transaction BD64 or the following menu path to maintain the model: From the IMG (Implementation Guide), Cross-Application Components -> Distribution (ALE) (*) -> Distribution Customer Model -> Maintain Distribution Customer Model Directly -> Maintain Distribution Customer Model Directly.

The IMG for ALE, Distribution (ALE) (*), can also be directly invoked by using transaction SALE. This transaction is used very frequently in ALE. (I’ll discuss the process of creating, maintaining, and distributing a Customer Distribution Model later in this article.)

Filter object type and filter objects. A filter object type is used in the Customer Distribution Model to impose a selection criterion on the message (type) flowing to a Logical System. A filter object type with a value associated with it is called a filter object. For example, BUKRS (Company Code) is a filter object type available for message type DEBMAS (Customer Master). To distribute Customer master data of only Company Code “1001” to a particular Logical System, you would use filter object type BUKRS to create a filter object with value BUKRS = 1001. You can have multiple filter objects with different values for the same message type associated with that LS. While determining the receiver(s) of a particular message based on the Distribution Model, ALE performs object filtering. As with the Customer Distribution Model, filter objects are relevant only to ALE.

(I’ll explain the steps to create a filter object, as well as how to create a new filter object type, later in this article.)

Listings. Listings are a special filter object type occurrence and are also used to specify a selection criterion for distributing master data. Listings are based on the SAP Classification system (classes and characteristics), and are applicable only to Material, Customer, and Vendor master data. Once a list has been created, based on certain classification information using the ALE customizing menu, it is associated with an LS. The listing is then used to create a filter object with type LISTING, for a message type associated with that LS.

Lists are maintained and allocated to an LS from the ALE customizing guide using transaction SALE, or Distribution Scenarios -> Master Data Distribution -> Distribution via Listings.

Change pointers. Change pointers are R/3 objects that mark changes to SAP master data. Change pointers are managed by mechanisms in a Shared Master Data (SMD) tool and are based on Change Document (CD) objects. CD objects record the changes occurring to master data at a field level. These changes are stored in tables CDHDR (header table) and CDPOS (detail table). ALE configuration provides a link between CD objects and change pointers. Internal mechanisms update tables BDCP and BDCPS, which host the change pointers. While CD objects are application-data-specific, the processing status of change pointers is message-type-specific. Also, the ALE change pointers are activated first at a general level and then at the message-type level.

ALE provides powerful capabilities to capture changes occurring to master data and to distribute them via the IDOC interface. This feature can be used to keep two or more systems synchronized with respect to master data.

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.

Process codes. Process codes are used in ALE and EDI to identify the function module or API to be invoked for subsequent processing. An 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.

Use transaction WE41 to display outbound process codes and WE42 to display inbound codes, or from WEDI select Control -> Outbound Process Codes/Inbound Process Codes, or from ALE customizing SALE select Extensions -> Outbound -> Maintain Process Code, or Extensions -> Inbound -> Maintain Process Code.

Message control and output type. In R/3, message control is a mechanism by which documents are output based on certain selection criteria, requirements, and sequences. Message control determines the type of document, its timing, number, and medium (print, fax, ALE, or EDI.). Outbound messages in SD (Sales and Distribution) and MM (Materials Management, Purchasing) are created and processed by message control records. The output records are stored in the NAST table.

Message control uses the condition technique. The conditions for creating an output message are stored in condition tables that have selection fields picked from a catalog of application fields/tables. To determine if an application document qualifies for output, search strategies are used through access sequences, output procedures, and requirements. Once a message qualifies for output, message control modules use the parameters set in the condition type or output type to determine the timing of transmission and the medium of the message. The output type also specifies the program or module to be invoked to create the output.

Message/output determinations are concepts applicable not only to EDI and ALE, but also to other output mediums.

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.

thanks

karthik

reward me points if helpfull

[Former Member]

Hi Friend,

U have chosen a wrong forum. Pls put ur post in ABAP forum...