Transaction Runner Implementation Guide

IntelleDoc Solutions Integration Options

CSi’s IntelleDoc Solutions is a multi-tier .NET Remoting application that provides document selection and document rendering. CSi’s business model is to partner with financial service companies, who integrate CSi’s components into their own software solutions. Because our partners have a wide variety of software architectures, CSi provides several different integration points within the Transaction Manager Suite of components.

You Are Here

This document is intended for partners who choose to integrate at the Transaction Runner level. This means the partner application will interface with CSi’s components using the methods and properties of the Transaction Runner. Since the Transaction Runner relies on both the Transaction Manager and Transaction Server, the document also discusses the installation and configuration of these components. This document does not describe the Transaction Server API. Partners who wish to interface directly with the Transaction Server should refer to the Transaction Server Implementation Guide.

About the Transaction Runner

The Transaction Runner is a transaction support system and serves as a means for managing document processing requests from client applications with CSi IntelleDoc Solutions^TM^ technology. The Transaction Runner receives data for a given transaction from client applications, then processes the data into document selection and document rendering for those client applications. Benefits of direct integration with the Transaction Runner are:

• Synchronous and asynchronous actions

• Load balancing

• Improved Fault tolerance

• Remote administration

• Improved performance over integrations using the Compliance Service web service

The Transaction Runner uses CSi’s Compliance Engine to select and render documents that are required to perfect a transaction.

Installing the Transaction Manager Suite

1. Double-click the CSi IntelleDoc Solution v7.00.msi to launch.

2. Wait while the installer prepares the program setup.

3. Click Next when the installer finishes program setup.

4. Read the licensing agreement, click Yes to accept the agreement, and click Next.

5. Enter your user name and organization and click Next.

6. Choose a setup type and click Next.

7. Click Install.

8. Wait while the installer installs the software.

9. Click Finish when installation is complete.

A number of fonts are installed into the C:\Program Files (x86)\Compliance Systems\CSi IntelleDoc Solutions v7.00 directory by the installer. These fonts must be installed on systems onto which CSi software integration components are redistributed. The installer does not automatically install them in order to make it clear upon which fonts the CSi software depends. Additionally, the CSi IntelleDocs Solutions rely upon the fonts Times New Roman and Courier New. These fonts are generally available on workstations using the Windows operating system. If they are not available on workstations using CSi IntelleDoc Solutions, then they must be installed.

Deployment and Scaling Recommendations

High-volume deployments require multiple Transaction Servers running on a dedicated server. This may include multiple virtualized servers on a single piece of hardware as long as one or more processor cores are dedicated to each virtual server. A single Transaction Server can handle a peak throughput of approximately 1,000 documents per hour. This may vary depending upon the number and speed of CPU cores, available memory, and other processes running on the system.

This table provides guidelines for the recommended number of Transaction Servers based on the expected number of transactions per month. These guidelines assume uneven distribution of transaction requests over time, that each transaction may render two or three times, and that each transaction contains between 4 and 30 documents.

Transactions Per Month	Number of Physical Servers or Virtual Machines	Configuration
500	1	Install Transaction Manager and Transaction Server on a single physical server.
5,000	4	Install one Transaction Manager and one Transaction Server on one server or virtual machine. Use 3 dedicated Transaction Servers on separate servers or virtual machines.
10,000	9	Install one Transaction Manager and one Transaction Server on one server or virtual machine. Use 8 dedicated Transaction Servers on separate servers or virtual machines.
25,000	24	Install 3 clusters, with each cluster comprised of: - One Transaction Manager and one Transaction Server on one server or virtual machine. - 7 dedicated Transaction Servers on separate servers or virtual machines.

Transaction Runner Configuration Settings

The Transaction Runner must be configured to connect to a single Transaction Manager instance. The following information, which is found in csi.Transaction.Runner.dll.config, must be added to the hosting application’s configuration file:

<configuration>
  <appSettings>
    <add key="JobManagerUri" value="tcp://localhost:7981/JobManager.rem"/>
  </appSettings>
</configuration>

The JobManagerUri value must point to the server and port where the Transaction Manager service is running.

Transaction Manager Configuration Settings

The Transaction Manager must be configured to listen on a specific channel/port. Its configuration file, TransactionManager.exe.config or csi.Transaction.ManagerWindowsService.exe.config, located in C:\Program Files\Compliance Systems\CSi IntelleDoc Solutions SDK v7.00.0\Transaction Manager Console, is structured as follows:

Which configuration file you use depends on whether you use the Transaction Manager as a command-line application or a Windows Service. Transaction Manager and Transaction Server Services provides more information on which method best suits your needs.

<configuration>
  <system.runtime.remoting>
    <application>
      <service>
        <wellknown mode="Singleton" type="csi.Transaction.Manager.JobManager, csi.Transaction.Manager" objectUri="JobManager.rem" />
      </service>
      <channels>
        <channel ref="tcp" port="**7981**" />
      </channels>
    </application>
</system.runtime.remoting>
</configuration>

The only configurable setting is the TCP port, in bold above. If this value is changed, the value of JobManagerUri in the Transaction Runner configuration file must also be changed to match it.

Transaction Server Configuration Settings

The Transaction Server must be configured to listen on a specific channel/port. Its configuration file, TransactionServer.exe.config or csi.Transaction.ServerWindowsService.exe.config, located in C:\Program Files\Compliance Systems\CSi IntelleDoc Solutions SDK v7.00.0\Transaction Manager Console, is structured as follows:

Which configuration file you use depends on whether you use the Transaction Manager as a command-line application or a Windows Service. Transaction Manager and Transaction Server Services provides more information on which method best suits your needs.

<configuration>
  <appSettings>
    <add key="**Key**" value="**Value**" />
    <add key="**Key**" value="**Value**" />
    …
  </appSettings>
  <system.runtime.remoting>
    <application>
      <service>
        <wellknown mode="Singleton" type="csi.Transaction.Server.JobServer, csi.Transaction.Server" objectUri="JobServer.rem" />
        </service>
      <channels>
        <channel ref="tcp" port="**7982**"/>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

The appSettings section contains key/value pairs, which are described in the table below. The only other configurable setting is the TCP port, which defaults to 7982.

Key (All keys are a single text string without breaks)	Value
JobServerUri	The URI of this Transaction Server. This is used only when Transaction Server is used with Transaction Manager. The Transaction Manager uses this URI to communicate with this server. The default value is tcp://localhost:7982/JobServer.rem. The port number used here (7982) must be the same as the port number specified in the <channel> element.
JobManagerUri	The URI of the Transaction Manager. This is used only when Transaction Server is used with the Transaction Manager. The default value is tcp://localhost:7981/JobManager.rem. The port number used here (7981) must be the same as the port number specified in TransactionManager.exe.config.
renderedFilePath	The directory path where temporary copies of PDF files are written when OutputFileData.ContentType is StorageType.inline. This directory is relative to the current application directory. The default value is RenderedFiles. Within the directory, Transaction Server will create a subdirectory named with the current date.
uncShareName	The remote path to a network share where output files are written when the JobTicket preferences specify RenderFormatType.pdfUnc or RenderFormatType.smartDocUnc.
uncShareLocalPath	The local path to the directory specified in uncShareName.
uriBasePath	The remote path to a URI where output files are written when the JobTicket preferences specify RenderFormatType.pdfUri or RenderFormatType.smartDocUri.
uriBaseLocalPath	The local path to the directory specified in uriBasePath.
formFileCacheCapacityDefault	The maximum number of FXL files that are cached in memory to improve performance. Files are retained in the cache based on the amount of time required to load them. Files that took the least time to load are removed from the cache first.
extractedDxlPath	This setting is used for testing and debugging. It is not used in a production environment.
repositoryFxlDir	The directory from which FXL files are read if a Transaction Server request specifies the ContentType as StorageType.fileName.
repositoryOxlDir	The directory from which OXL files are read if a Transaction Server request specifies the ContentType as StorageType.fileName.
repositoryMxlDir	The directory from which MXL files are read if a Transaction Server request specifies the ContentType as StorageType.fileName.
maxConcurrentJobs	The maximum number of requests that a JobServer object will accept at any one time.
TimeToRetainCompleted	The minimum time that a JobServer object will keep the results of a synchronous job. The default value is “00:00:30” (30 seconds).
SynchronousJobs
TimeToRetainCompleted	The minimum time that a JobServer object will keep the results of an asynchronous job when results have not been retrieved. The default value is “00:05:00” (5 minutes).
AsynchronousJobs
TimeToRetainsCompleted	The minimum time that a JobServer object will keep the results of an asynchronous job after the results are retrieved. The default value is “00:00:10” (10 seconds).
AsynchronousJobsAfter
RetrievalOfResults
TimeBetweenJobListPurgeCheck	The time interval between successive checks for jobs whose results are ready to delete based on the TimeToRetain settings above. The default value is “00:01:00” (1 minute).

Relative File Paths

When a render request references an FXL, OXL, or MXL file by name (e.g., StorageType.fileName), a relative path may be used to access a subdirectory of the file repository.

The repositoryFxlDir, repositoryOxlDir, and repositoryMxlDir settings designate the directory path to the library of files of that type (FXL, OXL, and MXL, respectively). A render request typically designates the name of the file in the library. However, there may be some situations where subdirectories are used to store particular documents—for example, custom documents for various customers. That subdirectory may be included in the render request in order to access the custom documents.

Transaction Manager and Transaction Server Services

The Compliance Service, via the Transaction Runner, communicates with the Transaction Manager and Transaction Server via .NET Remoting. The remoting services are launched in one of two ways: command line and Windows Services.

Launching via the command line is typically used during development, although it may be used for production if desired. The service runs with the credentials of the current user.

Launching via Windows Service enables the Transaction Manager and Transaction Server to run with any designated user credentials and allows the service to remain active when no user is logged in.

Launching Transaction Manager and Transaction Server from the command line:

1. Install the Transaction Manager and Transaction Server on the required machines.

2. Set the configuration files as necessary.

3. Execute TransactionManager.exe which is installed in the Transaction Manager Console directory.

4. Execute TransactionServer.exe which is installed in the Transaction Manager Console directory.

Launching Transaction Manager and Transaction Server using Windows Service

1. Install the Transaction Manager and Transaction Server on the required machines.

2. Double-click ManagerWindowsServiceSetup.msi in the \CSi IntelleDoc Solutions SDK v7.00.0\Transaction Manager Service directory to launch the Setup Wizard.

3. Follow the steps provided by the Setup Wizard to install the Transaction Manager as a Windows Service.

4. Double-click ServerWindowsServiceSetup.msi in the \CSi IntelleDoc Solutions SDK v7.00.0\Transaction Server Service directory to launch the Setup Wizard.

5. Follow the steps provided by the Setup Wizard to install the Transaction Server as a Windows Service.

The Windows Service automatically starts when the system is restarted. To start the Transaction Manager and Transaction Server manually after the initial installation:

1. Open the Microsoft Management Services Console dialog by clicking Start>Control Panel>Administrative Tools>Services.

2. Select CSiTransactionManager from the list of local services.

3. Choose Action>Start.

4. Select CSiTransactionServer from the list of local services.

5. Click Action>Start.

The user account under which these services run is configured by opening the Properties dialog for the service in question:

1. Right-click on the service name and select Properties from the context menu.

2. View the Log On tab.

Simple Integration

After installing and configuring the software, write a simple application to confirm that you have installed and configured it correctly. Use the Sample Code as a reference to create your first application. This code shows how to render a document as a PDF. Building an application similar to this will help you find any problems with your installation. It will also help you become familiar with the Application Programming Interface.

You will receive training as part of the integration. Writing a simple application is part of this training.

Supported Actions

After the Transaction Manager Suite is installed, configured, and tested to make sure it works, you can perform several actions.

• selectDocs
• renderDoc
• renderDocSet (asynchronous)
• transaction (asynchronous)
• getDocInfo
• checkForResponse
• cancelJob

Input Files

The Transaction Runner uses several different input files.

FXL Document Files

FXL is the file format used by an IntelleDoc file. It is an encrypted XML file that contains document content, content selection logic, and associated content metadata. It also includes data-processing logic for selecting documents and additional selection metadata. They perform two types of selection:

• Document selection. FXL files may be used to generate a list of documents required to perfect a transaction.

• Content selection. FXL files may be used to generate the text content of a document.

Multiple FXL files can be chained together in the Compliance Engine to enhance functionality. For example, partner and institution document-selection customization may be handled by chaining additional partner-specific and institution-specific FXL files behind a generic/general document selection FXL file.

OXL Overlay Files

OXL is the file format used by overlay files. It uses XML to store overlay information.

An overlay is a field used to add additional elements to a CSi document. The element can be:

• fixed text - a static text label that you define for the field. They may also hold variable datapoints inserted as part of the field text data.

• mergable text - data from any datapoint that you define for the field.

• images - contains a datapoint that specifies an image that is used for display in the field.

• graphic shapes used to format the document or increase its readability. These can be lines, rectangles, or circular shapes.

TXL Data Files

TXL is the data file format modeled on the CSi Data Schema. TXL is an XML file that supplies all of the information necessary to document a given transaction and may require multiple IntelleDocs to contain and present that information. Value elements in a TXL file may have a number of corresponding attributes that dictate their display characteristics.

DXL Data Files

DXL is the file format for an IntelleDoc data file. It is an XML file that supplies to the Compliance Engine data values along with the associated layout directives for values that are displayed. A DXL file corresponds to a single IntelleDoc form. Data values that are displayed on an IntelleDoc form may have a number of corresponding attributes that dictate their display characteristics.

DXL files are supported by the Transaction Server for backward compatibility only. DXL is not supported in new integrations. TXL is preferred to DXL because you can process multiple documents at the same time.

Output Options

CSi IntelleDoc Solutions provide several options for rendering a document. A partner can:

• Create PDF files with or without interactive form fields that allow the user to enter data through Acrobat Reader.

• Send documents directly to a printer.

In the case of document variations of the Adjustable Rate Note and Fixed Rate Note, a SMART Doc® can also be requested.

For output options other than SMART Doc, you can produce one document at a time or combine a set of documents into a single PDF or print job.

Combining PDF Output

The CSi IntelleDoc Solutions™ software components can render a set of documents for a transaction as individual PDF files, with one PDF per document, or as a combined PDF, with all or a subset of documents required for the transaction contained in a single PDF.

Combined PDFs offer an important benefit to financial institutions. Because all pages of all documents for the transaction will be sent to a printer as a single print job, a combined PDF eliminates the possibility that documents from two different transactions will be interleaved in a printer’s output tray.

PdfCombine

PdfCombine is a stand-alone class library that is installed with the CSi IntelleDoc Solutions SDK. It concatenates a list of PDF files into a single PDF file, including locked PDF files generated by CSi IntelleDoc Solutions software. This functionality is part of the Transaction Server API.

The csi.Transaction.Shared.JobTicket.PdfCombineList property is used to designate the list of PDF files to include. The Transaction Runner action combinePdfs is used to perform the PDF file combination.

JobTicket properties are used as follows.

Prefs	Ignored - there are no preferences that are relevant to this action.
DocList	Ignored.
OxlList	Ignored.
MxlList	Ignored.
DataValuesList	Ignored.
DstFile.PdfCombineProperties.ContentType	Designates the manner in which the resulting PDF file is returned. Allowed content types include inline, unc, and uri. Other content types will generate an error.
DstFile.PdfCombineProperties.Encoding	Designates how to encode the resulting PDF file data. This value should be none when the resulting PDF is returned as a file path (e.g., unc and uri). It should be base64 when the resulting PDF is returned inline.
DstFile.PdfCombineProperties.InsertBlankPagesForDuplexPrinting	Designates whether a blank page should be inserted when needed to ensure that the first page of a document will not print on the back of the last page of the preceding document when the combined PDF is duplex-printed.
DstFile.Path	The file path to which the resulting combined PDF file is written. This property is ignored when DstFile.PdfCombineProperties.ContentType is inline.
PdfCombineList	List of input PDF files to be combined. The PDF files are packaged as a list of FileData objects. The order of this list drives the order in which they appear in the combined PDF file. This property is ignored for all other actions.

SMART Docs

MISMO (the Mortgage Industry Standards Maintenance Organization) has developed SMART Docs as a method for representing mortgage documents in electronic format. CSi currently supports the output of its Adjustable Rate Note and Fixed Rate Note in the SMART Doc version 1.02 format, which is a version synchronous with MISMO version 2.3.

In order to output CSi documents in the SMART Doc format:

• the financial institution must have a license key that supports SMART Doc output

• the partner must submit a job ticket requesting smartDoc as the OutputFileType

CSi recommends that the job ticket requesting a SMART Doc specify a StorageType of inline.

Other JobTicket properties that may be specified follow the general MISMO data groupings of Header, Data, View (XHTML), and Audit.

CSi manages the viewing of SMART Docs with its Compliance Engine. There are no public properties provided for the View element.

In addition to the MISMO elements noted above, CSi provides certain global public properties.

MersMinNumber	Required. Designates the unique MERS MIN (Mortgage Identification Number) used to track a mortgage loan throughout its life. This is an 18-digit number, where the first component of the number is used to identify the financial institution, the second component is used to identify the loan, and the final digit is used by the financial institution for internal purposes.
SmartDocVer	Optional. Designates the version of SMART Docs used to generate this SMART Doc.
PackageIdentifier	Optional. Designates an identifier for the package with which the SMART Doc is a part.

Header Entry

The header element contains information about the entire SMART Doc document.

headerEntry.DocumentInformationMustBeRecorded	Required. Designates if the SMART Doc is to be recorded. True indicates that it will be recorded. If this property is not included in the JobTicket, then the default MISMO value is applied to the SMART Doc.
headerEntry.DocumentInformationNegotiableInstrumentIndicator	Required. Designates if the SMART Doc is considered a negotiable instrument. True indicates that it will be treated as a negotiable instrument.
headerEntry.MetaDataName	Optional. Provides a descriptive name for a characteristic of the document.
headerEntry.MetaDataValue	Optional. Provides a the value associated with the MetaDataName attribute.
headerEntry.SignatureModelSignatureType	Required. Designates the type of signature. Valid values include Text, DigitalSignature, Object, Image, or Other.

Data Entry

The data element is optional and contains information associated with the SMART Doc.

dataEntry.mainEntry.LoanMismoVersionIdentifier	Read only. Reads the MISMO version.

Audit Entry

The audit element contains information that is logged about events performed on the document as well as status information.

auditEntry.AuditEntryPerformedByName	Required. Identifies the entity who performed the action.
auditEntry.AuditEntryDateTime	Required. Identifies the date and time that the action occurred. THe value must conform to the Schema DateTime data type and must be immediately followed by z to indicate Coordinate Universal Time (UTC) or, to indicate the time zone, immediately followed by a sign + or - followed by the difference from UTC represented as hh:mm. If the time zone is included, both hours and minutes must be present.
auditEntry.AuditEntryActionType	Required. Identifies the type of action that was taken and is being recorded. Valid values include Unpopulated, Populated, Signable, Recordable, Signed, Recorded, Voided, Exported, PaperedOut, Validated, and Other.
auditEntry.AuditEntryActionTypeOtherDescription	Records additional information when Other is selected as the value for AuditEntryActionType.
auditEntry.AuditEntryID	Optional. Identifies the specific audit trail entry.
auditEntry.AuditEntryDetailDescription	Optional. Records additional, supplemental details regarding the audit trail item.
auditEntry.AuditEntrySystemAuthenticationName	Optional. Records a system-assigned value used to identify the system that generated the audit trail entry.
auditEntry.AuditEntryNextActionDescription	Optional. Identifies the next step or action to be taken with the document. This is intended to help manage the loan workflow.

Optional Feature Settings

Optional feature settings are preferences that allow a business partner to optimize how documents are produced. Each business partner can change these feature settings to fit their specific business needs.

Blank Fields

A blank field refers to a data/fill-in datapoint that is rendered on a dynamic document as an empty fill-in field. The dynamic documents are assembled based on customer and transaction-specific data creating a customized document with fully integrated compliance logic and knowledge. Blank fields are used in documents that are intended for completion later. For example, a notary datapoint may be left blank for later completion at another location. There may also be instances when the datapoint information is not known at the time the document is rendered.

A datapoint is designated as a blank field by setting its value to an empty string and setting its DXL/TXL EmptyValue attribute to blankField.

A blankable datapoint refers to a data/fill-in datapoint whose value may be empty without triggering the “form must be completed” margin message when EnableBlankFields is true.

Structural datapoints are not allowed to be blank, as they are required to render the document. The only datapoints that may be blank are:

• data_required
• data_conditional
• optional

When blank fields are enabled, a non-zero blank field width allows space representing the blank datapoint to be rendered in the document. When a blank field width of zero is used, no space for the datapoint is rendered in the document. Blank fields are enabled with the BlankFields property.

The presentation of blank datapoints is managed in several locations, with an order of precedence determining if a blank datapoint is expressed in the document as a blank space.

Location	Precedence (1 is highest)	Description
DXL file	1	emptyvalue attribute within the datavalue element.
TXL file	1	emptyvalue attribute within a leaf node.
FXL file	2	Cannot be modified.
Transaction Runner	3	The Transaction Server sits behind the ComplianceService and ComplianceServiceSimple applications. Blank fields are enabled in the Transaction Server via the si.Transaction.Shared.JobTicket class as seen below

using csi.Transaction.Shared;
…
JobTicket jobTicket = new JobTicket();
jobTicket.Prefs.FieldPrefs.EnableBlankFields = true;
jobTicket.Prefs.FieldPrefs.BlankHighlight = DataFieldPreferences.BlankHighlightType.gray30;
// Not required, but helps readability of rendered document.
jobTicket.Prefs.FieldPrefs.RenderForDataCollection = true;

The background color of blank datapoints is managed with the BlankFieldsShading property.

Blank Width

The blankWidth attribute of DXL and TXL data elements indicates the character width of the field when it has an empty value.

If not set explicitly, a default width is used. The default for a specific datapoint may come from the datapoint dictionary of the FXL file being evaluated, or, if it is not provide there, the internal default of 10 is used.

Valid values include integers with a value of zero or greater. An empty data value with a blank width of zero is not rendered and will therefore not appear on the rendered document.

This property is ignored if the data value is not empty, or it is not designated as a blank field, or if blank fields are turned off.

For example, the following code segment sets the default blank width to 28:

using csi.Transaction.Shared;
…
JobTicket jobTicket = new JobTicket();
jobTicket.Prefs.FieldPrefs.BlankWidth = 28;

The preference setting takes precedence over the FXL file. If neither is defined, the hard-coded default of 10 is used.

Empty Value

The emptyValue attribute of DXL and TXL data elements indicates how an empty data value is treated when a document is rendered. Possible values include:

blankField	Indicates that, when blank fields are turned on, an empty value is rendered as a blank field according to the blankwidth value. When blank fields are turned off, an empty value is treated as an empty string.
emptyString	Indicates that an empty value is treated as an empty string. This allows an empty value to be treated as an empty string, not a blank field. Datapoints with an emptyString value are generally not rendered, and therefore have limited utility.
ignoreValue	Indicates that an empty value is ignored and treated as if no value was supplied for the datapoint.

If not set explicitly, a default value is used. The default can be specified in the Job Ticket. If neither is defined, the internal default of ignoreValue is used.

For example, the following code segment sets the empty data default to blankField.

using csi.Transaction.Shared;
using csi.Utility.Datapoints;
…
JobTicket jobTicket = new JobTicket();
jobTicket.Prefs.FieldPrefs.EmptyDataValueDefault = DataValue.EmptyValueType.blankField;

Changing the default EmptyDataValueDefault preference must occur on a job-by-job basis.

If the jobticket preference setting is not set, the hard-coded default of ignoreValue is used.

To be backwards compatible (prior to February 2009), set EmptyDataValueDefault to blankField.

Blank Fields in TXL Files

A feature that is important in some implementations involves setting the emptyvalue attribute to “ignoreValue”. This allows a TXL file to be generated (i.e., via XSLT) that contains a number of empty values, and those empty values will be ignored.

Sample

In the following sample data set, the middle name node will cause a blank field to be generated (assuming blank fields are enabled), and the name suffix node will be ignored regardless of whether blank fields are enabled.

<TransactionValues>
  <Entities>
    <Entity id="Borrower\_1">
      <Roles>
        <Role>Borrower</Role>
      </Roles>
      <Name>
        <First>Will</First>
        <Middle blankwidth="10" emptyvalue="blankField"></Middle>
        <Last>Badger</Last>
        <Suffix emptyvalue="ignoreValue"></Suffix>
      </Name>
    </Entity>
</Entities>
</TransactionValues>

Blank Fields in DXL Files

In the following sample data value set, the form will render as follows (assuming that blank fields are enabled):

• dp_01 will render as a blank field with a width of 10 characters.

• dp_02 will not render because blankwidth is zero.

• dp_03 will not render because emptyvalue is emptyString.

• dp_04 will render as a “Apollo”, blankwidth and emptyvalue are ignored.

<datavalues>
  <datavalue name="dp_01" blankwidth="10" emptyvalue="blankField" />
  <datavalue name="dp_02" blankwidth="0" emptyvalue="blankField" />
  <datavalue name="dp_03" blankwidth="10" emptyvalue="emptyString" />
  <datavalue name="dp_04" blankwidth="10" emptyvalue="blankField">Apollo</datavalue>
</datavalues>

Detecting Pending License Key Expiration

When a license key is close to its expiration date, the software generates a warning indicating how many days are left. This warning is generated upon each request to the software during the last 30 days of the licensing period.

To detect this warning programmatically, search the status messages returned from the job request for a warning with a code of “licenseKeyExpire”. Following is some code to illustrate what this might look like.

...
csi.Transaction.Runner.JobRunner jobRunner = new csi.Transaction.Runner.JobRunner( jobTicket );
csi.Utility.Messaging.Status status = jobRunner.Go( jobManagerUri, ActionType.renderDoc );
bool warningFound = false;
for(int i = 0; (i < jobRunner.JobStatus.MessageList.MessageCount) && !warningFound; i++ )
{
  csi.Utility.Messaging.Message message =
    (csi.Utility.Messaging.Message)jobRunner.JobStatus.MessageList.Messages[i];
  warningFound = (message.Level == csi.Utility.Messaging.Message.LevelType.warning)
    && (message.Code == "licenseKeyExpire");
}
...

Controlling Log File Size

CSi IntelleDoc Solutions uses the log4net library to handle logging services. The Compliance Engine configuration file csi.Engine.Configuration.dll.config handles logging directives for nearly all CSi IntelleDoc Solutions API assemblies.

By Log Level

The easiest way to reduce log file size is to set the log level to WARN or ERROR, thus suppressing all DEBUG and INFO level messages. For example:

...
<root>
  <level value="WARN" />
  <appender-ref ref="RollingLogFileAppender" />
</root>
...

By Specifying Assemblies

The logging level for specific assemblies can be set as well. For example, the following configuration logs warnings and errors for the csi.Transaction.Server assembly, but only errors for everything else:

...
<root>
  <level value="ERROR" />
  <appender-ref ref="RollingLogFileAppender" />
</root>
<logger name="csi.Transaction.Server">
  <level value="WARN" />
</logger>
...

By Maximum File Size

Another way to limit the size of the log file is to designate a maximum size. In the following example, the file will roll once it reaches 1000KB and up to 10 old files will be kept.

...
<appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
  <file value="\${APPDATA}\\CSi IntelleDoc Solutions Software\\IntelleDoc Visualizer\\engine.log" />
  <appendToFile value="true" />
  <rollingStyle value="Size" />
  <maxSizeRollBackups value="10" />
  <maximumFileSize value="1000KB" />
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date \[%thread\] %-5level %logger \[%ndc\] - %message%newline" />
  </layout>
</appender>
...

By Date

Log files can be rolled by date as well. Here, the file will roll every day.

...
<appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
  <file value="\${APPDATA}\\CSi IntelleDoc Solutions Software\\IntelleDoc Visualizer\\engine.log" />
  <appendToFile value="true" />
  <rollingStyle value="Date" />
  <datePattern value="yyyyMMdd" /> <!-- roll every day -->
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date \[%thread\] %-5level %logger \[%ndc\] - %message%newline" />
  </layout>
</appender>
...

Other configuration options are available. Detailed information can be found at http://logging.apache.org/log4net/release/manual/configuration.html[]{#H_29941 .anchor} http://logging.apache.org/log4net/release/manual/configuration.html.

Dependencies and Technology Requirements

Technology	Workstation Applications:	Server Components:	Web Server
	Custom Document Editor IntelleDoc Viewer IntelleDoc Advisor IntelleDoc Visualizer	Transaction Manager Transaction Runner Transaction Server Compliance Engine	Compliance Service
Processor	1.8 GHz Intel Core 2 Duo equivalent or better.	2.0 GHz Intel Core 2 Duo equivalent or better.	2.0 GHz Intel Core 2 Duo equivalent or better.
RAM	1 GB (minimum). 2 GB (minimum) for Windows 7.	2 GB (minimum).	2 GB (minimum).
Hard Drive	100 MB free space or more.	10 MB free space or more for software. Up to 1 GB free space for document library.	10 MB free space or more for software. Up to 1 GB free space for document library.
LAN	TCP/IP 100 Mbps or better. Applicable only when the documents being read/written are stored on the network.	TCP/IP 100 Mbps or better.	TCP/IP 100 Mbps or better.
Internet or WAN	NA	2.4 Mbps or better. Applicable only when components or document library are accessed via internet or WAN.	2.4 Mbps or better.
Operating Systems	Windows Server 2003 - all editions, latest service pack. Windows Server 2008 - all editions, latest Service pack. Windows 7 - latest service pack. Windows 8 - latest service pack.	Windows Server 2003 - all editions, latest service pack. Windows Server 2008 - all editions, latest Service pack. Windows 7 - latest service pack. Windows 8 - latest service pack.	Windows Server 2003 - all editions, latest service pack. Windows Server 2008 - all editions, latest Service pack. Windows 7 - latest service pack. Windows 8 - latest service pack.
.NET Runtime	4.6.2.	4.6.2.	4.6.2.
Internet Information Services (IIS)	NA	NA	V6.0 or better.
Fonts	Times New Roman Courier New	Times New Roman Courier New	Times New Roman Courier New

Glossary of Terms

blank field

A dynamic datapoint approved by CSi to have the data entered manually by the end user after the document is printed.

Compliance Engine

A CSi IntelleDoc Solutions™ assembly that evaluates input transaction data and selects appropriate documents or document content based on a given data set, returns error messages if more information is needed, and renders the documents. These documents are rendered on screen as well as output as PDF, printed copy, or image files.

Compliance Service

The Compliance Service is a web service that provides access to CSi IntelleDoc Solutions™ functionality through a web service interface.

CSi IntelleDoc Solutions™

An integrated solution suite of dedicated compliance modules delivered as .NET-managed code. It is dedicated to the production of CSi’s document library in both static and dynamic formats.

data_conditional

A datapoint usage type designating a datapoint that may be required, depending on the values supplied for one or more other datapoints. If the datapoint is required and not supplied, the Compliance Engine displays and prints the document with the warning message Form must be completed at the top.

data_required

A datapoint usage type designating a datapoint as required in order for the document to be legally compliant. If such a datapoint is not supplied, the Compliance Engine displays and prints the document with the warning message Form must be completed at the top.

datafield

The location on an eDoc form for the variable data associated with a datapoint. There can be many datafields associated with a single datapoint.

datapoint

A CSi variable data placeholder used to populate a document with transaction-specific information. Datapoints may have an associated data type for data validation. Datapoint names are not case sensitive.

datapoint usage type

The use of dynamic datapoints is indicated by one of the following: structural_required; structural_conditional; structural_optional; data_required; data_conditional; and optional. A structural_required or structural_conditional datapoint is generally part of a logic question that drives document creation.

DXL

An eDoc data file. An XML file that contains data values along with the associated layout directives for values that are displayed. It is used to aid processing of FXL files. It is equivalent to a DAT file.

fixed text overlay

An overlay field that holds static text labels. They may also hold variable datapoints inserted as part of the field text data.

FXL

An eDoc file. It is an XML file that contains coded file information as well as metadata about its form and contents. It is equivalent to an FAO file.

image overlay field

An overlay field that holds an image specified as the datapoint for the field.

IntelleDoc

A dynamic document supporting financial transactions that is assembled based on transaction-specific information.

Job Ticket

An object that packages all information related to the document request for the Transaction Manager, including the transaction data, preferences information defining document setup, and custom overlay information.

mergable text overlay

An overlay field that can hold any single datapoint.

optional

A datapoint usage type that designates a datapoint that is not required. If a value is supplied, the Compliance Engine includes this value in the document. If no value is supplied, the Compliance Engine displays and prints the document with no warning or error messages.

overlay field

A field used to add additional elements to an existing CSi eDoc or to a custom document.

OXL

The file format used by overlay files, which store overlay information for the document as XML.

PDF

An acronym for Portable Document Format, a file format developed by Adobe Systems that captures the text, graphics, and formatting of a file so that it may be viewed and printed correctly without the original authoring software. Adobe Reader is distributed by Adobe Systems as freeware to display or print PDF files.

primary overlay

An overlay field used as the standard for controlling the properties and layout of other overlay fields.

realized datapoint name

A realized datapoint name is one that has been populated with suffix data values (for datapoints with suffixes), as opposed to the generic “.i” suffix placeholder value.

secondary overlay

An overlay field that derives its properties and layout on the document from a primary overlay.

SOAP

An acronym for Simple Object Access Protocol, SOAP is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS.

structural_conditional

A datapoint usage type designating a datapoint as potentially required, depending on the values supplied for one or more other datapoints. If the datapoint is required and not supplied, the Compliance Engine displays a black screen with an error message.

structural_optional

A datapoint usage type designating a datapoint that is not required for a document to be considered complete, but affecting the structure of the document if values are supplied to it.

structural_required

A datapoint usage type designating a datapoint as required to render the document. If such a datapoint is not supplied, the Compliance Engine displays a black screen with an error message.

suffixing

A datapoint style that allows a single datapoint name to reference multiple values. It continues to render as long as data is sent to it. For example, if eight signatures are required on a document, a suffixed signature datapoint renders eight times so that all eight signers are listed on the document.

Transaction Manager

The Transaction Manager is a component within the Transaction Manager Suite. It assigns job IDs to Job Tickets brought by the Transaction Runner and selects a server URI for job processing based on a load-balancing algorithm.

Transaction Runner

The Transaction Runner is a transaction support system and serves as a means for managing document processing requests from client applications with CSi IntelleDoc Solutions™ technology. The Transaction Runner receives data for a given transaction from client applications, then processes the data into document selection and document rendering for those client applications.

Transaction Server

The Transaction Server is a .NET assembly that processes Job Ticket data into document selection and document rendering for the client applications. It translates input data into multiple Compliance Engine transactions, if necessary, and executes the Compliance Engine. The Transaction Server also reports job status and performance information to the Transaction Manager.

TXL

An XML data file based on the CSi Data Schema containing all of the transaction data necessary to document a given transaction.

unrealized datapoint

An unrealized datapoint is one that is not yet populated with suffix data values (for datapoints with suffixes), and uses the generic “.i” suffix placeholder value.