To test OpenEFM on a system level, you'll want a means of simulating the message output of an "electronic filing service provider"--or EFSP--and a means of capturing the content of OpenEFM's replies thereto. By triggering the EFSP's behavior, you can inject filings into your OpenEFM installation database, after which you can use the Web interface to examine the newly generated filings and submit them into your case-management or document-management system.
Important note: before filings will be accepted into OpenEFM, you will need to make sure an EFSP has been defined within OpenEFM and that the username and password for that EFSP are included in any messages generated.
OpenEFM provides such means in the form of a Java application wrapped by some shell scripts and a servlet container. Filing submission requests can be sent to a running OpenEFM installation, and the responses are saved to disk for examination. There are several ways to invoke this system:
The easiest way of generating filing submissions is to execute "
./scripts/efsp-sim/submit-filing-sample.sh". This script requires no arguments, providing default values for all variables. It will send a message to a default URL at "localhost"; which should work, provided you are running both this script and OpenEFM proper on the same host and have not changed anything critical in OpenEFM's configuration.
Immediate, synchronous responses will be saved as files in a new directory, which, by default, will appear under "
~/efile-data", in your home directory. Within the newly created directory, there should be a file ending with ".xml", which is the XML confirmation message returned from OpenEFM. Hopefully, you will find it fairly simple to view that file in order to tell the result of your filing submission test.
In the latest version, however, the aforementioned synchronous response messages from OpenEFM contain only an acknowledgement of transport. Two additional messages are sent asynchronously at various points in the e-filing process. These messages are received by a servlet--the other half of this EFSP simulation. The two callback messages should appear in the log files for the servlet container being used. They are also saved, by default, to a directory within the Web app's deployed Web root, called "efsp-stub". (This servlet is included in the "stub" Web app', part of OpenEFM.)
submit-filing-sample.sh" identifies itself by the EFSP username "gollum", password "precious". If no such EFSP exists in OpenEFM, the response XML should include an authentication error of some kind. The EFSP username and password to be used, along with the target URI and several other variables, can be changed by editing the "
submit-filing-sample.sh" script directly. One of the first things that script does is to define a number of environment variables, such as
TARGET_ENDPOINT. You can substitute your own values there.
Perhaps a better way to change these values, however, is to edit a file "
~/efilerc", in your home directory. This file, if present, is "sourced" by "
submit-filing-sample.sh", and it may contain any of the same variable declarations as appear in the first part of that script. Note that variables defined in "
~/efilerc" will override the values written directly into the script. The relevant variables are described below, under "Environment Variables".
./scripts/efsp-sim/submit-filing.sh" is the wrapper script that invokes an executable Java class,
SubmitFiling, to submit a test filing to an arbitrary target URI. It is invoked by "
submit-filing-sample.sh"; but unlike that script, "
submit-filing.sh" provides no default values. All required environment variables must be supplied in one way or another. You can write them directly into the script; or export them prior to invoking it; or define them in a wrapper script of your own, maybe using "
submit-filing-sample.sh" as a starting point.
Note: if you prefer, you can specify things directly on the command line, using the options (or "switches") required by the Java application. See "The Java Class" below.
For both of the aforementioned scripts, the following environment variables can be defined:
Messages generated by these EFSP-simulation scripts are currently formatted for the OXCI project (the format du jour involves SOAP with attachments and some needless EbXML tacked on the side). This is configured via the file "
./web/admin/WEB-INF/config.xml", which is the global configuration for OpenEFM. That file can be modified to change the message format expected by OpenEFM's "transceivers", and ideally, doing so will also change the format generated by these scripts, since the Java class described below shares that same configuration.
These scripts are just wrappers for a runnable Java class,
com.counterclaim.openefm.client.efspsim.SubmitFiling. Normally there should be no need to invoke it directly, but if you prefer to do so, just remember that the environment variables defined above only pertain to the scripts: the Java class itself has a normal command-line interface, using an option "-f" to designate the filing XML file path, for instance. Assuming you have set your CLASSPATH to include OpenEFM's code, this command should produce a usage message:
You will need to supply most of the options before this class will submit any filings. Incidentally, the two filing scripts described above will pass all command-line arguments on to the
java command, overriding the environment variables.
Update Author: Jason Van Cleve
Original Author: Jason Van Cleve