Released: April 2023
The matching operation triggers can now be paused on business objects.
This release contains no changes in functionality.
The SnakeYAML library was updated to version 2.0.
This release includes the following closed issues:
[MAME-8622] Hidden field values are not updated after the merge process finishes.
[MAME-8623] An inconsistent matching result is shown in the diagram when evaluating matching results.
[MAME-8624] The record order in when managing a group in the Consolidated view is incorrect.
[MAME-8626] Incorrect matching results are returned when using light relationships (FK from matching table to target table OR over a link table).
[MAME-8628] The State is duplicated in the Identified as false positives tab.
[MAME-8629] The back button does not work as expected after completing a merge.
[MAME-8630] Some text is not translated into French.
[MAME-8632] A false positive relationship is not created after merging records in the inline screen.
[MAME-8634] [UI] When hovering over the False positive icon in the Manage group screen, the cursor displays as a hand.
[MAME-8635] Records are not sorted correctly when accessing the Merge view when managing a group.
[MAME-8636] The warning banner does not display when accessing a group that includes at least one hidden record.
[MAME-8637] The matching field is changed when duplicating a matching policy.
[MAME-8638] [BO] There is no new golden record but the Apply merge policy button is still enabled.
[MAME-8640] When managing relationships during a manual merge, it takes a long time to display records.
[MAME-8646] An incorrect error message displays when manually merging and the main table's primary key is not auto-incremented.
[MAME-8670] All add-on services still display in the Actions menu after pausing the corresponding matching configuration.
[MAME-8678] Matching cannot be evaluated for selected records when using a matching policy without having a merge policy defined in the related table.
[MAME-8884] Unexpected information is included in the log file.
[MAME-8891] An error displays after unmerging an auto-created golden record that had been merged multiple times.
[MAME-8894] The login page displays when executing any action in the Actions menu in the Manage group screen after accessing the group from a workflow.
[MAME-8920] The decision tree result is inconsistent when evaluating matching for a URI field through a relationship.
[MAME-8932] An error occurs when running manual merge if the primary key is a String and includes an apostrophe in the data value.
[MAME-8936] An error displays when applying sort criteria for false positive records or when viewing records in the Manage group screen.
This release contains the following known issues:
A field configured for use in matching operations cannot be configured for other relationships. For example, in a Person table the Address field is configured through matching by foreign key. This field cannot be configured in another instance with a different relationship (over linked table, or none).
[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: February 2023
This release was updated to ensure compatibility with TIBCO EBX® Add-ons Bundle version 5.6.1.
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 includes no closed issues.
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: November 2022
This release contains the following new features:
The UI was updated for manual merge operations on the tables that comprise business objects.
The stewardship UI was updated so that lineage and metadata can be viewed for a business object's related tables.
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 FasterXML jackson-databind library was updated to version 2.13.4.2.
This release includes the following closed issues:
[MAME-7953] The manual merge view is slow to load if the table has a merged records association.
[MAME-8157] The Align foreign keys step does not display when a merge policy attribute is defined and Use for manual merge is set to No.
[MAME-8201] Hidden field values are still highlighted when selecting a survivor field by merge function.
[MAME-8265] Matching state is cascaded to child levels when unmerging even though the child records are excluded.
[MAME-8283] When using matching fields from related tables with the Exact algorithm and Both value are null = Match, there are inconsistent matching result between Evaluate Matching and See details.
[MAME-8286] An HTML block is displayed instead rendering the Decision tree and Business object activation.
[MAME-8318] Deleted records display in the Data selection view of the Supersede survivorship service.
[MAME-8326] The Manage group screen should be reloaded after a successful manual merge operation.
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: September 2022
This release contains the following new features:
Matching and merge operations can be configured on multiple tables that comprise EBX® business objects.
The Manage group view is able to display records from multiple tables in a business object.
To improve the user experience, the progress bar was updated.
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 Apache Taglibs library was removed from this release.
This release includes the following closed issues:
[MAME-7661] The content does not display correctly when there are more than 50 errors in a validation report on the Consolidated view.
[MAME-7844] There is a disparity between matching results when using Evaluate matching vs Run match.
[MAME-7874] After rejecting a suspect record, users are navigated away from the Manage group screen and back to the tabular view.
[MAME-7989]DecisionTreeComparator is not thread-safe.
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: 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.