This release contains the following enhancements:
Null value management:
Previously, a field's null value management settings were applied anytime the field was used in a decision tree's comparison node. To provide more flexibility, comparison nodes now include settings for each field to determine the outcome when one or both of the compared values is null. This makes it possible to apply different matching behaviors for the same field in different parts of the decision tree. For example, one node can require an exact match, where both records must contain a value, while another node can use a "not mismatched" strategy, which considers records matching unless their values are explicitly different. Note that these new settings apply only to the decision tree processing phase of matching.
A new Do nothing option was added to the Matching fields tab's options. This option ensures that null values are not considered as similarity criteria during the pre-processing clustering phase. When null values are ignored, matching performance and quality can improve as it can prevent unnecessary decision tree computations. For instance, it can prevent false positives from being passed to decision tree processing for evaluation.
The following new options were added for specifying when golden records are automatically created for business objects:
Only duplicates (available for a business object parent entity only): A new golden record is automatically created only when the add-on identifies a positive match between records. With this option selected, child entities must use the Any duplicates option described below.
Any duplicates (available for child entities only): If the parent has positive matches, a new golden is created for the parent and its children. If matches are found for children of the same parent, but not the parent, a new golden is created for the child only.
This release includes the option to show whether records were matched through a transitive match. Transitive matching refers to the inclusion of records based on indirect relationships. For example, if Record A matches Record B, and Record B matches Record C, then Record A and C are grouped together due to their transitive connection through B. Administrators can configure display of this information using the new Show match type property, located on each matching policy. When enabled, users will have a new Match type column in the Manage group screen that shows whether the match type is Direct, Transitive, or N/A for the survivor record.
Performance improvements: This release includes multiple backend updates and enhancements to improve the add-on's performance.
Improved exception handling:
Workflows that include matching operations are now stopped when an exception occurs in the add-on. An error message detailing the issue displays in the workflow UI.
When performing a grouping operation, an exception is thrown when the center record cannot be found. Previously, only a NullPointerException was thrown. Now, an error message is logged and shown in the UI. The message includes the group Id to support location and correction of the issue.
Logging enhancements:
Warnings for SurvivorServiceImpl#getFieldSurvivorsByMergeFunction could be repeatedly logged, leading to a performance cost and difficulty in parsing the logs. To alleviate this, the warnings are consolidated and logged after longer increments.
A log entry is now created when pausing and resuming the matching trigger. The log includes information on the affected table.
Logs created when merged data includes many null fields were condensed to improve readability.
API enhancements: The simulate match API previously returned a list of MatchingEngineResult objects that contained primary keys for the target and pivot records. This required additional resources to look up the record's corresponding Adaptation. Now the Adaptation is returned instead of the primary key.
When upgrading from version 3.0.0, 3.1.0, or 3.1.1 you must update existing matching configurations. After updating configuration settings, you should re-execute matching to ensure that matching related metadata is up to date.
As the add-on UI is under development, some images in the documentation might not exactly match those in the UI.
In addition to existing functionality, the Purge old results service removes any records that are orphaned for any of the following reasons:
If record was, but is no longer linked to a golden record (for example if the golden was deleted).
If a record was deleted in the main table, but still exists in the RecordMetadata table.
Take the following into account if you upgrade TIBCO EBX® Match and Merge Add-on:
When upgrading from version 3.0.0, 3.1.0, or 3.1.1 you must update existing matching configurations. After updating configuration settings, you should re-execute matching to ensure that matching related metadata is up to date.
If upgrading from any version prior to 6.2.0, a performance improvement was made to better balance the weights of fields that participate in matching. The automatic balancing occurs during the pre-processing phase. This helps mitigate issues that might occur when fields include many values. As a result of this update, matching operation results might be impacted. To mitigate any negative impacts, you can test and adapt your existing weights to achieve the desired matching outcome. Alternatively, you can set the ebx.clustering.balance property to false in the ebx.properties file to restore the legacy behavior.
This release contains no updates to third-party libraries.
This release contains the following closed issues:
[MAME-9695] The log4j.property should be removed to ensure proper logging.
[MAME-9773] The error message displayed does not have enough details when a metadata dataset and business table cannot be linked.
[MAME-9836] The column size in the Manage group screen does not work correctly when switching between views.
[MAME-9861] The Merge button is active when managing groups, even under circumstances when it should be disabled.
[MAME-9866] It is no longer possible to resize columns in the Merge view.
This release contains the following known issues:
The following workaround is for a known issue in EBX® (CP-27860). When child dataspaces or snapshots are created before enabling the EBX Match and Merge Add-on on a data model, some operations can fail after the add-on is enabled. For instance, child dataspace merge might not work correctly, or snapshots might have errors.
Workaround: Disable the add-on before performing the dataspace merge, or creating a snapshot; enable the add-on after completing the operation:
Open the data model, navigate to Configuration > Add-ons.
To disable the add-on, tic the box next to Match and Merge and select Delete from the Actions menu.
Publish the data model.
After performing the desired operations, enable the add-on by re-creating the Match and Merge record in the Add-ons table.
Publish the data model.
[MAME-8084] The Evaluate matching service returns inconsistent results for related matching fields that have the DateTime data type.
[MAME-8857] It is not possible to accept or reject suspects in groups that contain a large number of records.
Foreign key alignment of recursive foreign keys is not possible.
[MAME-7434] Linked records are duplicated in the link table when one of the foreign keys is not part of the primary key.
[MAME-9049] A manual merge operation cannot be performed on more than 400 records.
When matching using the foreign key option, you can only specify a single hop foreign key. In other words, it cannot be a foreign key to a foreign key.
The Validation service in the Consolidated view runs as expected when first executed, but slow on subsequent executions.
In order to accurately track record lineage, table history must remain activated over time. If the table's activation status repeatedly changes, the lineage data will be inconsistent.
Severe errors occur when multiple datasets based on the same model exist and a table from one of these datasets is activated in an add-on matching configuration. As a workaround, you can create another data model publication using the Manage publications service in the Data Model Assistant. After creating a dataset for the new publication, you can follow the normal procedures to configure a matching policy for tables in the new dataset.
For foreign key alignment, the FKs that are multi-value fields cannot be aligned (either manually or automatically).