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

Introduction

The Service Provider Infrastructure (SPI) offers standard enhancement mechanisms for Metadata Provider and Service Provider implementations via enhancement spot /PLMB/ES_SPI.

Use BAdI Filter

It is important to maintain the BAdI filter to avoid that the BAdI implementation is called in foreign applications.

Metadata Provider Enhancement

The enhancement spot /PLMB/ES_SPI contains BAdIs to enhance an application's Metadata Provider in the following ways:

Enrich Node Definition

The enhancement spot /PLMB/ES_SPI contains the BAdI definition /PLMB/EX_SPI_METADATA with interface /PLMB/IF_EX_SPI_METADATA.
This interface defines the method ENRICH_NODE_DEFINITION that allows enhancing an existing metadata model.

Method signature:

Parameter

Data Type

Description

IV_ABBID

/PLMB/SPI_ABBID

Application Building Block ID (ABBID)

CS_METADATA_ABBID

/PLMB/S_SPI_METADATA_ABBID

Metadata on Application Building Block (ABB) level

CT_METADATA_NODE

/PLMB/T_SPI_METADATA_NODE

Metadata on node level

Standard usage of this BAdI would be that a customer adds new nodes to an SAP delivered metadata implementation.
It is also possible to change the SAP metadata definition but only in a restricted way:
There are some hard checks for essential metadata attributes which lead to an exception in case they are violated, e.g. when nodes, actions, etc. are removed by the enhancement or when data type definitions are changed. But in general the enhancement logic is tolerant wherever meaningful and will merge the SAP metadata with the enhancement's metadata, e.g. when the original side-effect is MYSELF_CHILD and the enhancement side-effect is PARENT the SPI will merge it to side-effect MYSELF_CHILD_PARENT.

Customer Namespace

The namespace for customer nodes, actions, queries etc. is Y* and Z*, so SAP metadata must not contain such names.

Support Changes in Node Metadata at Runtime

The enhancement spot /PLMB/ES_SPI contains the BAdI definition /PLMB/EX_SPI_METADATA_DYN with interface /PLMB/IF_EX_SPI_METADATA_DYN.
This interface defines the method GET_NEW_NODE_DEFINITION which allows providing the updated metadata of a node at runtime.

Method signature:

Parameter

Data Type

Description

IV_NODE_NAME

/PLMB/SPI_NODE_NAME

Node name whose metadata is requested

IG_PARAM

ANY

Parameter type needs to follow the definition of the node metadata

CS_METADATA_NODE

/PLMB/S_SPI_METADATA_NODE

Node Metadata

When a customer node's metadata is depending on certain conditions that can be changed while the application is running the usage of this BAdI is required.
Example: the type of an object alters the available attributes of this object and the user can set the object type directly in the UI.

Service Provider Enhancement

The enhancement spot /PLMB/ES_SPI contains BAdIs to enhance an application's Service Provider in the following ways:

Node Specific Enhancements

To enhance the node specific methods of the Service Provider (RETRIEVE, INSERT, UPDATE, DELETE, ACTION and QUERY) BAdI /PLMB/EX_SPI_APPL_ACCESS with the interface /PLMB/IF_EX_SPI_APPL_ACCESS offers MODIFY_BEFORE, BEFORE and AFTER methods, which are processed in that sequence.
All required context information is provided via import parameters (e.g. ABBID and node name). The BAdI implementation can supply e.g. messages to the provided Collector if required. Via IO_METADATA the metadata definition can be accessed, this might be required in case of dynamic nodes or when implementing a generic enhancement logic.

The MODIFY_BEFORE method allows the modification of the import parameters that will reach the Service Provider (if call is not skipped in BEFORE method).

Example signature of MODIFY_BEFORE_UPDATE:

Parameter

Data Type

Description

IV_ABBID

/PLMB/SPI_ABBID

Application Building Block ID

IV_NODE_NAME

/PLMB/SPI_NODE_NAME

Node Name

IO_COLLECTOR

/PLMB/IF_SPI_COLLECTOR

Collector

IO_METADATA

/PLMB/IF_SPI_METADATA

Metadata Provider

CT_NODE_DATA

INDEX TABLE

Changed/updated node data

CT_CHANGED_FIELD

/PLMB/T_SPI_CHANGED_FIELD

Changed fields

The main purpose of the BEFORE method is to decide whether the standard Service Provider implementation is to be called or skipped.
One can set the changing parameter CV_SKIP_STANDARD and by doing so the SPI will not call the standard implementation (Service Provider implemented by SAP) of the method but directly call the AFTER BAdI implementation of the method. If (for some reason) the complete processing of the method is to be cancelled the changing parameter CV_FAILED can be set.

Example signature of BEFORE_UPDATE:

Parameter

Data Type

Description

IV_ABBID

/PLMB/SPI_ABBID

Application Building Block ID

IV_NODE_NAME

/PLMB/SPI_NODE_NAME

Node Name

IT_NODE_DATA

INDEX TABLE

Changed/updated node data

IT_CHANGED_FIELD

/PLMB/T_SPI_CHANGED_FIELD

Changed fields

IO_COLLECTOR

/PLMB/IF_SPI_COLLECTOR

Collector

IO_METADATA

/PLMB/IF_SPI_METADATA

Metadata Provider

CV_SKIP_STANDARD

/PLMB/SPI_SKIP_STANDARD

Indicator: skip the standard implementation

CV_FAILED

/PLMB/SPI_FAILED_IND

Indicator: processing failed, cancel further processing

The AFTER method offers all parameters of the corresponding application access interface method.
The input parameters always provide the data as it was also handed over to the standard implementation, while the changing parameters contain the node data as it is exported from the SAP Service Provider i.e. both tables need not to be identical. The Service Provider could e.g. have enriched data. This means that it is possible in the AFTER BAdI implementation to identify such differences and (if required) react on them. In case that the standard implementation was skipped by the BEFORE method the changing parameters will be empty and need to be filled in the AFTER method accordingly.

Example signature of AFTER_UPDATE:

Parameter

Data Type

Description

IV_ABBID

/PLMB/SPI_ABBID

Application Building Block ID

IV_NODE_NAME

/PLMB/SPI_NODE_NAME

Node Name

IT_NODE_DATA

INDEX TABLE

Changed/updated node data

IT_CHANGED_FIELD

/PLMB/T_SPI_CHANGED_FIELD

Changed fields

IO_COLLECTOR

/PLMB/IF_SPI_COLLECTOR

Collector

IO_METADATA

/PLMB/IF_SPI_METADATA

Metadata Provider

CV_FAILED

/PLMB/SPI_FAILED_IND

Indicator: processing failed, cancel further processing

CT_INDEX_FAILED

/PLMB/T_SPI_INDEX_FAILED

Indices of node IDs for which the update failed

CT_NODE_DATA

INDEX TABLE

Changed/updated node data

CT_NODE_ID_REL

/PLMB/T_SPI_NODE_REL

Relationship between IT_NODE_DATA and CT_NODE_DATA

Handling Additional Fields of an Existing Node

If the data structure of a node was enhanced with additional fields, e.g. by using an enhancement include, the AFTER BAdI methods can be used to fill/handle these fields.

Manipulating (SAP) Data of an Existing Node

Changing the data content of 'standard' fields of an existing node works exactly the same as handling additional fields of an existing node.

SPI doesn't Validate Enhancement Logic

SPI cannot check whether the data manipulation done by the enhancement is valid: e.g. changing a description text might be uncritical while other data changes could lead to erroneous further processing.

Handling New Nodes or Replacing the SAP Implementation for an Existing Node

If a new node was added via Metadata Provider enhancement to the applications node model or the implementation of an existing SAP node shall be replaced, it is required to implement the BEFORE BAdI methods and set the flag CV_SKIP_STANDARD to ABAP_TRUE to ensure that the standard Service Provider implementation is not called for this node.
The AFTER BAdI methods can then be used to implement the actual logic, e.g. reading and writing the node data from an own persistency/application.

Transactional Enhancements

To enhance the transactional methods CHECK_BEFORE_SAVE, SAVE and CLEAN_UP of the Service Provider, BAdI /PLMB/EX_SPI_TRANSACTION with the interface /PLMB/IF_EX_SPI_TRANSACTION offers AFTER methods.
Those methods provide the ABBID and a Collector instance via input parameters. For the AFTER_CHECK_BEFORE_SAVE and AFTER_SAVE method additionally a changing parameter CV_FAILED is available that allows cancelling the call. The AFTER_CLEAN_UP method additionally provides the cleanup reason as import parameter.

Field and Operation Properties

When own fields or even own nodes are added to an application not only the fields content needs to be handled but also the properties of the field. How the field control is handled depends on the application using either the pull mechanism or the push mechanism for supplying properties.

Enhancing Pulled Properties

If the application is using the pull mechanism an own BAdI needs to be implemented – comparable to the Service Provider implementing an own interface for the pulling of properties. The enhancement spot /PLMB/ES_SPI contains the BAdI definition /PLMB/EX_SPI_PRPTY_ACCESS with the interface /PLMB/IF_EX_SPI_PRPTY_ACCESS which defines methods for pulling field and operation properties.
The purpose of the methods is the same as for the regular pull methods implemented by a Service Provider.

Both methods provide the same import parameters as their Service Provider counterparts. In addition they receive as import parameters the properties information as it was provided by the standard implementation; this information might be required to control own fields (e.g. customer include field A shall always have the same property control as SAP standard field B). Via changing parameters the BAdI implementation can return its own/additional properties. These properties are then merged with the existing standard properties based on the normal merging rules.
Note: the BAdI method GET_PROPERTIES provides the export parameter ET_PROPERTIES_SINGLE_IDX and ET_PROPERTIES_MULTI_IDX of the Service Provider method GET_PROPERTIES already combined in import parameter IT_PROPERTIES, so that it can be evaluated more easily by the BAdI.

Enhancing Pushed Properties

If the application is using the push mechanism the properties can be directly supplied within the MODIFY_BEFORE, BEFORE or AFTER methods of the application access BAdI via the provided Collector instance using the respective Collector methods. These properties are then merged with the existing properties handed over to the Collector by the SAP Service Provider based on the normal merging rules.

How to Enhance Pushed Properties Consistently

When enhancing the properties that are provided by the standard in the "push" approach it is important to know that whenever new properties are provided by the backend the old properties are overwritten and NOT merged with the new ones.
This means that if it is desired to enhance field properties of the standard in a consistent manner it is necessary to enhance all methods that are used by the standard to push field properties.
If for example the standard passes field properties in the RETRIEVE, UPDATE, INSERT and ACTION method to the Collector, also those methods need to be enhanced to adjust the field properties accordingly. If one would only enhance the RETRIEVE method it may happen that after an additional ACTION call the enhanced properties are again overwritten with the ones provided by the standard.

  • No labels