XSQL rules – CDM RuleFrame business rules classification application

1. Intro

In this article I will explain how easy it is to
create a web application based on XML and XSL-T/XPath techniques and
using the Oracle XSQL Servlet for server side parsing. I will
demonstrate this by explaining the on-line business rules
classification application I build some time ago.
The application is a questionnaire that helps in classifying your
business rules according the Oracle CDM RuleFrame method of business
rule classification. The application consists of two web pages: the
main page is a dynamic questionaire where the user can classify his/her
business rule(s). Depending the given answer the application searches
the appropriate next question to answer, until the business rule is
classified. The second page is more a reference page or help page that
shows a (static) list of defined business rule classes. Figure 1 shows
a screen shot of the questionnaire. The questionnaire consists if a
number of questions the user should answer with YES or NO (using the
radio buttons). Depending on the given answer, the application searches
the next question to ask, using XPath, and presents that question to
the user. This goes on until the business rule is classified. Figure 2
shows a screen shot of the list of defined business rule classes.
 

Figure 1: screen shot questionaire page

Figure 2: Screen shot business rule classes

2. Under the hood

The questionaire page consists of the following building blocks. You will find all files in this war file
(I changed the extension to zip, because .war was not allowed, but you
do not need to unzip it, just rename the file). You can deploy the war
file on your web container or application server. I deployed it on a
Tomcat 5.1, but it should work on any J2EE web container.

• One XSQL file (cdmruleframe.xsql) for server
  side XML parsing. This file is picked up by the XSQL Servlet engine.
  The file includes both a parameter named choice and the
  classification.xml file into it’s own XML file (…): see figure 3. The parameter "choice" gets it’s value via the URL.

  Figure 3: result XSQL file without transformation
  

• One XML file (classification.xml) describing the business rule
  classes. Each rule consists of unique number, a title, a statement and
  two pointers for the answer (yes and no), pointing to the next
  question. To keep things simple, I have chosen to store these rules in
  an XML file; if you like you could store the rules inside a database
  table, and query the table into the application. Also, without a
  database you can run this as a stand-alone application.
• One XSL-T file (cdmruleframe.xsl) that transforms the
  classification.xml file to the web page. This file holds all
  application logic and hence is the heart of the application. I will
  talk you through this file. The file’s output is html. To render page
  in the "portlet like" look-and-feel shown in figures 1 and 2, an
  external style sheet (tmp-amisLAF.xsl) is included. The rendering of
  the look-and-feel is deliberately performed via an external style
  sheet, because I wanted to decouple the application-specific
  transformation code from the general look-and-feel transformations and
  functionality. By doing so I can alter the look-and-feel of the
  application without changing the application-specific transformation
  code and, also important, I can very easily reuse the look-and-feel
  file in other applications that I want to render with the portlet
  look-and-feel without any changes or copying of code. Just copy the
  tpl-amisLAF.xsl to the new application, and it’s done.
  Next a parameter named rule is defined. The purpose of this parameter
  is to extract the value of the URL parameter choice, if it exsists! The
  first call to the application is always performed without a choice
  parameter: the node does not exsist. If the node does not exsist $rule
  is given the value 1 so the questionaire starts with question 1.
  The style sheet uses two named templates to render either a
  questionnaire with radio buttons (template questionnaire) or the final
  rule class (template showResult). The questionnaire template renders a
  html-form that posts the answer back to the same XSQL-page using
  parameter choice.
  Next, the neccessary matched templates are coded. The match on the root
  node adds the required html-head tags with help from the external style
  sheet. To fill the html-body the template for authorisationrules is
  applied. The match on authorisationrules node renders only the rule
  number defined in parameter $rule, not all the other rule nodes. The
  match on the rule makes a choice between rendering the questionaire and
  rendering the final business rule class, by using the follwoing XPath:
  Because
  in file classification.xml only rule nodes do have a child node
  statement and business rule classes do not, when the XPath results to
  the boolean value true(), the questionaire is rendered.
  Finally, the match on the yes and no nodes renders radio buttons and
  the corresponding choice URL parameter.

3. Listing of business rule classes

The other web page is a static list of all the defined business rule
classes. The page is rendered by simply including the
classification.xml into the XSQL-page (listclasses.xsql) and
transforming the authorisation rules to the html-table
(listclasses.xsl). The result is shown in figure 2. The web page is
called via the hyperlink "show defined rules" on the main page.

4. Deploying the war file

The war file includes all required
sources to run the application. You can download the file to your
favorite web container without making any changes to the file. Two jar
files are included in the WEB-INF/lib directory. oraclexsql.jar for
runnning the XSQL Servlet engine and xmlparserv2.jar for XML parsing.
File web.xml is adapted so files with mime-type *.xsql are mapped to
the XSQL Servlet. File XSQLConfig.xml, located in WEB-INF/classes, is
the configuration file for the XSQL Servlet. In respect to the default
config file, I’ve removed/invalidated the database connections.
If you do not want users to see your XML nodes or more important if you
want to disable users hacking your XSQL-pages by overriding your style
sheets, change the following node in XSQLConfig.xml:
noFigure 3 shows how you
override the transformation by extending the URL with parameter
xml-stylesheet=none or xml-stylesheet=myhack.xsl.