In the preceding part of this blog series, I introduced the client imperative: The client decides if it is willing to accept data from the SAP HANA secondary database, which may have a few seconds of delay. Let me now have a more detailed look at this.
1. Clients that are analytical by nature
There are quite a few clients that are analytical by nature such as SAP Analysis for Office Excel and SAP Design Studio.
The clients may act standalone, or as embedded parts in other UIs, such as an analytical grid embedded into an ABAP Web Dynpro UI. They access the SAP S/4HANA ABAP server using the INA protocol or other protocols. Within the S/4HANA ABAP server the receiving component for analytical calls initiated by these clients is the so called SAP Analytical Engine (AE).
Here we simply decided that those UIs which are analytical by nature and address the SAP Analytical Engine in the S/4HANA ABAP server are allowed to read from a secondary SAP HANA database by default.
1.2 Clients that are analytical by nature: Design time
There is no specific setting required at design time with these clients.
1.3 Clients that are analytical by nature: Runtime
At runtime, the SAP Analytical Engine as part of the ABAP server adds the suitable database hints when the call was initiated by such a client.
The hint is not added once the AE recognizes that the call is not for a purely retrospective analytical scenario, but for a planning scenario.
So for a client that is analytical by nature, the refined sequence diagram I already showed in the preceding blog post looks as follows:
2. SAP Fiori Apps Clients
SAP Fiori App clients can have both, transactional as well as analytic parts. Only the analytical parts shall be candidates to get enabled to read data from a secondary SAP HANA database.
So in this case, the nature of the client is not a criterion. Instead, the client has to tell for each call it makes to the ABAP server at runtime if it is willing to accept slightly delayed data. The maximum age it accepts must
- Be defined at design time
- Be sent with the call to the backend at runtime
2.1 SAP Fiori App Clients: Design time
To enable a SAP Fiori app to read data from a secondary SAP HANA database, it must be defined as part of the app that the client shall add the information to the requests it sends to the backend that it accepts data that is not older than a specified duration.
This definition must be done at Design Time, and this is what I call “enabling the App for the Active/Active (read enabled) Configuration”.
2.1.1 SAP Fiori Apps that are based on SAP SMART business
For SAP Fiori apps that are based on SAP Smart Business, we keep it simple: In the configuration of an SAP Smart Business tile there is already a setting to configure acceptance of delayed data. It is the field called “cache duration”. This controls on the one hand a frontend near-cache of the last tile value, and it now also controls what is sent as accepted maximum data age to the backend at runtime. If one defines a cache-duration of 1 minute, requests may be served by reading from the secondary SAP HANA database at runtime. If one defines more than one minute, the request may also be served by reading data from other sources such as caches.
Why 1 minute, if we expect that the real delay on a secondary SAP HANA database will be in the order or magnitude of seconds? Well, we wanted to keep the tile configuration simple and not offer a value in seconds in addition.
Find more information on the configuration of SAP Smart Business tiles here.
2.1.2 SAP Fiori Apps that are not based on SAP SMART business
For SAP Fiori apps that are not based on SAP Smart Business, the respective setting is done in the app descriptor. The app descriptor is a manifest.json file, which – among other information – defines which ODATA services are called by the app.
If you build your own app, and want to enable the analytical part of it to read from a secondary SAP HANA database, you have to add the maxAge to the respective data source section in the manifest.
Note that you should take care not to use the same dataSources section for analytical and transactional parts of your application (because you selectively want to enable the analytical part). If this is not possible due to technical limitations, do not enter a maxAge value.
2.1.3 SAP Fiori App Clients: Runtime
SAP Fiori clients use the ODATA protocol based on http to communicate with the S/4HANA ABAP backend. Fortunately, http offers standard ways by which the client can communicate to the server that it is willing to accept potentially delayed data. This is expressed in http header fields in the http request. In addition, http header fields in the http response can transport valuable information about the real data age back to the client. The relevant header fields are specified in the Internet standard: Hypertext Transfer Protocol (HTTP/1.1): Caching.
You may ask why we at SAP decided to use cache-related header fields for addressing a secondary HANA database. Of course this would be the method of choice to address caches, and we see great benefit to subsume any provider that may provide delayed data under that term. Like when browsing the internet, the performance can be optimized by the client telling the server which age it is willing to accept, and the client does this by adding the http header field ‘cache-control’ with the value ‘max-age = <value in seconds>’. For the client, it should not make a difference where the data comes from as soon as its requested max-age is respected.
So for a SAP Fiori app client for which an accepted max-age of 59 seconds is configured, I can add more details to the sequence diagram I already showed in the preceding blog post:
No comments:
Post a Comment