Closed ndowmon closed 3 years ago
@fomentia FYI - I'm sure you're already aware of this behavior but just in case.
The mapper creates _key properties using the source entity ID, rather than source entity key. I've visually confirmed that the only difference between the 8 mapped relationships is that some of the old mapped relationships have a tag.AccountName property, where the new mapped relationships do not.
The id properties were changed from number to string in order to conform to some requirements of jobState.addEntity. I could change them back for posterity, and we could open issues to use createIntegrationEntity() for safety.
I think it good that they become strings. I'd be surprised if anyone is running queries that expect a number
.
The mapper creates _key properties using the source entity ID, rather than source entity key. I've visually confirmed that the only difference between the 8 mapped relationships is that some of the old mapped relationships have a tag.AccountName property, where the new mapped relationships do not.
I saw similar results in the Okta integration. As long as the relationships between the entities exist, I would expect any queries that care about the relationships will continue to function.
This diff was generated with two fresh integration instances. I'm not sure if the old integration had behavior that allowed certain findings / reports etc to not be deleted (partial datasets). I would appreciate a review of the old code to ensure I haven't missed any partial datasets in the conversion.
Reviewing the old code, I don't see that there are any partial sets. Does this new code do anything to limit the amount of data processed?
Reviewing the old code, I don't see that there are any partial sets. Does this new code do anything to limit the amount of data processed?
@aiwilliams no, not yet. I suspect once this goes into production we'll want to make further incremental improvements there.
See computed diffs between the old integration & new integration. Notes:
tenable_scan_report
,tenable_scan_finding
,tenable_scan_malware
, ortenable_scan_unwanted_programs
entities or associated relationships.id
properties were changed from number to string in order to conform to some requirements ofjobState.addEntity
. I could change them back for posterity, and we could open issues to usecreateIntegrationEntity()
for safety._key
properties using the source entity ID, rather than source entity key. I've visually confirmed that the only difference between the 8 mapped relationships is that some of the old mapped relationships have atag.AccountName
property, where the new mapped relationships do not.