Released: July2022
This release contains no new features.
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.
This release contains no changes in functionality.
This release contains no changes to third-party libraries.
[MAME-7715] The merge process is slow when changing the record state to Unset.
This release contains the following known issues:
[MAME-7434] Linked records are duplicated in the link table when one of the foreign keys is not part of the primary key.
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).
Released: June 2022
This release contains the following new features:
The following algorithms were added:
Phonetic full text: An algorithm best used for strings. It can recognize the phonetic equivalent of two words spelled differently using the Beider-morse phonetic tokens. The comparator takes into account the synonyms and stop words defined in the data model.
Hybrid fuzzy: An algorithm best used for string and text data types. It can capture complex relationships between two field values by automatically customizing transformations for a given criterion. Points of note about this algorithm:
Does not return a 100% matching score on synonyms.
Strings that are similar, but contain characters like spaces or dashes do not return a 0% matching score.
When strings fall within the acceptable distance score they are not considered as the exact same. For example, a distance of 1 returns .95, a distance of 2 returns .9, etc.
A script task was added to run a matching operation from a workflow.
Fields can now have a weight of 0. Setting the weight to 0 excludes the fields from the pre-processing phase.
An API was added to check whether the add-on has any ongoing background operations.
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.
The options to specify what happens after a merged record is modified were removed. Now, the following behavior is applied when a record is in the merged state and the modified field:
Is not configured to use in matching operations: The add-on executes an automatic merge using the settings defined in the default matching policy's merge policy.
Is configured to use in matching operations: The record is changed to the <unset> state.
This release contains no changes to third-party libraries.
This release contains the following closed issues:
[MAME-7400] Changing record state to Unset fails when many transactions are committed in a short period of time.
[MAME-7455] The Evaluate matching and Run match services return inconsistent results.
[MAME-7479] There is conflict between the Evaluate matching and See details results.
[MAME-7542] Results cannot display after running Evaluate matching on a display with 1920X1080 resolution at 150% zoom.
This release contains the following known issues:
[MAME-7434] Linked records are duplicated in the link table when one of the foreign keys is not part of the primary key.
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).
Released: June 2022
This release contains no new features.
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.
This release contains no changes in functionality.
This release contains no changes to third-party libraries.
[MAME-7532] A performance issue occurs during the grouping phase when running matching on an entire table.
This release contains the following known issues:
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).
Released: May 2022
This release contains no new features.
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.
This release contains no changes in functionality.
The Spring framework was updated to version 5.2.22.
This release contains no closed issues.
This release contains the following known issues:
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).
Released: April 2022
This release contains no new features.
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.
This release contains no changes in functionality.
This release contains no changes to third-party libraries.
This release contains the following closed issues:
[MAME-7397] The Merge view and the Lineage view cannot be accessed when all fields in a group or table are computed fields.
[MAME-7398] Performance is slow when fetching values n to n relationships.
[MAME-7436] When running the Evaluate matching service the field values do not display correctly when using the same field identities, but in different tables.
[MAME-7407] Boolean fields cannot be merged when Check null input is enabled.
This release contains the following known issues:
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).
Released: April 2022
This release contains no new features.
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.
This release contains no changes in functionality.
The Spring framework was updated to version 5.2.20.
This release contains no closed issues.
This release contains the following known issues:
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).
Released: March 2022
Performance was improved to retrieve groups containing suspect records.
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.
This release contains no changes in functionality.
This release contains the following changes to third-party libraries:
The Spring framework was updated to version 5.2.19.
The FasterXML/jackson-databind library was updated to version 2.13.2.1.
This release contains no closed issues.
This release contains the following known issues:
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).
Released: February 2022
This release includes the following new features:
You can now replicate matching metadata. This allows you to use third-party tools to access and query the metadata.
The following algorithms are now available:
Fuzzy full text: This algorithm works best for strings and can find the similar and fuzzy matches of the words in the compared values. It is based on the Levenshtein distance algorithm. The comparator takes into account the synonyms and stop words defined in the data model.
Range: This algorithm matches values within a predefined range. The two values are considered a match if the distance between two values is within the specified range.
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.
This release contains the following changes in functionality:
When Auto create new golden is enabled, the requirement was removed for the matching table's primary key to be an auto-incremented integer.
When executing add-on operations, only the add-on's table triggers are disabled. All user custom triggers remain enabled. Note that table triggers related to metadata linked fields are not recommended as it might affect the accuracy of match and merge operations.
This release contains no changes to third party libraries.
When matching is set to After submission and batch creation of records occurs using the EBX® API, the number of submitted or created records is limited to 2000 records in an API call for tables that have a single primary key. For a composite primary the limit is divided by the number of fields that makes up the primary key. For example, with a table that has a primary key comprised of 2 fields, the limit would be 1000 records. When your requirements exceed these limits, it is recommended that you pause the matching trigger, load the data, and resume matching. Also, note that when matching is triggered the dataspace is locked until matching completes. Any incoming requests during this time are blocked and will return errors.
This release contains the following known issues:
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).
Released: December 2021
This release includes no new features.
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.
The Apache Log4j library was upgraded to version 2.17.1.
This release contains no changes to third party libraries.
This release contains no closed issues.
This release contains the following known issues:
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.
When matching is set to After submission and batch creation of records occurs using the EBX® API, the number of submitted or created records is limited to 2000 records in an API call for tables that have a single primary key. For a composite primary the limit is divided by the number of fields that makes up the primary key. For example, with a table that has a primary key comprised of 2 fields, the limit would be 1000 records. When your requirements exceed these limits, it is recommended that you pause the matching trigger, load the data, and resume matching. Also, note that when matching is triggered the dataspace is locked until matching completes. Any incoming requests during this time are blocked and will return errors.
Released: November 2021
This release includes the following new features:
You can now exclude records from matching operations by specifying a field value. If a record contains the specified value, it is not included in matching operations. Using this functionality can help improve performance and improve the quality of matching results.
You can now modify records that were included in a merge operation.
The new Evaluate matching service allows you to test matching results. This can help you fine tune configuration settings to achieve desired results.
Adding an association to your data model allows you to view: a hierarchy of golden and merged records, and a tab when viewing golden record details that displays all merged records that target the golden.
Matching now supports use of non-Latin based text.
A new merge function on field survivorship allows you to add a constant value that is merged into golden records on survivorship.
The Full Text algorithm is now available to use in matching for fields with Text and String data types.
You can now use a foreign key field as a field in a decision tree's comparison node.
When upgrading from version 3.0.0, 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.
This release contains the following functionality changes:
The default mode for Align foreign keys is now set to Manually.
The Case sensitivity option is now only available for fields with String and Text data types.
This release contains no changes to third party libraries.
This release contains no closed issues.
This release contains the following known issues:
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.
When matching is set to After submission and batch creation of records occurs using the EBX® API, the number of submitted or created records is limited to 2000 records in an API call for tables that have a single primary key. For a composite primary the limit is divided by the number of fields that makes up the primary key. For example, with a table that has a primary key comprised of 2 fields, the limit would be 1000 records. When your requirements exceed these limits, it is recommended that you pause the matching trigger, load the data, and resume matching. Also, note that when matching is triggered the dataspace is locked until matching completes. Any incoming requests during this time are blocked and will return errors.
Released: September 2021
This release includes updates and enhancements to improve the performance of matching operations.
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.
This release contains no functionality changes.
This release contains no changes to third party libraries.
This release contains no closed issues.
This release contains the following known issues:
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.
When matching is set to After submission and batch creation of records occurs using the EBX® API, the number of submitted or created records is limited to 2000 records in an API call for tables that have a single primary key. For a composite primary the limit is divided by the number of fields that makes up the primary key. For example, with a table that has a primary key comprised of 2 fields, the limit would be 1000 records. When your requirements exceed these limits, it is recommended that you pause the matching trigger, load the data, and resume matching. Also, note that when matching is triggered the dataspace is locked until matching completes. Any incoming requests during this time are blocked and will return errors.
Released: July 2021
This release includes the following new features:
A new REST API is available to perform matching related operations. You can use Swagger to view the API documentation. See REST overview for more information.
Matching operations after record submission are now available for records created using the EBX® API. There are some limitations to this functionality. See the Known issues section below for details.
Several matching services are now available to use in workflows and perspectives. See Perspectives and workflows for more information.
The add-on now supports link tables when matching with relationships. Additionally, to avoid confusion with EBX®'s concpet of associations, this feature was renamed to Use relationships.
The add-on's matching algorithm library now includes the Soundex algorithm. This algorithm works well for short strings such as names. See Matching algorithms for more information.
The list of algorithms is now filtered based on the search strategy configured for a matching field. Additionally, the validation report will display a warning if the configured algorithm is not compatible with the field's search strategy. See Matching algorithms for more information.
Administrators can now set a matching policy as the default policy from the Matching policies tab in the Actions menu.
A merge policy's record selection mode now includes the First acquired option to select the oldest record during survivorship.
The Customize source value for new golden now supports foreign keys.
Matching metadata can now be added to tables by creating a custom view. See Displaying matching metadata for more details.
The add-on's Consolidated view the Actions menu where you can execute matching related operations.
When viewing table data, you can now access the Metadata view's Lineage tab by selecting View lineage.
When a group contains only one record that does not need to be merged, a new Set as golden button allows you to set its state to golden.
This release contains the following functionality changes: When using the Run match service to run a match on all records in a table, you must now select all records in the table instead of selecting nothing.
This release contains no changes to third party libraries.
This release contains no closed issues.
This release contains the following known issues:
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.
When matching is set to After submission and batch creation of records occurs using the EBX® API, the number of submitted or created records is limited to 2000 records in an API call for tables that have a single primary key. For a composite primary the limit is divided by the number of fields that makes up the primary key. For example, with a table that has a primary key comprised of 2 fields, the limit would be 1000 records. When your requirements exceed these limits, it is recommended that you pause the matching trigger, load the data, and resume matching. Also, note that when matching is triggered the dataspace is locked until matching completes. Any incoming requests during this time are blocked and will return errors.
Released: March 2021
[MAME-5857] A documentation issue was corrected.
Released: March 2021
The TIBCO EBX® Match and Merge Add-on locates and merges duplicate data values. The goal is to obtain a singular record that most accurately defines a business entity. The add-on identifies these as golden records.
Features available to administrators in include the ability to:
Make data available to the add-on by registering and activating matching on tables.
Configure a matching policy that determines how the add-on compares data. A matching policy also specifies whether users must start the matching process manually or if it starts automatically when data is created or updated.
Create a merge policy that establishes how duplicate data values are merged into a golden record. Merge policies can also execute automatically after a matching process runs.
Set up trusted sources that define a hierarchy of data sources. The add-on uses the source's trust level to during matching to choose the most accurate record and during a merge to select values to merge.
Administrators can use Administrator Guide to learn more about configuration options available in this release.
Features available to business users include the ability to:
Select data and initiate matching and merge operations. Search for records that might match when creating a new record.
Manage records that grouped together after running a matching process. The add-on groups records that are suspected of containing duplicate data or are positively identified as being duplicate. When managing groups you can also specify that a record is a false-positive match so that it no longer matches with the records in its group.
View record metadata applied by the add-on to categorize records. Two different views allow users to view individual record, or an entire table's metadata. Some information displayed includes the record's history, lineage, state, and records identified as false positive matches.
Business users can learn more about available actions and view in the User Guide.