DOCGILITY - ENTERPRISE EDITION

# Configuration

This page presents the different configuration options to be used in the installation script. It provides options for modifying the configuration for your deployment environment.

# Environment Variables

The installation script comes with a config.yml file that is used to customize the variables used in the application. These settings are used to override the defaults when installing in th application helm script.

# General Variables

global:
  servicename: A CORP - BUYER
  appssologin: FAL

In the config.yml file, there are 2 variables that are specified under global:

  • global.servicename = This is the name of the application as displayed in the application as the title.
  • global.appssologin (allowed values = TRU or FAL) = This tells the UX to provide the link to select for SSO.

Under the app section, there is an additional field to control app-specific authentication for new email addresses. If you use SSO, you can set this to false.

  • app.norequireauthemail (allowed values = TRU or FAL) = if no authentication email is needed for a new registration, set this to TRU. Otherwise, set this to FAL.

# SMTP Variables - for Email Notifications

app:
  smtpusername: example@docgility.com
  smtpsendasemail: example@docgility.com
  smtppassword: xxxxxxxx
  smtphostname: smtp.gmail.com
  smtpport: 587

The below variables are used to configure the outbound notification emails used in the system. Configure to use for outbound emails from Docgility (like email alerts):

  • app.smtpusername = SMTP email used for authentication
  • app.smtpsendasemail = SMTP email alias used for sending (usually the same as above)
  • app.smtppassword = SMTP password
  • app.smtphostname = SMTP host name for the outbound email.
  • app.smtpport = SMTP port used for emails.

# SAML/SSO (Single Sign-on) Variables (TBD)

saml:
  activated: TRU
  idpentityid: http://www.okta.com/example
  idpsinglesignonserviceurl: https://example.okta.com/app/example_docgility_1/example/sso/saml
  idpx509cert: (certificate)

Single Sign-on is enabled by an industry standard SAML interface which configures for your internal SSO environment. By default, the installation script provides a deactivated configuration, but you can use the configuration file to override these settings in order to enable the sign-on service. By doing so, calls to the UXservice/SSO where UXservice is the url link to the UX service would trigger an automatic request to authenticate this user for the Docgility. The SSO service then provides the application with an authenicated email address that can be used to authenticate the user and automatically login to the applications.

The SAML configuration consists of:

  • saml.activated (allowed values = TRU or FAL) = Set to TRU if you want to enable SSO.
  • saml.idpentityid = url for the SSO service.
  • saml.idpsinglesignonserviceurl = url to the SSO sign-on service.
  • saml.idpx509cert = certificate for the SSO service.

These settings should be available from the IT department of your organization.

# Docgility VCN (Virtual Collaboration Network)

app:
  vcnenabled: TRU
  vcnaddress: https://vcntest.docgility.com
  vcnverifiedemailsuffixes: a.com
  vcnsourceid: M11
  vcnsourcekey: M11key
  vcnsecuritykeys: NONE
  vcndestkeys: M11key1,M11key2,M11key3

The Docgility VCN (Virtual Collaboration Network) is an external service that allows external parties to seamlessly collaborate and negotiate with you. By connecting to the VCN, contracts shared with the external parties are automatically available to them via this network.

  • app.vcnenabled (allowed values = TRU or FAL) = If not enabled, use FAL. Otherwise, use TRU and fill in the other values below.
  • app.vcnaddress = the external address used to communicate with VCN. Keep in mind that only https services are accepted to ensure that all communications are encrypted in transit.
  • app.vcnverifiedemailsuffixes = a comma-separated list of email address suffixes that are authenticated by your organization. For example, A corporation emails may be in the form of something@a.com. You would then list a.com in this list. Keep in mind that needs to be consistent with the list maintained at the VCN.
  • app.vcnsourceid = this is a unique identifier provided to your organization by the VCN registration.
  • app.vcnsourcekey = this is a comma-separated list of passwords that can be used to authenticate your orgnaization to the VCN.
  • app.vcnsecuritykeys = this is a list of security keys (if needed) to authenticate to the destination. (not usually used)
  • app.vcndestkeys = this is a list of security keys that allow your environment to authenticate calls from the VCN.

In the event of a data breach related to the VCN or the exposing of these credentials, you should contact the VCN provider to provide a new set of security keys for your organization.

# Scalability Variables

In Docgility, we have several AI pipelines that are both CPU and memory intensive. In order to speed AI pipeline execution, jobs are submitted to the docbeai service and parallelized using multiprocessing compute methods.

In Docgility, legal topic analysis runs very quickly but both PDF scanning and language translation are processes that require substantial runtime CPU and memory resources. If there are a large number of documents submitted concurrently that require PDF scanning (not Word .docx files) and non-English contracts, there will be a substantial spike in docbeai utilization. You can see this activity in the monitoring and logs.

In order to limit the possibility of overtaking available compute resources, we exposed the parameters for tuning the multiprocessing compute stack in the backend engine. So, as an example, if you expect a large number of concurrent jobs of PDF documents, it's best to reduce the multiprocpdfscans parameter so that no one PDF scan operation will overload the backend compute environment.

The following are the parameters to adjust as needed (in the helm chart, in the docbeai values.yaml file):

  • app.multiennonpdf (default: 50P) = the percentage of CPU to allocate for English docx documents
  • app.multiproctrans: (default: 30P) = the percentage of CPU to allocated for non-English document translations.
  • app.multiprocpdfscans: (default: 50P) = the percentage of CPU for PDF scan operations.

The way to read the parameters is that 50P would trigger the backend to use 50 percent of available CPUs for multiprocessing. So, the backend would be able to process 2 scan operations in parallel and additional scan operations would be queued. If you process each request as fast as possible(to optimize the UX experience) but you do not expect a large number of new concurrent jobs from users, you can increase these parameters to increase runtime multiprocessing.

The default values in the helm chart should be applicable for most environments and they are now exposed so that customer environments can tune performance to the needs of their user community.

As always, if overall load increases (or moving to production), you can also increase the number of docbeai production nodes and/or increase the CPU and memory for each docbeai service.

We recommend 1-2 docbeai services for a Docgility pilot with at least 8CPU and 32 GB of available memory. You can scale the number of docbeai services as needed for your environment.

# Backend Data Service Variables

In the helm chart, you will see configuration variables for MySQL, MongoDB, and Minio services. By default, these services are provided via an open-source bitnami images for each of these services. If you organization would prefer to use managed services for these data services, you can change these settings as ne

# Suggest Changes to Default Deployment (Depends on your client environment)

This is presented to demonstrate how to quickly bring all the components for Docgility to run in a very quick time. Some of the considerations -

  • Changing Images to Local Container Store. - You may want to pull the Docgility images into your local container store to stage them in order to install the software without further access to external resources.
    --> Pull the images and store in your environment. tar -xvf docbe-3.1.0.tgz to extract the helm chart and change the locations of the container images. You should be careful to maintain the image version numbers to be the same in your environment.

  • HTTPS and TLS certificates - To enable HTTPS in your environment, you may want to generate TLS certificates to secure the communications between web browser and application services. --> Generate TLS keys and add them to the helm chart to secure the communications.

  • Application Gateway Changes - In this script, the backend application services are exposed via a port through the application gateway. The user may change how the application gateway exposes these endpoints. Change your application gateway to use the new endpoints. Then, change the variables passed to the UX service to reference the application services. These settings are available as DOCGILITY_BACKENDSERVERENV in the docux/templates/_helpers.tpl file.

TIP

BE and UX need to be exposed in the client environment for the proper execution of the environment. Client should not use path-based routing, since the path exposed to the backend service calls. If path-based routing is used, the routing would need to strip the path to enable the original API call to backend services.

  • Managed Services (within client environment) - Currently, data services are provided by MySQL, MongoDB, and Minio (for interfaces to file storage services). If these services are available within the organization, you may want to change the helm script to reference these managed services.

    MySQL - In the helm chart, change the connection settings (including password) in docbe.mysql.env in templates/_helpers.tpl file. Also, disable the creation of the minio image in values file under the mysql section.

    MongoDB - In the helm chart, change the connection settings (including password) in docbe.mongodb.env in templates/_helpers.tpl file. Also, disable the creation of the minio image in values file under the mongodb section.

    Minio - In the helm chart, change the connection settings (including password) in docbe.minio.env in templates/_helpers.tpl file. Also, disable the creation of the minio image in values file under the minio section.

  • Using config.yml file to store your settings - The config.yml file is a template file that can be used to override the values settings in the helm chart. It is provided for the Use the config.yml file to store the organization secrets. You can modify the config.yml file to override the default settings in the configuration. You can then change the runinstall script to use the config.yml file. Settings include settings for SSO/SAML (for single signon in the application), SMTP (for sending emails from the application).