Configure a multi-application environment

You are the site administrator for a large legal firm, and you have set up a number of XpressDox applications. Each application has its own set of templates which are located in a folder for each application. Say for example there is an Estates application, a Litigation application and a Conveyancing application, and these are in the folders P:\SharedApplications\Estates, P:\SharedApplications\Litigation and P:\SharedApplications\Conveyancing, respectively. Drive letter P is mapped to a shared folder on the network.

The default location for merged documents as well as captured data files is the same folder as that in which the template is located. Clearly this is a good place to start off, but for more sophisticated applications this is not really appropriate.

What this example will show is how to configure the three applications so that when a template is required for a particular client (i.e. in this recipe a customer of the firm of attorneys), then the template will be selected and run, and the merged document will be saved in a sub-folder of the application folder, where that sub-folder’s name is somehow related to the name of the client for whom the template is being run (i.e. the sub-folder will have the client’s name and/or account number or file number). The name of the merged document file in that sub-folder will be the same as the template file name.

The data for each client should be saved, in a similar manner, but all data for a client will be kept in one file (regardless of the template that the data were captured for) and that data file’s name should also somehow related to the client’s name.

Let’s assume that the merged document sub-folder will be MergedDocuments, and that the saved data sub-folder will be SavedData.

Let’s further assume that the way of identifying the client is via the firm’s File Number which is assigned to that client (or to the particular case that is being worked on for that client). This file number needs to be captured for each template being run, and so the fillpoint «FileNumber» will appear on each template.

You can insist that this data element is never left blank by using the command «Required(FileNumber)» rather than, or in addition to, the simple fillpoint.

Now it’s a case of configuring the three applications so that their merged documents and captured data are saved to the correct locations.

An example would be to configure the Standard Folders for the P:\SharedApplications\Estates application as follows:

Document Save Folder:
P:\SharedApplications\Estates\MergedDocuments\<FileNumber>

Pattern for saved file name:
<TemplateName>

Data Save Folder:
P:\SharedApplications\Estates\SavedData

Pattern for saved file name:
<FileNumber>

Then in the same way, the Litigation application could be configured as:

Document Save Folder:
P:\SharedApplications\Litigation\MergedDocuments\<FileNumber>

Pattern for saved file name:
<TemplateName>

Data Save Folder:
P:\SharedApplications\Litigation\SavedData

Pattern for saved file name:
<FileNumber>

However, XpressDox’s configuration merging feature, together with the Windows File System’s relative path addressing mechanism, makes this multi-application configuring a much simpler task.

So, instead of the above example configuration settings being done, the configurations for the separate application folders should be left untouched – i.e. empty.

Then, the applications’ common parent folder, i.e. P:\SharedApplications is configured instead, so that its Standard Folder Configuration looks like this:

Document Save Folder:
.\MergedDocuments\<FileNumber>

Pattern for saved file name:
<TemplateName>

Data Save Folder:
.\SavedData

Pattern for saved file name:
<FileNumber>

As long as the application folders’ Standard Folder configurations have no entries in them, the merged configuration setting of the parent folder will apply, and the same result will be obtained: i.e. the merged documents will be saved under the application’s template folder in a folder called MergedDocuments, etc.

This will also mean that any new application added into this folder hierarchy will inherit that same Standard Folder configuration automatically.

Lastly – the above won’t really work (that’s an understatement) unless users capture the correct FileNumber value when running a template. This is because the FileNumber data element forms part of either the path or the file name of the merged documents as well as the saved data set. You can insist that at least a non-empty value is supplied by including the command «Required(FileNumber)» in each template – when XpressDox sees this it will not accept the “OK” button in the data capture UI for that template until the user has supplied a value for the required data element(s).

If you are using the IncludeTemplateText command to include help text on all the templates in the suite, then it would make sense to put the «Required(FileNumber)» command into the same file as the help definitions.

Ensuring the same letterhead template is used for all applications

Have a look at the recipe entitled Use the same letterhead throughout the company. It relates how a letterhead template is created and it will have been stored with a name like P:\SharedArea\Templates\Utilities\Letterhead.xdtpl.

All that’s needed now is that the configuration for P:\SharedApplications is configured so that it has a Helper folder with suitable Alias (in example 2 it was “utilities”, and all the «BaseTemplate» commands referred to the letterhead template with the “utilities:” prefix), and which refers to the folder where the letterhead template is.

The configurations for the application folders (i.e. P:\SharedApplications\Estates, P:\SharedApplications\Litigation and P:\SharedApplications\Conveyancing) inherit the Helper Folders from their parent folder(s) in the same way as they inherit the Standard Folders. That means that as long as the application folders leave their Helper Folders unconfigured (or at least do not have a Helper called “utilities”), then they will inherit that “utilities” Helper from their parent folder.

All that is then needed is to make sure that the various templates (in the application folders) that will be based on the letterhead all refer to the letterhead template via the alias “utilities”, i.e. «BaseTemplate(utilities:Letterhead)».

The configuration screen for folder P:\SharedApplications would look like this:

What if the FileNumber has bad filename characters?

So far the discussion has assumed that whatever value the user types in as the data element FileNumber will be acceptable to the Windows file system as a file name (or folder name). But often this might not be the case, either because the user makes a mistake, or possibly because the file numbering convention at a particular site requires that the file numbers have characters such as “\” in them, which would have undesirable results when interpreted as a file or folder name.
If this is the case, then you could invent a new data element name, say FileNumberFileName and use <FileNumberFileName> in the configuration wherever the above example uses <FileNumber>.
Then all that remains is to get the required value into the FileNumberFileName data element. This can be done using the very powerful «GetValidFileName()» function. The value of FileNumber can be passed to the function, asking that invalid file name characters be replaced by, say, a hyphen, and that the result be stored in the newly created data element. This is done by placing the following anywhere in the template:

«CreateDataElement('FileNumberFileName',GetValidFileName(FileNumber,'-'))»