- SAP Managed Tags:
Reusability of RAP Business Objects
Restful ABAP Programming model offers developers an efficient way to build enterprise-ready applications in cloud as well as on-premise. RAP programming model has been around for some time and has proven advantages in developing SAP FIORI applications and Cloud APIs in A2X scenarios.
This blog post is about a use case on how RAP business objects has been cascaded to achieve reusability, flexibility and specialization. For all other latest happenings from the RAP please refer other other informative blogs and articles on RAP.
Product substitution is one of the first substitution functionality released to customers since SAP S/4HANA Cloud Edition 2008 and on SAP S/4HANA 2020 On Premise. Other types of substitutions that consume the master data substitution framework will be available in the upcoming releases. For more information on product substitution kindly refer the blog post Defining Master Data for Product Substitutions
Below block diagram pictorially explains the use case that there are different applications which are specializations of the underlying generic master data substitution framework. Hence it was necessary to adopt a layered approach to achieve this flexibility using the RAP business objects.
All the substitution functionalities have a common requirement to store the substitution master data in the generic layer as relationship between object and a substitute. There are consuming application specific functionalities (eg. additional validations) that need to be done only for that specific application. This demanded having a common reusable business object based on RAP at the core. The consumer can have additional processing logic to suit the specific use case.
The business objects have been layered in such a way that the master data substitution BO becomes the foreign entity in the upper level product substitution layer. The core has been designed as a non-draft managed RAP business object so that it takes care of the lifecycle of the data that’s being processed. All standard functionalities like the UUID generation, locking, SADL authority checks and e-tags are handled by the underlying RAP managed business object. Additionally, generic validations like the date plausibility checks, status handling etc. are also implemented in the managed master data substitution business object. The master data substitution business objects work with the generic data type of CHAR40 as the object and the substitute. The underlying persistence database table maintains the relationship between the object and the substitute along with other attributes of substitution.
Consuming applications on the other hand need not implement the generic functionalities again and again, rather they can create an unmanaged RAP business object based on the nature of consumption and do the data type casting according to the type of substitution. SAP Object Type(SOT) plays a key role in identifying the type of substitution data that is being maintained from the consuming applications. For example, product substitution uses “Product” as the SOT and only processes the product substitution data. This means that the unmanaged product substitution BO has a where condition as ‘Product’ in the corresponding CDS View. Additionally, the data type conversion is also a responsibility of the consuming BO as the lower layer has a generic data type. The consuming applications only can define the exact data types for the given application. Below diagram explains the layering and give more details on how the redirection and the data type conversion happens.
In the diagram above you can see that the SADL framework does the read via core business object. Operations like create, update and delete need to be explicitly delegated to the underlying managed business object as the consuming product substitution business object is an unmanaged non draft RAP BO. This design provides the flexibility to perform additional application specific processing on the upper unmanaged layer (example: if the material/plant is valid for product substitutions or authority checks etc.) and by keeping the core functionality consistent in the generic managed layer. The generic layer handles the persistence of the data in the underlying data model. Messages from the foreign entity can be mapped to the unmanaged layer and those can be passed to the SAP Fiori applications.
To summarize -
Hope you like this blog post, in case of any questions please post them here. Your feedbacks are welcome in the comments section below.
Please visit the SAP S/4HANA Community page for other SAP S/4HANA topics.
Happy coding!
Restful ABAP Programming model offers developers an efficient way to build enterprise-ready applications in cloud as well as on-premise. RAP programming model has been around for some time and has proven advantages in developing SAP FIORI applications and Cloud APIs in A2X scenarios.
This blog post is about a use case on how RAP business objects has been cascaded to achieve reusability, flexibility and specialization. For all other latest happenings from the RAP please refer other other informative blogs and articles on RAP.
Product substitution is one of the first substitution functionality released to customers since SAP S/4HANA Cloud Edition 2008 and on SAP S/4HANA 2020 On Premise. Other types of substitutions that consume the master data substitution framework will be available in the upcoming releases. For more information on product substitution kindly refer the blog post Defining Master Data for Product Substitutions
Below block diagram pictorially explains the use case that there are different applications which are specializations of the underlying generic master data substitution framework. Hence it was necessary to adopt a layered approach to achieve this flexibility using the RAP business objects.
Different Substitution applications
All the substitution functionalities have a common requirement to store the substitution master data in the generic layer as relationship between object and a substitute. There are consuming application specific functionalities (eg. additional validations) that need to be done only for that specific application. This demanded having a common reusable business object based on RAP at the core. The consumer can have additional processing logic to suit the specific use case.
The business objects have been layered in such a way that the master data substitution BO becomes the foreign entity in the upper level product substitution layer. The core has been designed as a non-draft managed RAP business object so that it takes care of the lifecycle of the data that’s being processed. All standard functionalities like the UUID generation, locking, SADL authority checks and e-tags are handled by the underlying RAP managed business object. Additionally, generic validations like the date plausibility checks, status handling etc. are also implemented in the managed master data substitution business object. The master data substitution business objects work with the generic data type of CHAR40 as the object and the substitute. The underlying persistence database table maintains the relationship between the object and the substitute along with other attributes of substitution.
Consuming applications on the other hand need not implement the generic functionalities again and again, rather they can create an unmanaged RAP business object based on the nature of consumption and do the data type casting according to the type of substitution. SAP Object Type(SOT) plays a key role in identifying the type of substitution data that is being maintained from the consuming applications. For example, product substitution uses “Product” as the SOT and only processes the product substitution data. This means that the unmanaged product substitution BO has a where condition as ‘Product’ in the corresponding CDS View. Additionally, the data type conversion is also a responsibility of the consuming BO as the lower layer has a generic data type. The consuming applications only can define the exact data types for the given application. Below diagram explains the layering and give more details on how the redirection and the data type conversion happens.
Master Data Substitution block diagram
In the diagram above you can see that the SADL framework does the read via core business object. Operations like create, update and delete need to be explicitly delegated to the underlying managed business object as the consuming product substitution business object is an unmanaged non draft RAP BO. This design provides the flexibility to perform additional application specific processing on the upper unmanaged layer (example: if the material/plant is valid for product substitutions or authority checks etc.) and by keeping the core functionality consistent in the generic managed layer. The generic layer handles the persistence of the data in the underlying data model. Messages from the foreign entity can be mapped to the unmanaged layer and those can be passed to the SAP Fiori applications.
To summarize -
- Restful ABAP Programming model offers developers an efficient way to build enterprise-ready applications in cloud as well as on-premise.
- To achieve the flexibility and reusability, business objects can be layered as foreign entities to delegate operations to the lower layers.
- Additional data processing can be done in the unmanaged layer there by having the flexibility to perform application specific processing.
- Mapping of messages between the calling and the called business objects can be done in the unmanaged layer.
Hope you like this blog post, in case of any questions please post them here. Your feedbacks are welcome in the comments section below.
Please visit the SAP S/4HANA Community page for other SAP S/4HANA topics.
Happy coding!
