Home > Partners > Systems Integrators > Enterprise Architecture

Enterprise Architecture

1       Overview

1.1      Enterprise Deployments

HotDocs is deployed in many large organisations that require very high volumes of document through-put combined with very high availability. HotDocs Server, and in particular, the mechanism by which HotDocs Server interview logic is processed, makes HotDocs Server very well suited to such deployments.

Notable deployments of HotDocs Server include those which;

  • generate approximately 500,000 customer contracts per month,
  • are load-balanced; and
  • are architected with geographically redundant clusters.

 

1.2      Performance  

Although the following metrics are highly influenced by the underlying hardware, a single HotDocs Server installed on a virtualised environment can be expected to assemble between 10 and 50 pages per second of DOCX, per hardware thread. The precise number of pages per second is dependent on the complexity and density of the business rules defined within the template.

Under low to moderate load, increasing the number of hardware threads available to the virtualised guest operating system running HotDocs Server does not necessarily increase the response times for any single request (in fact tests suggest a slightly negative correlation between hardware threads and response times under low load). Increasing the number of threads increases the number of requests a HotDocs Server can handle simultaneously though owing to the stateless nature of a large scale HotDocs Server implementation, a single user session requiring the loading, filling and submission of the HotDocs interview, followed by the assembly of the document itself, typically only requires a three or four separate requests each typically taking tens or hundreds of milliseconds each to process.

The business logic for required by the intelligent HotDocs interview is processed in the client browser rather than on the server. This architecture means that many thousands of HotDocs users can be serviced by very few HotDocs Servers.

CPU performance is the single-biggest factor impacting HotDocs Server. CPU specification has a greater effect on response times than disk or network IO performance.

Client-side, browser performance can also be an important factor for larger and more complex interviews. Modern browsers are very much more efficient than their earlier counterparts. In addition, consideration and extra interview performance testing should be carried out where end user desktop environments are also virtualised and where many users’ desktops share the same hardware.

 

1.3      HotDocs BASICS

This document outlines how an organisation, new to HotDocs, might architect their own high performance, highly fault-tolerant HotDocs implementations.

As a starting point, we recommend those new to HotDocs, and who are integrating HotDocs Server into their own networks, architecture and business process, read this technical overview.

http://www.hotdocs.com/partners/systems-integrators/technical-documentation

It also a good idea to read this overview of HotDocs Server.

http://help.hotdocs.com/server/desktop/overview-hotdocsserver.pdf

 

The rest of this document outlines how HotDocs Server can be deployed in conjunction with other

 

2       Deploying HotDocs Server in a Large Enterprise

2.1      network components

A Large Scale HotDocs Server Deployment always contains these components.

HotDocs Component Purpose
HotDocs Server

The core engine for HotDocs Document Assembly. In load-balanced service architectures HotDocs Server is deployed on Windows Servers with its stateless REST WEB API. A large enterprise deployment

http://help.hotdocs.com/server/desktop/overview-hotdocsserver.pdf

 

In configurations where HotDocs Servers where the content or the cache for content is located on a shared network resource, it is necessary to configure the HotDocs Service to run under a domain account with read access to that resource. 

HotDocs Content HotDocs Server needs content in the form of HotDocs templates authored using HotDocs Developer. That content needs to be stored somewhere, either in the HotDocs template repository, or on a networked device.
HotDocs WEB API

Stateless REST API allowing business applications to communicate with a HotDocs Server or cluster of HotDocs Servers behind a load balancer.

The Statelessness of the HotDocs WEB API means that there is no need for a ‘sticky IP’ or affinity for a user session with a particular HotDocs Server.

In large scale deployments the WEB API is typically configured to run under SSL and under a domain account with access to the HotDocs Server content location.

HotDocs Template Repository The HotDocs Template Repository is a new utility for managing published templates. It supports version control, template uploading from HotDocs Developer and a powerful API (again stateless, restful and ideal for load balancing). Templates are stored in SQL Server, ideally with Enterprise level fault tolerance and failover. 
Non HotDocs Components Purpose
Hardware Load-Balancer Sends network request to alternate HotDocs Servers (or those that respond fastest – there are various algorithms that can be used). Load balancers automatically take servers out of the cluster if faults are detected. IBM’s Big IP F5 is a commonly used Hardware load balancer.
SAN Storage Area Network. High performance and highly fault-tolerant network storage.
Business Application This is the application that manages the interaction between the User and the HotDocs content. In a Bank this might be the lending application, or in a law firm might be a client inception or other type of Business Process Application.  
Cluster A series of servers that are typically virtualised. A large enterprise may have more than one cluster. Clusters may be geographically distributed so that even if power goes down in one building, requests are sent to an alternative building. As long as the end user is not in the building the user sits in, there will be no interruption to the user.   

 

2.2      Architecture Diagrams

Figure 1: HotDocs Enterprise configuration. Backend Publishing. Content managed via backend automated processed via client’s preferred or own content management. Sometimes implemented with automated scripts for migrating content from UAT or staging environments. 

 

Figure 2: HotDocs Enterprise configuration with standard HotDocs Template Repository. Business Applications manage interaction between content management and assembly service. 

 

 

3       HotDocs Professional Services

While this document is guide to the large scale, fault tolerant deployments, we recommend organisation contact their HotDocs account representatives before committing to any-one architecture.

HotDocs consultants have deployed HotDocs at some of the World’s largest organisations and are ready to offer their guidance.

HotDocs is continuously adding to its Enterprise product offering. Consulting your account manager will help in identifying new and up-coming products and feature that may be of benefit to your deployment.

With more than 1,000,000 users in 7,000 companies across 50 different countries,
you’ll be in great company when you deploy HotDocs.

  • RBS uses HotDocs document automation software
  • XL Insurance uses HotDocs document assembly software
  • Orrick, Herrington & Sutcliffe uses HotDocs document assembly software
  • ECE
  • Lockmann Krane uses HotDocs document automation software
  • Caltrans uses HotDocs document assembly software