Archived Features

Expere Testing System retirement

Wolters Kluwer is committed to continually ensuring our software applications and tools adhere to rigorous security standards. As part of that effort, we are informing you of an upcoming change regarding the Expere Testing System for our self-hosted, “on-prem” Expere customers.

Because of our security diligence, we have decided to retire the Expere Testing System application that is provided with the Expere Engine. Our internal security scans had identified several issues with the Expere Testing System.

When will this occur?

The Expere Testing System retirement will occur in conjunction with the 2024.2 external Engine release. No application installation (in the form of an .EXE) will be provided with this release. In addition, the Expere Testing System User Guide, available as online help, will no longer be accessible to users.

Is there user action required?

We recommend that users uninstall the Expere Testing System if it is still used as part of regular Expere testing.

FOP 2.8 upgrade

Expere uses Apache™ FOP (Formatting Objects Processor) to generate PDF documents. Currently, the Expere Engine supports two FOP versions: 1.1 and 2.8.

  • Expere uses version 1.1 to generate standard PDF documents and is the default rendering engine.
  • Expere uses version 2.8 to generate Web Content Accessibility Guidelines (WCAG) compatible Tagged PDF documents.

Scheduled for a 2024 Quarter Two (2) release, Expere will use FOP 2.8 to generate both standard PDF and Tagged PDF documents.

What do you need to do?

If you want to test or use FOP 2.8 before Quarter Two 2024, perform either of the following:

  • Use an optional “FOP26” element at the root of the SelectAndGenerateRequest or Generate API call with a “true” value.
  • In the bsi.properties file, set the com.bankerssystems.expere.render.FOP26 property to “true”

Otherwise, you can wait until we enable FOP 2.8 for all customers in the Expere 2024.1 release, targeted for mid-April.

What is changing?

With the upgrade to FOP 2.8, you can expect to see the following:

  • Minor document generation performance improvement.
  • Transaction barcodes are no longer bolded and now honor case-sensitive values.
  • Transaction barcode height will be supported.
  • For single page documents containing Header and Footer notices, Wolters Kluwer-authored source content files (REQs) must include a "FirstPage" attribute when document logic dictates different Header and Footer requirements per page.
  • For single page documents containing specific margin requirements, Requirements Editor files must include "InstanceFirstPage...Margin" and a corresponding value when document margin logic dictates different Margins per page.
  • REQs using the Integrated Disclosure Stylesheet no longer produce barcodes when not specified to do so.

Fillable Field Default Behavior Change

Effective Date for Hosted Expere users:

  • Customer Test Environment: July 2024
  • Production Environment: August 2024

Effective Date for self-hosted Expere users:

  • 2024 Release Two

Expere’s behavior has been updated to generate Fillable Fields when specified rather than producing them by default. These changes simplify the logic and makes Expere more maintainable.

The current default allows documents to support fillable fields but not eSignature fields. The new behavior will support fillable fields when eSignatureAndFieldSupport options are specified in the request; otherwise, fillable fields will not be generated on the documents

There are two types of fields that can be added to the generated documents.

  • Acroform fields (referred to as “fillable fields”) can contain user-entered data for editing a document after it has been generated and output by Expere.
  • Electronic Signature fields (eSignature) are used to populate signature names, dates, or initials.

The ability to control these fields is based on data passed in the API Request from the Loan Origination System (LOS) integration to Expere.

User action and impacts

The com.bankerssystems.expere.render.acroformSupport property ONLY supports a "false" value.

No user action is required provided that fillable fields are not needed unless the eSignatureAndFieldSupport ancillary output is specified. To return fillable fields without eSignature fields (the current default behavior), the following eSignatureAndFieldSupport ancillary output options should be specified:

  • eSignatureAndFieldSupport = true
  • eSignatureCoordinatesOnly = true and
  • NonSignatureFieldCoordinatesOnly = false

These ancillary options are currently available and can be utilized at any time. If the desire is to have documents with no fillable fields nor eSignature fields, no further action is required.