It's no secret that Docupresentment (part of
the Oracle Documaker suite) is powerful tool for integrating on-demand and interactive applications for publishing with
the Oracle Documaker framework. It's also no secret there are are many details with respect to
the configuration of Docupresentment that can elude even
the most erudite of of techies. To be sure, Docupresentment will work for you right out of
the box, and in most cases will suit your needs without toying with a configuration file. But, where's
the adventure in that? With this inaugural post to That's
The Way, I'm going to introduce myself, and what my aim is with this blog. If you didn'
t figure it out already by checking out my profile, my name is Andy and I've been with Oracle (nee Skywire Software nee Docucorp nee Formmaker) since
the formative years of 1998. Strangely, it doesn'
t seem that long ago, but it's certainly a lifetime in
the age of technology. I recall running a BBS from my parent's basement on a 1200 baud modem, and
the trepidation and sweaty-palmed excitement of upgrading to
the power and speed of 2400 baud! Fine, I'll admit that perhaps I'm inflating
the experience a bit, but I was kid! This is
the stuff of War Games and King's Quest I and
the demise of TI-99 4/A. Exciting times. So fast-forward a bit and I'm 12 years into a career in
the world of document automation and publishing working for
the best (IMHO) software company on
the planet. With That's
The Way I hope to shed a little light and peek under
the covers of some of
the more interesting aspects of implementations involving
the tech space within
the Oracle Insurance Global Business Unit (IGBU), which includes Oracle Documaker, Rating & Underwriting, and Policy Administration to name a few. I may delve off course a bit, and you'll likely get a dose of humor (at least in my mind) but I hope you'll glean at least a tidbit of usefulness with each post. Feel free to comment as I'm a fairly conversant
guy and happy to talk -- it's stopping
the talking that's
the hard part... So, back to our regularly-scheduled post, already in progress. By this time you've visited Oracle's E-Delivery site and acquired your properly-licensed version of Oracle Documaker. Wait -- you didn'
t find it? Understandable -- navigating
the voluminous download library within Oracle can be a daunting task. It's pretty simple once you’ve done it a few times. Login to
the e-delivery site, and accept
the license terms and restrictions. Then, you’ll be able to select
the Oracle Insurance Applications product pack and your appropriate platform. Click Go and you’ll see a list of applicable products, and you’ll click on Oracle Documaker Media Pack (as I went to press with this article
the version is 11.4): Finally, click
the Download button next to Docupresentment (again, version at press time is 2.2 p5). This should give you a ZIP file that contains
the installation packages for
the Docupresentment Server and Client, cryptically named IDSServer22P05W32.exe and IDSClient22P05W32.exe. At this time, I’d like to take a little detour and explain that
the world of Oracle, like most technical companies, is rife with acronyms. One of
the reasons Skywire Software was a appealing to Oracle was our use of many acronyms, including
the occasional use of multiple acronyms with
the same meaning. I apologize in advance and will try to point these out along
the way. Here’s your first sticky note to go along with that: IDS = Internet Document Server = Docupresentment Once you’ve completed
the installation, you’ll have a shiny new Docupresentment server and client, and if you installed
the default location it will be living in c:\docserv. Unix users, I’m one of you! You’ll find it by default in ~/docupresentment/docserv. Forging onward with
the meat of this post is learning about some special configuration options. By now you’ve read
the documentation included with
the download (specifically ids_book.pdf) which goes into some detail of
the rubric of
the configuration file and in fact there’s even a handy utility that provides an interface to
the configuration file (see Running IDSConfig in
the documentation). But who wants to deal with a configuration utility when we have
the tools and technology to edit
the file <gasp> by hand! I shall now proceed with
the standard Information Technology Under
the Hood Disclaimer: Please remember to back up any files before you make changes. I am not responsible for any havoc you may wreak! Go to your installation directory, and locate your docserv.xml file. Open it in your favorite XML editor. I happen to be fond of Notepad++ with
the XML Tools plugin. Almost immediately you will behold
the splendor of
the configuration file. Just take a moment and let that sink in. Ok – moving on. If you reviewed
the documentation you know that inside
the root <configuration> node there are multiple <section> nodes, each containing a specific group of settings. Let’s take a look at <section name=”DocumentServer”>: There are a few entries I’d like to discuss. First, <entry name=”StartCommand”>. This should be pretty self-explanatory; it’s
the name of
the executable that’s run when you fire up Docupresentment. Immediately following that is <entry name=”StartArguments”> and as you might imagine these are
the arguments passed to
the executable. A few things to point out:
The –Dids.configuration=docserv.xml parameter specifies
the name of your configuration file.
The –Dlogging.configuration=logconf.xml parameter specifies
the name of your logging configuration file (this uses log4j so bone up on that before you delve here).
The -Djava.endorsed.dirs=lib/endorsed parameter specifies
the path where 3rd party Java libraries can be located for use with Docupresentment. More on that in another post.
The <entry name=”Instances”> allows you to specify
the number of instances of Docupresentment that will be started. By default this is two, and generally two instances per CPU is adequate, however you will always need to perform load testing to determine
the sweet spot based on your hardware and types of transactions. You may have many, many more instances than 2. Time for a sidebar on instances. An instance is nothing more than a separate process of Docupresentment.
The Docupresentment service that you fire up with docserver.bat or docserver.sh actually starts a watchdog process, which is then responsible for starting up
the actual Docupresentment processes. Each of these act independently from one another, so if one crashes, it does not affect any others. In
the case of a crashed process,
the watchdog will start up another instance so
the number of configured instances are always running. Bottom line: instance = Docupresentment process. And now, finally, to
the settings which gave me pause on an not-too-long-ago implementation! Docupresentment includes a feature that watches configuration files (such as docserv.xml and logconf.xml) and will automatically restart its instances to load
the changes. You can configure
the time that Docupresentment waits to check these files using
the setting <entry name=”FileWatchTimeMillis”>. By default
the number is 12000ms, or 12 seconds. You can save yourself a few CPU cycles by extending this time, or by disabling
the check altogether by setting
the value to 0. This may or may not be appropriate for your environment; if you have 100% uptime requirements then you probably don’t want to bring down an entire set of processes just to accept a new configuration value, so it’s best to leave this somewhere between 12 seconds to a few minutes. Another point to keep in mind: if you are using Documaker real-time processing under Docupresentment
the Master Resource Library (MRL) files and INI options are cached, and if you need to affect a change, you’ll have to “restart” Docupresentment. Touching
the docserv.xml file is an easy way to do this (other methods including using
the RSS request, but that’s another post).
The next item up: <entry name=”FilePurgeTimeSeconds”>. You may already know that
the Docupresentment system can generate many temporary files based on certain request types that are processed through
the system. What you may not know is how those files are cleaned up. There are many rules in Docupresentment that cause
the creation of temporary files. When these files are created, Docupresentment writes an entry into a properties file called
the file cache. This file contains
the name, creation date, and expiration time of each temporary file created by each instance of Docupresentment. Periodically Docupresentment will check
the file cache to determine if there are files that are past
the expiration time, not unlike that block of cheese festering away in
the back of my refrigerator. However, unlike my ‘fridge cleaning tendencies, Docupresentment is quick to remove files that are past their expiration time. You, my friend, have
the power to control how often Docupresentment inspects
the file cache. Simply set
the value for <entry name=”FilePurgeTimeSeconds”> to
the number of seconds appropriate for your requirements and you’re set. Note that file purging happens on a separate thread from normal request processing, so this shouldn’t interfere with response times unless
the CPU happens to be really taxed at
the point of cache processing. Finally, after all of this, we get to
the final setting I’m going to address in this post: <entry name=”FilePurgeList”>.
The default is “filecache.properties”. This establishes
the root name for
the Docupresentment file cache that I mentioned previously. Docupresentment creates a separate cache file for each instance based on this setting. If you have two instances, you’ll see two files created: filecache.properties.1 and filecache.properties.2. Feel free to open these up and check them out. I hope you’ve enjoyed this first foray into
the configuration file of Docupresentment. If you did enjoy it, feel free to drop a comment, I welcome feedback. If you have ideas for other posts you’d like to see, please do let me know. You can reach me at
[email protected]. ‘Til next time! ###
