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

Introduction

To enable your application backend to be accessed via the Service Provider Infrastructure (SPI) the following steps need to be performed:

  1. Create a Metadata Provider (MP) which will expose the hierarchical node model of your application.
  2. Create a Service Provider (SP) for accessing your backend.
  3. Define an Application Building Block ID (ABBID) to identify your MP and SP.

Implementation Guidelines

When implementing a Metadata Provider or Service Provider it is advisable to read the guidelines and best practices first.

Create a Metadata Provider

The Metadata Provider (MP) exposes the hierarchical node model of your application and defines the interface of all your Service Provider methods.

Prerequisites

There are no prerequisites.

Procedure

  1. Create a normal ABAP OO class that will be your Metadata Provider.
  2. Add the interface /PLMB/IF_SPI_METADATA_BASE to your Metadata Provider class.
  3. Implement the GET_NODE_DEFINITION method.
  4. Set the metadata version via attribute GV_VERSION (for SAP_BS_FND 731 and later).

Next Step

Create a Service Provider class.

Create a Service Provider

The Service Provider (SP) is an ABAP OO class which is called by the SPI and functions as entry point to the backend.

Prerequisites

You have already created a Metadata Provider.

Procedure

  1. Create a normal ABAP OO class that will work as your Service Provider.
  2. Add the interface /PLMB/IF_SPI_APPL_ACCESS to your Service Provider class.
  3. Implement the methods of this application access interface.
    (The implementation has to follow your metadata definition).
  4. Implement the initialization method of your Service Provider
    • For SAP_BS_FND 731 or newer add interface /PLMB/IF_SPI_APPL_ACCESS_INIT to your Service Provider class and implement the INITIALIZE method.
    • For older versions of SAP_BS_FND add a CONSTRUCTOR method to the SP which has one import parameter IO_COLLECTOR of type ref to /PLMB/IF_SPI_COLLECTOR.
  5. If you want to use the pull mechanism for the field and operation control (recommended for SAP_BS_FND 703 or newer)
    you also need to add interface /PLMB/IF_SPI_PROPERTIES_ACCESS to your Service Provider class.

Next Step

Define an Application Building Block ID (ABBID).

Define an Application Building Block ID (ABBID)

The ABBID identifies for one application – or one part of an application – the relevant Service Provider class and Metadata Provider class.
With this information the SPI layer instantiates and accesses those classes.

Technical Details of ABBID DB Table

The database table for defining an ABB is cross-client; table type is 'E' with customer namespace 'Y*' and 'Z*' for the ABBID.

Prerequisites

You have already created a Metadata Provider and Service Provider.

Procedure

The Application Building Block ID can either be maintained via transaction SM30 or SPRO:

  1. Start transaction SM30
  2. Open view /PLMB/V_SPI_ABB

OR

  1. Start transaction SPRO
  2. Click on Cross-Application Components, Processes and Tools for Enterprise Applications, Settings for BO Framework and Navigation, BO Framework, Define Application Building Blocks

Now you need to enter the following details:

  • ABBID (key) – Your Application Building Block ID
  • Application Building Block Description – Short description of your application building block
  • MP class name – Name of your metadata provider class
  • SP class name – Name of your service provider class

Next Step

Test the application.

Test the Application

Prerequisites

You have already created a Metadata Provider, Service Provider and defined an Application Building Block ID (ABBID).

Procedure

To test the application we offer two tools, the Metadata Browser (transaction MDB) and SPI Browser (transaction SPB).
Those tools allow you to view and check the Metadata of any ABBID and to access any Service Provider via a generic UI.

Demo SPI Application – EPM

For demo and test purposes we offer an Application Building Block (ABB) for the Enterprise Procurement Model (EPM) which was introduced by the NetWeaver team for demo and test purposes.
The ABB ID of this application is EPM and its SP and MP classes are /PLMU/CL_FRW_EPM_SP and /PLMU/CL_FRW_EPM_MP.

It offers various real-world business scenarios and gives the ability to design business processes inside a company as well as scenarios where customers are affected, you can:

  • manage your employees and departments
  • manage products in stock
  • sell goods and services
  • manage your customers

The following EPM objects are implemented:

Objects of the Enterprise Procurement Model

  • Organization – Represent the demo enterprise 'ITelO' including departments, employees, ...
  • Business Partner – Represent customers and contacts inside these companies
  • Sales Order – Represent single orders done by customers
  • Sales Order Invoice – Represent invoices for sales orders
  • Storage Bin – Ability to model simple Stock scenarios
  • Product – Products that can be used for sales scenarios
  • Text – Texts that can be found everywhere in the EPM Model
  • Address – Address details for e.g. Business Partners

The node hierarchy of the SPI implementation is closely mapped to the EPM objects as you can see in the next figure.

SPI Node Hierarchy of the EPM Application

  • No labels