Architecture of SAP NetWeaver Exchange Infrastructure

SAP NetWeaver XI is a runtime environment that assigns the inbound messages to the relevant receivers, and, if applicable, maps them to another structure or protocol.
To do so, SAP NetWeaver XI requires information about how the messages are to be processed. This information is provided by the Integration Repository and Integration Directory, which contain all the design and configuration objects of the interfaces respectively. The System Landscape Directory (SLD) contains information about which systems are connected to SAP NetWeaver XI. The Adapter Engine provides information about the protocols and addresses to be used to access each system. The monitoring tools enable all messages that pass through SAP NetWeaver XI, regardless of their origin, to be monitored centrally.

We will now focus on each of these components one at a time. As you can see in the image above, the base component is the System Landscape Directory (SLD).

To be able to exchange data between systems, all the information about the type of systems and the applications they contain must be available in a central location so that the Integration Server can access it as required. In the case of SAP NetWeaver XI, this central location is known as the System Landscape Directory (SLD). The SLD distinguishes between two kinds of systems: technical systems specify the type of system (SAP, Java, or third-party) and how it can be accessed; business systems specify the role of the system in the system landscape, and which of the software versions provided by the technical system are actually used. In the SLD, each technical system is assigned one or more business systems. In the SAP world, a technical system corresponds to an actual SAP installation, whereas a business system corresponds to a client of an SAP installation.
Consequently, the SLD also contains all software products, software components, and software component versions, which are in turn provided by the technical systems and used by the business systems. The following figure explains this relationship.

Integration Builder

The Integration Builder accesses two storage locations. The Integration Repository provides all the objects that are requiredat design time to describe a system-independent connection. This description is used at configuration time in the Integration Directory to describe the actual communication between two existing systems. One reason for keeping the two phases separate is that if the same process is to take place between multiple systems (for example, between a test system and the equivalent productive systems), you need to describe it only once. It can then be accessed as many times as required at configuration time. Another reason is that SAP NetWeaver XI is currently included in the shipment of a relatively large number of other SAP products. By keeping the design phase and the assignment of the real systems separate, SAP is able to ship default scenarios for these products that customers can then apply to their system landscape.

Defining Processes, Interfaces, and Data Types in the Integration Repository

The next image shows you an overview of which elements are part of the Integration Repository (IR), how they are processed within SAP NetWeaver XI, and how they can be imported or exported.

To be able to describe interfaces and processes, you first need to define the data to be used. You can do this directly in SAP NetWeaver XI by creating your own data types and reusing them in message types. Message interfaces can then access one (asynchronous) or multiple message types (synchronous). However, you can also import these descriptions. From within an SAP system, you can import IDoc or RFC descriptions, which can be made available immediately as inbound and outbound interfaces. You can also import message interfaces in WSDL format and message types in XSD or XSLT format from non-SAP systems.

From these interfaces, one outbound interface (from the perspective of the business system, not from SAP NetWeaver XI) and one inbound interface (also from the perspective of the business system) are connected to each other by a mapping (this is always required when the message types used are not identical). A mapping defines how the structures are to be mapped and, if applicable, which values are to be mapped.

Mappings can also be either created directly in the graphical editor in SAP NetWeaver XI, or imported as Java or ABAP classes, or as XSLT or ABAP-XSLT transformations.

Defining Real Interfaces with Your Partners in the Integration Directory

You use the Integration Directory to define actual scenarios with real business partners. Using a wizard, you can access the scenarios from the Integration Repository so that you need to enter only the system names. You can also design your own scenarios; however, they must reference message interfaces and mappings that already exist in the Integration Repository. The receiver of an inbound message (and any conditions) is specified in the receiver determination; the relevant inbound.
You also need to define how the involved systems communicate with SAP NetWeaver XI. This is achieved using sender communication channels for the sender of the outbound interface, and using receiver communication channels at the receiver of the inbound interface. These communication channels define both the protocol and how a system is to be reached (for example, the RFC destination in RFC communication).

Processing Messages in SAP NetWeaver XI

The receipt of a message always triggers the SAP NetWeaver XI runtime. The information in the Integration Directory is used in the pipeline to determine which business system is the receiver of the message, and which message interface and communication channel is expected. Technical routing in the business system then determines which technical system is concerned. The system also checks whether a mapping is required and executes it, if applicable.

Well, i think this information is enough for this post and we will continue to talk about monitoring the messages from XI and also give some simple scenario example from head to toe in the next posts...