Sie sind auf Seite 1von 4

7 Steps For ALE Configuration

ALE configuration normally involves the seven basic steps which


are :
1. Creating users for ALE Transfer

2. Creating Logical system and assign the client

3. Creating the RFC

4. Configuring Distribution Model

5. Configuring and checking the port

6. Configuring and checking the partner profile

7. Creating the message type

The steps to configure and use it is mentioned below :


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.

Path:

1. Structure>Basic Settings>Logical system>


2. Structure>Basic Settings>Communication
3. Structure>Basic Settings>Modelling and Implementation Business Processes.

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 and click on Environment -> Generate Partner Profiles
o Select Transfer IDOC Immediately and Trigger Immediately radio buttonsF
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

1. INTRODUCTION TO ALE DEVELOPMENT Developing a new custom ALE scenario comprises 5 steps:
 Design and develop the custom IDoc with it’s segments and a new message type
 Configure the ALE environment with the new IDoc and message type (customer model, partner profiles and linking IDoc to
message type)
 Develop the outbound process which does the following:
o Populates the custom IDoc with control info and functional data
o Sends the IDoc to the ALE layer for distribution
o Updates status and handles errors
 Configure the ALE inbound side (partner profiles with inbound process code)
 Develop the inbound process which does the following:
o Reads the IDoc into a BDC table; selects other data that is required
o Runs transaction using call transaction or BDC session
o Updates status and handles errors
Below is a pictorial representation of the flow of a complete ALE scenario from the sending system to the
receiving

1: ALE Scenario model 1.1. ALE Example For the purposes of this example we will develop a small ALE
scenario. This scenario is described below. “The receiver of an internal service must be able to reverse
(cancel) the invoice receipt which will then cancel the applicable billing document automatically on the service
provider’s

system.”
Figure 2: Example Purchasing & Selling scenario
We will develop a custom IDoc to carry the billing number from the Service Receiver’s system to the
Service Provider’s system. We will populate the IDoc in a user exit on the sending side and we will process
the transaction on the receiving side using a custom function module and a BDC transaction call. No rule
conversion, segment filtering or version conversion will be implemented in the model as described in Figure
1. Requirements
 Working ALE environment - See ALE Basis Configuration Guide;
 ALE scenario design together with the business requirement;
 Development access; and
 ALE configuration access.
NOTES:
1. All IMG references to transactions are located in the transaction SALE which is the ALE portion of the IMG
2. This is one way of developing a scenario where no message control exists. If message control exist (EG. On purchase orders)
then NAST can be used to call an outbound function module that would create the required IDocs.
2. OUTBOUND PROCESSING
2.1. Create IDoc type (WE30) Client independent The IDoc type refers to the IDoc structure that you will
require for your development. In our case the IDoc type is called ZINVRV01. This IDoc type will have 1 segment
called Z1INVRV with 2 fields, LIFNR & XBLNR, in this segment. If you require many segments or nested
segments then they are also created using the same procedure.

Das könnte Ihnen auch gefallen