The SAP Netweaver Cloud Platform is an excellent choice for building applications that should be available outside of your premises for e.g. your customers, suppliers or employees. Instead of having to add a new layer of application servers, reverse proxies and networking/firewall rules, to expose these new applications to the internet, you could also just start building on the SAP Netweaver Cloud platform.
In many scenario's a connection to your back-end, to both retrieve and update information from e.g. you ERP system is required though. The cloud connector comes in very handy here, as it allows to do this in a secure way.
Reduce the number of hits on your back-end
When you use the cloud connector, you need to be aware of the fact that every time someone knocks on the doors of your application, this will also cause a hit on your ERP system. Especially when the application is a huge success and many users are using it intensively, the number of hits on your ERP system may also increase. On top of that, the back-end system is a "remote" system for a cloud application, so there will always be some lag.
To keep the number of hits within proportions it may be wise to think about caching at an early stage of the development process, so that it will be possible to scale the application quickly when necessary. Especially relatively static information such as e.g. a department lists are very easily cacheable.
The easiest way to achieve caching is to implement http-caching at the client-side. By inserting expiry-information in the header of a http-response, the browser will not hit the server again if the cached data is still valid.
Although this may work in scenario's in which a limited number of clients generate a lot of traffic, it will be less beneficial in a scenario in which a large number of clients generate a limited amount of traffic. In that scenario it will be better to implement caching within the application to prevent hits on your back-end.
Caching from within your cloud application
When multiple clients need the same information, such as e.g. a department list, it may be a good idea to store the department list somewhere in the application, instead of hitting the back-end system with the same request multiple times. What comes to mind is e.g. a hash-map that is stored in a thread-local or static application-level object. If it's just a department list, this is probably not such a bad idea, but if the department lists contains multiple attributes about the department as well, this may hit the memory quite badly though. As a department list may also grow in the future, it may be wise to already take precautions and make sure the cache isn't just a fixed hash map, but a real cache that drops records as soon as too much memory is consumed.
In previous web-based projects, memcached was always my cache of choice, because of it scaling and clustering capabilities. However, memcached is not a java application and can't be run on the SAP Netweaver Cloud Platform. To run a cache on the SAP's Java platform, a Java cache is needed. In the Java world Ehcache is a widely used cache library that can be integrated with your own application. If the need arises if can scale up to a distributed cache, just like memcached.
The nice thing about ehCache as compared to a fixed hash map is the fact that it is highly configurable and allows you to e.g. set the maximum number of elements to keep in cache and how housekeeping should be done, i.e. what cache entry should be removed first when the cache is full.
To use Ehcache, you will have to add some code to the methods that call your back-end:
public V readSomeData(K key)
{
Element element;
if ((element = cache.get(key)) != null) {
return element.getValue();
}
if (value = readDataFromBackEnd(key)) != null) {
cache.put(new Element(key, value));
}
return value;
}When the method is launched, it will try to search for the data in cache. And if it's not in cache, it will call the back-end to retrieve the data from there. Once the back-end is returning data, that data is store in cache for future use.
Eager loading
In the scenario of a department list, it may make sense not to wait for a client to retrieve information about a single department and fill the cache lazily, but it may make more sense to pull all departments from the back-end and fill the cache in a more eager way. R/3 usually processes one SELECT resulting in multiple records more efficient than separate SELECT SINGLE calls for each individual record. Ehcache also has a bulk load mode, and is able to process cache writes much faster in this mode.
When cache-refreshes are scheduled to update the cache when it is about to expire, future request would be served straight from cache, which dramatically increases performance and lowers the number of hits on the back-end.
Code cleansing
Complex applications have several different methods to retrieve various information from the back-end. All these methods would need to be modified to implement caching for these methods, while the code pattern that needs to be inserted is almost the same each time. SpringSource has seen that, and has implemented a nice annotation for this, to make your code look better and cleaner.
When you are using Spring and the built-in ehCache bridge, you can use the @cacheable annotation instead of adding logic in the top of a method to check if the resulting value can be retrieved from cache. Please find an example below:
@Cacheable("elements")
public V readSomeData(K key)
{
return readDataFromBackEnd(key);
}This example actually does exactly the same as the previous example, but the @Cacheable annotation now takes care of trying to pull the resulting value from cache and pushing it in there when data is pulled from the back-end.
A nice tutorial on how to use this Spring annotation can be found here.
When you are buildling an application, using SAP UI5 as front-end, you will probably be building many REST/JSON services. In that case this tutorial may give you a head-start, applying CXF (to build REST services) and the Spring version of Ehcache to cache back-end data.
Oh, and if you're going down the path of using the Cacheable annotation from the Spring framework, I highly recommend to Mavenize your project.
Available memory on SAP Netweaver Cloud Platform
The amount of memory assigned to a virtual machine is not unlimited, and to find the optimal cache sizes it may be necessary to do "the math". Please find a number of key-values/rules-of-thumb below, based on the so-called "Lite" VM:
- Default number of threads: 200
- Total amount of memory available per VM: 2GB
- Amount of memory available for an application: ~1GB, the other 1GB is consumed by your application, the infrastructure (perm size, server itself, your application, SAP UI 5 etc.)
- Amount of memory available per thread: ~1GB / 200 = ~5MB
- SAP Managed Tags:
4 Comments
