Features

Expere Engine-related features by release.

What is a "Feature?" A feature is a new function or series of functions within an application which did not previously exist. On this page you will find changelog entries associated to features being delivered in incremental pieces. Each changelog entry describes a small function delivered to support the larger feature function as a whole. Below you will find a list of features, with their respective changes, associated to the Expere version the feature is or will be delivered.

Ability to return custom document instance information

The Expere Engine has been updated to assign the party information for a document when the Entity is a non-signing entity. Expere now supports an 'InstanceProperty' Name/Value Pair element that can be used to capture the Entity details as authored in the REQ. The element is repeatable to support additional values; these values are returned in the Expere response.

The 'InstanceProperty' Name/Value Pair element will appear as the following in the Expere response:

<r:InstanceProperties>
	<r:InstanceProperty>
		<r:Name>ABC</r:Name>
		<r:Value>TestValue</r:Value>
	</r:InstanceProperty>
</r:InstanceProperties>
Additional information:
  • If both the Name or Value element contain blank values, the InstanceProperty container is not included in response.
  • If either the Name or Value element contain a value is provided, that single value will appear in response as a child under InstanceProperty.

Using Overflow pages with EmbeddedPDF REQ documents

During document generation, data populates data fields at runtime. Any discrepancy between transaction data received and the properties of the fixed data fields is handled by overflow rules including overflow to a target (an addendum, for example). Other mechanisms to accommodate data overflow include truncated text and reduced font size.

EmbeddedPDF document functionality has been updated to handle the amount of characters that can appear in the PDF, through the creation of overflow pages.

EmbeddedPDF documents can be generated as standard or Tagged PDF's.

For more information

Expanding merging PDF options

The Expere Engine is currently being updated to specify when merged PDFs can be generated by discrete parties through the use of the following new ancillary outputs:
  • MergedCopyPDFDiscreteParty
  • PdfMergeDiscreteParty

Expere can set the merged PDF files' Document Title to the original PacketName when passing in either the MergedCopyPDFDiscreteParty or PdfMergeDiscreteParty ancillary output. The packet name is specified in the PKG file in the content library or in EZ Config Packages and Packets.

Both MergedCopyPDFDiscreteParty and PdfMergeDiscreteParty ancillary outputs are supported when Packets are authored as part of the PKG file in the content library.

For more information, refer to the following:

XPath 1.0 Compatibility Mode to be disabled

XPath Compatibility is a function that evaluates the transaction and logic within Expere .REQ files (Requirements files that comprise Wolters Kluwer content) during document generation. Users can leverage the current rule processing logic to determine whether to specify a specific instance of a datapoint within a collection container (see example below). If so, this results in always using the first instance of the value, specifically if duplicate data in a transaction exists. This could happen as a result of duplicate data in the transaction or the PTR logic not specifying the specific instance to use. Our internal log files can identify when XPath 1.0 Compatibility mode logic is triggered. Wolters Kluwer will be disabling XPath 1.0 Compatibility Mode.

Example of duplicate value in transaction; in the example below <OrgExemptInd> appears twice.

Sample error message (ERROR): when XPath 1.0 Compatibility is disabled, users should expect to see an error message similar to the sample below if a duplicate XPath value is used: 
/[96e8a388-786c-4987-824e-b1fd00dc5954:100194837][902.xxxx202403x20240802.1.ORG.xxxx][PKG.xxxx_Pre-Approval][INS.UniformResidentialLoanApplication-M2]
Due to an XPath 2.0 compatibility issue the following XPath could not be evaluated - /p:Txn/p:Borrowers/p:Borrower(not(p-ApplicationID = preceding:p:Borrower/p:n/p:Borrowers/p/Borrower/p:ApplicationID0][not(string(p:ApplicationID) = ' ')]
...
Sample error message (WARN): log files will display a WARN status when transactions fall into XPath1.0 Compatibility Mode but do not fail. In the sample, duplicate XPath elements are detected and the print rules evaluated. XPath 2.0 does not allow for duplicate values to be present for the same XPath that is being evaluated. 
2025-02-11 08:58:31,914 INFO  [com.bankerssystems.expere.parser.ERLAssemblyManager] (default task-1) Assembling document: 'INS.UniformResidentialLoanApplication-M2'.
2025-02-11 08:58:33,376 WARN  [com.pingdynasty] (default task-1) Due to an XPath 2.0 compatibility issue the following XPath could not be evaluated: boolean(/p:Txn/p:CollateralItems/p:Collateral[p:LocationState = 'NV'] and 
(/p:Txn/p:MortgageBrokers/p:MortgageBroker[1][string(p:ExemptInd) != '1'] or string(/p:Txn/p:OrgExemptInd) != '1'))
net.sf.saxon.s9api.SaxonApiException: A sequence of more than one item is not allowed as the first argument of fn:string() (<OrgExemptInd>, <OrgExemptInd>) 
2025-02-11 08:58:33,376 WARN  [com.pingdynasty] (default task-1) XPath 1.0 compatibility is enabled so this XPath will be retried

Interpreting the ERROR and WARN messages

The following list provides information related to the highlighted syntax in the sample above and pertains to both ERROR and WARN messages:
  • INS.UniformResidentialLoanApplication-M2: refers to the document where duplicate XPaths have been identified.
  • boolean(/p:Txn/p:CollateralItems/p:Collateral[p:LocationState = 'NV'] and (/p:Txn/p:MortgageBrokers/p:MortgageBroker[1][string(p:ExemptInd) != '1'] or string(/p:Txn/p:OrgExemptInd) != '1')): refers to specific PTR (Product Technical Rule) logic whereby the Engine has evaluated multiple data points in the transaction could resolve to one of the XPaths referenced in the PTR.
  • A sequence of more than one item is not allowed as the first argument of fn:string() (<OrgExemptInd>, <OrgExemptInd>): in this example, the identified XPath element is referenced in /p:Txn/p:OrgExemptInd within the PTR. In this example, two OrgExemptInd elements were passed in the transaction; as a result, when the PTR listed attempted to query for the value it found a potential duplicate XPath element and logged the message.

When will this change occur?

Hosted users: this change will be implemented with our standard deployments:
  • Customer Test Environment: April 2025
  • Production Environment: July 2025

Document Generation Services users: this change will be implemented in July 2025.

Expere "on-prem" users: this change will be implemented in the 2025.3 release (targeted for August 2025).

User impact: If you have a scenario in which duplicate data exists when XPath 1.0 Compatibility Mode is disabled, any transactions may fail. Depending on the root cause of the failure, you may need to update your data mapping or deploy an updated content library. Wolters Kluwer recognizes the dynamic nature of this enhancement due to regular content updates, regulation changes, and application improvements impacting users’ front-end systems. We wanted to provide adequate lead time so you can prepare for this change.

Note: For our Hosted users, Wolters Kluwer Professional Services team has been reaching out to users regarding log files they have identified as triggering XPath 1.0 Compatibility mode logic.

For our self-hosted users: your log file will contain a prepend of "Due to an XPath 2.0 compatibility issue, the following XPath could not be evaluated" before the XPath in question. The image below displays an example log message. You will notice that the transaction file lists OrgExemptInd twice directly under Txn. XPath 2.0 does not allow an XPath of /Txn/OrgExemptInd twice. With XPath 1.0 compatibility enabled it will use the first instance.



Expere eNotes Registration with MERS - SMARTDoc Address Parsing

We’ve identified a challenge affecting some customer attempts to register Expere eNotes with MERS, specifically related to the PARSE_STREET_ADDRESS field in the SMARTDoc not being consistently populated. While Expere includes an Address Parser component, its current logic may not fully accommodate unique address formats used in certain states (e.g., “123 KY 78”).

To enhance compatibility and flexibility, we have implemented a solution that maintains the existing parsing logic while also introducing an option for integrators to directly provide address components in the format MERS expects during upload.