Filtrage au sein de Réponse aux vulnérabilités

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 1 minute de lecture
  • Les règles, calculateurs et règles d’affectation de tâches de rattrapage utilisent des conditions lors de l’importation, créées à l’aide du Créateur de conditions. Les changements apportés à leurs critères peuvent affecter les performances, car chaque enregistrement est évalué à l’aide de ces filtres.

    Les règles et calculateurs fournis avec le système de base sont optimisés pour les performances. L’édition ou la création de règles ou de calculateurs prend soin et peut nécessiter les deux ServiceNow et Réponse aux vulnérabilités une expertise.

    Éviter le filtrage basé sur les champs de sous-classe

    Certaines tables prennent en charge l’extension. La table CI CMDB [cmdb_ci] en est un exemple. Des tables comme cmdb_ci_hardware et cmdb_ci_computer étendre cette table. Si vous filtrez en fonction d’un champ qui ne figure pas dans la table parente, la construction et l’évaluation de ce filtre peuvent s’avérer coûteuses.
    Exemple de menu déroulant de filtre de condition.

    Par exemple, le filtrage sur Élément de configuration > Coût ne nuirait pas aux performances, car le coût est un champ de classe et non un champ de sous-classe de l’élément de configuration. Filtrage sur l’exemple de champ de classe

    Élément de configuration > Ordinateur, cependant, est une sous-classe nécessitant une remontée pas à pas vers un autre champ, dans ce cas, le système d’exploitation. Ce processus peut prendre plusieurs millisecondes, ce qui s’additionne rapidement, lorsque des millions d’éléments vulnérables sont importés, et affecte les performances. Filtrage sur l’exemple de champ de sous-classe.
    Remarque :
    L’utilisation de la condition [contient] s’apparente à une recherche par caractères génériques et peut avoir un impact sur les performances. L’utilisation de [est], dans la mesure du possible, est plus efficace.