Page tree
Skip to end of metadata
Go to start of metadata


The Service Provider Infrastructure (SPI) is an application and UI technology independent layer for business data exposure which is part of the SAP Business Suite Foundation (SAP_BS_FND). Its main goal is to support the application developer in building timeless software and to decouple the UI from the backend completely.

SPI handles huge amounts of data with a great performance and no additional buffering while being minimal invasive to the underlying implementation (arbitrary data repositories can easily be connected). Also dynamic backends can be accessed via the SPI, which for example do not have a static DDIC representation of their data structures or which even change their data type definitions at runtime. Every application that is using the SPI correctly can – out of the box – either run the UI and the backend on the same system or run the UI on a system in the DMZ and the backend on a second system behind the firewall. Furthermore the SPI provides a central enhancement spot which can be used by customers or partners to enhance the application backend modification free.


Structure of an SPI Application

An SPI application is identified by a so called Application Building Block ID (ABBID). This Application Building Block (ABB) can represent a complex application with many objects, a single object or even only a small part of an object.

Every SPI application exposes its data via a hierarchical node model. There may be several hierarchies within one application i.e. there can be multiple root nodes. A node normally represents an object or a part of an object. Each node has an ID and data structure and typically allows to read and modify its data.

The definition of the nodes and their capabilities is done via the Metadata Provider whereas the Service Provider is the entry point into the application backend and handles the data flow at runtime. Technically those two entities are ABAP classes that implement certain SPI interfaces.


Main Entities of the Application Building Block

Consumption of an SPI Application

SPI offers an FPM integration which supports GUIBBs as well as application own ABAP Web Dynpro components i.e. freestyle UIBBs. SAP Netweaver Gateway has implemented a generator that allows creating OData services to consume SPI applications. Of course SPI can also be used as backbone for many other technologies in the ABAP environment like POWLs and Adobe Forms.

One central class of the SPI allows the consumption of all SPI application – the so called Connector. It implements the same access interface as the Service Providers, so it feels like calling the SP directly, when using the Connector. Internally the Connector e.g. takes care of the system switch, when running in a DMZ scenario.

Almost all SP methods return a direct result via export parameters for example a table with requested node data. There is however also an indirect channel of communication between the SP and its consumer via the so called Collector. This object stores additional information like messages or field control information and thereby reduces the complexity of the SP's interface.

The complete node model of the application is described by the Metadata Provider. This includes for example the data type of nodes as well as available actions and queries that can be executed on those nodes. Beyond the definitions that are required from a technical perspective by application consumers, also attributes are contained that have a declarative/explaining character; i.e. to allow a consumer to understand what is possible with this application.

1 Comment

  1. The concept of SPI sounds very similar as SADL. Is SADL the successor of SPI?