EDQ would rely on the Java Security Manager framework for secure script execution, but this feature is deprecated in JDK version 17 and later. EDQ now implements a new configuration property called scriptprocessor.security that you can use to control the behavior of direct entry script processors and gadgets.

Note that this enhancement applies to the use of scripts in direct-entry script processors and gadgets only. This does not affect all the other uses of scripts (for example, triggers and so on). See Configuring Secure Script Execution for more information.

EDQ includes a REST API that supports read and write of MBean attributes and invocation of MBean operations.

EDQ defines a large number of JMX MBeans, some of which have real-world uses. The following MBeans have been web-enabled in 14.1.2.0.0:

• Logger control
• Runtime data Nexus
• Bucket providers and consumers
• Runtime engine
• Source code control

See Using REST APIs to Access and Manage MBeans for information on how to use the REST interfaces to read and write MBean attributes and invoke operations.

Earlier versions of EDQ would store the binary data for case management attachments in a BLOB column in the dn_caseattachments table. While this allowed fast storage and retrieval, systems with a large number of attachments could use a significant amount of database storage, which could lead to tablespace sizing and backup issues.

EDQ 14.1.2 onwards you can store attachment data in the file system or in cloud storage. New attachments are stored externally, while existing attachment data remains in the database table. This release also includes REST APIs that you can use to migrate data to external storage and return the migrated external data back into the database. See Configuring External Storage for Case Management Attachments for detailed information about how to configure and use external storage for attachments.

In versions prior to EDQ 14.1.2.0.0, case management and note attachments were downloaded to the local system and opened using Desktop.open. This bypassed any file scanning provided by browser downloads.

For security reasons, such attachments are now opened and saved using the browser by default. When you try to download a case management or note attachment, EDQ generates a temporary unique URL in the http://server/edq/downloads/key/name format and opens it using the Desktop.browse API. For Save operations EDQ adds a Content-Disposition: attachment header to the result to force the browser to save the file.

While browser-based downloads are now the default, there may be situations where organizations or individual users may wish to use the current "local" download mode. You can control the download type by adding the attachment.download.style property to clientstartup.properties. If the value is local, EDQ uses the current local mechanism for all users. If the value is choose, individual users can select how to download the attachments.

Note that the same download style setting is applied across the EDQ application.

EDQ now supports AWS Roles Anywhere stored credentials alongside the current access key/secret stored credentials type.

AWS Roles Anywhere allows on-premise workloads to access AWS services such as S3 or SQS. Roles Anywhere is an alternative to the use of standard access key based AWS credentials. See Creating AWS Roles Anywhere Stored Credentials for more information.

You can now access configuration and log files using HTTP and HTTPS.

For compatibility reasons web access is not enabled by default, but you can enable this by setting director.properties and an MBean. See Using HTTP and HTPS Server to Access EDQ Files for more information.

EDQ now includes a tool called usergc.jar that can check whether users that have been deleted from the internal or external store have a reference in any of the configuration schema tables.

You can use this tool to identify such users and then cleanup the respective records from the database. For detailed information about the tool, see Using the User Garbage Collection Tool to Manage Deleted Users.

You can now use the new "import" Autorun task to import package files at system startup.

The chore XML includes the package import definition as inline JSON or as a file name. See Using Autorun to Execute Startup Tasks for more information.

Support and customers can use the http://server:port/edq/admin/sysreport endpoint in the system administration name space to generate sysreports in JSON format.

You can use the REST API to return a subset of the full report, which could be useful for automated testing and quick diagnostics. See REST Interface for EDQ System Report for information on how to use the REST interfaces to retrieve configuration and runtime information.

Now you can also include global case filters when packaging and importing configuration between EDQ environments.

For more information, see Using REST APIs for Importing and Exporting Configuration.

The Case Management REST API now allows you to define filter specifications as a JSON map, bulk update cases and alerts, bulk export cases and alerts, run a report, and cancel bulk operations. This release also includes simple REST APIs for Case Management Administration.

The Case Management REST API includes the following new functionality:

• Filter definitions as a JSON map to run searches: In previous versions it was necessary to specify a named filter to run searches using the case management REST APIs. Now the filter attribute in the runfilter and bulkdelete POST operations can be a JSON map defining the conditions for the search. These filter conditions can include any of the standard and extended attributes that are supported in the Case Management UI. Note that currently searches using case comments and transitions are not supported.
• Bulk update multiple cases using filter: You can filter and update multiple cases or alerts using the bulkupdate method. The user making the call must have the case management bulk update permission as well as any permissions defined with the transitions used in state change definitions.
• Export multiple cases and alerts: You can now use the export method to filter and export multiple cases or alerts to a file or URL. Supported output formats are JSON, JSON lines, XLSX and CSV. The user making the call must have the Export to Excel case management permission.
• Run a report: You can use the report method to run a case management report using a generic filter.
• Cancel a bulk operation: You can cancel a bulk delete, update or export operation using the execution key that is returned by the call that initiated the bulk operation.
• Case Management Administration APIs: This release includes simple APIs that allow you to list and delete case sources, case workflows, case management dynamic permissions, and global filters.

For detailed information about the Case Management REST APIs, see Using the EDQ Case Management API.

Fonts are no longer shipped with Oracle JDK 11 and later versions. Applications that require font rendering rely on the fonts that are installed along with the operating system.

Apache POI relies on the Java font mechanism to determine the average character width. If the Linux fontconfig package is not present, output generation fails with the “java.lang.reflect.InvocationTargetException” error.

To avoid this issue, you can do one of the following:

• Install the fontconfig package:

  # yum install fontconfig

• Allow Apache POI to ignore the missing fonts by setting the Java property org.apache.poi.ss.ignoreMissingFontSystem to true.

  Note that this is applicable to Apache POI version 5.2.x and later.

The generalized filter format in EDQ Case Management REST APIs allows you to filter records using the sourceid attribute to run searches.

For example:

sourceid": "process(cm-wf-p) processor(Advanced Match)" 

The filter code builds a map between the sourceid display value and the internal sourceid identifier. However, the sourceid display values may be duplicated, for example, if you copy a match process between projects. Such duplicate sourceid display values can cause the map building to fail with an IllegalStateException error.

To avoid this issue, do not use the sourceid attribute to run filters.

The result objects that are stored using the asynchronous operation for the Case Management bulk delete and update API are not serializable. When you try to bulk delete or update cases or alerts using the Case Management API in a clustered environment, an exception is thrown when the operation completes and the result object is stored for later retrieval.

The error is reported with the following status:

{
    "start": "2024-11-13T13:27:30.002Z",
    "complete": true,
    "failed": true,
    "error": "(Wrapped) java.io.NotSerializableException: oracle.edq.casemanagement.rest.data.DeleteResult",
    "end": "2024-11-13T13:27:30.050Z"
}

To support complex conversions, for example XML parsing, a JavaScript script can be provided to process the record value. The script XMLTransformer.purifyXML function does not disable external entity expansion, which could cause security vulnerabilities.

The Dashboard provides a high-level view of results, in the form of Indexes, Summaries or by Rules. These are collectively known as elements. The dashboard UI sorts all elements by status and passrate. The sorting is done by comparing passrates (passcount / totalcount).

If the total count is zero, this evaluates to NaN. Greater than and less than comparisons with NaN always return false, and so the comparison method returns 0.

For example, say you have elements A, B, and C where C has zero counts and the A passrate is greater than B. In this scenario, the comparisons will return as follows:

A > B (correct)

B < A (correct)

A = C (incorrect)

B = C (incorrect)

Since A = C and B = C, the sort expects A = B as well, which is incorrect.

If there are any dashboard rules that have zero comparison because no records in the process passed through the related processor, then the UI display may fail with a 500 error caused by the following exception:

java.lang.IllegalArgumentException: Comparison method violates its general contract!

To avoid this error do one of the following:

• Ensure that all rules have some published records
• Set the following system property:

  -Djava.util.Arrays.useLegacyMergeSort=true

If an export is configured to create a new table, EDQ removes the existing table first using the DROP TABLE tablename SQL statement. The space associated with the table is not immediately removed. The Oracle database renames the table and places it and any associated objects in the Recycle Bin.

You can change the schema password either automatically using the schema.password.auto.reset.after option or manually using the REST API. The schema password change updates the password in the database and in the director.properties file, but not in the underlying connection pool.

After the schema password update, the existing idle connections in the pool work fine, but any attempt to get a new connection will fail with an invalid username/password error.

The DatabaseMetaData getIndexInfo method is used to retrieve details of the table's indices. In almost all cases this is not necessary because the table is newly created and has no indexes.

When multiple threads are used to create tables in an Apache Derby database, the getIndexInfo call can trigger a deadlock on the data dictionary causing the following exception:

ERROR 40XL1: A lock could not be obtained within the time requested

The CEWS processor always decodes the result body using UTF-8 encoding. If a server returns an error message in a different encoding, the message will not be displayed correctly. This has been observed in calls where an incorrectly formatted payload resulted in a 400 error, but the error message was garbled.