 |
Previously, all organizations were cached together, including OPPSA organization. This presented an issue when multiple Expere instances were used, including the hosted OPPSA application. Expere cleared the AllOrganizationsList object from the database whenever OPPSA changed, but this was insufficient.
We have implemented an enhancement to our database caching capabilities: com.bankerssystems.database.organization.caching was added to the bsi.properties file. By default the value is set to "true" but should be set to "false" when Expere installed with Document Generation Services.
## When set to false the organization structure from the database, which includes the OPPSA organizations won't be cached. ## Set this to false if there will be more than one Expere server in an OPPSA environment ## The default is true if this key isn't found com.bankerssystems.database.organization.caching=true
Previously in PBI 416188, we enhanced Expere to support the following documents in PDF/A format:
With this enhancement, if the <RequestUCD/> flag is set to "true" in the Expere request, the documents above are rendered in PDF/A format. The ClosingDisclosure is also merged with its corresponding addendum, if the addendum exists. The merged documents are included in the response file as the closing disclosure document instance and the addendum instance is removed.
We recently included support for PDF Merge functionality with Expere whereby a </SignaturePointSet> element is now returned in the response when at least one document has fields and PdfMerge is requested.
We have updated the BSI.properties file for the Expere Wildfly installer to include the following lines:
## Indicates whether the ESignatures and MergePDF output is enabled com.bankerssystems.expere.model.ESigPdfMerge=true
This enables eSignature and PDF Merge functionality for Expere.
Previously, eSignature and Field Support settings from a transaction were not retained when resubmitting that same transaction. As a result, users were required to reenter these settings.
The following eSignature and Field Support settings are saved in the database, regardless if "True," "False," or "NULL:"
In a previous release, we implemented enhancements that return XY coordinates for all fillable fields (Expere Engine: continued enhancement of eSignatureAndFieldSupport and SignaturePointSet elements; Expere Engine: SignaturePointSet and eSignatureAndFieldSupport element changes). In this release, checkboxes associated with fillable fields now appear on all documents even if requesting X/Y coordinates. Note the following guidelines:
For more information, see Using eSignature and Acroform fields.
Expere users can now produce the following documents in PDF/A format:
The request file now contains a new <RequestUCD/> element that, when set to "True," produces the documents above. If not setting the flag, documents are produced using the standard PDF format.
What is PDF/A format? It is an ISO 19005 compliance PDF file used for archiving and long-term preservation of electronic documents. For more information, see the following:
We have introduced a new <Sequencing/> element to the following field types in the Expere response file:
This <Sequencing/> element is implemented for the Secure Document Exchange (SDX) product for those users who sign across documents. It also makes each field unique so Document Generation Services can merge PDF documents that use signature, date, initial, and fillable text fields.
If the "MergePDF=true" in the response file, the Signature, Date, Initials, FillableCheckboxes and FillableText field types elements will contain sequencing in the <FieldName/> element using an incremental numbering system with an underscore.
Sequencing logic and format example:
<r:SignaturePointSet> <r:Signer> <r:Id>Homer</r:Id> <- Signer ID <r:Description>Borrower, Borrower</r:Description> <r:SignaturePoints> <r:Type>Initials</r:Type> <r:Sequencing>1</r:Sequencing> <r:FieldName>INI_Borrower_null_homer_false_1_SigField_1</r:FieldName> </r:SignaturePoint> <r:SignaturePoint> <r:IncludeDate>true</r:IncludeDate> <r:PageNumber>1</r:PageNumber> <r:SignatureText>Homer Simpson</r:SignatureText> <r:Type>Signature</r:Type> <r:Sequencing>2</r:Sequencing> <r:FieldName>SIG_Borrower_null_homer_false_1_SigField_2</r:FieldName> </r:SignaturePoint> <r:FillableFieldSet> <r:FillableText> <r:FieldName>FillableField_3</r:FieldName> <r:ToolTip>fill in here</r:ToolTip> <r:PageNumber>1</r:PageNumber> <r:Width>420.0</r:Width> <r:Height>72.0</r:Height> <r:XCoordinate>56.0</r:XCoordinate> <r:YCoordinate>100.0</r:YCoordinate> <r:Sequencing>3</r:Sequencing> </r:FillableText> <FillableCheckBox> <r:FieldName>FillableCheckBox_4</r:FieldName> <r:ToolTip>check here</r:ToolTip> <r:PageNumber>1</r:PageNumber> <r:Checked>false</r:Checked> <r:XCoordinate>22.0</r:XCoordinate> <r:YCoordinate>140.0</r:YCoordinate> <r:Sequencing>4</r:Sequencing> </FillableCheckBox> </r:FillableFieldSet>
In a previous release, we added a new element called eSignatureWKES, which allowed Wolters Kluwer Electronic Signature (WKES) users to initial documents with a fillable text field (Acroform). Please refer to change log notes for PBI 408221 - Secure Document Exchange users initials can now render with Acroform fields for past work
We have enhanced this functionality to now follow WKES (previously Secure Document Exchange) naming conventions for initial(s) and checkbox fields. The following behavior now applies:
Users may now select which fillable fields, including eSignature fields, appear or do not appear on documents based on a selected package. This functionality is accomplished by supporting an exclusion list per account in the content library which suppresses the fillable fields in any documents included in the list based on the package.
This exclusion list now resides in the .XML file in order to enable this functionality; the .XML file is stored in your custom content folder of the appropriate repository.
.XML structure:
PKG.ABC PKGD.DOC1 PKGD.DOC2 PKG.DEF PKGD.DOC1 PKG.GHI PKGD.DOC1 PKGD.DOC3
When requesting a transaction for PKG.ABC and that request generates PKGD.DOC1 or PKGD.DOC2, the fillable fields will be suppressed on those two docs, but will remain on all others with fillable fields. If the XML file is empty or the users requests a transaction for a package not in the list, all documents rendered that have fillable fields will be produced with fillable fields.
Previously, DiscretePartyID's were only returned for dynamic documents. We have now enhanced the DiscretePartyID functionality to be returned with static documents.
Previously, users had to modify transaction data sent to Document Generation Service with the Expere database values.
Users can now apply OPPSA compatibility configuration changes to their appropriate Expere distributed or hosted installation package through database updates. This allow their Expere instance to connect to the Expere OPPSA database to receive policy and organization data and FileSystem content.
For Expere Engine installations, must enter the Expere database information in the bsi.properties file. See Applying OPPSA compatibility configuration changes - .NET Installations for more information.
For JBoss/Wildfly installations, add the database information to the standalone.xml file located in wildfly-10.0.0.Final\standalone\configuration\. See Applying OPPSA compatibility configuration changes - JBoss/Wildfly installations for more information.
We have implemented the following enhancements to the <SignaturePointSet/> element:
This element appears in the Expere response file when including the "eSignatureWKES" flag in the initial request. Sample code below:
<r:SignaturePointSet> <r:Signer> <r:Id>homer</r:Id> <r:SignerEmail>Joe.Doe@wolterskluwer.com</r:SignerEmail> <r:Description>Borrower, Borrower</r:Description> <r:SignaturePoints> <r:SignaturePoint> <r:IncludeDate>true</r:IncludeDate> <r:PageNumber>1</r:PageNumber> <r:PageOrder>1</r:PageOrder> <r:Height>72.0</r:Height> <r:Width>540.0</r:Width> <r:SignatureText>Homer Simpson</r:SignatureText> <r:XCoordinate>36.0</r:XCoordinate> <r:YCoordinate>396.0</r:YCoordinate> <r:Type>Initials</r:Type> <r:FieldName>INI_Borrower_null_homer_false_1_SigField_joe.doe@wolterskluwer.com</r:FieldName> </r:SignaturePoint> </r:SignaturePoints> </r:Signer> </r:SignaturePointSet>
As data requirements functionality is not supported in the Hosted Expere application, SCHEMA files are not required. However, missing schema files would cause unnecessary errors in the log files.
We have modified missing schema file requirements; when a document request is made for a document that does not have a corresponding schema file a message is now logged as a warning (WARN) instead of error (ERROR).
Previously, a SelectAndGenerate document request that did not select any documents resulted in the following errors:
These two responses should not be considered errors. These responses are simply indicating the transaction provided does not meet any of the document autoselection criteria, and therefore did not select any documents.
The log file has been enhanced to now display these two responses under a status of INFO status instead of an ERROR status when a SelectAndGenerate call is inititated but no documents are generated.
Previously, the signerNames HashMap variable was designated as "static;" as a result, the a potential for the following issues existed:
This issue has been resolved by changing the way SignerName is stored in the Signer class; as a result, the signer name is assigned correctly on a per-transaction basis.
Wolters Kluwer Electronic Signature (WKES) users can now initial documents with a fillable text field (Acroform) using a new element called </eSignatureWKES>, as a child of the </ESignatureAndFieldSupport> element in the </AncillaryOutputOption>. If setting this element to "true," the initials render as a fillable text field on the document(s). By default, this element is set to "false" and renders as an eSignature field. In a future release, WKES users will be able to capture initials one time per signer and populate those initials to all the respective signer fields.
<r:AncillaryOutputOption> <r:OutputType>ESignatureAndFieldSupport</r:OutputType> <r:ESignatureAndFieldSupport> <r:eSignatureTooltip/> <r:eSignatureInitialsTooltip/> <r:eSignatureCoordinatesOnly>false</r:eSignatureCoordinatesOnly> <r:eSignatureDateSupport>true</r:eSignatureDateSupport> <r:NonSignatureFieldCoordinatesOnly>true</r:NonSignatureFieldCoordinatesOnly> <r:eSignatureWKES>false</r:eSignatureWKES> </r:ESignatureAndFieldSupport> </r:AncillaryOutputOption>
Users can now configure the DPI of PDF417 barcodes. This allows users more flexibility when scanning and imaging documents.
In the bsi.properties file, users can set the DPI for the X and Y values, as bolded below.
## Indicates whether 2D barcodes should use DPI or scaling ## If these DPI values are commented out, then scaling will be used. ## 2D Barcode Height and Width are in inches ## com.bankerssystems.expere.model.DpiX=200 ## com.bankerssystems.expere.model.DpiY=200 ## com.bankerssystems.expere.model.2DBarcodeWidth=2.42 ## com.bankerssystems.expere.model.2DBarcodeHeight=0.41
We had previously introduced a new JavaScript caching object that works with Expere file system servers; however, we did not create a similar database caching object for database-only servers. This resulted in users encountering errors accessing the database through the lack of proper authentication credentials.
A JavaScript object that works with Expere databases is currently in development. This enhancement adds authentication credentials to access the database.
Previously when printing a document PDF package with a cover sheet, users reported an Adobe generation error. It was determined that this issue was caused by an invalid PDF syntax in the cover sheet generation method.
This issue has been resolved; a document PDF package with a cover sheet now prints without errors.
It was reported that requests containing <Error Correction/>, <Rows/>, and <Columns/> element values, other than the default, were not honored.
We have implemented code changes to honor requests containing non-default values for <Error Correction/>, <Rows/>, and <Columns/> element values.
For example, in the following <Barcode/> configuration: The “<Rows>10</Rows>” is used, and the “<Columns>5</Columns>” is ignored.
<exp:AncillaryOutput> <exp:AncillaryOutputOption> <exp:OutputType>Barcode</exp:OutputType> <exp:Barcode> <Type>barcode2D</Type> <UseCoverPage>True</UseCoverPage> <Pattern>577+BMHPF000000000024456+%BRCD%</Pattern> <Barcode2DConfigurationOptions> <ErrorCorrectionLevel>8</ErrorCorrectionLevel> <Columns>5</Columns> <Rows>10</Rows> </Barcode2DConfigurationOptions> </exp:Barcode> </exp:AncillaryOutputOption> </exp:AncillaryOutput>
Expere can now print a desired party name in the signature field with a script font type, Pinyon Script. The new script font is embedded into the .PDF document. Additionally, we have added the font to the fonts.xsl file to indicate that we now support Pinyon Script.
As a part of Discrete Party enhancements, we have updated to iText 7 to work with Merged PDF functionality. This enhancement will also allow support of merged PDF with fillable fields and eSignatures in a future release.
See DiscretePartyID for more information on using the <DiscretePartyID/> element.
The <DiscretePartyID/> element is now available in the Document Generation Services WSDL in the DocInstance complex type. It is a sibling to the <InstanceDisplayName/> element and a child element of <DocInstance/>.
<DiscretePartyIDs> - <DiscretePartyID>x</DiscretePartyID> <DiscretePartyID>x</DiscretePartyID> </DiscretePartyIDs>
It was discovered that .PKG rules were not identified in the Generate API; this resulted in packages having incorrect barcode values. For example: If I have PKG.ABC that has rules to print a value for the BRCD (25 for example), and PKG.XYZ has rules to print a BRCD value of 136, the Generate call applies the first BRCD value vs the PKG identified in the request.
The Generate API ignored the .PKG entered and only applied the data to the documents identified in the request.
The Generate now applies the PKG information to the call when BRCD values apply and subsequently ignore the AutoSelection rules as the documents are pre-identified.
The Expere IE Cache Manager now allows users to reset the Javascript cache, which stores Javascript files the cache to improve performance.
Users can now access the DocViewer release notes ONLINE here.
Recently, we had implemented SignaturePointSet and eSignatureAndFieldSupport element changes in PBI's 382028 / 392582. With this continued focus we have implemented the following flags for the eSignatureAndFieldSupport element to return X/Y coordinates:
For more information, see the eSignature feature overview section on the Using eSignature and Acroform fields page.
Previously, users reported slow performance and time out issues when generating documents. These issues occurred with custom organizations where images existed at a parent level.
When a missing image existed: the system scanned the entire organization tree instead of the requested hierarchy level and incrementally scanning the levels above the original level.
This issue has been resolved; we have addressed the issue above through code changes that have replaced the previous method.
In an effort to support returning XY coordinates for all fillable fields we have begun the development work. The first step in supporting this feature is creating a new element (eSignatureAndFieldSupport).
Recently, Java 8, Saxon, and stylesheet upgrades have been implemented; with these upgrades, users must run a script to remove duplicate imports for the database and file system. The scripts are available on your release media at:
See Important update regarding Java 8 and Saxon upgrade: DB and File System script process for detailed information.
It was reported that when installing Expere Engine 2015.3.0.1355 on Windows Server 2012 R2, a .NET Runtime Required error appeared stating that .NET 4.0 was required. However, Windows Server 2012 includes .NET 4.5.1.
Users were instructed to either click OK on the error message or create the following folder: C:\Windows\Microsoft.NET\Framework\v4.0.30319, then remove the folder after completing the installation.
This issue has been addressed; we have removed the verification that checks the .NET version. Users can now complete the Expere Engine installation without seeing this error message or performing the workaround above.
When utilizing UseCoverPage with the Ancillary Barcode functionality, data within the Instance Display Name elements would overflow off the cover sheet when too long.
This behavior has been enhanced. The Instance Display Name now wraps on the cover sheet. The following text was added to the cover sheet so recipients of the documents know to return the cover sheet with the document:
When viewing the endpoint URL (Common/WSEndpoint) with NO transaction data, it was expected that Expere would return the results of the GetServiceInfo call; however, the SAXParser threw an exception due to the absence of data. This resulted in the GetServiceInfo call not occurring.
With the Expere 2016.1.3 hotfix, Expere now successfully returns the results of the GetService Info call when the endpoint is viewed with no transaction data.
The ExpereResponse.xml file now contains Cash to Close calculated values available in a new <r:DocCustomDataItems/> parent element and <r:DocCustomDataItem/> child elements. Each of these elements has a DataItemName attribute and number for the value.
The new Expere Engine stylesheet, AddDocCustomDataItem.xsl, adds these elements as DocCustomDataItems.
The new elements exist as children and grandchildren of the <r:DocDescriptor/> element. The <r:DocCustomDataItem/> elements contain the following DataItemName attribute values:
The following code snippet appears in the ExpereResponse.xml file:
<r:DocDescriptor> <r:DocID>PKGD.LoanEstimate</r:DocID> <r:DocType>Dynamic</r:DocType> <r:DocDisplayName>Loan Estimate</r:DocDisplayName> <r:DocRootEntityName>INS.LoanEstimate</r:DocRootEntityName> <r:DocCustomDataItems> <r:DocCustomDataItem DataItemName="/Txn/IntegratedDisclosuresLoanEstimateTotalClosingCostsStoredValueAmount">34287</r:DocCustomDataItem> <r:DocCustomDataItem DataItemName="/Txn/IntegratedDisclosuresLoanEstimateClosingCostsFinancedStoredValueAmount">-34287</r:DocCustomDataItem> <r:DocCustomDataItem DataItemName="/Txn/IntegratedDisclosuresLoanEstimateCashToCloseStoredValueAmount">107815</r:DocCustomDataItem> </r:DocCustomDataItems> </r:DocDescriptor>
Previously, hosted and non-hosted transactions that called the Expere Engine failed when using certain special characters on static documents.
We have enhanced the Expere Engine to support the following special characters:
Newly Supported:
Existing (Previously Supported):
We have laid the ground work for a future enhancement to support additional hosted platforms. However, no customer-facing changes currently exist for this change. We will provide additional information as it impacts our users in a future release.
Logging has been enhanced for the caching and file system repository to help track the progress of requests; these enhancements include the RequestID, OrgID, and PackageID. This enhancement is also a result of the changes made in PBI 382041 below.
Changes were made to the file system repository to make the indexing process more efficient.
Previously, users could not enable or disable eSignatures or AcroForm fields for transactions.
Users can now pass eSignature and Acroform values in the AncillaryOutput of a SelectAndGenerate or Generate request. For detailed information on enabling or disabling eSignature or Acroforms, see Select And Generate, and Generate.
Previously, an issue existed in the Expere Config Tool utility in the 2016.1 release (Important update regarding the Expere Config Tool). Users reported an error when launching the Expere Config Tool utility and as a result, could not update various fields.
As a workaround, we had provided instructions on how to manually update the following configuration files and various settings within these files:
The Expere Config Tool has been enhanced, consisting of the following:
Users can access the updated Expere Config Tool utility here.
An issue had been identified with certain PDF viewers and e-signatures. Specifically, documents with e-signatures turned on but not captured, would display, and sometimes print a box around the signature field.
This has been corrected; e-signature capable documents, where an e-signature has not been captured, will no longer display or print a box around the signature field.
Previously, when a document was removed from base content, OPPSA stopped printing when it encountered the missing document. In some instances, the system stopped printing any remaining documents depending on where the document was located.
This behavior has been enhanced; when an OPPSA package includes a document that has been removed, an error appears stating which document must be removed from the specified package in the OPPSA product.
Summary: Embedded versions of Expere .NET and Requirements Editor now utilize Java 8 and Saxon.
For more information, see the following Expere System Requirements Sections:
We have recently consolidated the .NET and Java installation procedures to now reside in one webhelp implementation, available here: Expere Implementation Guide.
Issue: Previously, the Expere Engine reserved space for ancillary barcodes on dynamic documents even though the barcode element was not included in the .REQ file.
Solution: This issue has been resolved; when generating a dynamic document and selecting an ancillary barcode option, the document will no longer reserve space for the barcode if the .REQ file does not contain a barcode element.
This feature requires an Expere Engine update.
|