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.
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:
- 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
- ...
- 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 Questions 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
Questions 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.
