Hot deployment in Intershop Enfinity Suite

19.06.2012.

Intershop e-commerce platform (previously known as Enfinity Suite) is frequently used for hosting more than one online sales channels. Such multi-site (or multi-tennant) feature enables better utilization of the hosting capacity by greatly reducing the costs of hardware and software in the enterprise environment. Such multi-site capability has unfortunate side-effect of making the needed upgrades and changes of the system much more frequent than in environments that have a separate infrastructure for each sales channel. Therefore required restarts of the multi-tennant system cause downtimes for all sales channels which can carry significant operational costs.

Problem statement

Large Intershop instance can easily host several sales channels, where each channel is typically upgraded quite often. If we assume just ten different channels and one upgrade or bugfix per month that leads to 120 deployments per year. For production environments, even a simple bugfix requiring restart can easily reach one hour of downtime (and larger deployments typically require more). But even 120 hours of downtime per year due to various restarts can really affect targeted system availability. In addition, such actions are typically scheduled out of the normal business hours, which puts system administrators into ungrateful position requiring frequent nightly deployments. In such environment the hot deployment capability comes to rescue.

Hot deployment

The term hot deployment implies deploying your code without having your application server restarted. The main purpose of this code deployment technique is to avoid application downtime, denial of access to application or possible slower application response due to increased number of requests on other nodes in a cluster.
Usually, the deployment process involves copying the compiled and built code from the source to the target point and restarting application servers. During this period the application is unavailable or, in case having more than one application server, the page load time may be increased depending on a number of application requests and the system architecture. As a result of these actions the user experience is affected. To avoid such cases, deployments are usually organized in the nightly actions, which require an extra effort of all the parties involved in the process. Every restart also causes disruption of all user sessions that are currently in place and also gives gaps in the document sequence numbers since the sequence numbers are cached. Therefore this article (with related articles for technical subsystems) discusses Intershop Enfinity Suite architecture and the actions that can be taken to perform hot deployment actions. Such actions should be considered for small scale deployments: changes that affect limited number of resources and do not represent system wide changes.

Possibilities of hot deployment in Intershop

For implementation of e-Commerce channels, Intershop uses Java based framework that is functionally similar to JEE web application model. It features the following technical layers to provide user response:

Templates are pieces of code that generate HTML presentation sent to the user’s browser. They are pieces of HTML code enhanced with presentation logic implemented in custom ISML (InterShop Markup Language). ISML templates are conceptually similar to Java Servlet Pages, but include functionalities specific to e-Commerce features provided by the Intershop platform. As such, hot deployment of ISML templates shares similarities with the hot deployment of JSP files in JEE web applications.
Pipelines are the “controllers” of the request processing, that are similar to Java servlets (or Struts actions, for example). There is one major difference – pipelines are not written/programmed in Java. They are designed using visual tools and saved in XML. Such model enables interesting features not available in standard web applications. One example is hot deployment by reloading the XML file. The other is possibility to debug a processing pipeline without a need to restart a server in the “debug” mode, which enables administrators and developers to troubleshoot problems even in the production environment.
Pipelets are standard Java classes loaded and executed through the ordinary java class loaders. Although they are most problematic from the aspect of hot deployment, even they can be hot-deployed in certain cases.

Similar to other java based application servers and servlet containers, Enfinity Suite supports hot deployment of templates and pipelines through configuration setup. Unfortunately this feature is generally enabled only in development and test environments because it requires the system to check the source files before every access. This affects system performance significantly by increasing disk I/O. Thus the related articles discuss the techniques when it is possible to hot-deploy even in cases where source checking is disabled (typical and recommended production setting).

OptimIT