Custom API based on BO with custom (read) logic

[EgbertVenema]

To start with the big question:
Can I use both an existing BO interface and custom CRUD (so including Read) methods?
If not, is a completely unmanaged implementation the only feasible alternative?

And then for the bit of context:
We are currently in the process of moving several customers from their on-premise systems to the public cloud environment. The starting point of any public cloud implementation is "stick to standard", making use of public API's to interact with the SAP system.

In the past, they have of course used all the flexibility at their disposal, meaning loads of ZBAPI's to tackle client-specific logic. We can't completely remove all this logic, so are looking into our options to create custom APIs in which we can still adjust the behavior for all CRUD operations. Note the 'R' here, we also want to be able to adjust the data being retrieved during a READ operation.

An existing BO sounds like a great starting point, as the standard coding for CRUD should do fine in most cases and saves time. As a first go, I'm trying to create one for the Product BO, represented by I_ProductTP_2. To be able to filter on fields, I create a new root view entity with reference to that BO. By using an existing BO, it has to be a projection instead of a select.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Product custom projection'
@Metadata.ignorePropagatedAnnotations: true

define root view entity zp_product_custom
provider contract transactional_query
as projection on I_ProductTP_2
{
  key Product,
  ProductType,
  (...) etc.
}

Followed by a behavior definition, which in turn has to be of type projection as well:

projection implementation in class zcl_product_custom unique;
strict ( 2 );

define behavior for zp_product_custom alias Product
{
  use create;
  use update;
}

There is no 'read' behavior. That could only be added using an unmanaged implementation, but the projection part prevents me from using that type. Trying to implement a read method anyway, results in the message that "ZP_PRODUCT_CUSTOM" has the implementation type "projection", hence the implementation type "READ" is superfluous". Tried several approaches so far, all run into technical issues in the end.

Testing the custom API using Postman, I can use it to read data, that works out of the box with the default BO implementation. No method to adjust that data anywhere in the process so far. The create method would possibly work, but Postman is giving me some trouble there... let's say that's a work in progress. Focusing on the read method now.

So coming back to the initial question... is this even possible, or is an unmanaged implementation (forcing me to write all the data handling myself) be the only alternative?

[AndreasMuno]

Thank you for your question, @EgbertVenema.

By now you may have found an answer elsewhere. Still, your question gives me the opportunity to try an AI-based response I solicited from Joule for Consultants, SAP's new-ish chat bot for implementers:

"Custom API Implementation Using Business Objects

You can use a combination of existing Business Object (BO) interfaces and custom CRUD methods, including custom read logic, in SAP's ABAP RESTful Application Programming Model (RAP). RAP offers both managed and unmanaged implementation types for business objects, with managed implementations automatically handling CRUD operations through the RAP framework and unmanaged implementations requiring manual code [1][2].

Managed BO Implementation:

• The RAP framework automatically handles CRUD operations, allowing developers to focus on business logic[1].
• You can modify the save sequence for specific use cases, such as adding custom save procedures[3].

Unmanaged BO Implementation:

• Requires manual implementation of transactional logic in ABAP classes, offering full control over database operations and allowing integration of legacy code like BAPIs[2].
• This approach is suitable for integrating existing business logic and handling complex interactions[4].

For your need to adjust the read logic in cloud environments, both methods can be applied, but if more flexibility is needed, incorporating custom read logic with unmanaged implementation might be preferred. Using managed implementation with additional or unmanaged save options allows customization in standard interactions.

A hybrid approach leveraging managed BOs with unmanaged save can also be considered to balance agility with the need for specific customizations[1][3]."

If this response was helpful to you, please mark it accordingly. Thank you.    

[EgbertVenema]

Thanks for your response. It's still classic AI, somewhat about the subject, but ignoring parts of information. Based on this reply, in short the answer is yes; the unmanaged implementation is the only one providing me with custom read options. The unmanaged query is another option that I'm currently looking at, it might prove useful as well 🙂