This article describes how to build a complete IBM® DB2® application in a day using an end-to-end XML architecture. The latter means that XML is used for storing, viewing, and manipulating information. The application may be shown to colleagues and customers to get feedback on the architecture, infrastructure, and user interface. Being able to develop, augment, and modify applications through short iterations promotes an agile application development approach.

Introduction

XML is the most popular choice for exchanging data in a structured and self-describing notation. The W3C suite of XML standards describes a set of specifications that are well accepted in business, governments, science, and other industries. Because XML's direct predecessor SGML has been in use since the 1980s, there is more than 20 years of experience and tools for working with XML.

Various industries utilize XML standards for defining industry-specific formats for standardized information exchange. Furthermore, XML is a popular notation for viewing and manipulating data, for example, through XForms or Lotus Forms. XML and hybrid database systems, such as DB2 pureXML™, provide native XML storage. The latter means that XML is stored as-is without the need to split the information encoded in the elements and attributes of XML into relational tables (also known as "shredding").

Being able to utilize XML and XML-based industry formats allows the creation of applications that utilize an end-to-end XML architecture. One major advantage of end-to-end XML applications is that the same XML-based industry format or custom notation can be used for storing (see the "Data" layer in Figure 1), for exchanging (see the "Information Exchange" layer in Figure 1), and for viewing and manipulating (see the "User Interaction" layer in Figure 1) XML.

Overview

The goal of this article is to illustrate how to create a functioning application quickly by adopting an end-to-end XML architecture for a specific industry-specific exchange format. The exchange format used as a basis for the work presented is the IRS e-File 1120 format which is an exchange format defined by the United States Department of Treasury for the purpose of reporting taxes (see the Resources). The steps for creating an end-to-end XML application include:

• Creating a DB2 pureXML database capable of storing IRS e-File 1120 XML documents natively
• Exposing the database using the Universal Services for accessing the database through Web services
• Creating a user interface using the XML Forms Generator (XFG) for viewing and manipulating IRS e-File 1120 XML documents

Finally, ideas are given to show how applications utilizing an end-to-end XML architecture may be augmented with additional technology to improve their functionality. Before continuing to read the article, ensure that the software listed in the Requirements section is installed and configured properly.

Requirements

For experimenting and following these instructions, the software listed below needs to be installed properly

• IBM DB2 Express-C (FREE): A hybrid database system utilizing the pureXML technology to store XML data natively. For more information, refer to the Resources section of this article.
• IBM Data Studio (Trial): The development environment offering a multitude of functionalities, such as exposing database operations as Web services. IBM Data Studio is also the environment needed to run the XFG. For more information, refer to the Resources section of this article.
• XML Forms Generator (FREE): An Eclipse-based plugin that allows you to generate XForms based on an XML document instance and a Web service Description Language (WSDL) file. To fully utilize the plugin’s capabilities with IBM DB2 pureXML, it must be installed within IBM Data Studio. For more information, refer to the Resources section of this article.

Back to top

Create the database (DB2 pureXML industry bundle) for storing XML

DB2 pureXML industry bundles contain vertical industry samples of XML documents, links to relevant XML schemas, and sample code to help database administrators, software developers, and architects in vertical industry businesses get started with DB2 9.x pureXML features. An industry bundle is typically created for one specific industry, such as an industry bundle for the Financial products Markup Language (FpML) or the IRS e-File 1120 format.

The industry bundle for the IRS e-File 1120 format is used in this article to create a database and populate the same with sample XML documents, providing the first layer to an end-to-end XML architecture (see Figure 2).

Figure 2. First layer providing native XML storage capabilities

For setting up and populating the DB2 pureXML database, refer to the Set up a sample database section of "Universal Services for pureXML using Data Web Services" (developerWorks, May 2008). If a broader overview on industry bundles is needed, consult "Get started with Industry Formats and Services with pureXML" (alphaWorks, December 2006). (see the Resources section).

The populated database serves as a basis to continue with the next level of development: exposing the database through Web services.

Back to top

Create the Web services (Universal Services) for exchanging XML

The Universal Services, based on the Data Web Services mechanism, are a fixed set of database operations, including insert, update, delete, and query for accessing the database through simple REST or SOAP requests, as illustrated in Figure 3.

Setting up the Universal Services is achieved through configuring and executing a command line script. Executing the script creates a Web archive (WAR) file that may be deployed to an application server, such as the WebSphere® Application Server or Apache Tomcat.

Figure 3. Second layer exposing the database through Web service operations

The configuration and installation of the Universal Services is not illustrated any further since it is already described in another, accompanying, article. Therefore, refer to the Install the Universal Services section of "Universal Services for pureXML using Data Web Services." If more information on Data Web Services is needed, refer to the Resources section.

Now it is possible to develop a User Interface (UI) accessing the database through simple Web service requests, as illustrated in the following section.

Back to top

Create the forms (XFG) for viewing and manipulating XML

In the following section, XForms for viewing and manipulating data stored in the database are created, providing the third layer, namely the "User Interaction" layer, illustrated in Figure 4.

Figure 4. Third layer for viewing and manipulating information

The XForms are created utilizing the XFG plugin installed as part of IBM Data Studio. Therefore, a brief introduction to the XFG plugin is provided followed by an illustration that shows how to create XForms using the XFG plugin.

Overview of the XFG

In the following section, an overview of the functionality of the XFG plugin is provided. However, the description contains relevant information for this article only. If a broader and more detailed overview on all the capabilities of XFG is needed, refer to the related series of articles "Integration between XML Forms Generator and Data Studio" found in the Resources section.

For generating fully functional XForms, the XFG plugin bases the generation process on various artifacts, which are: the WSDL file of the Web service to be used, a sample XML document, and optionally the XML schema according to the XML document.

Figure 5. Runtime artifacts used by the XFG plugin

To generate XForms, the XFG plugin at first analyzes the WSDL file describing all the Web service operations available through a particular Web service (see Figure 5, Number 1). After the user chooses one of the available operations, the XFG plugin analyzes the different input parameters of the operation, since for each input parameter an appropriate input field in the forms needs to be generated. The latter is simple for data types, such as integer or characters, but more complex for input parameters of type XML. The generation of the input fields for the XML data type is based on a sample XML document (see Figure 5, Number 2) and optionally also on the backing XML schema (see Figure 5, Number 3) of the XML document used. Therefore, the plugin automatically retrieves a set of sample XML document instances from the database (see Figure 5, Number 2). Out of the sample XML documents retrieved, the user may choose one sample XML document serving as a basis to generate the XForms. If a backing XML schema reference by the XML document is available in the XML Schema Repository (XSR) of DB2, the user may choose to utilize XML schema information in the XForms generation.

The description above may sound like a complex process but is, as illustrated below, a straight-forward task. Before proceeding, ensure that a workspace containing all the artifacts needed by the XFG plugin is available. It is also described in the following section.

Create and prepare the workspace in Data Studio

As mentioned above, one of the artifacts needed by the XFG plugin to generate XForms is the WSDL file describing the Web service to be used. In particular, this means that it is necessary to have a workspace available containing the WSDL of the describing Universal Services. To do so, the Universal Services are typically imported into a new or an existing workspace. Since the Universal Services are pre-configured for a particular sample database, it is also necessary to adjust the services to fit the database details used in the scenario of this article. Before continuing to read the instructions below, note that it is possible to either import and adjust the project as described below or to import a pre-configured project without the need to make any particular adjustments. The latter is recommended.

Option 1: Import original Universal Services data development project

To import and adjust the original data development project of the Universal Services, follow the instructions provided in the Modify the Universal Services section of "Universal Services for pureXML using Data Web Services" (developerWorks, May 2008).

Option 2 (recommended): Import the pre-configured Universal Services data development project

In order to use the pre-configured data development project utilizing the correct database connection details, table names, and database schema name, first locate the archive file universal_services_data_studio_project_irs1120.zip, available in the Download section of this article. To import the archive file, follow the instructions described in the Import Universal Services Data Development Project section of "Universal Services for pureXML using Data Web Services." Note that after importing the archive file, no further adjustments are required.

Use the XFG

This section illustrates how to generate XML forms for the IRS e-File 1120 message format utilizing the XFG. Generating XForms requires Data Studio to be launched using the workspace that contains the Universal Services data development project imported in the previous step. The user of XFG in Data Studio is guided through the generating XForms process by a wizard. All the steps performed through the wizard are described in more detail below.

Step 1: To launch the wizard that guides you through the process of creating XForms, navigate to the WSDL file describing Universal Services in the data project explorer of Data Studio followed by right-clicking the WSDL file. The latter causes a submenu to appear. In the submenu choose Generate XHTML/XForm to launch the wizard, as illustrated in Figure 6.

Figure 6. Launch the wizard

Step 2: As mentioned in previously, the XFG plugin utilizes a sample XML document and a WSDL file to create XForms. To retrieve sample XML documents from the database, the XFG plugin needs user credentials to access the database. Therefore, as shown in Figure 7, a valid username and password need to be provided. Furthermore, the option "Retrieve PureXML instance from Database" needs to be checked to trigger the XFG plugin to actually retrieve samples from the database. Click Next to continue.

Figure 7. Configure database access information

Step 3: After the XFG analyzed the WSDL file and recognized all the operations available, the wizard allows the selection of one of the operations. Since the XForms are used to insert new information into the database, the operation named "insertXML()" is chosen, as illustrated in Figure 8. Click Next to continue.

Figure 8. Choose the Web service operation

Step 4: Since the operation chosen in the previous step contains one input parameter of type XML, the wizard allows you to choose a sample XML document used as a basis to create appropriate input fields and controls. Retrieving sample XML documents is triggered through clicking the button located in the column "Reference Instance" (see Figure 9).

Figure 9. Choose reference sample XML document

A separate window opens showing sample XML documents retrieved from the database. One of the sample XML documents needs to be chosen (see Figure 10). Click OK to proceed.

Figure 10. Choose reference sample XML document

The sample XML document chosen in the previous step is now used as a basis to generate the input fields and controls for the XForms (see Figure 11). Click Next to continue.

Figure 11. Choose reference sample XML document

Step 5: The XFG plugin needs an appropriate file name and location for storing the generated XForms. Therefore, either leave the default settings unmodified (see Figure 12) or choose the customized file name and location. Click Next to proceed.

Figure 12. Choose a file name and location for the XForms

Step 6: To generate fully functional XForms, the XFG plugin allows you to specify the endpoint of the Web service to be used. In the current scenario, the endpoint is the SOAP endpoint of the Universal Services (http://localhost:8080/UniversalServices/services/UniversalServices). To specify the custom endpoint, uncheck Use default submit target. and enter the SOAP endpoint of the Universal Services into the input field named "Use this submit target." (see Figure 13).

Figure 13. Specify the submit target to be used

Step 7: Another artifact used by the XFG plugin is the XML schema associated with the XML document instance. Since an XML schema describing the structure of XML document instances allows you to define mandatory as well as optional elements and attributes, the wizard allows to choose between: generated input fields for all elements and attributes (optional as well as mandatory) or required elements and attributes only. Leave all settings unchanged and click Next to proceed (see Figure 14).

Figure 14. Choose the type of elements and attributes to be generated

Step 8: Also, the XFG plugin allows you to store the XML schema and the sample XML document used as a basis for generating the XForms. Therefore, choose a file name and location for the XML document (see Figure 15) as well as for the XML schema (see Figure 16). In each of the steps, click Next to continue.

Figure 15. Choose the file name and location for the sample XML document

Figure 16. Choose the file name and location for the XML schema

According to the settings chosen throughout the different pages of the wizard, the XForms have been generated (see Figure 17).

Figure 17. Completely generated XForms

Back to top

Run the application

After completing all three major tasks, it is time to see the generated XForms in action. For rendering XForms properly, Mozilla Firefox is required. In addition, Mozilla Firefox needs the Mozilla XForms plugin installed. Note that not all versions of the Mozilla XForms plugin are compatible with each versions of Mozilla Firefox. The software used in the current scenario is Mozilla Firefox, Version 2.0.0.18 together with the Mozilla XForms plugin, Version 0.8.6ff2. Rendering the XForms may look similar to the XForms illustrated in Figure 18.

Figure 18. XForms rendered in Mozilla Firefox with input data entered

To continue, enter information into the available input fields. Note that two particular input fields, referenced as "P1" and "P2", are two input parameters of the Web service operation that were used to generate the XForms. The input parameter named "P1" is of data type integer, the other input parameter "P2" is of type character. The sample data entered to illustrate the XForms in this scenario is the number "24" for parameter "P1" and the text "data entered through XForms" for the parameter "P2." The two input fields for the parameters "P1" and "P2" are followed by a number of input fields that were created based on the attributes end elements of the sample XML document used to generate the XForms. Sample data may be entered in any of the input fields.

After entering the data needed, scroll all the way down to the end of the forms where the Submit button is located (see Figure 19).

Figure 19. Submit button to invoke the submit function of the XForms

Click Submit to invoke the submit functionality of the XForms, inserting the data entered into the DB2 pureXML database through the Universal Services. Therefore, the response message from the Web service is shown (see Figure 20) indicating a successful insert into the database.

Figure 20. Response from the Web service

To ensure that the new record was inserted into the database, the test page included as part of the Universal Services may be used again. If more information on accessing the test page is needed, refer to the Test the Universal Services section of "Universal Services for pureXML using Data Web Services." The URL to access the Universal Services is typically http://localhost:8080/UniversalServices/wsdl. Note that hostname and port may change due to the local system configuration used.

On the test page, navigate to the operation getXMLDocumentByKey, and enter the identifier of the newly created record (for example, the number "24" entered in the XForms input field "P1"), and click Invoke to invoke the Web service operation.

As a result, the data previously entered into the XForms is shown, as illustrated in Figure 21.

Figure 21. Information previously entered into the XForms

Back to top

Augment the application

The article has shown the ease, simplicity, and speed of creating an application utilizing an end-to-end XML architecture. The user interface and the Universal Services can then be adjusted in response to feedback. In addition, there are a number of possibilities for extending the application with additional functionality.

One possible extension is the validation of data entered into the XForms. Currently, the XForms generated through the XFG plugin may contain simple validation rules generated based on the metadata of the input parameters of the Web service operation used and based on the XML schema used as a basis to generate the XForms. However, an additional technology to validate XML content is Schematron, which may be used in combination with XForms. An example of how to incorporate Schematron validation rules into XForms can be found in the article "Apply Schematron constraints to XForms documents automatically" (developerWorks, June 2006).

An important aspect of structure and content validation of XML document instances is the ability to track validation failures. Part 1 of this series illustrated structure and content validation of XML document instances through XML schema and Schematron. The validation was performed through the IBM® WebSphere® DataPower® SOA appliance. In this article, see how IBM DB2® pureXML™ can further complement the WebSphere DataPower SOA appliance by providing an easily accessed and queried audit log. The scenario illustrated in this article is applicable to any situation where XML document instances are being exchanged.

Prerequisites

The ideas presented in this article follow on from Part 1 of this series, "XML schema and content validation in the context of DataPower and DB2 pureXML" (developerWorks, May 2008) Please refer to that article for the theoretical background on this topic.

Back to top

Introduction

The previous article in this series illustrated the validation of structure and content of XML document instances through the IBM WebSphere DataPower SOA appliance before storing the XML document instances in a DB2 pureXML database.

The purpose of this article is to illustrate the use of a DB2 pureXML database as an easily accessed and queried audit log for the WebSphere DataPower appliance (see Figure 1). In addition to logging the XML document instances, the audit information can include details of the routing, transformation, or validation of XML document instances through the WebSphere DataPower appliance.

Figure 1. DB2 pureXML audit log scenario

The basic idea of the scenario is that the WebSphere DataPower appliance stores the validation results in a DB2 pureXML audit log database, after performing XML schema and Schematron validation on XML document instances received from the submitting endpoint. An example for the submitting endpoint can be an XForms client or even another information system exchanging XML document instances. The WebSphere DataPower SOA appliance stores a success or failure message in the audit log database, containing detailed information on why the validation failed. Regardless of the validation result, the WebSphere DataPower appliance also forwards the validated XML document instance to the receiving endpoint, which can be, for example, another DB2 pureXML database, or even another application or information system.

A major benefit of the solution illustrated here is that it can be applied to any scenario where XML document instances are exchanged. The exchange of XML document instances can be, for example, between two information or application systems through Web services. A similar article entitled "Using DB2 9 pureXML with WebSphere ESB" (developerWorks, June 2008) describes the use of DB2 pureXML as an audit log for WebSphere Enterprise Service Bus (WESB).

Back to top

Setting up the scenario

The following sections describe the setup of a simple scenario, as illustrated in Figure 2, that showcases the use of a DB2 pureXML database as an audit log for the WebSphere DataPower SOA appliance. To keep the scenario brief and simple, it is assumed that XML document instances are submitted from a client to the WebSphere DataPower appliance, which validates the XML document instances and then forwards the XML document instances to another DB2 pureXML database.

Figure 2. DB2 pureXML audit log example scenario

In order to set up the scenario illustrated in Figure 2, follow the steps outlined below:

• Step 1: Create XML documents, XML schema, Schematron, and the receiving endpoint
• Step 2: Create DB2 pureXML audit log database
• Step 3: Configure WebSphere DataPower SOA appliance

Back to top

Step 1: Create XML documents, XML schema, Schematron, and the receiving endpoint

The scenario illustrated in Figure 2 is an extended version of the scenario used in Part 1 of this series. The first step to set up the scenario used in this article is to follow Steps 1 and 2 of Part 1.

Back to top

Step 2: Create DB2 pureXML audit log database

This section describes the setup of the DB2 pureXML database that serves as an audit log for the validation results from the WebSphere DataPower appliance.

As illustrated in Listings 1 and 2, below, the setup of the audit log database consists of one table and one stored procedure only:

Listing 1. Setup of DB2 pureXML audit log database

DROP DATABASE AUDIT@ CREATE DATABASE AUDIT@ CONNECT TO AUDIT@ CREATE SCHEMA DB2ADMIN@ CREATE TABLE DB2ADMIN.AUDIT (ID INT PRIMARY KEY NOT NULL GENERATED ALWAYS AS IDENTITY, AUDITINFO XML, RECORD XML)@

Listing 2. Setup of the stored procedure to insert audit information into the Audit table

CREATE PROCEDURE insertAuditRecord (IN xmlAuditInfo XML, IN xmlRecord XML) SPECIFIC insertAuditRecord P1: BEGIN INSERT INTO DB2ADMIN.AUDIT (AUDITINFO, RECORD) VALUES (xmlAuditInfo, xmlRecord); END P1@

The stored procedure insertAuditRecord is then exposed through a Data Web Service, as shown in Figure 3, below, which means that the Stored Procedure can be called through SOAP or REST requests:

Figure 3. DB2 pureXML audit log database configuration overview

This article will not cover further details on how to create Data Web Services. If you need more information, please read the tutorial "IBM Data Studio: Get started with Data Web Services" (developerWorks, November 2007).

Back to top

Step 3: Configure WebSphere DataPower SOA appliance

The theoretical background on the WebSphere DataPower SOA appliance relevant to this scenario is introduced in Step 3 of the first article in this series.

The first step is to configure XML Schema validation. In other words, XML documents being sent to this policy on the DataPower appliance are validated against a particular XML schema. To configure XML schema validation, add an XML schema validation processing action to the processing rule, as shown in Figure 4, Number 3:

Figure 4. XML firewall configuration of the DataPower SOA Appliance

The default behavior of the XML schema validation is that if the validation action fails, the DataPower appliance will respond to the request with a failure message and the HTTP 500 error code back to the client that initially sent the XML document. The standard error message for this case does not contain any specific information on why the validation action failed.

To override the default behavior and provide more information on the validation failure, we include an on-error action in the rule, as shown in Figure 4, Number 2. The on-error action causes the policy to call another rule named Rule #2 (shown in Figure 5, Number 1). If Rule #2 is called, it executes the XSL stylesheet shown in Listing 3.

Figure 5. Screenshot of the XML Firewall configuration of the DataPower SOA Appliance

After executing Rule #2, the default behavior for the on-error action is to abort the processing policy, which can be overridden to continue processing. In this scenario, the on-error action is configured to continue processing if any fatal errors occur during XML schema validation.

Listing 3. XSL stylesheet reading validation failure details and inserting audit record in DB2 pureXML audit log database

<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" extension-element-prefixes="dp" exclude-result-prefixes="dp"> <xsl:output method="xml"/> <xsl:template match="/"> <dp:url-open target="http://auditdb2:8080/audit/rest/audit/insertAuditRecord" response="ignore" data-type="xml" content-type="text/xml"> <q0:insertAuditRecord xmlns:q0="urn:example"> <q0:_xFFFF_xmlAuditInfo> <error> <xsl:value-of select="dp:variable('var://service/error-message')"/> </error> </q0:_xFFFF_xmlAuditInfo> <q0:_xFFFF_xmlRecord> <xsl:copy-of select="." /> </q0:_xFFFF_xmlRecord> </q0:insertAuditRecord> </dp:url-open> </xsl:template> </xsl:stylesheet>

The XSL stylesheet shown in Listing 3 obtains the specific error message that explains why the validation action failed and inserts the error message into the audit log database through the Data Web Service of the DB2 pureXML audit log database. The stylesheet then forwards the original XML document instance to the receiving endpoint.

Now there are two items left the DataPower appliance needs to perform. The first one is applying the Schematron XSL stylesheet to the incoming request XML document instance. After Schematron validation, the WebSphere DataPower appliance forwards the Schematron validation result to the Data Web Service of the audit log database, which inserts the validation result into the DB2 pureXML audit log database. Regardless of the validation result, the DataPower appliance also forwards the request XML document instance receiving endpoint. The Schematron validation and the forwarding are achieved through another XSL stylesheet transformation action, as shown in Figure 4, Number 4, which executes the XSL stylesheet illustrated in Listing 4:

Listing 4. XSL stylesheet executing XSL stylesheet, inserting result in DB2 pureXML audit log database, and forwarding the XML document instance to the receiving endpoint

<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" extension-element-prefixes="dp" exclude-result-prefixes="dp"> <xsl:output method="xml" /> <xsl:template match="/"> <xsl:variable name="schematronResult"> <error> <xsl:value-of select="dp:transform('local:///simple.xsl', .)" /> </error> </xsl:variable> <dp:url-open target="http://aduitdb2:8080/audit/rest/audit/insertAuditRecord" response="ignore" data-type="xml" content-type="text/xml"> <q0:insertAuditRecord xmlns:q0="urn:example"> <q0:_xFFFF_xmlAuditInfo> <xsl:choose> <xsl:when test="$schematronResult/error/text()"> <xsl:copy-of select="$schematronResult" /> </xsl:when> <xsl:otherwise> <success>All validation Steps completed successfully!</success> </xsl:otherwise> </xsl:choose> </q0:_xFFFF_xmlAuditInfo> <q0:_xFFFF_xmlRecord> <xsl:copy-of select="." /> </q0:_xFFFF_xmlRecord> </q0:insertAuditRecord> </dp:url-open> <dp:url-open target="http://endpointdb2:8080/patient/rest/patient/insertPatient" response="xml" data-type="xml" content-type="text/xml"> <q0:insertPatient xmlns:q0="urn:example"> <q0:_xFFFF_xmlRecord> <xsl:copy-of select="." /> </q0:_xFFFF_xmlRecord> </q0:insertPatient> </dp:url-open> </xsl:template> </xsl:stylesheet>

Demonstration

After successfully setting up this example, it's now time to show the DataPower SOA Appliance, DB2 pureXML, and Data Web Services together in action. The XML document instances previously defined in this article are used in this demonstration.

To begin the three XML document instances are submitted to the WebSphere DataPower SOA appliance through the command line tool cURL. The submission of the sample XML document instances is illustrated in Listing 5, below:

Listing 5. Submitting the sample XML document instances

cpichle@DAIRYFARM /tmp $ curl --data-binary @simple_1.xml http://datapowerbox:2055/ <?xml version="1.0" encoding="UTF-8"?> <ns1:insertPatientResponse xmlns:ns1="urn:example" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> cpichle@DAIRYFARM /tmp $ curl --data-binary @simple_2.xml http://datapowerbox:2055/ <?xml version="1.0" encoding="UTF-8"?> <ns1:insertPatientResponse xmlns:ns1="urn:example" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> cpichle@DAIRYFARM /tmp $ curl --data-binary @simple_3.xml http://datapowerbox:2055/ <?xml version="1.0" encoding="UTF-8"?> <ns1:insertPatientResponse xmlns:ns1="urn:example" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> cpichle@DAIRYFARM /tmp $

After submitting the sample XML document instances, it is possible to check the audit information and the receiving endpoint, which is described in the following sections.

Audit information

The major benefit of using DB2 pureXML as an audit log for the WebSphere DataPower SOA appliance is that it provides an easy-to-access log.

We expect three different error messages and one success message in the audit log database as a result of submitting the three sample XML document instances to the DataPower SOA appliance. The first XML document instance violates the Schematron rule, the second document violates the structure defined in the XML schema and the Schematron rule, and the third XML document instance complies with both, XML schema and Schematron.

It is now possible to query the DB2 pureXML audit log database for the validation results of the XML document instances. The query statement to do so is illustrated in Listing 6. Note that the supplied query statement does not return the original XML document instances contained in the audit log.

Listing 6. Query audit records in the DB2 pureXML audit log database

C:\scenario_2\>db2 CONNECT TO AUDIT Database Connection Information Database server = DB2/NT 9.5.1 SQL authorization ID = CPICHLE Local database alias = AUDIT C:\scenario_2\>db2 SELECT ID, AUDITINFO FROM DB2ADMIN.AUDIT ID AUDITINFO -- ------------------------------------------------------------------- 22 <error>First name must not be 'christian'!</error> 23 <error>http://watdp.watson.ibm.com:2056/: cvc-particle 3.1: in element person with anonymous type, found <name> (in default namespace), but next item should be identification </error> 24 <error>First name must not be 'christian'!</error> 25 <success>All validation Steps completed successfully!</success> 4 record(s) selected. C:\scenario_2\>

In addition to the error and success messages, the audit log database furthermore stores the XML document instances the messages belong to. The query to retrieve all messages and XML document instances is illustrated in Listing 7:

Listing 7. Alternative query to retrieve complete audit log records containing the original XML document instance

C:\scenario_2\>db2 SELECT ID, AUDITINFO, RECORD FROM DB2ADMIN.AUDIT

Receiving endpoint

Since the WebSphere DataPower SOA appliance performed the validation of three XML document instances, we can expect three records at the receiving endpoint. In the example in this article, the receiving endpoint is a separate DB2 pureXML database. The database can be queried, as illustrated in Listing 8:

Listing 8. Query XML document instances stored in DB2 pureXML endpoint database

C:\scenario_2\>db2 CONNECT TO HOSPITAL Database Connection Information Database server = DB2/NT 9.5.1 SQL authorization ID = CPICHLE Local database alias = HOSPITAL C:\scenario_2\>db2 SELECT ID, COMMENT, RECORD FROM DB2ADMIN.PATIENT ID COMMENT RECORD -- ------- ---------------------------------------------------------- 13 <person xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:noNamespaceSchemaLocation="simple.xsd"> <identification>1</identification> <name> <first>christian</first> <last>pichler</last> </name> </person> 14 <person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="simple.xsd"> <name> <first>christian</first> <last>pichler</last> </name> </person> 15 <person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="simple.xsd"> <identification>3</identification> <name> <first>keith</first> <last>wells</last> </name> </person> 3 record(s) selected. C:\scenario_2\>

Back to top

Summary

This article has illustrated the practical and convenient use of DB2 pureXML as an audit log for the WebSphere DataPower SOA appliance. The scenario shown is applicable to a variety of scenarios where XML document instances are being exchanged. This article showed how DB2 pureXML adds additional value to the scenario since it provides an easy to query audit log. The audit log information stored in the database is ready for further processing and analyzing XML document instance validation failures. This article has again shown that the combination of the WebSphere DataPower SOA appliance with DB2 pureXML provides a powerful and flexible environment to perform XML document instance validation.

Back to top

Acknowledgement

Thank you to Bob Callaway and others who have contributed to this work by providing their knowledge and guiding advice