- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-27-2024 10:45 AM
Hi folks!
Is there anybody out there that might be able to simplify an explanation, point to a more distinct document or KB article that explains the linkages of the Integration to the source integration, to the source integration, the integration parameters, the REST details (Message and Method), and the integration script itself? I am trying to create a custom copy from the Host Detection integration, and want to more selectively associate API filter values to those required for the call being built. There are items coincidental to the detections (like Truncation Limit for example).
I am missing something in just where each item is pulled from and what gets actually placed in the restmessage variable that gets executed over to the API call and not finding the easy flow map that I am hoping for.
Thanks, in advance, if anybody has a suggestion for me.
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-02-2024 10:00 AM - edited ‎04-02-2024 10:03 AM
Hey Joe - understood, that's a fair reason for going with the cloned job and components.
On that cloned HTTP Method - did you override the 'truncation_limit' query param "Value"?
- It does have the dynamic $substitution / $string replacement format - but since you cloned that object for this job, you can override it with the explicit value you have with the actual value (e.g. "750")
- Then your baseline Detection job would still operate with Truncation of 200 (using the dynamic substitution that uses the input from the Qualys int source config), and your tailored IG / InfoGath job would run with a Truncation of 750 that is a literal input (overriding the dynamic substitution / Qualys int source config).

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-02-2024 08:20 AM
Hey there.
At some point, an older diagram was floating around that sort of stitched the picture together with the different Script Includes involved for the Qualys API request and processing once the data comes in - having a tough time finding it, and also not sure if it is current.
That said - the main Script Include you will want to review is -> `QualysHostDetectionIntegration2`; specifically the method <_buildRESTMessage>.
- Here is where you can see some of the "dynamic" parameters that feed into the API Request, gathering inputs like the "startTime", inputs that were set on Setup Assistant like "Severity", inputs from properties like "Truncation", etc.
For the additional filtering that you were interested in - you could certainly create your own cloned flavor of an integration job (using the same Integration Source), and your own flavor of the REST (POST) message - or - you could append the baseline REST message with your filtering needs as well.
Curious - what sort of filtering were you looking to add in - e.g. further filtering by Qualys Host Tags, IP ranges, etc?
That may help paint the picture for which path would be more desirable (cloning the job with your additional filtering, or modifying the baseline request with your additional filtering).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-02-2024 08:42 AM
Thanks for the response Andy - the piece I am really the most interested in is how an item added to the method translates to how it gets used in the script (query parameter versus string parameter, for example) and how it relates to the integration parameters for the instance.
We have a need for "Information Gathered" Qualys checks, not just the "Vulnerabilities", and I was told flat out that ServiceNow does not support that and that I needed to acquire Configuration Compliance module to bring in the Policy Compliance items. Not all Information Gathered QIDs have Policy Compliance CID equivalents.
One place of conflict for me is in the truncation limit - an API filter that is defined in the instance parameters, included in the Method list of items with string replacement notation, and set by (if I remember correctly) the set string parameter statement within the _buildRestMessage logic - where truncationLimit is the string name being used and truncation_limit is the API filter spelling of that ... my example is that we had to go down to 200 hosts at a time for the Detection integration, but I can run at 750 hosts at a time for the limited Info data we are after.
I have managed to copy/paste/edit all the components, the integration, its script, the HTTP Method, the report processor, and a few other objects to make a custom copy. I didn't want it conflicting with the data sources of the original integration so I made a copy/paste/edit of those as well ... all seems to be working for me, but I am still not keen on just how all those places work in choosing a query versus string on setting the parameters, and when a field should be added to the integration parameters, or when hard coding of values in the method would work just as well.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-02-2024 10:00 AM - edited ‎04-02-2024 10:03 AM
Hey Joe - understood, that's a fair reason for going with the cloned job and components.
On that cloned HTTP Method - did you override the 'truncation_limit' query param "Value"?
- It does have the dynamic $substitution / $string replacement format - but since you cloned that object for this job, you can override it with the explicit value you have with the actual value (e.g. "750")
- Then your baseline Detection job would still operate with Truncation of 200 (using the dynamic substitution that uses the input from the Qualys int source config), and your tailored IG / InfoGath job would run with a Truncation of 750 that is a literal input (overriding the dynamic substitution / Qualys int source config).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-02-2024 10:09 AM
Yes, Andy, while still wanting to better understand how it all links up, I did exactly as you are asking. I hard coded 750 into the new post method I created for this cloned integration. The one filter example was sort of easy to do that, and see the effects. But I would still like to see better documentation that fully (clearly?) describes the linkages and how one item gets translated from the integration instance parameters to actual API filters without my need to get into the trial and error attempts to trace and understand what is happening. Better understanding of what I was getting myself into could have saved a few hours of my time in cloning this thing.