Search

Which API should I use?

XpressDox has three APIs.  The choice of which to use depends on the particular application and situation.

XpressDox Engine API

The XpressDox Engine API comes in two flavours – the first is for access from Microsoft .NET programming languages.  Using this API a .NET developer will be able to write code which gathers data from any data base or other location, determine via program logic and/or interaction with users what templates are to be merged, and can call on the API to merge the data into the template(s).  The templates referred to using this XpressDox Engine API can be sourced from the Windows file system, or from any other source such as a document management system.

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.

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 MS Word installed on that system.  MS Word is needed in order to author templates (which in turn requires XpressDox to be installed as an Add-in to Word), 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 MS Word.

The XpressDox Engine 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, from the XpressDox web site.  The download can be accessed by navigating from any page on the XpressDox web site to PARTNERS > DEVELOPERS and following the links from there.

XpressDox Engine API for COM

The second flavour of the XpressDox Engine API is for use by non-.NET developers and it exposes an interface to XpressDox via COM.  It is called the XpressDox Engine API for COM, or  COM Engine for short. This interface is very similar to the XpressDox Engine API, the major difference being that templates are expected to reside somewhere on the Windows file system.   Which 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 Engine will be able to access them.  Similarly to the XpressDox Engine API, 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 Engine API in the download process referred to above.

The COM API would be used in much the same circumstances as the XpressDox Engine API.

Using either of the two XpressDox Engine 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 Template Author Toolkit (TAT), as well as Data Source commands and commands in the Advanced document and file handling section of the TAT) will be ignored when the template merging is handled via either of the two XpressDox Engine APIs.

Which brings us to

The XpressDox-In-Word API

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 Engine 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 MSWord 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.