These guidelines are based on the experience of developing many applications with the Service Provider Infrastructure (SPI) and its FPM integration.
They intend to ease the life of every developer or architect that is using the SPI by providing best practices and a certain guidance to avoid common mistakes.
DMZ Test Strongly Recommended for Every Application
Although the DMZ might not be a valid use case for every application, still we strongly recommend test the DMZ scenario with every application.
This helps to identify a UI-backend-coupling, since in the DMZ the backend is not available and vice versa.
So to ensure that the application is really decoupled from the UI it is a good idea to test the DMZ scenario.
- To ensure clean data access between the logical layers User Interface (UI), Service Provider (SP), Metadata Provider (MP) and Business Object (BO) distinct packages for each layer shall be introduced.
- A development object and also the application logic shall be implemented in the package where it semantically belongs to.
Example: If a DDIC object or a constant interface needs to be accessed from the UI and the SP layer it shall be created in a separate package e.g. a common DDIC package or (if suitable) the MP package.
- The rules for data access (read, insert, update, delete data) across packages are:
- The UI layer shall only access data via the Application Model (NO direct access to any SP/MP/BO classes!).
- The SP layer shall only access data via BOs or the SPI (NO direct access to any UI/MP or foreign SP classes!).
- The MP layer shall not insert, update or delete any data at all. The Metadata Provider shall only read data via BOs, backend APIs or the SPI.
- The BO layer shall only access data via backend APIs, other BOs or the SPI (NO direct access to any UI/SP/MP classes!).
- The flag for package encapsulation (package check as server) shall be set for all packages.
The consequence of this is that only the development objects exposed in package interfaces are visible to the outside.
Package interfaces shall be maintained as follows:
- The UI package interface shall only contain reusable UI components and corresponding (e.g. DDIC) objects (which shall only be accessed by other UI layers).
- The content of the SP package shall not be exposed via a package interface since any access to the SP must go through the SPI.
- The MP package interface shall only contain DDIC objects and constant interfaces that belong to the metadata.
The MP class itself shall not be part of the package interface, since it must only be accessed via the SPI.
- The BO package interface shall contain the BO classes and corresponding (e.g. DDIC) objects.
User Interface (UI)
- To access the backend the Application Model shall be used
- The UI shall not contain:
- direct access to any SP-, BO-, MP-class, backend API or database
- business logic
- Every application should consider the current official UI Guidelines.
- When an existing application is being enhanced the enhancement should be implemented following the UI Guideline of the existing application to avoid a mixture of UI Guidelines within one UI.
- Wherever possible GUIBBs shall be used.
- When a freestyle UIBB i.e. application-specific Web Dynpro component is created it shall be built as fine grained as possible i.e. it shall contain only one node of the Metadata Provider.
This increases the reusability of the UIBB.
- For the exchange of key information between the UIBBs to retrieve the data the Wiring shall be used.
- Use an application specific namespace for your application specific FPM events/feeder actions/feeder parameters.
When you use a foreign namespace such as FRW_* or FPM_* a future enhancement in those reuse components could lead to issues in your application.
Not using a namespace at all reduces the reusability of your UIBBs.
Metadata Provider (MP)
Goal: Provisioning of a semantically complete metadata definition that enables connection of the SPI to the Service Provider (SP) implementations, implementation of browser tools for visualization of metadata and readability of provided functionality at design time for consumers.
- All new Metadata Providers shall be implemented based on the EHP6 SPI metadata definition. The version attribute of the metadata interface shall be set accordingly, this is a binding commitment that the implementation supplies all relevant metadata attributes:
- Attributes on ABBID level
- Attributes on node level
Optional parts of metadata (become mandatory as soon as the SP implementation supports/uses the definition):
- Query and Action definition tables
- ID and data structure/table definition (in case of usage the structure and table type shall be defined)
- Insert parameter structure
- A node data/ID structure shall not contain any references or instances, as this invalidates the DMZ scenario.
- A node ID structure shall contain only components that are required for unique identification of one data set (all additional components shall not be part of the node ID structure).
- A node data structure shall not contain components that are only required on a User Interface, e.g. a long text link field.
- A node data structures should not contain XSTRINGs and deep structures. This disables a generic consumption and enforces application specific implementations on consuming layers. If this cannot be avoided alternatives (e.g. additional flat nodes providing the same functionality) shall be provided in addition to allow a generic consumption.
- If in current development existing Metadata Providers are extended the implementation shall be enhanced to satisfy the EHP6 SPI metadata definition.
- A metadata data node shall function independently from other nodes, e.g. it shall be possible to access child nodes without the necessity of previously reading the parent node. Deviations from this guidelines have to be modeled in the metadata as prerequisite operations on ABBID level (global initialization) or node level (local initialization) respectively (Prerequisite initializations are to be avoided whenever possible).
- Side-effects shall be modeled as accurate as possible to avoid performance issues when nodes are unnecessarily invalidated, e.g. do not use side-effect ALL when a PARENT side-effect would be sufficient.
- If additional data needs to be read to build up the metadata only backend APIs, BOs, or the SPI shall be accessed for that purpose.
- A Metadata Provider shall not contain any access to UI or SP classes.
Service Provider (SP)
Goal: Provisioning of a reusable decoupling layer for arbitrary consumers (e.g. FPM SPI Integration (FSI), POWL, UXF...). Especially with regards to an adaptation to other generic layers a complete and semantically correct implementation of the Service Provider layer is mandatory. Otherwise the reusability is heavily restricted and most probably not given.
- A Service Provider provides a complete implementation of the node specific interface methods (e.g. RETRIEVE, UPDATE...) for each node of the metadata model (whenever possible). Example aspects of completeness:
- Methods shall be implemented mass-enabled, even if currently known consumers only work on one data set or the underlying BO itself is not mass-enabled
- All method export parameters are filled
- A subordinate node shall not only support a RETRIEVE by association (parent) but also a direct RETRIEVE with its own IDs
If an interface method is not used at all an ASSERT statement shall be used, rather than having an empty implementation for avoiding Checkman errors and identifying invalid calls during development.
- The transactional methods (CHECK_BEFORE_SAVE, SAVE and CLEANUP) have a static character and shall handle the complete node model of a Service Provider.
- Functionality shall be provided via the expected methods: e.g. creation of a new data set shall be realized via the INSERT method and not via an ACTION or UPDATE.
Usage of Generic Export Parameters
Especially the generic export parameter EG_PARAM of the ACTION method shall not be misused, e.g. for reading/handling data that from a semantically point of view could have been modeled via an own metadata node.
- Main purposes of a Service Provider are:
- Enrichment of data
- Handling of 'non-BO' data (nodes) and field control information
- Provisioning of messages in SPI format
- Hand-over of field control information to SPI
- A Service Provider shall not contain:
- Business logic. Business logic is implemented in the below lying Business Object / Layer.
- Buffering of business data
- Direct database accesses
- Access to any components on UI level (including components of the FPM SPI Integration (FSI), e.g. the error flag of the Application Model) and vice versa the UI shall access the backend only via SPI (i.e. NO direct calls of SP/BO classes or Databases)
- Implicit mechanisms required for a Service Provider usage shall be avoided whenever possible. An implicit mechanism is e.g. an initialization action that needs to be executed before a Service Provider can be used; same applies also to nodes that need to be instrumented before other nodes can be used. A Service Provider node shall be functional stand-alone whenever possible.
- A Service Provider should be implemented in a node based approach: for each node of the metadata node model an own SP subclass is provided that is accessed via application specific interface and factory mechanism. Especially for larger applications this approach is strongly recommended.
With class /PLMB/CL_SPI_REUSE_SP we already offer a generic implementation of this Service Provider factory that you should use for your application.
- The field control pull mechanism should be used rather than an automatic push of field control information.
- Service Provider implementations should use break point groups for better maintenance and debugging possibilities, e.g. at all application access interface method implementations and when calling node-specific SP classes.