परिचय

ServiceNow के संचालन और रखरखाव के साथ‑साथ Database View बनाने का तरीका अक्सर व्यक्ति‑निर्भर हो जाता है, क्योंकि यह बुनियादी RDB ज्ञान पर टिका होता है। GUI से डेटा उपयोग करने की कोशिश में भी व्यावहारिक समस्याएँ आती हैं: बड़े डेटा पर export सीमा पार हो जाती है, list view बदलने से चुने गए column बदल जाते हैं, और attachments अलग‑अलग records में बिखरे रहते हैं। इसी कारण मैंने GUI के साथ PowerShell utility बनाई, जो raw data export और Database View definition को सपोर्ट करती है।

यह लेख सार्वजनिक repository के implementation के आधार पर पृष्ठभूमि, implementation policy, design, और operational impact को व्यवस्थित करता है।

पृष्ठभूमि 1: Export संभव है, पर संचालन भारी है

ServiceNow का standard UI डेटा export कर सकता है। लेकिन वास्तविक संचालन में ये समस्याएँ जमा होती हैं:

  1. टीमें हर बार समान column layout चाहती हैं, पर list view state आउटपुट को प्रभावित करती है।
  2. सभी columns और internal names के साथ fixed export चाहिए तो documentation और handover लागत बढ़ती है।
  3. बड़े datasets पर GUI export ही भारी हो जाता है, re-run प्रबंधन कठिन हो जाता है।

नतीजतन maintenance टीम का समय “डेटा कैसे निकाला जाए” में जाता है, “डेटा का उपयोग कैसे हो” में नहीं। इसलिए मैंने API आधारित self-service standard export संरचना अपनाई।

पृष्ठभूमि 2: Database View निर्माण RDB ज्ञान की कमी उजागर करता है

Database View उपयोगी है, लेकिन non-engineers या सीमित RDB अनुभव वाले उपयोगकर्ताओं के लिए बाधा ऊँची है।

  • sys_db_view और sys_db_view_table अलग contexts में होते हैं, जिससे कई screen transitions लगते हैं।
  • internal column names को एक जगह review करना कठिन है।
  • admin अधिकार न होने पर internal names कहीं और देखकर manual वापस लाना पड़ता है।
  • हाथ से WHERE/JOIN लिखने में typo और reference mistakes बढ़ते हैं।

इसीलिए निष्कर्ष था कि candidate देखते हुए definitions assemble करने वाला GUI support जरूरी है।

मैंने क्या बनाया: PS1 SNOW Utilities

PS1 SNOW Utilities एक PowerShell tool है जो ServiceNow के बार‑बार होने वाले operational tasks को एक GUI में समेकित करता है। मुख्य tab संरचना:

1. Export tab

  • target table चयन (या manual input)
  • filter condition सेट (all records / sys_updated_on period)
  • output format चयन (CSV / JSON / Excel)
  • बड़े record counts के लिए CSV split export
  • output folder चयन और execution logs की समीक्षा

ऑपरेशनल लक्ष्य extraction procedure को standard करना और operators के बीच भिन्नता घटाना है।

2. Database View Editor tab

  • view internal name और label इनपुट
  • base table और prefix सेट
  • JOIN जोड़ना (left/right columns, variable prefix, LEFT JOIN option)
  • column candidates refresh और display columns चयन
  • view create करके result link दिखाना

candidates देखते हुए definition बनाने से ServiceNow screens में बार‑बार आना‑जाना और manual WHERE/JOIN input का भार घटता है।

3. Attachment Harvester tab

  • update period के आधार पर related attachments bulk collect
  • sequence numbers जोड़कर filename collision से बचाव
  • retrieval process logs रिकॉर्ड

इससे audit और investigation attachment collection को reproducible procedures में चलाया जा सकता है।

4. Truncate tab

  • development उपयोग हेतु full table deletion
  • confirmation code input, target information display, retry settings

यह खतरनाक operation है, इसलिए production उपयोग अनुशंसित नहीं है; verification environments में data reload testing के लिए है।

5. Settings tab

  • instance name
  • authentication method (user ID + password / API key)
  • language setting (Japanese/English)
  • theme setting (Dark / Light)
  • custom domain connection (instanceDomain)

इनपुट settings.json में संग्रहीत होते हैं; sensitive values Windows DPAPI (CurrentUser) से encrypted रखी जाती हैं।

प्रमुख डिजाइन बिंदु

इस implementation में प्राथमिकता operational maintenance burden कम करना था।

  1. साझा functions में communication processing का केंद्रीकरण
    Invoke-SnowRequest केंद्र में रखकर GET/POST/PATCH/DELETE/attachment retrieval को wrap किया, ताकि authentication, exception handling, logging बिखरे नहीं।

  2. UI निर्माण और display control का विभाजन
    UI elements Build-* से बनते हैं, जबकि display switching Apply-*Language और Set-Theme से होती है।

  3. settings persistence को स्थिर बनाना
    Load-Settings / Save-Settings और Request-SaveSettings से missed saves और excessive saves दोनों कम किए।

  4. खतरनाक operations के लिए बहु‑स्तरीय पुष्टि
    Truncate में confirmation codes और target display से misoperation risk घटाया।

  5. log traceability केंद्रित implementation
    Logs tab और ConvertTo-LogCompactJson से execution results को बाद में trace करना संभव हुआ।

कार्यान्वयन में व्यावहारिक trade-offs

कॉर्पोरेट वातावरण में installers बाँटना या resident apps शुरू करना कठिन हो सकता है। इसलिए मैंने ऐसा PowerShell script delivery model चुना जो plain text रूप में भी चल सके।

इस trade-off ने adoption barrier कम किया और first use तक का समय घटाया।

लागू होने के बाद प्रभाव

लागू होने के बाद चार प्रमुख प्रभाव स्पष्ट हुए:

  1. export procedures स्क्रीन पर स्थिर हुए, जिससे प्रत्येक extraction request की व्याख्या लागत घटी।
  2. Database View निर्माण में ServiceNow UI पर manual WHERE clause input कम हुआ।
  3. period conditions के साथ bulk attachment collection संभव हुई, जिससे दोहराए जाने वाले investigation कार्य का समय घटा।
  4. saved settings ने instance names और credentials की पुनः प्रविष्टि कम की।

यह चमकदार परिवर्तन नहीं है, पर operations staff के repetitive work time को लगातार घटाने में व्यावहारिक मूल्य देता है।

सीमाएँ और सावधानियाँ

  • table lists sys_db_object पर निर्भर हैं; ACL settings के आधार पर retrieval विफल हो सकता है (manual input workaround है)।
  • कुछ environments में WHERE/JOIN definitions के auto-save पर constraints हैं, इसलिए ServiceNow में manual completion चाहिए हो सकता है।
  • यह tool ServiceNow, Inc. से स्वतंत्र है और कंपनी का endorsement, warranty, support प्राप्त नहीं करता।

निष्कर्ष

PS1 SNOW Utilities को data extraction और Database View definition की व्यावहारिक bottlenecks घटाने के लिए बनाया गया।

व्यक्तिगत रूप से मुझे पता था कि PowerShell से GUI बन सकता है, लेकिन मैं खुद इसे आगे बढ़ाऊँगा, यह नहीं सोचा था। generative AI के सहारे लगभग no-code शैली में निर्देश-आधारित विकास करके यह utility आकार ले सकी। इस अनुभव ने AI की तेज प्रगति को बहुत स्पष्ट किया। साथ ही मुझे लगता है कि पारंपरिक low-code/no-code tools अब ऐसे चरण में हैं जहाँ उन्हें commoditization दबाव के बीच अपनी बढ़त फिर से परिभाषित करनी होगी।