With the exchange infrastructure, SAP boasts of the ability to share
collaboration knowledge, which begs the question: Just what is collaboration
knowledge, and why would I want to share it?
When SAP refers to collaboration knowledge,
it means all the information and knowledge necessary to enable the integration
of applications and business processes. This includes the description
of interfaces between systems, and the mapping and routing definitions
needed for exchanging XML messages or Web services. It also includes detailed
descriptions of integration scenarios and collaborative business processes,
as well as any necessary system landscape details.1 It is precisely this
collection of collaboration knowledge that allows you to integrate all
your SAP systems with each another, and with non-SAP systems, with minimum
expenditure of resources.
The exchange infrastructure and a tool
called the Integration Builder (see Figure 1) provide the means
to capture this type of knowledge so that it can be automatically called
into play at the proper time. With this tool, defined elements are used
as the basis for collaboration knowledge, so you do not have to hard-code
integration efforts into your applications.2
||Integration Builder for Development of Interfaces and
And why would you want to share this knowledge?
The answer lies in the phrase minimum expenditure of resources.
In a heterogeneous system landscape, you only want to use a single, synchronized
pool of information for integration one that can be accessed across
your company and applied to all the systems in your landscape. Of course,
this is only possible if all parties are speaking the same language.
For this reason, the exchange infrastructure uses open standards as the
basis for collaboration knowledge, and provides a tool (the Integration
Builder) to help you easily access, share, and add non-SAP knowledge to
your information pool.3
From an architecture point of view, collaboration
knowledge is based on an outside-in approach that is,
it enables you to implement interfaces independent of any programming
language or development platform. You can then generate both platform-
and programming-language-dependent proxies that are actually used in the
application for the generation and processing of incoming XML messages.
As a result, you no longer need to rely on the middleware layer. You are
shielded from the technical infrastructure, and do not need to worry about
complicated transport logs or runtime services.
In this article, Ill show you what
you need to know to start working with collaboration knowledge.
The Basic Components of the Exchange Infrastructure
For this article, youll need to be familiar with a few other
basic elements of the exchange infrastructure, included in the figure
- Integration Repository
- Integration Directory
- Integration Engine
All of SAPs predefined
information for integration (which you establish via the Integration
Builder) is stored in something called the Integration Repository.
Only the specific pieces of information needed within your own production
landscape (a subset of all this information) end up in the Integration
The Integration Engine accesses information
from the Integration Directory at runtime, making it available to
the services that need it.
For more information about the Integration
Repository, Integration Directory, and Integration Engine, please
refer to the article SAPs Exchange Infrastructure
The Remedy for Escalating Application Integration Costs by
Sven Leukert in this issue of SAP Insider.
External information can be added and, again, the only condition
is that you use open standards to describe them.
Enabling Integration of Legacy and SAP Systems With Just the
Flip of a Switch
Lets suppose you have an R/3 4.6C system that you want to integrate
with a legacy system and with your new mySAP Supplier Relationship Management
(SRM) system. For the R/3 and SRM systems, much of this process is taken
care of for you. When the exchange infrastructure is incorporated into
your landscape, integration information about the R/3 and SRM systems
is already delivered by SAP. But there are a few additional steps needed
to integrate a legacy system.
First, you would make the legacy system
known to your exchange infrastructure by simply entering the system-relevant
information into the Integration Directory. Here, you can tell the exchange
infrastructure that you are using the SAP-supplied file adapter to convert
the ASCII data from your legacy system to an XML message. The exchange
infrastructures adapter framework and the Integration Builder help
you with this process.
For the R/3 and SRM systems,youll
find that most of the required collaboration knowledge has already been
included in the Integration Repository. For example, the corresponding
IDoc description has already been uploaded and is consequently usable
as a WSDL description. All that remains for you to do is some fine-tuning
(for example, selecting the correct routing rule or mapping) and to activate
those settings using the Integration Builder.
This type of configuration exercise can
be done using only SAP-supplied shared collaboration knowledge. But what
if you need to connect a non-SAP system? Thats what we will review
Integration of Third-Party Systems into Your Landscape
As you have already seen, one advantage of the exchange infrastructure
is its use of open standards. If a third-party system supports XML messages,
then it can easily be connected to the existing system landscape using
the exchange infrastructure. If the system information (the interfaces
of the third-party system, for example) is described using open standards,
then you can import these descriptions into the central Integration Repository
or Integration Directory and use them to make additional settings. It
may be necessary to create an extra mapping to align the data structure
of both systems. However, you can use the Integration Builder to do this,
and you can copy and adjust a mapping that already exists.
However, if the third-party system does
not support XML and these standards, you will need an adapter to integrate
the system. This, of course, demands increased effort, especially since
you need an adapter for each of these different third-party systems. Therefore,
the consistent use of standards minimizes the integration effort.
As you can see from these examples, most
of the interfaces or Web services that are necessary for the integration
of SAP applications are implemented and delivered by SAP. But what if
you need one thats not included? Because the exchange infrastructure
is based on an outside-in, open-standards approach, you can build your
own. You will find details about this in the appendix at the end of this
article, Building Your Own Interfaces and Web Services.
Components and Collaboration Knowledge for a More Highly Integrated
The exchange infrastructure not only comprises technical components for
exchanging XML messages between your systems, but also delivers the full
collaboration knowledge required to activate SAP-delivered integration
scenarios in your system landscape with a minimum expenditure of resources.
You are supported in this process by the Integration Builder, which you
use to create not only these settings, but also content as needed, bolstering
the existing collaboration knowledge.
SAP delivers collaboration knowledge to
enrich the information and systems already at work within your company.
Thanks to the use of open standards, you can more easily and efficiently
share that knowledge within your company to ensure that your systems are
integrated in the best possible way.
For more information on the exchange infrastructure,
see the articles by Matthias Haendly, Coping with Application Integration
Its a Critical Challenge for Every IT Organization,
and by Sven Leukert, SAPs Exchange Infrastructure The
Remedy for Escalating Application Integration Costs, in this issue
of SAP Insider.
For example, the names (including the IP addresses) of systems in the
2 See the appendix
to this article for details on the Integration Builder.
only condition for storing external information
in the Integration Repository (that is to
say, filling the Integration Repository with
non-SAP information that is necessary for
integrating third-party solutions, for example)
is that this information is described using
open standards (from W3C and others), such
as WSDL (Web Service Description Language),
XSDL (XML Schema Definition Language), CIM
(Common Information Model), or XPath.
| Appendix: Building Your Own Interfaces and Web Services
With the Integration Builder tool, consultants and administrators
can define and configure settings for integration scenarios, mappings,
routings, Web services, and so on. The same tool is also used by
application developers and consultants (whether they are SAP employees
or not) to initially create all interfaces, mappings, and so on.
So in the event that the interface or Web service you need isnt
part of the SAP-provided offering, you can build your own, with
help from the Integration Builder.
You begin by creating a message interface
independent of any programming language or development platform.
Interface descriptions are saved in the Integration Builder using
the open standards WSDL and XSDL: general XSDL types describe data
types, and the other parts of the interface are saved in a WSDL-compatible
You dont have to be an expert
in these formats either, since the Integration Builder provides
an XSDL editor. This editor tool enables you to create data types
graphically, without having to write plain XSDL. Lets take
a closer look at the Integration Builder in Figure 1. Here,
were defining the data type Price in the XSD editor.
||A Closer Look at the Integration Builder
From the individual data types, you
create a complex data type, like OrderCreateInternalIn in
Figure 1, which means that you can also use data types from pre-existing
ones recursively. These data types can be reused, and less time
is spent developing new ones.
Here is another example: Suppose
you want to create a new interface for collecting customer information
in a banking application name, address, account number, and
First, from the list of data types
in the Integration Builder, you want to select the data type name.
In addition, you select the predefined, complex data type address,
which consists of the elements city, house number
and zip code. You also then require the data type customer
number (which also already exists). However, the bank
account data type is missing. Therefore, define this data
type directly in the XSD editor by choosing that name for the data
type and selecting a corresponding XSDL data type (integer,
So far you have defined the semantics.
The next step is to define the message type. Each message
type contains a data type and its semantic description (which is
required later for mapping, as well as to conform to the structure
Now that youve defined the
semantics of the interfaces, let us now return to the creation of
a message interface. You create the message interface using the
message type. Your choice of message interface attributes is crucial
for future communication between the components to be integrated.
You can choose the mode (synchronous or asynchronous) and the direction
(inbound outbound) (see Figure 2). In the synchronous and
asynchronous inbound case, you can also choose a fault message.
Your choice of properties depends entirely on your application scenario,
although asynchronous calls are preferred to synchronous calls.
||Examples of Interface Properties
||TIP: A paradigm of the outside-in
approach is very important here: the presence of inbound/outbound
interfaces. An inbound interface can only be called with
an outbound interface; in other words, you must always
create these two as a pair.
Now that you have created your interface, independent of any programming
language or platform, how do you get all this information into your
application code? The answer is quite simple: You generate a proxy
in the Integration Builder. Proxy generation is available for Java,
ABAP, and Microsofts .NET.
You probably already recognize some
of the big advantages of this outside-in approach:
- You now have interface descriptions that can be used on many
- The interface is not anchored to any particular application
- The proxy shields you from more complex areas of a middleware
Perhaps you would like to integrate
an additional component with the one that already exists using this
same interface. This new component is now implemented in Java, unlike
the ABAP components that already exist.
As far as outbound interfaces are
concerned, an outbound proxy (Java or ABAP Objects classes) is generated
for you, and you can copy this to the application code. You transfer
the data using the parameters of these classes, and the proxy generates
the XML document for you and forwards it to the Integration Engine
(see Figure 3).
||An Example of a Proxy Generation Scenario
When it comes to inbound interfaces,
an inbound proxy (an ABAP Objects interface with an ABAP Objects
class, or a Java interface with method declaration) is generated
for you. But in this case, you must then, metaphorically speaking,
give some life to it in other words, you must program these
interface methods further to process a received inbound XML document.
This is all well and good, but you have probably already asked
yourself, What happens when the message structure in other
components is not the same? Sure, the structures are the same as
far as semantics are concerned but what happens when they
are syntactically and structurally different?
In that case, you require a mapping.
In integration scenarios delivered
by SAP, the mapping is, of course, already available and you merely
need to select it in the Integration Builder.2
If you want to use your own mapping,
you can include it in the Integration Builder and link it to the
corresponding interface with minimal effort. In general, XSLT, Java
classes, or a combination of the two can serve as the mapping descriptions,
which are then called mapping sequences. In this way, you
can execute every form of structure mapping and/or value mapping.
The actual physical execution of the mapping then takes place at
runtime in the Integration Engine by calling the mapping services.
While I wont go into further
detail on mapping here, for more information see the article by
Sven Leukert in this issue of SAP Insider.
A short note on routing: Routing, or routing rules, are required
to determine the receiver of a message. Sometimes the content of
an XML message is used for this purpose. You must also maintain
these routing rules or create them in the Integration Builder, where
sender-receiver relations are used. You can implement routing rules
either with XPath or with Java code.
Using this outside-in approach, the creation of interfaces and
Web services reaches a new dimension. Interface descriptions are
independent of development languages and platforms. Proxy generation
shields application developers from the technical infrastructure
and enables them to concentrate on application development, thus
minimizing the effort required to integrate, and later maintain,
For the specialists among you, each complex type is an abstract
definition of a data type in XSDL. To be able to use this complex
type, it must be added into an element and this element must be
part of the message type definition.
Note that in certain instances more than one mapping is possible.
Christoph Wachter received his honor degree
in physics in 1995 from the University of Karlsruhe,
Germany. After working as a technical writer
and quality manager for a medium-sized enterprise,
he joined SAP in 1997 as a member of the ABAP
Development Workbench product management group.
Currently, he is working in the GBU Application
Integration, where he is a Product Manager
and responsible for tools of the new exchange
infrastructure, along with various other areas,
such as SAP Smart Forms. You can reach him