Transaction Server 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 Server level. This means the partner application will interface with CSi’s components using the methods and properties of the Transaction Server. This document does not describe the Transaction Runner API. Partners who wish to interface directly with the Transaction Runner should refer to the Transaction Runner Implementation Guide.

About the 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.

Installing the Transaction Server

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.

Transaction Server Configuration Settings

Transaction Server settings are configured using your application’s configuration file. The structure of this file is as follows:

<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 SynchronousJobs	The minimum time that a JobServer object will keep the results of a synchronous job. The default value is “00:00:30” (30 seconds).
TimeToRetainCompleted AsynchronousJobs	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).
TimeToRetainCompleted AsynchronousJobsAfter RetrievalOfResults	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).
TimeBetweenJobList PurgeChecks	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.

Simple Integration

After installing and configuring the software, write a simple application that renders a document as PDF to confirm that you have installed and configured it correctly. Building such an application 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 Server is installed, configured, and tested to make sure it works, you can perform several actions.

• selectDocs
• renderDoc
• renderDocSet
• transaction
• combinePdfs
• getDocInfo
• checkForResponse
• cancelJob

All actions are asynchronous.

Input Files

The Transaction Server 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 - static text that displays in the same way every time the document is used. Fixed text overlays may also hold datapoints inserted into the static text.

• mergable text - data from any single 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 the 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 only supported for backward compatibility.

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, or send documents directly to a printer.

For each output option, 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 Server 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.

E-Signature Configuration

The Transaction Server provides functionality to:

• Maintain PDF file encryption and document security from the point of rendering and through the signing and archiving process.

• Map standard CSi datapoints to the field naming conventions of the e-signature provider to facilitate e-signature processing.

Please note that when custom documents output from CSi Simplicity are included in the document set, any electronic signature scripted for inclusion on those custom documents will work without additional configuration from the partner.

Signer Identification

The partner must provide a unique identifier in the transaction data for a signer in each digital signature datapoint for all active entities. This ensures that a signer who is actually performing multiple roles in the transaction will only be represented as a single signer in the signature process.

The data value to be provided should follow this simple JSON format:

{ "Signer": "12flsfu"}

Please note that the leaf node name in the CSi Data Schema is DigitalSignatureImage. This is because this data element was previously used only the rendering of image in the PDF, not actual e-signature functionality.

Transaction Server Response

The JobTicket that you provide to the Transaction Server should enable the e-signature option for the signature property:

jobTicket.DstFile = new csi.Transaction.Shared.OutputFileData(csi.Transaction.Shared.OutputFileData.OutputFileType.pdf);
jobTicket.DstFile.FileNamePrefix = baseFileName + "-Transaction-";
jobTicket.DstFile.PdfProperties.ContentType = FileData.StorageType.unc;
jobTicket.DstFile.PdfProperties.EmbedFormFields = arguments.fields;
jobTicket.DstFile.PdfProperties.DigitalSignatureProvider = DigitalSignatureProviderType.xxx;
jobTicket.DstFile.PdfProperties.Security = new PdfProperties.PdfSecurity();

Each transaction should be rendered with one PDF per document in order to work successfully in the e-signature process.

The Transaction Server response will include the transaction-entity-to-signing-party name mapping. An XML file for each document will be created that includes the entity-to-signature-field (signing party) mapping. This will be read by the partner software and used to construct the call to the e-signature provider API. The format of the XML matches the format of the e-signature provider web service call. It also includes the CSi entity information and the field name as it is mapped to e-signature provider’s naming convention.

Data Integrity Metadata

A new PDF metadata item will be added to each document returned when using the e-signature provider setting. This item will be named DocumentRenderingTrail and contain a compressed and encrypted representation of the data and CSi software versions used to produce the document. This information will be preserved by the e-signature provider process.

No special action is necessary on the partner software side to preserve this information.

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 csi.Transaction.Shared.JobTicket class:

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.Shared.IJob job = jobServer.StartJob( jobId, jobTicketXml, ActionType.renderDoc );
csi.Utility.Messaging.Status status = job.JobStatus.MessageListSnapshot;
bool warningFound = false;
for( int i = 0; (i < status.MessageCount) && !warningFound; i++ )
{
    csi.Utility.Messaging.Message message = (csi.Utility.Messaging.Message)status.Messages\[i\];
    warningFound = (message.Level == csi.Utility.Messaging.Message.LevelType.warning)
        && (message.Code == csi.Engine.Messaging.EngineMessage.CodeTypeEngine.licenseKeyExpire.ToString());
}
...

Optional Debugging Settings

Optional debugging settings give business partners tools to debug certain workflows based on job ticket, giving insight into particular portions of processing.

TxlOutputFilePath

Setting TxlOutputFilePath to a valid output file path directs the Transaction Server to write merged TXL data to that file, allowing analysis of that data. The output file location must be accessible and writable by the user/service account that the Transaction Server is running as, and identically named files will be overwritten. Any errors from the output process will be reported as detailed warnings in the Status return value.

To set the output file path for a JobTicket, set the DebugSettings property on the JobTicket to a JobDebugSettings instance initialized with a valid path.

  JobTicket j = new JobTicket();
  …
  j.DebugSettings = new JobDebugSettings(@"C:\\Temp\\merged.txl");

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 1000 KB 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.

Managing Attributes for Concatenated Values

When any datafield comprising a concatenated string is locked, the entire concatenated value is locked. For example, if Last is locked in the concatenated string First, Middle, Last, then the consolidated value made from First, Middle, and Last is locked.

Similarly, the attributes backcolor, blankwidth, emptyvalue, forecolor, and alignment are now cascaded through a concatenated value string so that the first attribute defined is given precedence over subsequent attributes assigned in the string. For example, setting the forecolor attribute for First to blue will set the forecolor attribute for Middle and Last to blue as well, even if Middle and Last have different forecolor attributes.

Dependencies and Technology Requirements

Technology	Workstation Applications: Custom Document Editor IntelleDoc Viewer IntelleDoc Advisor IntelleDoc Visualizer	Web Server Components: Transaction Manager Transaction Runner Transaction Server Compliance Engine	Server Components: Compliance Service
Processor	1.8 GHz Intel	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 space or more for software.	100 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 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

The Transaction Server uses some .NET API calls that require the application to run as a user who is part of the Performance Monitor Users group. This is not an issue when the logged-in user is part of the Administrator group on the local machine, but it is an issue when the user has limited privileges.

If the Transaction Server is installed as a Windows Service, then ensure that the Log On As user is part of the Performance Monitor Users group. If the platform software directly integrates with the Transaction Server, then all users that run the software must be members of the Performance Monitor Users group.

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.