To enable your application backend to be accessed via the Service Provider Infrastructure (SPI) the following steps need to be performed:
- Create a Metadata Provider (MP) which will expose the hierarchical node model of your application.
- Create a Service Provider (SP) for accessing your backend.
- Define an Application Building Block ID (ABBID) to identify your MP and SP.
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.
There are no prerequisites.
- Create a normal ABAP OO class that will be your Metadata Provider.
- Add the interface /PLMB/IF_SPI_METADATA_BASE to your Metadata Provider class.
- Implement the GET_NODE_DEFINITION method.
- Set the metadata version via attribute GV_VERSION (for SAP_BS_FND 731 and later).
Create a Service Provider
You have already created a Metadata Provider.
- Create a normal ABAP OO class that will work as your Service Provider.
- Add the interface /PLMB/IF_SPI_APPL_ACCESS to your Service Provider class.
- Implement the methods of this application access interface.
(The implementation has to follow your metadata definition).
- 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.
- 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.
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.
The Application Building Block ID can either be maintained via transaction SM30 or SPRO:
- Start transaction SM30
- Open view /PLMB/V_SPI_ABB
- Start transaction SPRO
- 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
Test the Application
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:
- 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.