1.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.

2. After deploying a user-exit, all IDocs remain in status 64, why?

If an IDoc has a processing status 64, this means, that it is waiting to be processed by the
assigned application. After the application has processed the IDoc the status is set to
another status, usually to 53 if processing has been successful and 51 if processing has
failed.
Try to force IDoc reprocessing with transaction BD87 for the specific IDoc. If the status
still remains at 64, it is most certain that the application, which processed the IDoc
aborted abnormally. If you check the system dumps with transaction ST22 you will most
likely find a dump for every try you made to process the IDoc. The dump will also give
you a hint where the IDoc application aborted.

3.My EDI partner asks me to send data in EDIFACT format, can SAP do this?
SAP does not provide a conversion from IDoc to EDIFACT, ANSI/X.12 or other
classical EDI data exchange format. Conversion must be done by external converter
tools. These tools receive the IDocs from the R/3 instance via ALE, convert them to
EDIFACT etc. and forward the converted data to the receiver. There are numerous
converter tools available now. For a list of all SAP certified IDoc converter tools, you
may want to contact your SAP sales representative. The most advanced solutions will
make use of the IDocs converted to XML, as they are provided by R/3 standard from
realease 4.6 onwards. This will output IDocs to a file in XML. While this will not help
you in converting data into EDIFACT, it may be worth to ask your EDI partners, if they
really require EDIFACT (which in practice is seldomly pure EDIFACT but mostly an
adapted varaiant) or if they are satisfied in receiving an XML file with the proper IDoc
data.

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.

What are the benefits of ALE?

With ALE, companies get the opportunity to improve business performance and to solve
organizational or technical issues by:

• Increasing Flexibility: 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 cannot 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 cannot 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.
• Reducing Costs: 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).
• Increasing Security and High Availablity: 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.
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.

What is the relationship between ALE and Middleware?

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.

Which ALE business processes are available?

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, for example Master Data Replication, Accounting, Logistics and
Human Resources.

When should synchronous or asynchronous links be used?

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.

Why does SAP use 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.

How can I serialize IDoc processing?

There are various procedures for processing IDocs in a serialized way, that is to process
them or transfer them to the application in a certain sequence. Depending on your
respective requirements, one of the methods proposed in note 752194 may be suitable for
the required purpose.