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 Adaptatio...
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.
Summary
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.
The programming model is open for code pushdown. This means that code can be pushed down into the HANA database engines. On the Read side, this is already the case – all data is read by database views, so that complete work for optimizing the data access is left to the powerful HANA engines. On the Write side, the service adaptation is completely written in JavaScript. I think that this is not a problem, because here I do not expect expensive data operations. The business object interface is also in JavaScript. This is important to be able to always have the choice to write the real business logic (validations and determination) in JavaScript or in SQLScript. You can use SQLScript whenever this leads to performance improvements (in case of data-intensive operations). However, some logic can only be written in JavaScript (e.g. process integration such as web services calls, e-mail); and I think that many developers will feel more comfortable in JavaScript.
Outlook
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.
