GRC
HR
SCM
CRM
BI


Article

 

Just What Is "Collaboration Knowledge" and Why Would I Want to Share It?

by Christoph Wachter | SAPinsider

April 1, 2002

by Christoph Wachter, SAP AG SAPinsider - 2002 (Volume 3), April (Issue 2)
 

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


Figure 1 Integration Builder for Development of Interfaces and Data Types

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, I’ll show you what you need to know to start working with collaboration knowledge.

The Basic Components of the Exchange Infrastructure

For this article, you’ll need to be familiar with a few other basic elements of the exchange infrastructure, included in the figure below:

  • Integration Repository
  • Integration Directory
  • Integration Engine

All of SAP’s 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 Directory.*

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 “SAP’s 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

Let’s 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 infrastructure’s adapter framework and the Integration Builder help you with this process.

For the R/3 and SRM systems,you’ll 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? That’s what we will review next.

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 that’s 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 System Landscape

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 — It’s a Critical Challenge for Every IT Organization,” and by Sven Leukert, “SAP’s Exchange Infrastructure — The Remedy for Escalating Application Integration Costs,” in this issue of SAP Insider.


1 For example, the names (including the IP addresses) of systems in the landscape.

2 See the appendix to this article for details on the Integration Builder.

3 The 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 isn’t 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 format.

You don’t 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. Let’s take a closer look at the Integration Builder in Figure 1. Here, we’re defining the data type Price in the XSD editor.

Figure 1 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 so on.

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”, for example).

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 of XSDL1).

Now that you’ve 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.

Figure 2 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.

Proxy Generation

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 Microsoft’s .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 development platforms.
  • The interface is not anchored to any particular application code.
  • The proxy shields you from more complex areas of a middleware layer.

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

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.

Mapping

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 won’t go into further detail on mapping here, for more information see the article by Sven Leukert in this issue of SAP Insider.

Routing

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.

Conclusion

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, systems.

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

2 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 at christoph.wachter@sap.com.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ