XLiRAD AppServer Advanced Features

This document describes all of the advanced features of the XLiRAD AppServer that provide services for custom programmatic extensions, data replication, server arrays, work transfers among servers, etc.  These features provide the enterprise with the ability to customize XLiRAD to fit its needs for flexibility, managed workflow, and scalability.

Automated Templates

What is an Automated Template?

Automated Templates are templates created with the client tool, TemplateMaker, that are registered on the server for automatic execution based on a specified interval of time in minutes.  The purpose of automated templates is up to the XLiRAD administrator, but a few normal purposes are the following: batch jobs for credit card billing, regular cleaning of database tables, and scheduled emailing.

Scheduling Automated Templates

Select the "Automated Templates" menu item under the "Configuration" menu.  When the dialog box appears, a two column table will show up with all of the XLiRAD templates in the left column and their corresponding automation interval in minutes in the right column.  The number -1 in the right column indicates that this template is not scheduled for automation.  99% of all developer templates do not require automation and will have a -1 in the right column.   To schedule a template for automation, remove the -1 and enter a number in minutes in its place.  Pressing the "Submit" button will update the list of automated templates and put them in their proper location in the scheduling thread.

XLiRAD AppServer Arrays

What is an XLiRAD AppServer Array?

An XLiRAD array exists when the XLiRAD customer has bought more than one license and is running multiple copies on different machines.  XLiRAD Servers do not inherently know about each other; the XLiRAD administrator must create a knowledge array in each server to make it aware of its peers.

What are the Benefits of the Array?

By creating an array of servers aware of each other, they can work in tandem.  XLiRAD arrays can be used for load balancing much in the same way that multiple webservers and backend databases do.  In a live array of XLiRAD servers all fielding requests, they can pass requests to each other to create replication of data with multiple redundant data sources that do not have inherent replication built in.  A simple two box XLiRAD array with one live box and one box moderating a backup database can keep a perfectly synchronized backup box ready to be moved to the front lines in case of system failure.  Another example of a two box array is the development box, live box pair where developers only work on the development box.  The XLiRAD administrator can use the array to move work from the development box to the live box after testing is completed.  The arrays are tightly guarded as well; in order to create an array, the XLiRAD administrator must know the administrative password of the peer server.

Creating the Array

The creation of an array must be done on each server that needs to know about the others.  In some cases, like the development box, live box scenario, only the development box needs to pass work to the live box, and therefore, only the development box needs to have the array configured.  In summation, a server that needs to pass data or work needs to have the array configured; a server acting only as a receiver does not need an array configured.  To create the array, select the "Remote Server Array" menu item under the "Configuration" menu.   When the dialog appears, you will see a table of remote servers which initially will be empty.  To add a line to the table, press the "Register New Server" button.  Enter the remote server's location, XLiRAD port, and XLiRAD administrative password into the new line.  *Be sure to press "return" after entering the password to make sure that it is registered properly.  Enter as many servers as you need to configure and then press the "Test Array" button to ping the remote servers and validate that they are online, ready for requests, and that the password specified was correct.  With the server properly configured, press the "Submit" button to register your changes.

Testing the Array at Conception and Startup

As mentioned in the previous section, be sure to press the "Test Array" button before submitting your changes to make absolutely sure that the array is configured properly and working.  When the XLiRAD server is restarted, it will automatically ping the members of its remote array and will display the results in the XLiRAD display window if it is enabled.  This allows the administrator to view the status of the array all from one server.  If an error message is reported pinging a member of the array, the administrator should check the target server to make sure that it is running properly.

Replication

What is Replication?

Replication is the real-time backup of data stored in the database to an alternate store.

What are the Benefits of Replication?

Replication provides data protection and synchronization at all times.   In case of failure of the primary data store, the secondary backup store can be brought live to immediately service requests.  This prevents long periods of downtime after hardware or software failure.  Replication can also be used to keep data in synchronization amongst multiple databases fielding requests from the web at the same time in a server cluster.  The requests going through one XLiRAD server are mirrored to the others in the array which in turn relay them to their corresponding database.   XLiRAD replication is done in a real-time, per request basis to make absolutely sure that data is never lost and that the data sources are synchronized.  Replication does add extra load to the XLiRAD servers in the Replication Array.  XLiRAD replication provides one last major benefit: replication across different databases.   With the proper crafting of SQL Statements, for example, a live, high-performance database can be replicated to a slower, more reliable database as a backup.  This allows for maximum performance for the web clients and maximum data protection at the same time.

Configuring Replication by Group

In XLiRAD, replication is done on a group by group basis.  The administrator can choose to replicate some groups' data and not others.  Also, the groups in replication do not need to be replicated to the same members of the XLiRAD Server Array.  Group A can be replicated to one server and Group B can be replicated to a different server.   To access the replication configuration, select the "Replication" menu item under the "Duplication" menu.  The dialog box will show all of the XLiRAD groups in a ComboBox with a list of their targets and available targets below.  As the administrator selects different groups from the ComboBox, the lists below will change their members depending on the replication settings for that group.  The list of available targets is drawn from the XLiRAD Server Array that must be created first.  Use the left and right arrows to add and remove targets for each group as desired.  Press the "Exit" button after completing the Replication configuration.

Group Transfer

What is Group Transfer?

Group Transfer is the ability to move a group's work from one XLiRAD server to another in an XLiRAD Server Array.

What are the Benefits of Group Transfer?

Group Transfer allows for all of the development for numerous XLiRAD projects to occur on a single development box.  When a group of developers has finished testing its latest set of functionality on the development box, it can use Group Transfer to move and register this functionality onto any number of other XLiRAD Servers in the XLiRAD Server Array.  XLiRAD manages all the data passing across the network, source code control, and proper registering of work on the target server during the transfer.

Performing a Group Transfer

Select the "Group Transfer" menu item under the "Duplication" menu.  You will see a ComboBox with all the servers in the configured XLiRAD Server Array in it.  Select the proper target server from this ComboBox.  Highlight the groups you wish to transfer from the list below.  Press the "Transfer" button and a progress dialog will appear informing you of the status of the transfer.  *The groups you choose to transfer must exist on the remote server and have the exact same SQL Range as the sending server.  All existing work on the target server will be over-written by the transfer and its templates will be pushed back one level in the revision history.  In case of over-writing important work, the templates on the remote server can easily be restored using TemplateMaker and its revision history tools.

Statistical Tracking

Template Usage Statistics

XLiRAD keeps log files in the common log format that store template usage data.   The view the activity of XLiRAD templates, select the "Template Statistics" menu item under the "Statistics" menu.  You will be able to view template usage over multiple time frames.  You can also truncate the template usage log file at any time to flush old data and keep the log file size down.

SQL Statement Call Records

XLiRAD keeps log files in the common log format that store SQL statement call data.   The view the call records for XLiRAD SQL statements, select the "SQL Statistics" menu item under the "Statistics" menu.  You will be able to view SQL call records over multiple time frames.  You can also truncate the sql call record log file at any time to flush old data and keep the log file size down.

Custom Java Extensions

What are Custom Java Extensions?

Java Extensions allow the XLiRAD developer to create custom written java functions that can be called by XLiRAD templates.  For example, a developer could write a credit card billing function tied to a set of shopping cart templates. 

Who can Access Custom Java Extensions?

Java Extensions are owned by groups.  Only groups specifically designated access to an extension can call that extension from their templates.  This fits the ASP model specifically in that the ASP can create custom functions for specific business clients and only allow those clients to use the functions.

Embedding Custom Extensions in Templates

Template developers using TemplateMaker embed custom extension calls using the Command Dialog in the same way that they add normal SQL statement calls.

Configuring the Java Compiler

Select the "Java Compiler Setup" menu item under the "Extensions" menu.  Use the file chooser to locate the "javac" executable for your installed JDK.  This will automatically add that compiler's required classpath to the XLiRAD Server's classpath.  The classpath lines in the list are seeded with the entire classpath of the XLiRAD Server which should provide all of the pathing necessary for 99% of extended functions.  The administrator can, however, add and remove classpath entries as desired, but it is recommended that none of the seeded classpath be removed to ensure proper compiling and execution.  Press the "Submit" button to enact the changes.

Importing Jar/Zip Files into XLiRAD

Select the "Import JAR/Zip File" menu item under the "Extensions" menu.  Use the file chooser to locate the the desired java archive.  The import tool will extract the archived file into the "beans" subdirectory of the XLiRAD Server.  Thus, all of the required files will now be included in the current XLiRAD classpath.  XLiRAD will store and interpret Java Beans that exist in these archived files such that the Extended Function Editor, discussed below, can provide the required introspection into their makeup.  These Java Beans, however, must be properly documented in the Manifest file for the archive prior to the import into XLiRAD.

Importing Pre-Compiled XLiRAD Custom Extensions

Select the "Import Extended Function" menu item under the "Extensions" menu.  Use the file chooser to locate the the desired java class file.  The import tool will copy this file to the "classes" subdirectory of the XLiRAD Server and add an entry as an extended function to the server.   The administrator can then use the Extended Function Editor to set the group permissions and description of the function for the developers.

Managing Custom Extensions

Select the "Manage Extended Functions" menu item under the "Extensions" menu.  Select either to create a new function or edit an existing function.  New functions must have valid java function names to satisfy the compiler.  The Extended Function Editor will seed the new function with the necessary wrapper code around the contents.  This wrapper code should not be edited.  The Editor will create a class with the specified function name as a static function in the class.  The name of the class and the function name must remain as created.  The body of the function and perhaps some additional imports are the only things that the extended function developer should change.

The Extended Function Editor

The Function Description

The function description should describe the purpose of the function and its required inputs for the template developer.  This is the only window that the developer using TemplateMaker has into the nature of the function. 

Group Permissions to the Extended Function

The "Group Permissions" frame contains a list of all the current XLiRAD groups plus one more entry: "ALL GROUPS."  Highlight the groups that you wish to give execute permissions to this function.  Highlight "ALL GROUPS" to give all existing groups and any newly created groups access.  XLiRAD comes pre-packaged with numerous useful extended functions that are generic and initially set to "ALL GROUPS."  These functions include emailing, setting and retrieving cookies, etc.

The Code View

All XLiRAD Extended Functions take the form of a class containing a static function with the same name as the class.  New functions are seeded with the appropriate wrapper in which to develop the function.  The code view is where all hand-coding of custom functionality takes place.  The cursor position is stored when the mouse leaves the Code Frame to set the place holder for cutting and pasting and the insertion of helper code from the other Extended Function Editor frames discussed in the next section.

Java Beans in Extended Functions

Jar and Zip files imported previously using the import tool that contain Java Beans will provide helper functionality for the Extended Function Editor through Introspection.   Under "Registered Java Beans" the user will see a list of all imported Java Beans by class name.  Right clicking on a bean in the list will bring up a menu allowing easy instantiating and function calling for that bean in the code view.  Use those menu items to insert java bean code into the Code View at the last cursor position when the Code View was active.  For beans that need all of its data set before calling its methods, use the Create/Edit Setter Block menu item after instantiating the bean.  This will put a reverse-editable block of setter methods in the code view for easy editing.

The Compiler Frame

The Compiler Output view will show the compilation results when the "Save and Compile" button is pressed.  It will show the standard line number information about errors, etc. 

Servlet Helper Functions

The Extended Function Editor provides two views, "Server Commands" and "Server Variables," that place helper code in the code view for standard functionality.  To insert helper code from one of these views, simply double-click on the list item for the code you wish to enter.

1) GetValue() and SetValue(): Use these functions to set and retrieve variables from the servlet.  Any form data existing in the servlet is available for the GetValue() call.  To add data to the servlet for later processing in the template, use the SetValue() call.

2) SetErrorMessage() and SetErrorTemplate(): To indicate that an error has occurred during the processing of an Extended Function, the function should return the word "error" back to the servlet.  Prior to returning "error," the extended function developer can call SetErrorMessage() to customize the error message returned to the servlet for processing by the template.  The developer can also call SetErrorTemplate() if the desired result of the error condition is to redirect the XLiRAD request to another XLiRAD template for error processing.

3) GetDataVector(): Only used after a prior call to a command using the output type "Vector."  The select statement associated with a "Vector" output command will leave its entire result set in a Vector for custom processing by an extended function.  The "Vector" output command forces the developer to name a variable for the output Vector; that same variable is used by the GetDataVector() call to retrieve the Vectorized ResultSet.  This Vector is layed out in the following way:

        0) The number of rows in the set.

        1) The number of columns in the set.

        2 through 2 + numcolumns) The names of the columns in the set.

        2 + numcolumns and greater) The rows of the set in tip to tail fashion.

4) HttpServletRequest() and HttpServletResponse(): Return the servlet request and response accordingly.  These are useful for things like grabbing the ip address of the request, setting cookies, retrieving cookies, etc.

Reverting to the Last Good Version

Pressing the "Revert to Entry Version" button will undo all code changes that have been made during this editing session including permissions changes and description changes.

Enabling the Updated Extended Functions for Web Requests

In most scenarios, the webserver and servlet manager will not pick up code changes immediately even if the code changed resides in the current classpath of the server.   Hence, the servlet managing device must be restarted to enable the new/changed extended functions.  Otherwise, a cached version of the old function will probably still be active.