When you start with HANA Cloud Platform, you can find a vast amount of documentation, tutorials, online trainings. This information makes it easy to get your first application up and running. However, during our last month in developing on HCP, we found that there is a gap between the examples and a real-life application. This is, of course not a miracle, and, of course, when you start to build a real-life application, you have to think about your programming model and application architecture. In this blog series, I would like to present a programming model that fits business applications with the assumptions listed below.
The programming model that I discus in this blog is “implementation-agnostic”. But, to make it more tangible and discuss it based on a concrete example, I implement the model using the SAP HANA native development approach using HANA CDS defining the data models and HANA XS (XS OData and XS JavaScript) implementing the server side. For the UI side, I implement a small SAP UI5 mobile UI.
The programming model described in this document is based on the following application characteristics that apply for enterprise business applications.
General assumptions:
- UIs / external web services are not one-to-one images of the data stored in the database. The data mode stored in the
database may serve as base for multiple UIs / external web services. As a consequence, a data transformation from the database tables to the UI and vice versa has to be performed. - Security (restriction of data elements and data records) and consistency enforcement must be implemented on the server, not only on the UI client.
- (a) Application logic is performed on the server (not in the UI client). (b) Application logic can be written in SQL (“code pushdown”) or in a JavaScript. (c) Some application logic may also run redundantly on the UI client to provide early feedback to the user.
- Multiple entities can be changed within a roundtrip. As a consequence, entities provide a common transaction (phase) model. Application logic must be executed as a “bundle” when multiple instances are changed.
Performance Assumtions - Roundtrips between UI client and server are an expensive resource (~ 100 ms). As a consequence, data are written/read
with one roundtrip. - Read/write from/to the database to programming language container is expensive (~ 1 ms) in comparison to a read/write within the programming language (<< 1 microsecs).
Assumptions on state and concurrency - Stateless communication between frontend (browser) and server: The services provided to clients are stateless, in a sense that the runtime maintains no application server state. If an application needs to store state, for example an intermediate result of a multi-step interaction,
the state information needs to be stored in the database in a draft version or on the client. - Database performs COMMITED READs (only committed data are read, except from the transaction that actually changes the data, in contrast to a DIRTY READ).
- (a) During the transaction, locks are kept on database level. (b) Concurrency handling is (optionally) implemented using a delta detection mechanism (eTags). (Locking on application level is not required)
Assumptions 1 to 4 state that application logic has to be performed on the server side. This
application logic consists of:
- Access control
- for elements: restrict access to elements from the entity (example: expose columns for a public address book from employee/address entities)
- for instances: restrict instances from an entity (objects that I am allowed to see)
- Control of public/private elements, decoupling, layering
- Calculated elements – elements that are not persisted in the database but calculated at request
- Format transformation (date/time, alphanum, …) and conversions (currency, quantity, time/calendar, …)
- Data joins and unions
- Merge data from different entities, in particular read information that is managed in master or configuration data entities,
- Including data filtering of language-dependent texts, filtering of data that is relevant for a particular date/time, a particular role, specialization/generalization, etc.
- Responsibility determination (objects I am responsible for in a particular role, for example “my”, “myTeam”, …)
- Application Logic: Application logic can be classified as
- Property logic: Property logic provides information whether data can be updated, are mandatory, etc. depending on the lifecycle of an object.
- Validation logic: Validations implement check logic that evaluates the data consistency. Validation logic can add messages (errors, warning, info, success) to a message service (Example: do not save an order w/o valid account information). In addition, they can return an indication that the
object is in a critical state and that the transaction cannot be saved (in order to prevent loss of data, violate legal or business constraints, etc.) - Determination logic: HANA technology calls for the implementation of element calculations as “on the fly” calculations of non-persisted “view” elements with database means (SQL expression, “code pushdown”) wherever possible. However, the advent of HANA technology does not influence legal or business requirements, so there are still use cases where element calculations have to be persisted in the database.
Examples are:- The element calculation is only a default value and can be overwritten by the user, so the result must be persisted. (Example: New account: based on the input of the address and other properties, the sales territory, sales organization, and responsible is determined. These data can be overwritten by a user.)
- The result of the calculation is based on data that may change over time, in other words, the calculation is time dependent, and the element must represent the result of calculation at this point in time and therefore be persisted.
- Performance considerations: Calculations are time-consuming and so they are done once during change of the business object instead of repeating them every time the entity is read.
- Action logic: Action logic is called from a UI, external service or background process and typically starts a particular operation or process step.
Figure 1: Service Adaptation Layer and Business Object Layer
As mentioned before, I will show an example implementation using the SAP HANA native development approach with HANA CDS for defining the data models and HANA XS (XS OData and XS JavaScript) for implementing the server side. For the UI side, I implement a simple SAP UI5 mobile UI (split app).
So, on the server side, the boxes in Figure 1 correspond with the following artifacts:
| Box in Figure 1 | Implementation in XS |
|---|---|
| Protocol Handler (e.g. OData) | XS OData Service |
| Service Adaptation: Read service | Database View (CDS) |
| Service Adaptation: CUD Service | JavaScript Library (Exit implementation of the XS OData Service) |
| BO: BO Read | Database View (CDS) |
| BO: Table | Database Table (CDS) |
| BO: CUD Services | JavaScript Library |
| BO: Business Logic | JavaScript Library / SQL procedure |
At runtime the service provider simply interprets the client request (for example the filter, order clause, etc.), reads the data from the database view and converts the result into the protocol format (for example OData). In Figure 1, the boxes labeled with “Read service” and “BO Read” are implemented as database views.
For a write request, the data transformation has to be implemented. In Figure 1, the boxes labeled with “CUD services” and “CUD / Action API” and “Business Logic” are implemented in a programming language (for example JavaScript), boxes “Business Logic (SQL)” are implemented with database means (for example SQL Script).
Figure 2: Entity model of a Sales Application
Figure 2 shows the entity model of a sales application. It is simplified in comparison to the models that are used in the SAP CRM or SAP Business ByDesign, but it contains examples for real life “complexity”, such as “realistic” calculated fields and time dependency (here for a customer’s address). We will use this example for a discussion of the assumptions and building blocks introduced earlier and for implementation in the following posts.
The (simplified) entity model of the Business Partner is shown in the middle of the Figure. It consists of a business partner business object with 3 entities (Business Partner “main” or “root” entity, a Customer entity that stores customer-specific data, and an Address Information entity that holds the reference to addresses (time-, type- and role-dependent). We ignore the fact that the business partner’s name and other common elements may change over time and model them in the Business Partner “header” entity. The sub-entities Customer and Address Information show patterns that can be repeated for other business partners, for example Empoyee, Supplier, Contact, etc. and other business partner details, for example time-dependent Name and Identification, Bank Details, Business Partner Relationship, and so on.
The Address business object stores an address as a re-usable entity.An address can be used (referenced) from multiple business documents. This, however, means that an address cannot be changed once it was used in a business document. Instead a new address is created when a user changes an address on the UI. Let us have a look at the following use cases and their representation in the entity model:
- In the Customer master data UI, a user can enter various addresses for a customer, for example a (default) mail address, a ship-to and a bill-to address. These addresses are represented by three instances of the Address entity and three instances in the Address Information entity
- In the Customer master data UI, a user can change an address for a specific date in the future (relocation of the customer). This is represented by two instances of the Address entity and two instances in the Address Information entity with adjacent validity periods.
- In a Sales Order UI, the address information is normally automatically determined from the Customer master data, and persisted in the Party entity of the Sales Order business object. However a user may change the delivery address for a particular sales order, because the products shall be sent to the vacation address of the customer. This is represented by a new instance of the Address entity, the reference to this address is stored in the sales order Party entity.
In the simplified model, I have modelled the address as a flat structure. In reality, many address components (for example phone numbers) may have multiple records, so you would model them as separate entities. The postal address may be stored in multiple script codes (Latin, Chinese, …) to support global business.
The Sales Territory business object stores the assignment of customers to sales territories, which are used to manage access and responsibilities for sales operation. In our example application, a sales rep should be allowed to manage only sales orders for customer in territories he/she is assigned to.
The Sales Order business object consists of three entities, the Sales Order (header information), the Item entity and the Party entity. I think that header and item is self-explaining to everybody who bought something. The party is introduced as an entity to store all involved parties (for example account, ship-to party, sales representative) in a normalized way. The Party entity allows to flexibly add additional parties, for example a service performer when it comes to selling services.
Based on the entity model, we will discuss two UIs in the next blog series:
- A very simple special-purpose UI that allows the creation of a new private prospect (for example as a mobile UI as a part of a fair application) (Wireframe, Figure 3).
- A UI for a sales representative for managing sales orders of “his/her” accounts and territories (SAP UI5 application, screenshot see Figure 4)
Figure 3
Figure 4
The next blog in this series shows the implementation of the entity model using HANA CDS: go to A Programming Model for Business Applications (2): Implementing the Entity Model with CDS.
- SAP Managed Tags:
5 Comments
