I've been working with the two api's and have the following observations:
The activities search api brings back way more data than needed for the following search string. It brings back the whole incremental match thread graph of data including all items.data.type regardless of what it is...so long as at least one of them has a potential match thread in it. In this case the 'filter' really isn't filtering the items...it's just filtering the containing incremental match thread.
{{tenantURL}}/activities?filter=(gte(timestamp,'1632061607006') and equals(items.data.type,'POTENTIAL_MATCHES_FOUND'))%26max=25
I ran the export version of the activities api and had a happier result.
{{tenantExportURL}}/activities?filter=(gte(timestamp,'1632061607006') and equals(items.data.type,'POTENTIAL_MATCHES_FOUND'))
The exported file contains only potential matches and includes much less data than the activities search api. The one caveat here is that some items in the list may no longer be a potential match if something else caused an actual merge to take place subsequent to the potential match item being added to the activities log.
I will continue further investigations of these api's.
The assumption at this point is that a possible implementation would involve:
1) running an export api for activities since the last time it was ran
2) iterate through and process the file (we would likely use PDI) to get the entities affected and use another api call to create a workflow task for each item (possibly checking if they are still a potential match or maybe the api just fail to create the task in that case)
Question - would the generateFromQuery api not accomplish something similar to this (without the extra processing steps) or is there a limitation to what that can do with regard to net new potential matches?
------------------------------
Michelle Popovits
Empire Life
------------------------------