on 2021 Oct 02 3:53 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
User | Count |
---|---|
62 | |
12 | |
7 | |
7 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.