Learn IT with Shikha Blogs

Série OpenText NOM – Partie 1 SNMP expliqué pour les ingénieurs monitoring | Guide débutant supervision réseau La base de toute supervision réseau Fait partie de la série d’apprentissage OpenText Network Operations Management 👉 Voir la série complète : (ajouter le lien hub plus tard) Pourquoi chaque ingénieur monitoring doit comprendre SNMP Presque tous les outils de supervision — y compris OpenText NOM — reposent sur un protocole essentiel : SNMP (Simple Network Management Protocol) Routeurs, switchs, firewalls, imprimantes, serveurs… Ils ne communiquent pas automatiquement avec l’outil de monitoring. SNMP est leur langage. Sans SNMP : le tableau de bord resterait vide. Que fait réellement SNMP SNMP permet à un outil de supervision de : Vérifier si un équipement est actif Lire CPU et mémoire Surveiller la bande passante Détecter des pannes Recevoir des alertes En résumé : L’outil demande → l’équipement répond Modèle de communication SNMP 4 SNMP repose sur trois éléments : 1️⃣ Manager...

OpenText NOM Series – Part 1 SNMP Explained for Monitoring Engineers The Foundation of All Network Monitoring Part of the OpenText Network Operations Management Learning Series 👉 (Update later) View Complete Series Here: [Hub Page Link] Why Every Monitoring Engineer Must Understand SNMP Almost every enterprise monitoring tool — including OpenText NOM — depends on one core protocol: SNMP (Simple Network Management Protocol) Routers, switches, firewalls, printers, servers… They don’t “talk” to monitoring tools automatically. SNMP is the language they use. Without SNMP: Monitoring dashboards would be empty. What SNMP Actually Does SNMP allows a monitoring system to: Check if a device is alive Measure CPU & memory usage Monitor bandwidth utilization Detect failures Receive alerts from devices In simple terms: Monitoring tool asks → Device answers SNMP Communication Model 4 SNMP works using three components: 1️⃣ Manager The monitoring tool (Example: NOM / NNMi) 2️⃣ Agent Software runni...

  User Criteria vs Manager vs Groupe (quelle différence ?) Les approbations sont au cœur des processus ServiceNow. Que ce soit pour : une demande d’accès un ordinateur une validation budgétaire une demande RH Comprendre les types d’approbation est essentiel pour une bonne implémentation. Beaucoup confondent : Approbation manager Approbation groupe Approbation utilisateur User Criteria Clarifions cela simplement. Comment fonctionne une approbation 4 Lorsqu’une demande est soumise : REQ → RITM → Approbation → Création des tâches Si l’approbation est requise, le processus s’arrête jusqu’à validation. 1️⃣ Approbation Manager Type le plus courant. ServiceNow vérifie automatiquement : Requested For → Manager Exemple Demande de logiciel → validation du responsable Attention Si aucun manager n’est défini → approbation bloquée. 2️⃣ Approbation Groupe Utilisée quand une équipe doit valider. Exemple : Équipe sécurité informatique Modes possibles : Un seul membre valide Tous les membres doiven...

  User Criteria vs Manager vs Group (What’s the Difference?) Approvals are the backbone of service delivery in ServiceNow. Whether it’s: Access request Laptop provisioning Budget approval HR request Understanding how approvals work is essential for proper implementation. But many developers get confused between: User-based approvals Manager approvals Group approvals User Criteria Let’s break it down clearly. How Approvals Work in ServiceNow 4 When a request is submitted: REQ → RITM → Approval → Task Creation Approval must complete before tasks proceed (if configured). 1️⃣ Manager Approval This is the most common approval type. Used when: The requester’s manager must approve. ServiceNow automatically checks: Requested For → Manager field (on user record) Example Employee requests software Manager must approve before provisioning Key Point If user has no manager defined → approval fails. 2️⃣ Group Approval 4 Used when approval must come from a team. Example: IT Security Team approva...

  Quand utiliser lequel (et éviter les problèmes de performance) Beaucoup de débutants ServiceNow se demandent : Dois-je utiliser un Client Script ou une UI Policy ? Les deux peuvent : rendre un champ obligatoire afficher / masquer un champ rendre un champ en lecture seule contrôler le comportement d’un formulaire Mais choisir le mauvais outil peut ralentir les formulaires et compliquer la maintenance. Différence principale UI Policy → Comportement basé sur la configuration (sans code) Client Script → Logique basée sur du script (JavaScript) Que fait une UI Policy ? 4 La UI Policy est utilisée pour des conditions simples. Exemple : Si Catégorie = Matériel → afficher le champ Numéro de série. Aucun code nécessaire. Avantages Plus rapide Plus propre Facile à maintenir Accessible aux administrateurs Que fait un Client Script ? 4 Le Client Script est utilisé lorsque la logique est plus complexe. Exemples : Valider un format (ID employé) Calculer automatiquement une valeur Contrôler la ...

  When to Use Each (and Avoid Performance Problems) Many ServiceNow beginners ask: Should I use Client Script or UI Policy? Both can: make fields mandatory hide/show fields set read-only control form behavior But choosing the wrong one creates performance issues and difficult maintenance. The Main Difference UI Policy → Configuration based behavior (no coding) Client Script → Logic based behavior (requires scripting) What UI Policy Does 4 UI Policy is used when behavior depends on simple conditions. Example: If Category = Hardware → show Serial Number field No scripting required. Advantages Faster Cleaner Easy to maintain Non-developers can manage What Client Script Does 4 Client Script is used when logic is complex. Example: Validate employee ID format Check value dynamically Calculate field value Requires JavaScript. Types of Client Scripts onLoad onChange onSubmit onCellEdit Used for dynamic validation and processing. Practical Comparison Requirement Use UI Policy Use Client Scr...

Quand utiliser lequel (explication pratique) Beaucoup de débutants pensent que Record Producer et Catalog Item sont identiques. Ils apparaissent tous les deux dans le portail. Ils collectent les informations utilisateur. Ils créent un enregistrement. Mais leur objectif est totalement différent. Choisir le mauvais type rend le système difficile à maintenir. Différence principale (en une phrase) Catalog Item → Demande de service avec processus Record Producer → Création directe d’un enregistrement Fonctionnement du Catalog Item 4 Le Catalog Item suit le cycle ITSM : REQ → RITM → Tâches → Approbations → Livraison Il représente : « L’utilisateur demande un service » Exemples : Demande d’ordinateur Accès logiciel Onboarding employé Il implique une automatisation métier. Fonctionnement du Record Producer 4 Le Record Producer crée directement un enregistrement. Portail → Script → Enregistrement Il représente : « L’utilisateur signale un problème » Exemples : Créer un incident Signaler un pr...

 When to Use What (Practical Explanation) Many beginners assume Record Producer and Catalog Item are the same. Both appear in the Service Portal. Both accept user input. Both create records. But they serve completely different purposes. Choosing the wrong one leads to poor design and complex maintenance later. The Core Difference (In One Line) Catalog Item → Creates a service request process Record Producer → Creates a record directly in a table How Catalog Item Works 4 Catalog item follows ITSM lifecycle: REQ → RITM → Tasks → Approvals → Fulfillment It represents: “User is requesting a service” Examples: Laptop request Software access Employee onboarding This involves workflow automation. How Record Producer Works 4 Record Producer directly inserts a record into a table. No request structure. Portal Form → Script → Record Created Examples: Create Incident Report Issue HR complaint form It represents: “User is reporting something” Key Differences Table Feature Catalog Item Record P...