Using the API a developer can write code that gathers data from any data base or other location, determine via program logic and interaction with users what templates are to be merged, and can call on the API to merge the data into one or more templates.
XpressDox API for .NET
Typically this API would be used to embed XpressDox document assembly capability into systems such as accounting, practice management, work flow and any other system where there is a need for creating non trivial documents. The templates used can be sourced from the Windows file system, or from any other source such as a document management system.
If there is no need to render the merged documents on the machine on which the API will operate, then it is not necessary to have Microsoft® Office Word installed on that system. Word is needed in order to author templates, which in turn requires XpressDox Desktop, and to render the resulting merged document for printing or reading. The function of merging the template and data that XpressDox performs does not require Word.
The XpressDox API is embedded in the .NET assemblies which are installed with the Word Add In instance of XpressDox, so no additional software is needed in order to use the API. But a sample Visual Studio solution (in C#) can be downloaded, along with formal documentation on the use of the API.
XpressDox API for the Web
Two mechanisms available to access XpressDox over the Internet. Using the hyperlink API, you would be able to upload selected templates onto the XpressDox server, into your own secure area. After that, you would add hyperlinks into you own web site which would enable a user to choose from the list of templates uploaded, and then run one or more of the templates. The interview which is then presented to them in the browser will be almost exactly the same as the desktop interview which XpressDox-in-Word presents to the Word user. After completing the interview, your web site can then contain a hyperlink which permits the user to download the merged document (if that is what you want) from the server to their local PC. In addition, the template author can specify an email address (or list of addresses) to which the merged document and the captured data set will be sent. This email address would typically be that of an internal staff member who would process the results in the appropriate way.
There is an implementation of the XpressDox Web Server which can be hosted on your company’s intranet. This would enable all users who are registered to use your intranet to run XpressDox templates via a web browser (for example, Internet Explorer, Mozilla Firefox, Google Chrome or Safari). The look-and-feel of the XpressDox Web Server version is very much like that experienced when a user selects to “run a template” using the XpressDox Word Add-in. In other words, the user is presented with in interface which mimics the desktop XpressDox Explorer from which they select the template(s) to be run. The user is then presented with an interview, which again mimics the interview presented by the Word Add-in version, including functionality such as “Use Previous Data” or “Use Other Data”, and access to data sources, etc. Once the merged document is created, it is stored in a location on the server which is configured using the normal XpressDox configuration mechanism. The same holds for the location of the captured data set. The user can then download the merged document from the server onto their local desktop, in either Word or PDF format, depending on how this is specified by the template author.
XpressDox API for COM
The second XpressDox API is for use by non .NET developers and it exposes an interface to XpressDox via COM. This interface is very similar to the XpressDox Engine API for .NET, the major difference being that templates are expected to reside somewhere on the Windows file system. This does not mean that they cannot actually be stored in a document management system or database, but that they will have to be moved onto the file system before the COM API will be able to access them.
Similarly to the XpressDox API for .NET, the COM API uses assemblies that are installed along with the Word Add-in instance of XpressDox. It also needs another assembly, which is downloaded and installed along with the XpressDox API in the download process referred to above. The COM API would be used in much the same circumstances as the XpressDox API for .NET.
Using either of the two APIs, the developer is responsible for the creation of an XML data set and also the selection of the template and the storing of the merged document created from them. It is necessary to note that much of the functionality available to the XpressDox Word Add-in is NOT available to the API user. This includes the dynamic data capture interview and all the features exposed via the Configuration user interface (e.g. Standard Folders for document and data storage, Data Sources, Standard Data Items, Configuration merging, etc.). All commands which can be coded into templates which refer to these features (i.e. all the Data Capture commands in the Command Editor, as well as Data Source commands and commands in the Advanced document and file handling section of the CE) will be ignored when the template merging is handled via either of the two XpressDox Engine APIs. However, the XpressDox SDK, which is a new addition (and can be downloaded from the same place as the API download) will make all of the above exclusions available to the developer – try it and see.
Develop custom interfaces but with all the features of XpressDox Desktop. This API grants the developer access to most of the functionality provided for the Word Add–in version of XpressDox, which is denied to the APIs as noted above. The XpressDox–In–Word API would be used specifically where there is a need to develop a custom user interface for the capture of data and/or the selection of templates, but where the developer would still like to have access to the features made available by the Word Add–in. Use of this API requires Microsoft® Office Word to be installed not only for rendering the merged documents, but for some of the other pre– and post–merging functions as well.
The XpressDox–In–Word API and documentation is installed along with the installation of the XpressDox Word Add–in. The documentation is provided in the Word document XpressDox In Word API Specification.doc which will have been installed into the My Documents\XpressDox folder the first time Word is loaded after XpressDox has been installed. The Specification document refers the developer to a Word template in the My Documents\XpressDox\Samples folder. This Word template contains some Word VBA macros which demonstrate the usage of some of the XpressDox-In-Word API functions as called from within a VBA macro.