Building on the blog posted last week (/blogs/2011/09/12/applications-applications-applications%e2%80%a6-find-out-what-netscaler-does-special-about-them/) sharing history and current state of Application Templates in NetScaler, this one focuses on making you understand the simplified workflow for deploying Application Templates.

The workflow for Application Templates takes you through self defined steps which logically flows through the system. Here is a quick look through the involved workflow and understanding key functionalities and advantages at every step.

Step 1: Getting the required template from Citrix community site. This is crucial step where you need to understand the requirements correctly and identify right template for your Application deployment. We publish the tested and validated Application Templates on community site and keep updating them with new changes coming in. Every Template is also available for various releases and different builds. You need to select the correct release and build otherwise you may not be able to import the Template or imported one does not work correctly.

 

Step 2: Importing Template on NetScaler is the immediate step once you download the required files. While importing the Templates you would not be asked for any user defined changes unless dynamic rules are defined to customize the Template while uploading it. Dynamic behavior can be achieved with Variable definition while exporting the template. If a Variable was defined then while importing template you are asked to specify variable value for your deployment.

 

Step 3: The public endpoint is the IP/domain where all clients connect to and this is the IP address on NetScaler which hosts the Application on behalf of backend servers. The data path processing goes through this channel and this is the IP address visible to all the clients connecting to this Application. In background the public endpoint is a Content Switching vserver which switches the content delivery path through application units based on defined rules.

 

Step 4: At this step you align public endpoint to actual backend resources available in your internal deployment which are hosting the Application. There could be just 1 server or multiple servers hosting the Application in backend. You can define the content hosted by backend servers in similar way how Application Units are defined in the Template. With that you will be able to segregate and route traffic more efficiently through various Application Units talking to respective servers. You can have more than 1 backend server tied to the AppUnit based on the kind and nature of Application traffic requirement.

 

Step 5: The overall Template setup and configuration is done keeping most of the common use cases in mind.  Thus policies and actions configured are for generic use cases and in practical every deployment is different from any other. Thus in most cases you may want to fine tune or customize the existing configuration to suit your environment. In cases where a configuration can adversely affect any deployment, we do not include it in core Template. This helps by ensuring that default Template works as you import it on NetScaler and beyond that it is all about tuning it to your requirements. Lots of layer 7 intelligence and functionality is embedded in how the policies and actions are defined and processed in which order.

 

Step 6: Go Live!!!

With this simplified workflow you are ready to use Application Templates in your application environment.