Handling of Edited Inventory During Rescans
FlexNet Code Insight 2019 R1
FlexNet Code Insight enables you to make changes to inventory both in Analysis Workbench and on the Project Inventory tab. You create inventory items as well as edit both user-created and system-generated inventory. Edits to existing inventory can include changes to the following elements:
|
•
|
The component version string or the associated license |
|
•
|
Codebase-file associations (only in Analysis Workbench) |
|
•
|
Inventory properties and notes |
However, normal Code Insight rescan behavior can result in actions that impact your inventory changes. For example, an updated Automated Analysis rule set might associate codebase files to an inventory item different from the one to which you have manually associated these files. Logically, the rescan would remove the associations you defined and re-apply them to the inventory item identified in the rule set.
The following topics describe how the rescan process handles edited inventory:
Rescan Rules to Preserve Your Inventory Edits
To ensure that inventory changes are preserved, the rescan applies the following rules to edited inventory:
|
•
|
All the user-created inventory, its file associations, and edits are considered not system-updatable and therefore are preserved. |
|
•
|
Any change to a system-generated inventory item (including the component) results in the inventory item being classified as user-created and therefore not system-updatable (see the previous rule.) However, the rescan can add additional files to the inventory item if the component, version, and license match. |
|
•
|
If one or more files were disassociated from a system-generated inventory item before the rescan, rescan logic assumes that these files were erroneously associated with component initially. Therefore, the rescan does not attempt to re-associate these files to the inventory item; nor does it associate the files with another inventory item that uses the same component name (with a different version or license). The following example scenario illustrates this rule. |
Rescan Scenario: Handling of Files Manually Disassociated from Inventory Before Rescan
The following scenario demonstrates how the rescan process handles files that you manually disassociated from a system-generated inventory item before the rescan.
In this scenario, the initial scan on your codebase generated the inventory item log4j 2.6 and associated the files file1.jar and file2.jar with the item.
However, after analyzing the inventory, you realize that file2.jar should be associated instead with log4j 2.11, an inventory item that does not exist in your current inventory. To remedy this, you perform the following steps:
|
1.
|
Create an inventory item named log4j 2.11. |
|
2.
|
Disassociate the file2.jar from log4j 2.6. |
|
3.
|
Associate file2.jar with the inventory item log4j 2.11 that you just you created. |
On rescan, your edits remain intact:
|
•
|
The file file1.jar remains associated with the inventory item log4j 2.6. |
|
•
|
The inventory item log4j 2.11 that you created is preserved along with its association with the file file2.jar. |
The rescan also results in the creation of a new system-generated inventory item, log4j 2.10. However, the rescan does not associate the file file2.jar with the new inventory item.
Open topic with navigation