Skip directly to searchSkip directly to the site navigationSkip directly to the page's main content

View System Documentation - Artifacting

The IBIS-PH View System pages are 100% dynamically created. That is, there are not any static HTML files that are served up - all pages (except error pages) are a result of an XML/XSLT transformation that produces an HTML document/page. The application has an "artifacting" option which provides a caching mechanism that can be used to help with system performance and Java application server CPU/memory load. This mechanism utilizes a Java Servlet Filter that captures the dynamically generated content and stores it to a disk file. The next time that same request is made the filter sees that the page/content already exists and simply streams it back instead of creating it again. Listed below are the detailed flow of how the system works, some notes, and the reason why it is currently disabled on the Utah site.

General Logic

As mentioned above the "artifacting" operation is implemented as a Java Filter. Listed below is the general logic/flow of this filter and the artifacting response wrapper: 

If the request does not match a specified URI pattern or if the 
URI has one or more query parameters then normal downstream filter/
servlet request/response processing is done.

Else (the URI does match one of the patterns AND there are not 
any query parameters)

  Build an adjusted path based on if the client's browser supports 
  GZIP compression.
    If accepts GZIP, then set a path prefix according to the 
    specified property. 
	
    else set to the non GZIP path property.
	
    Path and filename = actual disk path property + compression/no 
    compression path + URI path and resource/filename.

  Try and open the file.
	
  If the file exists and if its creation time + the file life 
  property do not exceed the current system date/time then stream 
  back the file's contents and return - done.

  Else create a response wrapper and let the system generate 
  the dynamic content.

  Save the wrapped/captured dynamically created content to a 
  disk file using the above path.
	
  Stream the newly create file back to the requester.

How to Control

The artifacting functionality is implemented as a Java Servlet Filter. To turn this feature off, simply remove or comment out the filter-mapping elements located in the IBIS-PH View System's WEB-INF/web.xml file. Likewise to enable the filter definition and mappings must be in place as well as appropriate URL mappings. Within the filter definition element there are special init-params that provide properties which specify the root artifacting directory, compressed/uncompressed adjustment paths, file life value, and some more detailed pattern matching parameters/properties (these are needed due to the fact that the standard filter and servlet URL pattern matching is very limited). See the actual "web.xml" file for more detailed information on these parameters and what the valid values are.

Other Filters and Filter Ordering

Two special path adjustments are needed for artifacting: 1) compressed and uncompressed content as mentioned above, and 2) IBIS-PH View System pages that contain charts or maps. Currently these pages contain charts or maps:


The reason that these pages need to have different artifacting paths is because the page's contain use different HTML elements specific for SVG or JPEG type graphic images and thus are dependent on which graphic type the user has specified (this preference is saved as a cookie on the user's machine). As with GZIP compression, those HTML pages that contain graphic image HTML elements specific for SVG graphics or JPEG graphics need a different artifacting path. This functionality is NOT handled within the artifacting filter. A special graphic type request filter/wrapper is needed up stream from this filter. This upstream filter simply adjusts the request path so that the artifacting filter does not need to know anything about the user's selected/preferred graphic type. See the Filters Page for more detailed information about the filters implemented as part of the system and their ordering.

Current Status

As of March 2006, the artifacting filter has been fully tested and used - it works fine. However, the publishing controllers does not have an "Artifact File Deletion" object built yet (although the controller is built for it) so that if enabled and an indicator profile is published (which causes a new or updated XML file to be saved on the View System), or if the org units XML is updated and published the associated artifacted HTML artifacted pages will not be automatically deleted. Also there isn't a generic XML publishing mechanism built into the system (yet) so that static PAGE XML type page updates do not have an easy way to control artifacted page deletion. Also, Utah has a dedicated dual processor box with lots of RAM. This server while it is being hit frequently, it is not even close to being taxed or utilized (average load is 20%) with the the Artifacting filter turned off (configured for full dynamic content generation mode). Full dynamic mode lessens the complexity of live site content updates so at this point there is not a big push to finish the publishing system and enable artifacting.