Laserfiche WebLink
<br />to use TSTooI and StateDMI). The following StateDMI enhancements will be <br />implemented to support StateCU GUI use: <br />1. Add ability to StateDMI to run in batch mode, similar to TSTooI. The <br />commands file will be specified on the command line, allowing StateDMI to <br />be called from the StateCU GUI using a system call. Anon-zero status code <br />will be generated from the Java Runtime Environment (JRE) if a serious error <br />occurs (e.g., no HydroBase connection can be established). It is assumed that <br />the StateCU GUI will properly handle all output, including zero length output. <br />Configuration of the HydroBase connection will occur using the existing <br />CDSS configuration file (IcdsslsystemlCDSS.cfg) or a similar file for <br />StateDMI. Documentation for the batch mode of operation will be provided <br />by RTi to facilitate development of the StateCU GUI. <br />2. Evaluate the performance of the StateCU GUUStateDMI interaction and, if <br />necessary, implement an alternative solution. If StateDMI is called using a <br />system call (as per the above item), then the JRE must start up each time that a <br />commands file is processed. This startup time will slow the performance of <br />the StateCU GUI and may result in usability issues that are unacceptable. <br />Startup time is highly dependent on the computer speed, virus check software, <br />and file server performance. If performance is not acceptable after <br />implementing the initial approach, other options that maybe considered <br />include: <br />a. Work with State IT staff to evaluate virus check software settings. An <br />evaluation of startup time at RTi and the State indicates that for <br />TSTooI the initial startup time on local and server machines is <br />approximately 25-45 seconds, with subsequent startup time being 2-5 <br />seconds. It appears that the initial slow performance maybe due to <br />virus check software. The virus check software typically caches <br />information so that it does not need to recheck software that is <br />repeatedly used. However, the cache gets cleared and then a full check <br />is repeated. Optimizing the virus check software settings could <br />eliminate the need to evaluate other options. <br />b. Evaluate creating executable programs from Java compiled files. The <br />JRE that runs Java software requires loading the JRE software and all <br />of the compiled files that comprise an application. Loading multiple <br />files results in some of the load time issues mentioned in the previous <br />item. By converting the Java application files into a compiled <br />executable (*.exe), loading (and virus scanning) can be faster. <br />Potential issues with this approach are that a commercial product may <br />need to be purchased and software design changes maybe required. <br />c. Enhance StateDMI to run in server mode, whereby a single instance of <br />StateDMI is started at the beginning of the session and is available to <br />process commands files as requested, thus eliminating repeated <br />startup. This approach has been tested in limited fashion in TSTool <br />and could be implemented similarly in StateDMI. Requests will be <br />20 <br />