ALE in distributed landscape

Hi
I would like to know if it is possible to setup an ALE between 2 SAP systems that operates on different networks and are physically located in 2 different parts of a country. Or is it only possible to setup an ALE between 2 SAP systems locally within you organizations network.
Thank you
Wian

Hi,
yes we make integrte 2 systems using RFC Connection between two SAP Systems using transaction SM59
look to following links:
1)http://help.sap.com/saphelp_47x200/helpdata/en/22/042899488911d189490000e829fbbd/frameset.htm
2)
http://help.sap.com/saphelp_47x200/helpdata/en/54/31f438842e106ee10000000a11402f/frameset.htm
Reward points
Regards

Similar Messages

In ALE setting how to distribute GL account to severals company codes ?

Hi all ,
I use ALE to distribute G/L account data from one company code to one another company ( different host ) .
It's work fine now.
Now I want to distribute G/L account data from one company code to severals company codes.
But in cross-company code setting ( Tx: OBB5 ), one global company can only be assing to local company code in receiving host.
I have no idea how to set up the ALE configuration.
Can anyone give me some suggestion . Tks.
Regards,
Eric.

Dear Sharvari,
All the master data can be created in a central system and then distributed to the local systems through distribution models. I think no copy of GLs is possible. In your case you can create the GL Accounts in your central system and it'll flow to other systems automatically through ALE. To achieve this please consult your BASIS consultant who'll design the distribution model as per your requirement.
Regards
Edited by: drames on Aug 17, 2010 2:33 PM

Distributing message type MATQM using ALE

Hi everybody!
I am using ALE to distribute material data. This already works. Now I also want to distribute material data for quality management.
When I try to distribute materials using BD10 I get this message:
Could not determine recipients for message type MATQM
So I tried to create a new distribution model for MATQM using BD64. Unfortunately I could not choose MATQM or MATQM01 as the message type. (Error: Message type MATQM01 unknown)
However, in transaction WE60 I can display message type MATQM01.
What is the problem?
best regards
Roland

Hi Roland,
BD10 only can be used with message type MATMAS.
If you want to send message type MATQM and IDoc type, please use this FM MASTERIDOC_CREATE_SMD_MATQM. You still need to maintain partner profile (WE20) and IDoc Port (WE21).
Other you can use Change Pointer (BD21) to send out and ensure you have activated the change pointer for message type MATQM (BD50).
Hope this will help.
Regards,
Ferry Lianto
Please reward points if helpful.

TREX - Configuring Distributed Slave with Decentralized Data Storage

I am creating a distributed TREX environment with decentralized data storage with 3 hosts. The environment is running TREX 7.10 Rev 14 on Windows 2003 x64. These are the hosts:
Server 01p: 1st Master NameServer, Master Index Server, Master Queue Server
Server 02p: 2nd Master NameServer, Slave Index Server
Server 03p: Slave NameServer, Slave Index Server (GOAL; Not there yet)
The first and second hosts are properly set up, with the first host creating the index and replicating the snapshot to the slave index server for searching. The third host is added to the landscape. When I attempt to change the role of the third host to be a slave for the Master IS and run a check on the landscape, I receive the following errors:
check...
wsaphptd03p: file error on 'wsaphptd03p:e:\usr\sap\HPT\TRX00\_test_file_wsaphptd02p_: The system cannot find the file specified'
wsaphptd02p: file error on 'wsaphptd02p:e:\usr\sap\HPT\TRX00\_test_file_wsaphptd03p_: The system cannot find the file specified'
slaves: select 'Use Central Storage' for shared slaves on central storage or change base path to non shared location
The installs were all performed in the same with, with storage on the "E:" drive using a local install on the stand-alone installation as described in the TREX71InstallMultipleHosts and TREX71INstallSingleHosts guides provided.
Does anybody know what I should try to do to resolve this issue to add the third host to my TREX distributed landscape? There really weren't any documents that gave more information besides the install documents.
Thanks for any help.

A ticket was opened with SAP customer support. The response to that ticket is below:
Many thanks for the connection. We found out, that the error message is wrong. It can be ignored, if you press 'Shift' and button 'Deploy' (TREXAdmin tool -> Landscape Configuration). We will fix this error in the next Revision (Revision 25) for TREX 7.1.

ALE FOR HRM - EREC SYSTEMS

Hi all..
We are trying to configure ALE between Ecc Hr and EREC systems.
what we did :
3 badi imlementations were activated in HRM and EREC systems.
1. created logical system and assigned cleint.
2. created RFC connection and determined RFC dewstinations.
3. created Model view , added HRMD_A message type and created filers.
4. Generated profiles and distributed models.
5. Using Tcode Pfal for message type HRMD_A, for a ORG unit , we had sent data and IDOC status shows green with message reciever available , no filters, no conversions.
Issue :
But this org unit is not sent to EREC.
Differences :
1. In EREC system : Model is available with message type HRMD_A , but filters are not availale which are active in HRM ecc system.
2. in EREC , PFAL transaction : message type HRMD_B is comming by default and is in disabled mode, so even cannot change the message type. Even found that in table HRMD_A ia not available.
Please let us know , wether we should create the filters manually in EREC system or should we create HRMD_A message type manulally.
Thanks in advance
Regards
Ravi

Application Link Enabling (ALE)
You distribute data using ALE if you want to communicate from one system to
one or more other (mostly internal) systems. ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
· ALE enables the integration of business processes across several SAP or non-SAP systems.
Electronic Data Interchange (EDI)
You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor). The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12). This enables communication with non-SAP systems.

New to SAP...Doubts regarding ALE.

Hi all,
I am new to SAP.
Can any one please explain me the following.!
What is the difference between EDI and ALE?
What is Logical system, Port, RFC destination, Customer Distribution Model, Partner Profile, Message type, Message control and if any of the important terminology that I have missed in the ALE concept?
Please help to explain me clearly in detail as I have no knowledge reg these and tried searching for info in various links, but still found difficult to understand?
Many thanks in advance....
Regards
Nani Ancha

ALE/EDI
Purpose
Electronic Data Interchange (EDI) and Application Link Enabling (ALE) are used for exchanging business data between different systems.
For both these forms of communication, you require the IDoc Interface. The IDoc interface is made up of the definition of a data structure and the processing logic of this data structure. The data structure is the IDoc. The IDoc is the general exchange format of the communicating systems. IDocs can be sent using different methods (for example, Structure linkRFC or as a file).
Application Link Enabling (ALE)
You distribute data using ALE if you want to communicate from one system to one or more other (mostly internal) systems. ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
· ALE enables the integration of business processes across several SAP or non-SAP systems.
Electronic Data Interchange (EDI)
You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor). The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12). This enables communication with non-SAP systems.
· By definition, two partners are involved in the process in an EDI application scenario: The sender and the recipient of an EDI message.

Application document not psted status 51 in ALE/IDOC

Hi Gurus/Experts;
Status number : 51 Application document not psted.
I have configured ALE for distributing material master data. On the outbound side the status of every Idoc is sucess. But on the inbound side some of them are red stating error.
Outbound Side :
we05 t-code.
03 success.
Inbound Side:
we02 t-code.
51 Error.
when I execute the we02 t-code and
Expand Status Record 51
am getting error like : Function module not allowed: AFS_RETAIL_ARTMAS_IDOC_INPUT
Please Give me some suggestion on this..
Thanks;
Ravi.

HI jayanth;
thanks for your replay.
we are almost 1 step ahead i think ...
plz suggest me the same...
those steps are very usefull and its cleard the step status type 51 error
now am getting error on inbound side when we execute we02 t-code.
status Error number 29.
Could not determine recipients for message type MATFET
Message no. B1003
Diagnosis
An IDoc of message type MATFET was passed to the ALE layer, but the three receiver fields in the header record were not filled. In this case the ALE layer tries to determine the receivers from the entries in the distribution model. There are no entries available in the distribution model for the above message type.
Procedure
Define the receivers in your distribution model for this message type or deactivate distribution for these message types.
Thanks;
Ravi.

What is the use of ALE and EDI in IDOC process

hi gurus,
in which scenario we use ALE/EDI?
actually IDOC stands for Intermediate document which stores the data and sendng outbound and receiving inbound.
i am not understanding onething here what is the necessity to use ALE/EDI?
could you please tell me?
Regards,
SOMIU.

Hi Somu,
Purpose
Electronic Data Interchange (EDI) and Application Link Enabling (ALE) are used for exchanging business data between different systems.
For both these forms of communication, you require the IDoc Interface. The IDoc interface is made up of the definition of a data structure and the processing logic of this data structure. The data structure is the IDoc. The IDoc is the general exchange format of the communicating systems. IDocs can be sent using different methods (for example, Structure linkRFC or as a file).
Application Link Enabling (ALE)
You distribute data using ALE if you want to communicate from one system to one or more other (mostly internal) systems. ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
· ALE enables the integration of business processes across several SAP or non-SAP systems.
Electronic Data Interchange (EDI)
You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor). The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12). This enables communication with non-SAP systems.
· By definition, two partners are involved in the process in an EDI application scenario: The sender and the recipient of an EDI message.
Thanks&Regards,
Phani.
Points if Helpful.

Difference btw: Distributed, High-Availability and Additional SAP System Instances

Hello,
In the installation Doc for NW 741, there is 3 other installations scenarios beside the single instance, can you pl. highlight the difference?
Cheers,
F

Hello Fouad,
Distributed landscape:
In distributed landscape, every instance can run on a separate host
- Central services instance for ABAP ( ASCS)
- Enqueue replication server instance (ERS instance ) for ASCS instance
- Database instance
- Primary application server instance (PAS)
High availability :
In high availability ,all above instances can run on seperate host. Here you can run all instance in switchover cluster infrastructure. That means ,for any instance if one node in cluster fails ,it switch over to other other node and still operations can run without any distrubance.
Additional SAP instance:
Additional SAP aaplication instance can be installed to scale the performance of an SAP system. It can be installed on one of the above instance host or on differnt host.
The term "additional application server instance "was introduced to replace term dialog instance from SAP Netweaver 7.1 and higher.
For more and detailed information ,you can refer to Installation guide for the SAP release you are planning to install and for DB/OS combination.
Hope this helps.
Regards,
Archana

Study material on ALE and IDOCS

Hi
If anyone has some study material on ALE and IDOCS ,if you can please send it across to me , it would be very helpful to me .
My mail id is : [email protected]
Thanks in advance
Ankit

1. What is ALE?
Application Link Enabling (ALE) is a set of business processes and tools that allow applications on different computer systems to be linked. This can be done between different SAP systems as well as between SAP and non-SAP systems.
In a single SAP system different applications are integrated via a single database (e.g. finance, sales, production, human resources). However, many companies do not have just one integrated system but a distributed environment with different applications running on different systems. To run the whole business in such an environment the distributed applications have to be linked. This can be done through Application Link Enabling (ALE).
ALE provides distributed business processes that can be used to link the applications on different platforms. There are some ALE business processes delivered in the standard SAP system. Furthermore, there are tools that can be used to change the existing ALE business processes or to implement new distributed business processes.
Besides the business processes there are special ALE services that are required to set up and control a distributed environment. These services include a distribution model, business object synchronization and tools for monitoring or error handling.
ALE is a major part of SAP's Business Framework Architecture. Besides the basis middleware, that provides the communication between components, and the interfaces (BAPIs), ALE business processes and ALE services enable the cooperation of the single components within the framework. That makes ALE the glue of the Business Framework.
2. What are the benefits of ALE?
With ALE companies get the opportunity to improve business performance and to solve organizational or technical issues.
Through distribution you can decentralize your business, enabling local units to operate independently from each other. This flexibility enables the local units to return better business results than in a centralized environment. They have the necessary flexibility to optimize business processes in different organizational units and can ensure that information systems can handle the speed of change in rapidly expanding markets. Distribution allows a high level of freedom, provided that this level of freedom has been clearly defined.
On the other hand, some companies, that already have a distributed organization with different computer systems in the local units, have the opportunity to link their units through ALE business processes. This enables them for example to provide a 'one face to the customer' approach. Another area that can benefit through ALE are virtual organizations (partnerships between independent companies, joint ventures and mergers and acquisitions).
Of course, in many cases an integrated solution based on a single system is not possible at all. Some applications used by a company can not run on the same computer system. This includes legacy systems or complementary software. It may also be possible that a company uses different SAP industry solutions or specific country solutions, which do not run on the same SAP System. If these applications run on different systems they can not be linked by a central database but have to use a special integration mechanism like ALE. In this way ALE also links SAP Core Systems to other SAP components like CRM, Business Information Warehouse or APO.
Besides the benefits of having an improved flexibility in setting up the whole business processes, ALE may also reduce costs, in particular costs of upgrading. If the whole business is run on one integrated system you have to upgrade the whole system, even if only one part of your company (e.g. human resources) requires an update. So the entire company is affected by the upgrade project and all users have to be trained for the new release. Within a distributed environment with release independent interfaces, like those provided by ALE, you can focus the upgrade project on that part of the company that has to be upgraded. The other parts of the company are not involved and need no training. This can save a lot of money. Furthermore, existing investments are protected.
Another cost factor for distribution might be communication costs. For an overseas connection it can be more expensive to provide online access to one central system (T1) than to connect distributed systems to each other (64K line).
There might also be some technical reasons for distributed systems. If some parts of the business have special requirements for security of data access (e.g. human resources), this can be set up much safer on a standalone system, which is, however, linked to other parts of the company through distributed business processes. A similar example is high availability. High availability is usually required by the operations part of the company (production, logistics) but not by other areas (e.g. financials, human resources). In a distributed environment high availability can be set up for specific parts of the environment instead of for the whole business. This can also reduce costs.
In a distributed environment you can not decrease the overall workload of the systems but you can separate the user workloads on different systems. Through this scalability you can improve performance. Another benefit of distributed systems is that if a technical failure occurs on one system, all other systems continue to operate. Only a small part of the business is disrupted by the error. On one central system such an error would disrupt the entire business.
3. When should ALE be used?
Besides the benefits of ALE there are also reasons not to distribute:
The functional scope in a distributed environment is restricted. Not all functionality that is available in an integrated SAP system can be used with distributed systems in the standard yet. Although ALE provides tools to create new ALE business processes or to enhance existing business processes, this does involve additional expenditure.
Each company needs some organizational standards and data harmonization. In a distributed environment less standards are required than on a single integrated system. However, in a distributed environment the maintenance of the standards and the data harmonization is more difficult than on a single system.
The administration of decentralized systems is more expensive. Support and service costs for hardware and software in decentralized systems are higher than these costs in a single centralized system.
ALE should be used in a company if the benefits of ALE for this company outweigh the reasons against distribution. For this you always need to carry out a company specific investigation, in which you also should consider the culture of the company. ALE is good for some companies but not for all.
4. What is the relationship between ALE and Middleware?
Electronic Data Interchange (EDI) is a term for the transfer of business messages between two systems. There are many such messages, the most common of these include a customer sending a purchase order message to a vendor, or a vendor sending an invoice message to a customer. Classic EDI is mainly restricted on the exchange of transactional data, no master data or configuration data. In most cases, EDI replaces the transfer of paper copies of these documents. Via the messages ALE business processes can be implemented between business partners. The EDI messages also use the ALE services.
For the communication between different types of systems special EDI messages are defined as standards for inter company communication. There are many standards for these messages - in the United States, the ANSI X.12 standard is the most prevalent, in Europe, the UN/EDIFACT standard is used. For sending EDI messages the information has to be converted into an EDI standard. With SAP systems this is done by EDI subsystems. This conversion is the only difference between EDI messages and other messages used in ALE business processes. The processing of these messages on the SAP System is the same as the processing of other ALE messages.
5. Which ALE business processes are available?
IDoc Types - Message Types
ALE business processes are integrated business processes that run across distributed systems. This can be two different SAP systems, links between SAP and non-SAP systems, SAP and Web-servers (Internet Application Components) or SAP and desktop applications. The links between the systems may be loosely (asynchronous) or tightly (synchronous) coupled. These business processes are release independent and can run between different release levels of the systems.
Many SAP applications offer ALE distribution processes. The following list gives some examples:
Master data replication (IDoc Types - Message Types - Master Data)
- Material
- Customer
- Vendor
- General Ledger accounts
- Bill of materials
Accounting (IDoc Types - Message Types -Accounting Business Processes)
- Links to logistic systems
- Distributed financial accounting
- Distributed cost center accounting
- Distributed special ledger
- Profitability analysis
- Distributed profit center accounting
- Consolidation
- Treasury
Logistics(IDoc Types - Message Types - Logistics Business Processes)
- Reallocation of materials
- Distribution of sales and shipping
- Product data management
- Purchasing contracts
- Sales and operations planning
- Warehouse management
- Links to warehouse control systems
- Links to production optimization systems
- Links to transport planning systems
Information systems (IDoc Types - Message Types - Logistics Business Processes)
- SAP Business Information Warehouse (BW)
- Exchange of data between information systems
- Web reporting
Human resources (IDoc Types - Message Types - HR Business Processes)
- Human resources as a single component
- Payroll results
- Travel expense accounting
- Links to time collecting systems
However, these standard solutions may not fit 100% for a company. There may be differentiation in the business process or a required distributed business process is not supported in the standard. If this happens, ALE provides tools that can be used to adapt a standard ALE business process or to create a new distributed business process.
6. Which ALE services are available and what do they do?
To integrate distributed systems you need more than a communication infrastructure and interfaces. Some additional services are required that are provided by ALE:
Business process harmonization:
Within system overlapping business processes multiple functions running on multiple systems are involved and connected through multiple interfaces. The processes are combinations of functions (sub-processes) running on the single systems.
(Example: A business process for customer order management involves functions in sales, manufacturing, warehouse management, finance, and so on. It is possible that the sales functions are carried out on another system than the manufacturing, the warehouse management or the accounting. Furthermore, some information exchange with the customer, a supplier or a bank may be involved in the process.)
ALE helps to coordinate the whole business process by defining it within a global model. In this model the business rules for the distribution are defined. Via the model the sub-processes get to know which part of the overall process they have to do themselves and when they have to pass the process over to another system. Through this the whole business process gets harmonized.
Receiver determination:
For distributed business processes a sub-process on one application (client) has to start another sub-process on another application (server). It is important that the new sub-process is started on the right server. Which server is the right one can not be defined by technical values, it depends on the business content of the process.
(Example: A sales system forwards customer orders to two different production systems. To which system a special sales order is forwarded depends on the entries in the sales order (this may depend, for instance, on the ordered material or on the customer). One sales order may also be split into two or more different orders that may be forwarded to different production systems.)
To notify the client which system is the receiver of the communication (server), ALE uses a distribution model. From this model the applications get the information about the right server. There are special ALE BAPIs and function modules available for this. The receiver determination makes sure that the information is sent to the right places.
Business object synchronization (semantic synchronization):
If business processes run across distributed systems, they have to share some data to be harmonized. This is data like business information data, master data or customizing data. If this data is changed in any of the distributed systems, other systems have to be informed about the change. There has to be some kind of subscription of the data.
ALE provides a special service for this data synchronization. This service can detect data changes and distribute the information to those systems that need to know about the change. This service also defines which data is shared. You can determine which fields of a data object shall be common and which fields may vary locally.
Consistency checks:
For a business process running across two distributed applications there has to be some harmonization of the sub-processes in the single applications. For making sure that the sub processes are harmonized there are special ALE consistency check tools. These tools help to find and repair inconsistencies. By this it can be ensured that the whole ALE business process works in the right way.
Monitoring:
For the monitoring of distributed processes it is not enough to monitor all activities on the single systems. The overall business process has to be monitored. The ALE monitoring services provide detailed information about the communication process, the sub-process on the other systems and its results. Database links are created between the business objects in question on the client and the server. This is especially important for loosely coupled applications with asynchronous links. In this case the server can not give return values back to the client directly so that the ALE monitoring is the only channel for feedback.
Error handling:
Another problem with asynchronous communication is error handling. If an error occurs on the server the calling process on the client may have finished already. So the server can not return the error message to the client. A special error handling process required. This process is one of the ALE services. It uses workflow functionality to identify the error and to start the required error handling.
7. Synchronous vs. asynchronous links?
When distributed applications are linked by ALE business processes, the question often arises as to how tight the link should be. Synchronous and asynchronous links have both advantages and disadvantages.
Synchronous links have the advantage that the sub-process on the server can return values to the sub-process on the client that has started the link. Problems with synchronous links occur if the communication line or the server is temporarily not available. If this happens, the sub-process on the client can not be finished (otherwise there would be data inconsistencies).
(Example: There is a logistics system and a financial system. Every stock movement in logistics has to be posted in the general ledger of the financial system. If the link between logistics and finance is synchronous, no stock movement can be recorded in the logistics system if the communication line to the financial system is down.)
Because of this, synchronous links are usually used if the client only wants to get some data from the server and the sub-processes on the server do not have to write any data to the database.
With asynchronous links the sub-process on the client can be finished even if the communication line or the server is not available. In this case the message is stored in the database and the communication can be done later. The disadvantage of asynchronous links is that the sub-process on the server can not return information to the calling sub-process on the client. A special way for sending information back to the client is required. In addition, a special error handling mechanism is required to handle errors on the receiving side.
Asynchronous links are used if a synchronous link is not applicable. For the problems with sending return information to the client and with error handling there is some support from the ALE services.
8. Which kind of interfaces do ALE business processes use?
ALE business processes are integrated processes across distributed systems, requiring interfaces between the systems. These interfaces have to be stable to enable the communication between different releases and to reduce the impact of release changes within the distributed environment.
In SAP R/3 release 3.0 and 3.1 ALE uses IDocs as interfaces. An IDocs is a data container for transferring messages asynchronously. They are release independent. Since SAP Release 3.1G BAPIs are a new type of object oriented, stable interfaces that can be called synchronously or asynchronously. Asynchronous BAPIs use IDocs as data containers. ALE business processes can use BAPIs as well. In the future new ALE business processes will use BAPIs as interfaces. But the existing IDocs will still be supported. In time, BAPIs will be created with similar functionality to existing IDoc interfaces.
9. Why does SAP uses ALE instead of database replication or distributed databases?
Database replication is another possibility for doing business object synchronization. However, there are some major disadvantages with database replication. At the moment database replication is database dependent and release dependent within one database. This makes database replication impossible for the use with non-SAP systems and even for the replication between SAP Systems you have to make sure that all systems are running on the same SAP release and the same database release of a single database vendor. Furthermore, with database replication you cannot do things like field conversions or version changes. ALE does not have these shortcomings because it offers application driven data replication independent of the underlying database.
Another technology, distributed databases, is no alternative for ALE at the moment, either. There are some good results of distributed databases available, but the performance is far from sufficient for using it with larger applications like SAP.
10. What is the relationship between ALE and middleware?
For distributed business processes many different services are required. Most of these services are offered by SAP. For some of these services you can also use products that are provided by SAP's complementary software partners or by other companies:
The communication service for doing the pure communication is usually done via Remote Function Call (RFC). RFC is provided by SAP for most platforms both for synchronous and asynchronous communication. There are other messaging systems for the communication service available as well, like IBM's MQSeries. However, the communication between SAP and the messaging system is still done via RFC.
For the serialization of asynchronous communication the RFC provides little functionality at the moment. The serialization has to be checked by the application. ALE offers some support to do these checks. The serialization of the RFC communication will be improved in the future. Serialization services are provided by some of the existing messaging systems, but even they can not guaranty a 100% serialization of the communication, since they use RFC for the connection to SAP.
The monitoring and error handling of the communication is done via services provided by the RFC and ALE. If messaging systems are used for the communication they also offer some monitoring and error handling functionality.
If a non-SAP system is involved in the ALE business scenario and this system does not understand SAP's BAPI or IDoc interfaces, the data has to be mapped to any interface structure that this system offers. For this mapping SAP does not provide a service but it certifies mapping tools from software partners. These tools are called ALE translator. The most known product in this area is probably Mercator from TSI International Software. The same kind of mapping can also be done by 'EDI converters'.
Another type of middleware products offer process ware. This is mainly a combination of the communication service, the mapping service and a set of rules for the mapping. Some ALE translator can be used for this as well.
Receiver determination is one of the ALE services (see above). Parts of this service can also be provided by some of the messaging systems, but you cannot use these systems without using ALE receiver determination.
For the other ALE services like application monitoring, application error handling, semantic synchronization and business process harmonization, there are no middleware products available as a replacement of ALE.
ALE is open for the use of middleware products for the distribution, but in most cases the additional middleware is not necessary. In a communication between different SAP systems usually the use of additional middleware makes no sense at all. For the communication between SAP and non-SAP systems there might be some benefits, especially if the middleware is used at the company already. The only middleware tool that is really required if the non-SAP system does not understand BAPIs or IDocs is an ALE translator.
Check different sites for more information.
Regards

How the ALE settings differ from EDI

Hi
I have observed that the Port, partner profile, distribution model and creating logical system are same for EDI as well as ALE. My doubt over here is on what basis we can differentiate the ALE settings with EDI.
Any help highly appreciated.
Regards
Raj.

the basic difference between ALE and EDI is as follows
Application Link Enabling (ALE)
You distribute data using ALE if you want to communicate from one system to one or more other (mostly internal) systems. ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
ALE enables the integration of business processes across several SAP or non-SAP systems
Electronic Data Interchange (EDI)
You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor). The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12). This enables communication with non-SAP systems.
By definition, two partners are involved in the process in an EDI application scenario: The sender and the recipient of an EDI message

Relation of ALE , EDI and idoc

HI
     what is relation of these ALE, EDI, IDOC , i know the definition of these , i want know ( while the transfer of sap to sap ALE tool is used ,) where this idoc is used ,
regards
shivaji

Hi Shivaji,
What is EDI?
Electronic Data Interchange
     The computer-to-computer electronic exchange of machine processable business documents in a standard format
     An electronic alternative to paper, fax, and phone-based transactions used by companies to communicate with one another
Purpose:
     Allows for better time management and relieves the entering of duplicate information while cutting down on discrepancies and human intervention.
     The Electronic Data Interchange component in Sales and Distribution consists of an Intermediate Document (IDoc) [Ext.] interface. You can use this interface to
     send messages (outbound processing) such as an order confirmation through Electronic Data Interchange (EDI)
     receive messages (inbound processing) such as a sales order through EDI
EDI:
     What?
     The technology of transmitting documents electronically
     Why?
     For Electronic Data Interchange between a company and trading partners
     How?
     By means of an electronic document - the IDoc
From the SAP side, the EDI interface is based on IDoc technology, which is independent of
EDI standards. All data is transferred in files between the R/3 System and the EDI subsystem.
Synchronous Remote Function Call (RFC) is implemented to define the time of transfer for a
file between the two systems. The following data can be transferred using the EDI interface:
Outbound Idocs: IDocs are transferred from the R/3 System to the EDI subsystem.
Inbound Idocs: IDocs are transferred from the EDI subsystem to the R/3 System.
Status report: The EDI subsystem sends a status report to the R/3 System on the progress of
the processing of the outbound Idoc.
Contents of IDOC
The data in every IDoc is exchanged between the SAP system and a subsystem in the following three record types, irrespective of the IDoc type:
     Control record (Table: EDIDC): Contains information about Sender and Receiver. There is only one control record per IDoc. It consists of
IDoc Number
Sender and Receiver information
IDoc Message Type* / Port.
IDoc Type / Direction / Current status / Partner No / Partner Type (Vendor/customer)
     Data record (Table: EDIDD): Contains the message to be exchanged between Sender and Receiver. An IDoc can contain multiple data records, as defined by the IDoc structure. Data records store application data such as purchase order / sales order header information, sales order details like sales doc #, Material / Qty and other relevant information.
     Status record (Table: EDIDS): Contains Status of IDoc at various stages, during the transmission of IDoc between Sender and Receiver. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process like status code, date and time at every stage
Know Me
Basic Type: The form of IDOC type that is originally created in the system. Like ORDERS01 is a basic type IDOC for order messages. It is using the basic types only you would be able to enhance them to suit new requirements within the same IDOC structure. Any enhancement to the basic type IDOC will produce an Extension IDOC that would be more or less similar to the basic type with some new additions (of segments or fields). Here, I would go on to say that IDOC type and Basic type is the same thing that would be referred to interchangeably.
Message type: Again, obvious from the name, its the message that is being conveyed. A message type is assigned to the Basic type. Here, logical messages are assigned to the basic type to reflect a business message being transacted. For example, ORDERS is the message type for a purchase order sent by buyer to vendor. The use of which Basic type in this message will differ from buyer to vendor. Basic types used for ORDERS are ORDERS01/02/ etc...Also, one may come up with a custom built IDOC type (or basic type as you can say)...But it is essential to associate a message type with a basic type IDOC. This feature will enable the same IDOC type to be used for a related message. For example : ORDERS01 can be used for message ORDERS for posting a order, the same IDOC can be associated with message ORDCHG to indicate that the message is an order change and so the processing of this IDOC will change accordingly.
IDoc Type:
     Defines the structure of data records
      IDoc Type is used to understand the message in string form available in the data records.
      IDoc type is version dependent i.e an Idoc type can be used only in versions in and above the version in which IDoc is released.
      Transaction WE30 is used to define and release IDoc Types
      Newly created Idoc is a BASIC IDoc and modifications
             (Additions of segments) to IDoc after it has been released can be done by creation of extension      of IDoc.
      IDoc type can be defined by structuring Segments
Function Module: The most important player in the IDOC processing. This is nothing but an ABAP program to process the IDOC. SAP has supplied function modules to process all standard basic IDOCs and messages. A function module is determined based on the Basic IDOC type and the message type (also message code). So from the above descriptions about basic and message type, the combination of two would primarily determine which IDOC will process this idoc. As an instance, ORDERS01 with message ORDERS is configured to be processed by FM IDOC_INPUT_ORDERS. Similarly, ORDERS01 + ORDCHG will be processed by IDOC_INPUT_ORDCHG. Likewise, you can see all associations in WE57 for inbound. For out bounds, you would refer to process codes (WE41).
Segments: The idenfiers in the IDOC structure which indicates the data, their level, state of occurrence....You can take them as records in the IDOC. Each individual segment will come to you as a record in the IDOC. (Go to EDID4, provide an IDOC # and it will list all included segments as records.) Segments are logically nested to indicate various levels of data (header, item etc).
Qualifiers: Inside the segments, there are fields that can carry actual data often signified by use of qualifiers. A qualifier for a segment field would provide the exact meaning of the data. For example, E1EDK03 segment is configured for dates related data. Segment field IDDAT qualifies the date type and the DATUM field gives out the actual date. So you may see a date qualified as 002, which can be interpreted as requested delivery date. Likewise you can see all qualifiers and their meanings in the associated segment fields in SE12. Give the segment name and go to the domain the ranges for the ID fields.
How EDI Works
Sending Data
     Computer system serves as a data repository.
     EDI extracts information from existing computer applications.
     Transmits paperless, computer-readable documents via telephone lines.
Receiving Data
     Fed directly into a computer system.
     Automatically processed and interfaced with internal applications.
Processing Time
     Accomplished in minutes.
     No re-keying.
     No paper shuffling.
     No attendant costs of manual document processing and delivery.
What is the difference between ALE, EDI, IDocs and BAPI?
The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.
While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.
The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.
ALE/EDI - Purpose
Electronic Data Interchange (EDI) and Application Link Enabling (ALE) are used for exchanging business data between different systems.
For both these forms of communication, you require the IDoc Interface. The IDoc interface is made up of the definition of a data structure and the processing logic of this data structure. The data structure is the IDoc. The IDoc is the general exchange format of the communicating systems. IDocs can be sent using different methods (for example, RFC or as a file).
Application Link Enabling (ALE)
You distribute data using ALE if you want to communicate from one system to one or more other (mostly internal) systems. ALE transfers data in IDoc format and uses the methods of tRFC for data transfer.
1.     ALE enables the integration of business processes across several SAP or non-SAP systems.
Electronic Data Interchange (EDI)
You use EDI if you want to exchange business application documents with an (external) partner system (for example, a customer or vendor). The SAP system sends EDI messages in IDoc format to an EDI subsystem, where they are converted to a universal EDI standard (UN/EDIFACT or ANSI/X12). This enables communication with non-SAP systems.
1.     By definition, two partners are involved in the process in an EDI application scenario: The sender and the recipient of an EDI message.
IDoc Interface/ALE
Purpose
The IDoc interface exchanges business data with an external system.
The IDoc interface consists of the definition of a data structure, along with processing logic for this data structure.
The data structure is the IDoc. The IDoc is the exchange format common to all the communicating systems. You can specify exception handling in the SAP Business Workflow, with IDocs, without the data already having to exist as SAP application documents.
You need the IDoc interface in the following scenarios:
Electronic data exchange (EDI)
Connect other business application systems (e.g. PC applications, external Workflow tools) by IDoc
Application Link Enabling (ALE).
Application Link Enabling (ALE) is a technology to create and run distributed applications
Hope this would help you.
Reward points if helpful.
Vamsi.

MySAP HR system landscape

Hi
Please provide the following help for installation
1. What would be the mySAP HR system landscape
2. What would be the component of mySAP HR
3. Does it containts ABAP & JAVA engine both
4. How many servers are required for this
Any guide line documents , pl send
Regards
Vimal Pathak

Hi Vimal
customer specific system landscapes for an application as large as SAP ERP depend on many factors. It is thus not possible to give you "the" SAP ERP - Human Capital Management System landscape, without knowing which functions this HCM Landscape should support, where, in which languages.... (i.e. for some processes a pure SAP ECC System is sufficient, for others, you need a portal and Process integration as well)
For this reasons, the already mentioned SAP ERP 6.0 Master Guide takes a planning-support-approach. It discusses four different "typical" reference system landscapes (Minimal System Landscape,..... Individual/ Distributed Landscape), and extends them to different possible example landscapes, to show you how to plan your own landscape.
The example system landscape for HCM shown there assumes, that you intend to install the complete scope, and that you need firewalls, because this HCM landscape should support external recruiting scenarios as well.
Closeley related to the planning process for system landscapes is the process component list (service.sap.com/scl), where you find information about which SAP ERP process needs which software component, and is available in which countries/ languages.
regards,
Andreas R

ALE interface programing

hi experts,
whtat is ALE and why we r using ALE.please give the
steps with example.
regards,
cnu

Check this questions u may get ur answers.
1. What is ALE?
Application Link Enabling (ALE) is a set of business processes and tools that allow applications on different computer systems to be linked. This can be done between different SAP systems as well as between SAP and non-SAP systems.
In a single SAP system different applications are integrated via a single database (e.g. finance, sales, production, human resources). However, many companies do not have just one integrated system but a distributed environment with different applications running on different systems. To run the whole business in such an environment the distributed applications have to be linked. This can be done through Application Link Enabling (ALE).
ALE provides distributed business processes that can be used to link the applications on different platforms. There are some ALE business processes delivered in the standard SAP system. Furthermore, there are tools that can be used to change the existing ALE business processes or to implement new distributed business processes.
Besides the business processes there are special ALE services that are required to set up and control a distributed environment. These services include a distribution model, business object synchronization and tools for monitoring or error handling.
ALE is a major part of SAP's Business Framework Architecture. Besides the basis middleware, that provides the communication between components, and the interfaces (BAPIs), ALE business processes and ALE services enable the cooperation of the single components within the framework. That makes ALE the glue of the Business Framework.
2. What are the benefits of ALE?
With ALE companies get the opportunity to improve business performance and to solve organizational or technical issues.
Through distribution you can decentralize your business, enabling local units to operate independently from each other. This flexibility enables the local units to return better business results than in a centralized environment. They have the necessary flexibility to optimize business processes in different organizational units and can ensure that information systems can handle the speed of change in rapidly expanding markets. Distribution allows a high level of freedom, provided that this level of freedom has been clearly defined.
On the other hand, some companies, that already have a distributed organization with different computer systems in the local units, have the opportunity to link their units through ALE business processes. This enables them for example to provide a 'one face to the customer' approach. Another area that can benefit through ALE are virtual organizations (partnerships between independent companies, joint ventures and mergers and acquisitions).
Of course, in many cases an integrated solution based on a single system is not possible at all. Some applications used by a company can not run on the same computer system. This includes legacy systems or complementary software. It may also be possible that a company uses different SAP industry solutions or specific country solutions, which do not run on the same SAP System. If these applications run on different systems they can not be linked by a central database but have to use a special integration mechanism like ALE. In this way ALE also links SAP Core Systems to other SAP components like CRM, Business Information Warehouse or APO.
Besides the benefits of having an improved flexibility in setting up the whole business processes, ALE may also reduce costs, in particular costs of upgrading. If the whole business is run on one integrated system you have to upgrade the whole system, even if only one part of your company (e.g. human resources) requires an update. So the entire company is affected by the upgrade project and all users have to be trained for the new release. Within a distributed environment with release independent interfaces, like those provided by ALE, you can focus the upgrade project on that part of the company that has to be upgraded. The other parts of the company are not involved and need no training. This can save a lot of money. Furthermore, existing investments are protected.
Another cost factor for distribution might be communication costs. For an overseas connection it can be more expensive to provide online access to one central system (T1) than to connect distributed systems to each other (64K line).
There might also be some technical reasons for distributed systems. If some parts of the business have special requirements for security of data access (e.g. human resources), this can be set up much safer on a standalone system, which is, however, linked to other parts of the company through distributed business processes. A similar example is high availability. High availability is usually required by the operations part of the company (production, logistics) but not by other areas (e.g. financials, human resources). In a distributed environment high availability can be set up for specific parts of the environment instead of for the whole business. This can also reduce costs.
In a distributed environment you can not decrease the overall workload of the systems but you can separate the user workloads on different systems. Through this scalability you can improve performance. Another benefit of distributed systems is that if a technical failure occurs on one system, all other systems continue to operate. Only a small part of the business is disrupted by the error. On one central system such an error would disrupt the entire business.
3. When should ALE be used?
Besides the benefits of ALE there are also reasons not to distribute:
The functional scope in a distributed environment is restricted. Not all functionality that is available in an integrated SAP system can be used with distributed systems in the standard yet. Although ALE provides tools to create new ALE business processes or to enhance existing business processes, this does involve additional expenditure.
Each company needs some organizational standards and data harmonization. In a distributed environment less standards are required than on a single integrated system. However, in a distributed environment the maintenance of the standards and the data harmonization is more difficult than on a single system.
The administration of decentralized systems is more expensive. Support and service costs for hardware and software in decentralized systems are higher than these costs in a single centralized system.
ALE should be used in a company if the benefits of ALE for this company outweigh the reasons against distribution. For this you always need to carry out a company specific investigation, in which you also should consider the culture of the company. ALE is good for some companies but not for all.
4. What is the relationship between ALE and Middleware?
Electronic Data Interchange (EDI) is a term for the transfer of business messages between two systems. There are many such messages, the most common of these include a customer sending a purchase order message to a vendor, or a vendor sending an invoice message to a customer. Classic EDI is mainly restricted on the exchange of transactional data, no master data or configuration data. In most cases, EDI replaces the transfer of paper copies of these documents. Via the messages ALE business processes can be implemented between business partners. The EDI messages also use the ALE services.
For the communication between different types of systems special EDI messages are defined as standards for inter company communication. There are many standards for these messages - in the United States, the ANSI X.12 standard is the most prevalent, in Europe, the UN/EDIFACT standard is used. For sending EDI messages the information has to be converted into an EDI standard. With SAP systems this is done by EDI subsystems. This conversion is the only difference between EDI messages and other messages used in ALE business processes. The processing of these messages on the SAP System is the same as the processing of other ALE messages.
5. Which ALE business processes are available?
IDoc Types - Message Types
ALE business processes are integrated business processes that run across distributed systems. This can be two different SAP systems, links between SAP and non-SAP systems, SAP and Web-servers (Internet Application Components) or SAP and desktop applications. The links between the systems may be loosely (asynchronous) or tightly (synchronous) coupled. These business processes are release independent and can run between different release levels of the systems.
Many SAP applications offer ALE distribution processes. The following list gives some examples:
Master data replication (IDoc Types - Message Types - Master Data)
- Material
- Customer
- Vendor
- General Ledger accounts
- Bill of materials
Accounting (IDoc Types - Message Types -Accounting Business Processes)
- Links to logistic systems
- Distributed financial accounting
- Distributed cost center accounting
- Distributed special ledger
- Profitability analysis
- Distributed profit center accounting
- Consolidation
- Treasury
Logistics(IDoc Types - Message Types - Logistics Business Processes)
- Reallocation of materials
- Distribution of sales and shipping
- Product data management
- Purchasing contracts
- Sales and operations planning
- Warehouse management
- Links to warehouse control systems
- Links to production optimization systems
- Links to transport planning systems
Information systems (IDoc Types - Message Types - Logistics Business Processes)
- SAP Business Information Warehouse (BW)
- Exchange of data between information systems
- Web reporting
Human resources (IDoc Types - Message Types - HR Business Processes)
- Human resources as a single component
- Payroll results
- Travel expense accounting
- Links to time collecting systems
However, these standard solutions may not fit 100% for a company. There may be differentiation in the business process or a required distributed business process is not supported in the standard. If this happens, ALE provides tools that can be used to adapt a standard ALE business process or to create a new distributed business process.
6. Which ALE services are available and what do they do?
To integrate distributed systems you need more than a communication infrastructure and interfaces. Some additional services are required that are provided by ALE:
Business process harmonization:
Within system overlapping business processes multiple functions running on multiple systems are involved and connected through multiple interfaces. The processes are combinations of functions (sub-processes) running on the single systems.
(Example: A business process for customer order management involves functions in sales, manufacturing, warehouse management, finance, and so on. It is possible that the sales functions are carried out on another system than the manufacturing, the warehouse management or the accounting. Furthermore, some information exchange with the customer, a supplier or a bank may be involved in the process.)
ALE helps to coordinate the whole business process by defining it within a global model. In this model the business rules for the distribution are defined. Via the model the sub-processes get to know which part of the overall process they have to do themselves and when they have to pass the process over to another system. Through this the whole business process gets harmonized.
Receiver determination:
For distributed business processes a sub-process on one application (client) has to start another sub-process on another application (server). It is important that the new sub-process is started on the right server. Which server is the right one can not be defined by technical values, it depends on the business content of the process.
(Example: A sales system forwards customer orders to two different production systems. To which system a special sales order is forwarded depends on the entries in the sales order (this may depend, for instance, on the ordered material or on the customer). One sales order may also be split into two or more different orders that may be forwarded to different production systems.)
To notify the client which system is the receiver of the communication (server), ALE uses a distribution model. From this model the applications get the information about the right server. There are special ALE BAPIs and function modules available for this. The receiver determination makes sure that the information is sent to the right places.
Business object synchronization (semantic synchronization):
If business processes run across distributed systems, they have to share some data to be harmonized. This is data like business information data, master data or customizing data. If this data is changed in any of the distributed systems, other systems have to be informed about the change. There has to be some kind of subscription of the data.
ALE provides a special service for this data synchronization. This service can detect data changes and distribute the information to those systems that need to know about the change. This service also defines which data is shared. You can determine which fields of a data object shall be common and which fields may vary locally.
Consistency checks:
For a business process running across two distributed applications there has to be some harmonization of the sub-processes in the single applications. For making sure that the sub processes are harmonized there are special ALE consistency check tools. These tools help to find and repair inconsistencies. By this it can be ensured that the whole ALE business process works in the right way.
Monitoring:
For the monitoring of distributed processes it is not enough to monitor all activities on the single systems. The overall business process has to be monitored. The ALE monitoring services provide detailed information about the communication process, the sub-process on the other systems and its results. Database links are created between the business objects in question on the client and the server. This is especially important for loosely coupled applications with asynchronous links. In this case the server can not give return values back to the client directly so that the ALE monitoring is the only channel for feedback.
Error handling:
Another problem with asynchronous communication is error handling. If an error occurs on the server the calling process on the client may have finished already. So the server can not return the error message to the client. A special error handling process required. This process is one of the ALE services. It uses workflow functionality to identify the error and to start the required error handling.
7. Synchronous vs. asynchronous links?
When distributed applications are linked by ALE business processes, the question often arises as to how tight the link should be. Synchronous and asynchronous links have both advantages and disadvantages.
Synchronous links have the advantage that the sub-process on the server can return values to the sub-process on the client that has started the link. Problems with synchronous links occur if the communication line or the server is temporarily not available. If this happens, the sub-process on the client can not be finished (otherwise there would be data inconsistencies).
(Example: There is a logistics system and a financial system. Every stock movement in logistics has to be posted in the general ledger of the financial system. If the link between logistics and finance is synchronous, no stock movement can be recorded in the logistics system if the communication line to the financial system is down.)
Because of this, synchronous links are usually used if the client only wants to get some data from the server and the sub-processes on the server do not have to write any data to the database.
With asynchronous links the sub-process on the client can be finished even if the communication line or the server is not available. In this case the message is stored in the database and the communication can be done later. The disadvantage of asynchronous links is that the sub-process on the server can not return information to the calling sub-process on the client. A special way for sending information back to the client is required. In addition, a special error handling mechanism is required to handle errors on the receiving side.
Asynchronous links are used if a synchronous link is not applicable. For the problems with sending return information to the client and with error handling there is some support from the ALE services.
8. Which kind of interfaces do ALE business processes use?
ALE business processes are integrated processes across distributed systems, requiring interfaces between the systems. These interfaces have to be stable to enable the communication between different releases and to reduce the impact of release changes within the distributed environment.
In SAP R/3 release 3.0 and 3.1 ALE uses IDocs as interfaces. An IDocs is a data container for transferring messages asynchronously. They are release independent. Since SAP Release 3.1G BAPIs are a new type of object oriented, stable interfaces that can be called synchronously or asynchronously. Asynchronous BAPIs use IDocs as data containers. ALE business processes can use BAPIs as well. In the future new ALE business processes will use BAPIs as interfaces. But the existing IDocs will still be supported. In time, BAPIs will be created with similar functionality to existing IDoc interfaces.
9. Why does SAP uses ALE instead of database replication or distributed databases?
Database replication is another possibility for doing business object synchronization. However, there are some major disadvantages with database replication. At the moment database replication is database dependent and release dependent within one database. This makes database replication impossible for the use with non-SAP systems and even for the replication between SAP Systems you have to make sure that all systems are running on the same SAP release and the same database release of a single database vendor. Furthermore, with database replication you cannot do things like field conversions or version changes. ALE does not have these shortcomings because it offers application driven data replication independent of the underlying database.
Another technology, distributed databases, is no alternative for ALE at the moment, either. There are some good results of distributed databases available, but the performance is far from sufficient for using it with larger applications like SAP.
10. What is the relationship between ALE and middleware?
For distributed business processes many different services are required. Most of these services are offered by SAP. For some of these services you can also use products that are provided by SAP's complementary software partners or by other companies:
The communication service for doing the pure communication is usually done via Remote Function Call (RFC). RFC is provided by SAP for most platforms both for synchronous and asynchronous communication. There are other messaging systems for the communication service available as well, like IBM's MQSeries. However, the communication between SAP and the messaging system is still done via RFC.
For the serialization of asynchronous communication the RFC provides little functionality at the moment. The serialization has to be checked by the application. ALE offers some support to do these checks. The serialization of the RFC communication will be improved in the future. Serialization services are provided by some of the existing messaging systems, but even they can not guaranty a 100% serialization of the communication, since they use RFC for the connection to SAP.
The monitoring and error handling of the communication is done via services provided by the RFC and ALE. If messaging systems are used for the communication they also offer some monitoring and error handling functionality.
If a non-SAP system is involved in the ALE business scenario and this system does not understand SAP's BAPI or IDoc interfaces, the data has to be mapped to any interface structure that this system offers. For this mapping SAP does not provide a service but it certifies mapping tools from software partners. These tools are called ALE translator. The most known product in this area is probably Mercator from TSI International Software. The same kind of mapping can also be done by 'EDI converters'.
Another type of middleware products offer process ware. This is mainly a combination of the communication service, the mapping service and a set of rules for the mapping. Some ALE translator can be used for this as well.
Receiver determination is one of the ALE services (see above). Parts of this service can also be provided by some of the messaging systems, but you cannot use these systems without using ALE receiver determination.
For the other ALE services like application monitoring, application error handling, semantic synchronization and business process harmonization, there are no middleware products available as a replacement of ALE.
ALE is open for the use of middleware products for the distribution, but in most cases the additional middleware is not necessary. In a communication between different SAP systems usually the use of additional middleware makes no sense at all. For the communication between SAP and non-SAP systems there might be some benefits, especially if the middleware is used at the company already. The only middleware tool that is really required if the non-SAP system does not understand BAPIs or IDocs is an ALE translator.
Regards

Populate Segments in ALE

Hai Friends....
 How to Populate the Segment in ALE...
 Please Help me....
 BalajeeKannan

Hi,
You do not have to populate IDOC data in ALE. SAP does it for you using standard function module. Let's say you are using ALE to distribute material master record, you use transaction BD10.
Also, before using ALE you need to finish certain configuration. This is done in transaction SALE.
Check this link. This describe the scenario where you use your custom IDOC in ALE.
http://www.erpgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
Check these link for more information regarding ALE.
http://help.sap.com/saphelp_46c/helpdata/en/78/2173cf51ce11d189570000e829fbbd/frameset.htm
http://help.sap.com/saphelp_46c/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
Let me know if you need any other information.
Regards,
Rs

ALE in distributed landscape

Similar Messages

Maybe you are looking for