A Programming Model for Business Applications – (6) Summary and Outlook
We have no reached almost the end of the journey through the proposal for a programming model for business applications. The first five parts are:
A Programming Model for Business Applications (1): Assumptions, Building Blocks, and Example App
A Programming Model for Business Applications (2): Implementing the Entity Model with CDS
A Programming Model for Business Applications (3): Calculated Elements and Properties
A Programming Model for Business Applications (4) Service Adaptation and UI (Read Service)
A Programming Model for Business Applications (5) Write Service: Business Object, Service Adaptation, and UI
In this document I try to summarize some points that I found important and provide an outlook and ideas for topics I did not cover in detail in the previous documents.
Let me point out that the proposals discussed in this series are not the only solution for a programming model. First, the solution depends on the assumptions (first part of the series). If you have different assumptions for your application, you might come to a different solution.
Let me summarize the basic ideas behind the programming model discussed in the series:
On the server side, we introduced two layers, the service adaptation layer and the business object layer.
- The business object layer covers re-use functionality (functionality that is potentially needed in multiple UIs/reports/forms and service interfaces). It consists of the object persistency and read/write functionality implemented in (DB) views and coding.
- The service adaptation layer covers UI/service-specific functionality. It provides a service interface (e.g. in OData format) that is very close to the consumers need. For reasons of security, performance and data consistency, we assume that this layer is implemented on the server as (DB) views and coding.
In my blog series I was not able to work out all topics that are required for a complete programming mode in full detail. In the remainder of the document, I want to share some ideas on how the fill these gaps.
Business logic does not only consists of create, update, delete operations, which are discussed in part 5), but you might also provide business logic encapsulated in actions (functions, methods) that expose a special purpose interface (input and output parameters). For actions, CDS/XSODATA does not offer special support. But you can simply define a dummy table that contains the in and out parameters of the action and expose the create operation via XSODATA and implement the action in a XSJSLIB file. (Note: in the CDS file, you can use the annocation “@Catalog.tableType : #GLOBAL_TEMPORARY” to create the table as global temporary table, because it should persist no data).
During changing data, user must be provided with comprehensive and user-friendly system messages (errors, warning, and success messages). The standard HANA XS OData implementation of does not foresee a dedicated channel for system messages. My idea for a pragmatic solution would be to use a string field in the CDS view (“MessageContainer”, of type String) and send the messages from the application to the frontend using this field. For managing the messages centrally, I would recommend a re-use class.
The standard HANA XS OData implementation supports OData batch requests. HANA XS calls the service implementations request by request. This means, the standard works fine, if the business logic of the different data sets does not depend on each other. The following example shows the limits of this approach: A sales order shall be relevant for approval, when a configured total amount is exceeded. So when a sales order is created or changed, the amounts have to be calculated on item level and the approval relevance has to be calculated on header level afterwards. This area would be a topic for a next blog.