10 Key points for designing robust NetWeaver OData services

Based on my experience in modelling and implementing NetWeaver OData services, I have felt that one should always keep in mind below pointers while undertaking the realization of any OData service.

Based on the catered use cases, Service design and implementation should scrutinize the below points –

1. How is the exception handling done.

Technical exceptions should be used for those methods which have been decided not to be implemented but some how the UI call invokes them & Business exceptions for Business Layer validation failures. We should create custom exception classes inheriting from the CX_DYNAMIC_CHECK and CX_STATIC_CHECK classes.

2.How is data layering done and separation of concerns done.

We should always deliver decoupled applications which interact with each other via a common agreed upon interface. Generally, a delegator or process manager class is used to funnel the UI calls which invokes OData methods to proper Business Layer classes. After that BL classes interact with the Database Layer classes.

3. Any explicit commit work, auth checks, changeset handling?

Special care should be taken to avoid any explicit commit work statement in changesets. Also all/none or partial processing should be designed after understanding the use case at hand. Generally, authorization checks are implemented in the constructor of the Process Manager or Delegator.

4. Using which oData parameters is the data extracted – latest or obsolete ones?

Always latest non-obsolete parameters should be used for data extraction and processing as they offer extensive capabilities and are getting improved continuously.

5.Modelling and supported operations?

Generally there are multiple approaches to achieve any functionality and best fit design is one which keeps in mind performance and message  communication.

Example – When reading multilevel parent child data instead of relying on the default framework handling,  redefinition of *Expanded_Entity/EntitySet should be done, In case of multiple operations messages should be communicated once for all to UI, etc.

6. Static code or dynamic code for navigations.

The implementation of Expanded Entity and Expanded Entityset should be generic to only trigger the associated data fetch which is invoked from UI at the current instance of time.

7. Adequate validations at oData and backend layers

Always and I mean always validations should be put in backend layers irrespective of the fact that whether UI layer has any. Also only necessary data should only be passed back to UI from backend via OData layers and nothing extra should be transmitted.

8. ETags and locks?

Based on implemented use cases and criticality of business process, only ETags (optimistic concurrency control), only SAP Locks (pessimistic concurrency control) or both should be used. Design should be evaluated from this perspective as well.

9. Performance and data size which is passed to backend.

The five golden principles aka five performance guidelines hold true here.

10. Don’t pass unnecessary parameters & check naming convention.

Care should be taken that any irrelevant parameters should not be modelled. The less the number of parameters the more likely the app is designed for specific role keeping the design guideline of 3-3-1 in mind. Any system parameters should never ever be passed from UI to backend.

Please comment if you need any detailed discussion on any of these. Also, would love to add your pointers to this collated list. Feedback as always is most welcome.