RAP: Managed vs Unmanaged

[mvoros]

Hi everyone,

I am investigating an option of porting an application built with BOPF and oData service to RAP model. As the title suggests, I am trying to figure out which implementation mode to use. Ideally, I would like to stick to managed mode to avoid too much extra effort.

But the app has already some special requirements that I am not sure how to achieve with managed mode. One of them is soft delete (record gets flagged as deleted instead of actually removing it from DB). Another one is that we have a custom implementation of draft and merging is complicated. We allow users to work in parallel on the same object if they are not touching the same items (2nd level of the object hierarchy). Another one is to have a bit more complex selection queries that use subqueries.

Are these requirements achievable in managed mode? E.g. is there an option to provide a custom implementation for DELETE operation in managed mode? it does not seem to be the case.

I think these special requirements are achievable in unmanaged mode as in that case, we have much better control. But it all looks so custom and so much extra work for green field implementation. Another concern with unmanaged mode is an extensibility. If this is delivered as a product, how hard will it be for customers to enhance the solution?

My ideal solution would be to re-use as much as possible from managed mode and then adjust only parts that are really needed.

Anyone with some recommendations how to achieve these more complex requirements?

Thanks

[CarineTchoutouo · Accepted solution]

Hi Martin,

regarding your different application requirements.

REQ-1: "how to achieve with managed mode. One of them is soft delete (record gets flagged as deleted instead of actually removing it from DB)."
For this requirement, one of the following BO implementation types can be suggested:
1) managed BO with unmanaged save: The “soft delete” will have to be implemented in the unmanaged part of the save sequence.
2) managed BO: In this case, the generic delete operation will not be enabled in the behavior definition but instead an appropriate action will have to be specified and implemented to handle the "soft delete".

For both implementations, the result of the read operation will eventually have to be adjusted according to the application requirements. For example, by specifying an appropriate WHERE clause in the BO composition model (projection) or filtering the data appropriately in the relevant UI.

REQ-2: "custom implementation of draft "
The draft handling is fully managed by the RAP framework. No option for customizing the draft implementation is provided.

REQ-3: "work in parallel on the same object if they are not touching the same items (2nd level of the object hierarchy)"
This requirement is not supported, because only the exclusive draft is currently supported. The draft handling set an exclusive lock on the whole BO – i.e. the BO root node and all child nodes on the different hierarchy levels.

REQ-4: "Another one is to have a bit more complex selection queries that use subqueries."
This requirement is unclear. More information is needed.

Hope this helps.

Kind regards,
Carine

[mvoros · Accepted solution]

Hi,

thanks for your reply. Regarding requirement #4. This is my use case. I have calendar activities that start in one calendar week and end in another. I added virtual property that calculates value as <start week>...<end week>. For example an activity may start week 202140 and end in week 202145 (6 weeks duration). For good usability, the users can simply specify filter anything that runs in a specific week e.g. 202142. The solution should return the example as it runs in this week.

How this is implement in the old ABAP stack is that I have a CDS view that contains all calendar weeks per activity. When user specifies the filter, the WHERE statement is adjusted to convert original filter condition to subquery. RAP API seems to be really limited even if custom query is implemented. It does not return a tree of filter conditions.

Thanks

[TiagoAlmeida · Accepted solution]

The links are broken. Can you please check? Thanks in advance

[Jelena_Perfiljeva]

This is an excellent question and it's sad there has been no response at all for months.

My semi-educated opinion is that unless you're doing something brand new and very straight-forward, you can forget about managed scenario. For reference, below is a slide from openSAP RAP course that sort of confirms this.

I do not know if SAP has plans to expand this but then again, more enhancements in managed option would just turn it into unmanaged one, which would defeat the purpose.

It would be great if there was more "best practice" type of guidance available for RAP. There is a lot of information on it (or at least it seems this way) but personally, I'd love to have some simple IF... THEN... instructions. And I also would like to understand more about extensibility potential.

andre.fischer carine.tchoutouodjomo

[mvoros]

Hi,

thanks for you comment. But I was trying to prototype a brand new application or actually re-implement already existing application using RAP starting from scratch. The ideal solution would be more granular options to have custom implementation only when necessary (e.g. custom delete handler).

In general, RAP and whole ABAP PaaS seems to be at this moment not mature enough for custom app development. I haven't seen any solution from SAP delivered on top of this runtime. If somebody has an example of solution delivered on top of ABAP PaaS, it would be nice to know it. It's hard for me to believe that ABAP PaaS will be able to compete with other more open platforms long term (e.g. SAP CAP) for case of building a custom solution what SAP calls Industry cloud.

[Jelena_Perfiljeva]

martin.voros

Sorry, I assumed that we were talking about on-premise, since you've mentioned previous BOPF development. RAP can be used both on-premise and in Cloud, but I can't speak for the cloud options.

SAP does use RAP for new development. They've been bragging about creating new Sales Order app (VA01 replacement) using RAP and that this model will be used in general, going forward. Not sure what exactly you're referring to as "custom app development" but at least on-premise, RAP is mature enough right now for the customers to use from S/4 HANA 2020 onwards.

To be honest, I'm confused by your last sentence... SAP CAP = SAP Cloud Application Programing model, it's framework, not a platform. ABAP PaaS is an old project name, it's now called SAP BTP ABAP Environment. These are not the competing items. I think you might want to get more updated information on this.

[mvoros]

Hi,

sorry, I was not too clear. By custom development app I meant a development of a cloud native app that sits next to other SAP solutions. SAP calls this Industry Cloud at this moment. The whole task is to take an existing on premise solution and move it to cloud.

I can see RAP being used in S4/HANA and it works there. But I was mainly complaining about BTP ABAP Environment. As a side note, another confusing part is that I assumed that new features are delivered in order: BTP -> On premise. But that's not true. E.g. filtering by virtual element is available in on premise version but not in BTP version.

I know that CAP is just a framework but it's basically one of the options how to implement industry cloud solution. Hence it's competing with BTP ABAP environment. With industry cloud, SAP is saying your extensions to S4/HANA need to live outside to keep core clean. Here the developers have multiple options: use ABAP BTP environment, use CAP or actually use something completely outside of SAP. Here I am skeptical that ABAP will be able to compete with CAP as corresponding Node.js or Java ecosystem cannot be beaten. Released API of ABAP environment is so small so developers have to write lots of stuff that would be normally provided by standard library or old ABAP platform. I understand why they are slowly releasing API but at the end of the day, ABAP BTP is lacking severely comparing to alternatives.

And I know that they are working on embedded steampunk which brings us to full circle and make ABAP RAP as the only usable solution for that scenario.

[ravenclaw]

This is all good and well explained by carine.tchoutouodjomo. I am trying to wrap around my head into Unmanaged BOs. Is there any working example that will show case its me usage? All the learnings from SAP so far has been primarily focussed on Managed Business Objects(developing from ground zero). In most cases, big customers are still heavily invested on the advanced versions of S/4 HANA. In my case it is S/4 HANA 2021, with tons of custom developments. A lot of retrofit and use cases are difficult to fit into Managed scenarios and that's where I see heavy usage of unmanaged BOs. I beleive SAP should invest more use cases around Unmanaged BOs so that as their trusted partners we can really proof to our customer base the real value of unlocking the RAP Methodology, Thanks.

All the best,

Tanmoy

[Andre_Fischer]

Check out week 4 of the openSAP course CP13.

[Andre_Fischer]

And there is a sample implementation in GitHub

SAP-samples/abap-platform-refscen-flight: SFlight is back! This is the Flight Reference Scenario for...

[Andre_Fischer]

However I would recommend to post such requirements in addition as a question rather than adding it only as a comment to an existing question.