topic Re: ALE in Application Development and Automation Discussions

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/sapedi/idoc_abap.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm

http://www.sappoint.com/abap.html

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

Regards,

Priyanka.

Re: ALE

Former Member — Mon, 03 Sep 2007 06:31:58 GMT

Application Linking Enabling - Purpose:

Application Link Enabling (ALE) supports the distribution of business functions and processes across loosely coupled R/3 Systems. Connections from R/2 and non-SAP systems are supported.

Implementation Considerations:

Distributing business applications and at the same time ensuring data consistency is practical because:

The increasing globalization of markets has led to the physical division of organizational units.

Business processes are not restricted to one organization only and an increasing number of customers and vendors are involved.

The performance of an R/3 System can be improved by distributing the business applications.

Features:

ALE supports the configuration and operation of distributed applications. ALE supports the configuration and operation of distributed applications. ALE handles the Message Exchange

Between Distributed Applications across loosely coupled R/3-System, ensuring that data is always consistent.

Applications are integrated using a local database rather than a central one. There is no data retention. ALE ensures data is distributed and coordinated using asynchronous communication. ALE uses synchronous connections for reading data.

ALE supports:

Distribution of applications between different releases of R/3 Systems

Continued data exchange after a release upgrade without requiring special maintenance

Customer-specific extensions

Communication interfaces that allow connections to non-SAP systems

Coupling of R/3 and R/2 Systems

ALE has functions for controlling messages flows (Audit) and for eliminating malfunctions.

ALE and R/3 Procedure Model:

The R/3 Procedure Model provides cross-application information required for implementing R/3 software. The model is like a phase model whereby work steps are assigned to each phase and one or more Customizing works steps are associated with each phase.When implementing ALE functions you should refer to the R/3 procedure model to ensure that R/3 is implemented in a well structured way.

If ALE is to be supported in an R/3 System installation, implementation of the R/3 procedure model is affected at four points:

?Determining functions and processes

Specifying global settings

Modeling company structure

Modeling control data and master data

If ALE business processes are supported, functions and processes must be defined on a cross-system basis. The message types exchanged between the systems are described in the distribution model. When defining organizational units like company codes and plants in the R/3 System, it is important to note that these have to be unique worldwide, across all systems. For example, the plant 0001 can only exist in one R/3 System.

Message Exchange between Distributed Applications:

Purpose:

The basis for distributing application functions is asynchronous message exchange via ALE outbound and inbound processing.

Prerequisites:

Data exchange is based on IDoc. IDoc are created and dispatched by message types and by methods in distributed systems.

Process Flow:

An application creates a master IDoc containing the relevant data. The IDoc is passed to the ALE layer where it is prepared for dispatch. After the IDoc has been successfully transferred it is read by the target system and inbound processing is triggered. The data is processed either fully automatically or part manually according to the settings until is posted in the application.

Inbound and outbound processing can either be carried out for each individual IDoc or by massprocessing, whereby several IDoc are bundled together in one packet and processed in one step.

IDoc Definition:

An intermediate document (IDoc) is a container for exchanging data between R/3, R/2 and non-SAP systems.

Use:

ALE uses IDoc to exchange data between logical systems. Non SAP-systems can use IDoc as the standard interface for data transfer. IDoc are created by message types and (object) methods when data is to be distributed.

Structure:

An IDoc represents a configuration of an IDoc type that determines the IDoc structure. An IDoc consists of a header, several data segments and status records.The functions of the individual elements of an IDoc are as follows:

The contents, structure, sender, receiver and current status of the IDoc are defined in the IDoc header.

Each data segment contains a standard header consisting of a sequential segment

number, a description of the segment type and a 1000 character long string field

containing the actual data of the segment.

?The status records show the history of the processing steps applied to the IDoc so far.

The structure of the IDoc is recorded in the SAP System. The structure definition covers the

following:

The segment sequence. Hierarchical relationships between segments are possible.

The number of times a segment can occur is specified for each segment, as is

whether the segment is a mandatory segment or an optional segment.

The fields contained in a segment. In the example shown above the IDoc contains a

header segment that has to be the first segment of the message.

Thereafter there must be at least one additional item. The following conditions apply:

Each item must be followed by at least one sub-item and at most 99

Up to 9999 text segments can appear after an item's sub-items (optional)

The last segment in a message must be an accumulation segment (ACCUM)

An IDoc can only contain character fields.

Modeling Distribution:

Purpose:

To implement the distribution of business application processes and functions using ALE you need to construct a logical Distribution Model of the whole system. Within the framework of this configuration customers can specify what applications are to run on what systems and what messages are to be exchanged between the applications .

Distribution Model:

Definition: The distribution model describes the ALE message flows between logical systems.

Use:

You can specify the relationships between logical systems, message types, BAPIs and filters inthe distribution model. Applications and the ALE layer use the model to determine the receivers and to control data distribution.

Structure:

In the distribution model you can specify the messages to be sent to a logical system. You can also define requirements for message content and dispatch in the Filters. The distribution model consists of one or more views that you can define. With more complex distribution tasks you can assign business sub-areas or groups of logical systems to separate views. To ensure correct functioning the relevant views of the distribution model must be available in all the logical systems involved in ALE. You can find the functions for distributing views in Customizing for ALE.

Notes: 105 is Sender and 800 Receiver System For Example

1. Create Users for ALE transfer in both receiving and sending client/systems.

Create users in both the client/systems giving the same user name and proper authorizations. We need to use these user ids to logon through the remote connection and perform the IDOC transfers.

2. Creating Logical Systems

o Create logical systems for both sending and receiving systems in both systems.

o Login to Client 105 (SENDER)

o Go to T. Code SALE

o Expand Sending and Receiving Systems

o Expand Logical Systems

o Click on Define Logical System

o Click on New Entries

o Create Logical Systems with naming convention 'system name''CLNT'client no . For example for sending system ex: SSPCLNT105

o Create Logical Systems with naming convention 'system name''CLNT'client no ex: example for receiving system ex SEDCLNT800

o Save and come back

o Click on Assign client 105 to Logical system SSPCLNT105

o Now, logon to client 800, repeat the same above process to create logical systems SEDCLNT800 and SSPCLNT105

o Save and come back

o Click on Assign client 800 to Logical system SEDCLNT800

3. Creating the RFCs

o In client 105, Go to T. Code SM59

o Expand R/3 Connections

o Enter RFC Name as SSPCLNT105 (give this name same as that of logical name created in step1 so that the ports are automatically created)

o Connection Type as 3

o Language as EN

o Give the logon details for client 800 (usually, we create a new user with proper authorizations for this ALE data transfer)

o Click on Remote logon button to test the RFC

o Now, go to client 800 and repeat the same process to create the RFC connection to client 105, giving logon credentials to client 105

4. Creating Customer Distribution Model(we usually create this in the original system(sending system) and then distribute it to other systems. The actual creation of the model requests that you mention a technical name for the model (unique identifier in the systems landscape), a sender system, a receiver system and message types to exchange between those systems.)

o In Client 105, Go to T. Code BD64

o Click on change and Create model view button

o Enter the short text and Technical name as ZSSP_SED

o Select the model and click on Add Message Type Button,

o Give the Sender as SSPCLNT105, Receiver as SEDCLNT800,

o Give Message type as required, Ex: 'HRMD_A' for HR Module.(usually Message types given by SAP are available for a particular module, see this using tcode WE81, if not create a message type first)

o Note: If we are performing this data transfer task for all modules at a Customer site, then we will need to use the appropriate message type and create a new Distribution model.

o Select the above model view & click on Environment -> Generate Partner Profiles

o Select Transfer IDOC Immediately and Trigger Immediately radio buttons

o Click on Execute

o You should get a list in green color which means it executed successfully.

o Back to main screen, select the model view

o Click Edit->Model view->Distribute

o Click on continue

o You should get a list saying model view is distributed successfully.

5. Checking the Port

o In client 105, Go to T. Code WE21

o Expand Transactional RFC

o Find the port from the list which is created using BD64 for SEDCLNT800 (Receiving system) RFC Destination.

6. Checking the Partner Profiles.

o In client 105, Go to T. Code WE20

o Expand Partner Type LS

o Select the Partner profile SEDCLNT800

o Double click on Message Type (For Ex: In HR Module, HRMD_A in Outbound parameters.)

o Check Receiver Port is assigned correctly

o Check the Basic type as your Basic IDOC object.

o In the sending system, select the option to transfer IDOCs immediately.

o By default, in the receiving system IDOCS are bunched together and received.

7. Creating the Message Type

o Message type defines the 'meaning' of data. It is just a logical entity that gets connected to the Idoc type (in tcode we82) or gets connected to the distribution model (in tcode BD64)

o If necessary create a new message type. In client 105, go to tcode we81.

o Click on change, continue

o Click on New Entries button

o Give message type in customer namespace Z* and description

o Save and back

Purpose

Application Link Enabling provides a range of administration tools:

? Monitoring of IDoc processing and tRFC communication

? Transport of Customizing data from maintenance systems to receiving systems

? Optimization of ALE performance

? Serialization of messages

Status Monitor for ALE Messages (BD87)

Use

With the status monitor you can monitor the processing status of IDocs in ALE inbound and outbound processing and you can process IDocs manually.

Features

Choose Tools ¨ ALE¨ Administration¨ Monitoring ¨ Status Monitor for ALE Messages. (BD87)

Use the selection options to restrict and display the IDoc selection.

The IDocs are arranged by status in the hierarchy. You can rearrange them by message type/object type or by partner system. You can display a selection of IDocs, process IDocs directly or first restrict their number and then process them.

From the hierarchy display you can select an IDoc in the list and from here branch to the IDoc individual display.

Restricting IDoc Selection

In the selection screen you can use the following options for selecting IDocs:

? IDoc number

? Date created *

? Time created

? Date changed *

? Time changed

? IDoc status

? Partner system

? Message type

? Business object type and object key (selection takes longer than with message type)

The arrow keys are used to scroll week by week.

You can call up context-specific menus that you can call up by clicking on the right mouse button.

IDocs in inbound and outbound processing are displayed in a hierarchy grouped by their status.

Status (Text with or without status numbers, number of IDocs) Message type (Object method: via Settings ¨ Display business object) Message text

To display a legend of the symbols used in the hierarchy choose Goto ¨ Display legend.

You can also restrict the number of IDocs to display from the hierarchy screen by choosing Select IDocs.

Note that it takes a long time to expand the sub-tree IDoc entries in tRFC queue. You should therefore expand this node, only if you really need to.

Changing the Hierarchy Display

From the menu Settings and partly by using the symbols you can change the hierarchy as follows:

? Message type/object type highlighted

? IDoc status highlighted

? Display partner systems (highlighted message type or IDoc status)

You can put status information into groups and hide/show status numbers (in Settings menu).

Displaying the IDoc List

Choose Display IDocs to display a list of the associated IDocs for each main entry or sub-entry that contains the following information:

? IDoc number

? Status

? Message type

? Object type (only for business objects)

? Status text

? Partner number of receiving system

? Date created

? Time created

? IDoc basis type

? Number of segments

Displaying individual IDocs

You can display the IDocs belonging to the IDoc numbers individually. Select an IDoc and choose Display IDocs or double click on the IDoc. The IDoc display contains the control record, data records and status records.

Displaying links to objects

To display links select an IDoc number and choose Display links.

A list of objects linked directly to the IDoc appears.

Displaying status long text

In the IDoc selection you can display the associated status long text of an IDoc number by selecting the button of the same name.

Displaying object keys

For each IDoc number in the IDoc selection you can also display the columns Object type and Object key by choosing the button Object key.

Determining Status in Receiving System

You can determine the status of the IDocs in the receiving system (inbound processing) using ALE Audit and IDoc Tracing :

? Asynchronous Status Confirmation

Provided that you Monitor the Status of Inbound IDocs Using ALE Audit and confirmations are returned from the receiving system periodically, confirmations are displayed in the status monitor hierarchy. Such IDocs have status 39, 40 or 41. The confirmations contains status information from the receiving system. In the appropriate IDoc selection for each IDoc you can find the partner number and the status of the assigned IDoc in the receiving system (50, 51...).

Alternatively you can display an aggregated overview of all periodic confirmations. To do this you have to Evaluate the Audit Database in the sending system (outbound processing). Choose Goto ¨ ALE Audit ¨ Evaluate Audit Statistics

? Synchronous status determination

For inbound IDocs (in the receiving system) and for outbound IDocs with status 3 and 12 you can synchronously call up the status of the IDoc in the partner system. Choose Trace IDocs in the status monitor hierarchy. For more information see System-Wide IDoc Tracing .

You can print the hierarchy of the status monitor (IDoc selection ¨ Print).

Processing IDocs

If incomplete IDocs or IDocs with errors exist, you can determine the cause and correct the problem using the status long text (click right mouse button or choose IDoc selection).

You can then process the IDocs, or first restrict the number of IDocs and then process them.

A list of processed IDocs with their previous and current status appears.

In inbound processing you can post non-posted IDocs (status 51) afterwards (see Error Handling )

? You can not process communication errors.

Tracing IDocs System-Wide

Use

In the status monitor you can trace IDocs system-wide to determine the processing status in the receiving system of IDocs with status 3 and 12.

Activities

In addition to the status overview you can also display links between IDocs and objects and between individual IDocs.

Displaying Status Overview

Select a status text or a message type / object method and select Trace IDocs.

A status overview of IDoc pairs in the sending and receiving systems appears.

The IDoc selection contains the following columns:

? IDoc number

? Status in sending system

? IDoc number in receiving system

? Status in receiving system

? Message type

? Status text from receiving system

? Partner number of receiving system

? Date created

? Time created

? IDoc basis type

? Number of segments

Displaying Links to Objects

To display links select an IDoc number and choose Display links.

A list of objects linked directly to the IDoc appears.

Displaying IDocs

You can display the IDocs individually in the sending and receiving systems . Select an IDoc and choose Display IDocs or double click on the IDoc.The IDoc display contains the control record, data records and status records. For more information choose Help ¨ Application help.

Checking Processing Status

The system provides functions for monitoring communication. These functions enable you to confirm whether ALE messages have been processed and transferred correctly or whether errors occurred. If an error did occur, the type of error is indicated.

You can monitor the processing status in both the sending system and the receiving system. Choose Tools® ALE ® Administration ®Monitoring ® Status monitor for ALE messages.

Execute the function, and select the IDocs of the logical message type MATMAS which you created today.

A list of inbound and outbound IDocs grouped by status is displayed:

Outbound IDocs:

Status

Description of Status

03, 12, 38

IDoc successfully transferred

02, 04, 05, 25

26, 29

Processing error

Waiting status (still processing...)

>=50

Inbound IDoc (not relevant in this context)

Other

Not relevant in this context

Inbound IDocs:

Status

Description of Status

IDoc successfully updated by application

Waiting status (still processing...)

<50

Outbound IDoc (not relevant in this context)

51, 56, 60, 61,

63, 65

Inbound error

Other

Not relevant in this context

To display a list of IDocs with a particular status, double-click on a line. For detailed information on one of these IDocs, double-click on it. If an error occurs, you can display information about the cause of it by choosing Process ® Incorrect segments.

Error Handling

If an error has occurred, use the monitoring function to resolve it. The cause of the error is likely to be a value in your material that the receiving system does not know and therefore cannot process it. Try to eliminate the cause of the error and send your material again.

If your IDoc in the sending system was successfully transferred (status 03) but does not appear in the receiving system, a technical communication error is the likely cause. You can use the status monitor in the sending system to check this. Choose Goto ® Transactional RFC ® Display calls.

var domainName = 'https://wiki.sdn.sap.com/wiki'; var entityId = '36038'; var spaceKey = 'Snippets'new Ajax.Autocompleter('labelName', 'labelsAutocompleteList', '36038',

Unknown macro:

);

Intermediate Document

An IDoc is simply a data container that is used to exchange information between any two processes that can understand the syntax and semantics of the data. IDoc is not a process.

- IDocs are stored in the database.

- In the SAP system, IDocs are stored in database tables.

- IDocs are independent of the sending and receiving systems.

- IDocs are independent of the direction of data exchange.

Creation of IDOCs

? Transaction code: WE 30

Defining Segment:

Creating Segment : Tcode - WE31

Creating Message Type : Tcode - we81

Assigning Message type to Idoc type: Tcode - we82

Process

The two processes for IDoc are Outbound Process and Inbound Process.

Outbound Process

When the data is sent out from the system, the process is called Outbound Process and the IDoc is known as Outbound IDoc.

Inbound Process

When the data is coming in, the process is called Inbound Process and the IDoc is known as Inbound IDoc.

Outbound Process (Sending System) Steps :

1) Goto Tcode SALE:

Click on Sending & Receiving Systems à Select Logical Systems

Here Define the Logical Systems à Click on Execute Button

Go for New Entries

1) System Name : LOG1

Description: Sending System

2) System Name : LOG2

Description: Receiving System

Press Enter & Save it will ask for Request if you want new request create new request or press continue for transferring the objects.

Assigning Client to the Logical System:

Select Assign Client to Logical Systems -à Execute

Ø 100 à Double click on this and give the following information

Client : Sending System

City : Chennai

Logical System : LOG1

Currency :

Client role :

Ø 250 à Double click on this and give the following information

Client : Receiving System

City :

Logical System : LOG2

Save this Data.

Step 2) For RFC Creation:

- Goto Tcode SM59 à Select R/3 Connects

Click on create Button

RFC Destination Name should be same as partner's logical system name and case sensitive to create the ports automatically while generating the partner profiles

Give the information for required fields:

RFC Destination : LOG2

Connection type : 3

Target Host : sappdc.wipro.com

System No : 00

Client : 210

User : Login user name

Password :

Save this & Test it and Remote Login

Step 3) Goto Tcode BD64: - Click on the change button

Click on the create model view

Short Text: model view

Technical Name: LMOD

Save this & press ok

Select just created model view

Name: "LMOD"

Goto add message type

Model Name : LMOD

Sender : LOG1

Receiver : LOG2

Message type: ZAZHARMESS

Save and press Enter.

4) Goto Tcode BD82:

Give Model View : LMOD

Partner system : LOG2

Execute this by pressing F8

It will gives you sending system port No: A00000000089 (Like)

5) Goto Tcode BD64:

Select the model view

Goto à Edit à model view à Distribute

Press ok & Press Enter.

Run your Zprogram

REPORT ZIDOC1 .

DATA: Begin of imara occurs 0,

matnr like mara-matnr,

mtart like mara-mtart,

end of imara.

DATA: wamas_con LIKE edidc,

imas_data LIKE edidd OCCURS 0 WITH HEADER LINE,

icom_con LIKE edidc OCCURS 0 WITH HEADER LINE.

PARAMETERS: e_matnr LIKE mara-matnr,

e_msgtyp LIKE edidc-mestyp,

e_rcvprn LIKE edidc-rcvprn.

retrive app. data from DB

SELECT matnr mtart FROM mara INTO TABLE imara WHERE

matnr = e_matnr.

*Master idoc control record

wamas_con-rcvprt = 'LS'.

wamas_con-rcvprn = e_rcvprn.

wamas_con-idoctp = 'ZAZHARIDOC'.

wamas_con-mestyp = e_msgtyp.

master idoc data records

LOOP AT imara.

imas_data-segnam = 'ZAZHARSEG'.

move imara to imas_data-sdata .

APPEND imas_data.

ENDLOOP.

CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'

EXPORTING

master_idoc_control = wamas_con

TABLES

communication_idoc_control = icom_con

master_idoc_data = imas_data

COMMIT WORK.

6) Verifying Transfer of IDOCs Tcode - we05

ALE/IDOC Status Codes (outbound):

01 à IDoc Added

30 à IDoc ready for dispatch

29 à Error in ALE service Layer

12 à Dispatch ok

03 à Data passed to port ok.

Inbound Process (Receiving System) Steps:

Do the same step as you did in sending system

ü Creating IDoc

ü Defining the Segment

ü Creating Message Type

ü Assigning the Message Type

ü Defining the Logical System

ü Assigning the Logical System

ü Creating the Distribution Model

Goto Tcode - we57:

Assign function module to IDoc type

Module: Function module

Basic type:

Message type:

Direction: 2 (inbound)

Creating Inbound process code - we42

Verifying Idoc List Tcode - we05

ALE/IDOC Status Codes (Inbound):

50 à IDoc Added

51 à Application Document not posted

64 à IDoc ready to be transferred to application

62 à IDoc passed to application

53 à Application Document posted

Also do refer these links

ALE/ IDOC

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/sapedi/idoc_abap.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm

http://www.sappoint.com/abap.html

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419