Can the next release support boolean, we have hot fixed ours but we hope the official release could support boolean to string conversion.
Module “Tag name maps” to support converting Bool to String.
Thanks
Thanks Scott for the reaching out! Could you provide a bit more context so we make sure we fully understand the enhancement request? Are you attempting to tag a CI field that is a boolean and that field is what needs to be converted to a string? What does the field value currently get tagged as when the integration runs?
Any screenshots or examples would be appreciated. Thanks!
We were not able to fix the problem completely because of the read only protection policy on the following script.
Capture1
To add the support of Boolean type we add Boolean type here.
Capture2
Table: Tag Name Map (x_r7_rapid7_cmdb_i_tag_name_map)
Column: Field
Attribute (types): string;reference;sys_class_name;boolean
After we made the attribute change, the integration started to create the tags for the field value ‘true’ only but not for the ‘false’ values. This is because of the following condition used in _createTagAssociation function of the script include Rapid7SNConnector (line 138)
Capture3
tagNameField = cmdb.getElement(tagConfig.field); // tagNameField has either true/false in case of boolean tag name map field.
In case of boolean (false) value, tagNameField gets the value false and it changes to true inside the if-block condition (!tagNameField). Hence it returns back with the message instead of creating the tags.
We have encountered another issue:
We are testing “Asset import” integration of the “InsightVM Integration for ServiceNow CMDB”. We have two sites with different number of assets. The integration creates and runs the report for each site.
SQL which executed for each Site on InsightVM by the integration.
WITH criticality_tags
AS (SELECT fa.asset_id,
dt.tag_id,
tag_name
FROM dim_tag dt
join dim_tag_asset fa USING (tag_id)
WHERE tag_type = ‘CRITICALITY’
GROUP BY fa.asset_id,
dt.tag_id,
tag_name)
SELECT Max(da.asset_id) AS “asset_id”,
da.host_name AS “name”,
da.ip_address,
da.mac_address,
dos.description AS “os”,
da.last_assessed_for_vulnerabilities,
Round(fa.riskscore :: NUMERIC, 0) AS “risk_score”,
fa.vulnerabilities,
fa.critical_vulnerabilities,
fa.severe_vulnerabilities,
fa.moderate_vulnerabilities,
ct.tag_name AS “criticality_tag”
FROM dim_asset da
join fact_asset fa USING (asset_id)
left join criticality_tags ct USING (asset_id)
join dim_operating_system dos USING (operating_system_id)
WHERE da.host_name IS NOT NULL
GROUP BY da.host_name,
da.ip_address,
da.mac_address,
dos.description,
da.last_assessed_for_vulnerabilities,
fa.riskscore,
fa.vulnerabilities,
fa.critical_vulnerabilities,
fa.severe_vulnerabilities,
fa.moderate_vulnerabilities,
ct.tag_name;
For Site A:
[Redacted Image]
As we can see the names are mentioned as FQDN (for the two highlighted assets) in insightVM dashboard but they are not in the result returned by the query.
Total assets in site A: 6
Name represented as FQDN (on dashboard): 2
Name represented as FQDN (on query result): 0
For Site B:
[Redacted Image]
As you can see that two names are represented as FQDN on insightVM dashboard but only one of them is represented as FQDN on query result.
Total assets in site B: 3
Name represented as FQDN (on dashboard): 2
Name represented as FQDN (on query result): 1
Site names are:
Site A : *****
Site B : *****
The question is for site A the query returns all NON FQDN names whereas in Site A one result is FQDN and other NON FQDN?
@scott_scott Thanks for the follow up. I’ve open up an enhancement request internally with regards to supporting boolean fields. With the current implementation, we believe there is a bit more work needed to make the use of boolean fields valuable (eg. defining a second level prefix). We will certainly take into the false value as you’ve pointed out.
As for the Asset Import portion of the App, we are attempting to reproduce this situation. If I’m understanding correctly, you are saying that the hostname returned does not alway return as a FQDN and at times returns as the shortname/hostname only. Is that correct?
“are saying that the hostname returned does not alway return as a FQDN and at times returns as the shortname/hostname only. Is that correct?” Yes
Also we have a few performance concerns with the extension, is this the expected performance, do we know if it will scale linearly or is it hopefully closer to constant time? Any suggestions on how to understand these timings and any tuning would be great.
| Start | End | Run Time HH:MM:SS | Tags Created | Tags Updated | Tags Deleted | Tagged Assets | Unmatched Assets |
|---|---|---|---|---|---|---|---|
| 2020-03-27 13:19:52 | 2020-03-27 14:09:02 | 00:49:10 | 1 | 0 | 0 | 2 | 0 |
| 2020-03-27 11:31:13 | 2020-03-27 12:35:43 | 01:04:30 | 2 | 0 | 0 | 3 | 0 |
| 2020-03-27 11:17:54 | 2020-03-27 11:27:56 | 00:10:02 | 1 | 0 | 0 | 3 | 0 |
| 2020-03-27 09:08:04 | 2020-03-27 10:44:53 | 01:36:49 | 0 | 0 | 0 | 0 | 0 |
| 2020-03-27 07:26:35 | 2020-03-27 08:23:38 | 00:57:03 | 1 | 0 | 0 | 1 | 0 |
@scott_scott This is definitely not behavior we have experienced previously with many more assets in scope. When running the Asset Tagging job it might be beneficial to review the logs located at Rapid7 InsightVM Integration for CMDB -> Diagnostics -> Logs and note when the job gets started compared to entries for “Deleted InsightVM report”. An initial guess is running the reports on the InsightVM console is taking longer than it should for generating the asset and tag related data. Adding a screenshot of a recent run in one of our labs which only took 3 minutes:
Leveraging generated reports is our most scalable way to achieve this integration. It will be impacted by environment size; however, we are limiting the amount of data returned to avoid unnecessary impact to the console when running the reports. If you see that the reports are taking the vast majority of the time to generate during the job running, it would probably be best to identify if this is common with any other reports you run in your environment as well.
1 Like
So this makes sense because generating a report in this particular console takes an eternity and no one has been able to help us fix it.
Who coded this extension R7 or ServiceNow?
"Dear scott,
Your Rapid7 support case “FQDN or Hostname returned”, case #00236788, has been updated with the following information:
Hi Scott,
As ServiceNow is a partner integration I would have to refer you to their support team.
Regards,
…"
@scott_scott We have opened up a case on your behalf so that we can dig deeper into the issue you appear to be experiencing that is likely related to report generation on your console - since you mentioned past issues along with the current long running import. I will be reaching out to our team internally to make sure this is handled appropriately.
To answer your question, this specific integration was built and maintained by Rapid7.