পরিচিতি

ServiceNow অপারেশন ও রক্ষণাবেক্ষণ চলতে থাকলে Database View তৈরির পদ্ধতি ব্যক্তি-নির্ভর হয়ে যায়, কারণ এতে RDB-এর মৌলিক জ্ঞান লাগে। GUI দিয়ে ডেটা ব্যবহার করতে গেলেও বাস্তবে সীমাবদ্ধতা দেখা দেয়: ডেটা বড় হলে এক্সপোর্ট সীমা ছাপিয়ে যায়, লিস্ট ভিউ অনুযায়ী নির্বাচিত কলাম বদলে যায়, আর অ্যাটাচমেন্ট রেকর্ডে ছড়িয়ে থাকায় সংগ্রহ ব্যয়বহুল হয়। এই সমস্যার জন্য আমি GUI-সহ PowerShell utility তৈরি করেছি, যা raw data export এবং Database View definition-কে সহায়তা করে।

এই লেখায় পাবলিক রিপোজিটরির বাস্তবায়নকে ভিত্তি করে ব্যাকগ্রাউন্ড, বাস্তবায়ন নীতি, ডিজাইন, এবং অপারেশনাল প্রভাব সাজানো হয়েছে।

  • টুলের নাম: PS1 SNOW Utilities
  • রিপোজিটরি: https://github.com/arimagml-collab/PS1SOWUtilities
  • বাস্তবায়ন: PowerShell 5.1 + WinForms (Windows-এ লোকাল এক্সিকিউশন)
  • রেফারেন্স: README, মূল স্ক্রিপ্ট, ডিজাইন মেমো (docs/)

ব্যাকগ্রাউন্ড 1: এক্সপোর্ট সম্ভব, কিন্তু অপারেশন ভারী

ServiceNow-এর স্ট্যান্ডার্ড UI দিয়ে ডেটা এক্সপোর্ট করা যায়। তবে বাস্তব অপারেশনে নিচের সমস্যা বারবার দেখা দেয়:

  1. টিম একই কলাম লেআউট চাইলে লিস্ট ভিউ পরিবর্তনের কারণে আউটপুট বদলে যায়।
  2. সব কলাম ও internal name সহ স্থির এক্সপোর্ট দরকার হলে ডকুমেন্টেশন/হ্যান্ডওভার খরচ বাড়ে।
  3. বড় ডেটাসেটে GUI এক্সপোর্টই ভারী হয়ে যায়, রিরান ব্যবস্থাপনাও কঠিন হয়।

ফল হিসেবে মেইনটেন্যান্স টিমের সময় “ডেটা কীভাবে বের করব” ব্যাখ্যায় যায়, “ডেটা কীভাবে ব্যবহার করব”-এ নয়। তাই API-ভিত্তিক self-service standard export কাঠামোতে গিয়েছি।

ব্যাকগ্রাউন্ড 2: Database View তৈরি RDB জ্ঞানের ঘাটতি প্রকাশ করে

Database View কার্যকর, কিন্তু non-engineer বা সীমিত RDB অভিজ্ঞতার ব্যবহারকারীর জন্য বাধা বেশি।

  • sys_db_view এবং sys_db_view_table আলাদা কনটেক্সটে থাকায় স্ক্রিন বদল বেশি লাগে।
  • internal column name এক জায়গায় রিভিউ করা কঠিন।
  • admin অধিকার না থাকলে অন্য জায়গা থেকে internal name দেখে হাতে আনতে হয়।
  • হাতে WHERE/JOIN লিখলে typo বা reference ভুল বাড়ে।

তাই সিদ্ধান্ত ছিল candidate দেখতে দেখতে GUI-তে definition গঠন করা যায় এমন সহায়তা দরকার।

আমি কী তৈরি করেছি: PS1 SNOW Utilities

PS1 SNOW Utilities হলো একটি PowerShell টুল যা ServiceNow-এর ঘনঘন অপারেশনাল কাজ এক GUI-তে একত্র করে। প্রধান tab গঠন নিচের মতো।

1. Export tab

  • target table নির্বাচন (বা হাতে ইনপুট)
  • filter শর্ত সেট (সব রেকর্ড / sys_updated_on সময়সীমা)
  • output format নির্বাচন (CSV / JSON / Excel)
  • বড় রেকর্ড সংখ্যায় CSV split export
  • output folder নির্বাচন ও execution log যাচাই

লক্ষ্য হলো extraction প্রক্রিয়া standard করা এবং operator-ভেদে পার্থক্য কমানো।

2. Database View Editor tab

  • view internal name ও label ইনপুট
  • base table ও prefix সেট
  • JOIN যোগ (left/right column, variable prefix, LEFT JOIN option)
  • column candidate refresh ও display column নির্বাচন
  • view তৈরি ও result link প্রদর্শন

candidate দেখে definition গঠনের ফলে ServiceNow স্ক্রিনে বারবার যাওয়া-আসা করে WHERE/JOIN হাতে লেখার চাপ কমে।

3. Attachment Harvester tab

  • update period ধরে সম্পর্কিত attachment bulk সংগ্রহ
  • sequence number যোগ করে filename collision এড়ানো
  • retrieval process log সংরক্ষণ

এতে audit/তদন্তের attachment সংগ্রহ পুনরুত্পাদনযোগ্যভাবে চালানো যায়।

4. Truncate tab

  • development ব্যবহারের জন্য table full delete
  • confirmation code ইনপুট, target info প্রদর্শন, retry সেটিং

এটি ঝুঁকিপূর্ণ কাজ, তাই production ব্যবহারের জন্য সুপারিশ নয়; verification environment-এ data reload পরীক্ষার জন্য।

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 value Windows DPAPI (CurrentUser) দিয়ে এনক্রিপ্ট হয়ে রাখা হয়।

মূল ডিজাইন পয়েন্ট

এই বাস্তবায়নে আমি অপারেশনাল রক্ষণাবেক্ষণ খরচ কমানোকে অগ্রাধিকার দিয়েছি।

  1. শেয়ারড ফাংশনে কমিউনিকেশন প্রসেসিং কেন্দ্রীভূত
    Invoke-SnowRequest কেন্দ্র করে GET/POST/PATCH/DELETE/attachment retrieval র‌্যাপ করা হয়েছে, ফলে auth, exception handling, logging ছড়িয়ে পড়ে না।

  2. UI নির্মাণ ও display control আলাদা করা
    UI element Build-* দিয়ে তৈরি, আর display switching Apply-*Language ও Set-Theme দিয়ে নিয়ন্ত্রিত।

  3. settings persistence স্থিতিশীল করা
    Load-Settings / Save-Settings / Request-SaveSettings দিয়ে missed save ও excessive save কমানো হয়েছে।

  4. ঝুঁকিপূর্ণ অপারেশনে বহুস্তর যাচাই
    Truncate-এ confirmation code ও target display দিয়ে misoperation ঝুঁকি কমানো হয়েছে।

  5. log traceability-কে কেন্দ্র করে বাস্তবায়ন
    Logs tab ও ConvertTo-LogCompactJson দিয়ে পরবর্তী সময়ে execution ফল ট্রেস করা যায়।

বাস্তবায়নের ট্রেড-অফ

কর্পোরেট পরিবেশে installer বিতরণ বা resident app চালু করা কঠিন হতে পারে। তাই আমি plain text হিসেবেও চালানো যায় এমন PowerShell script delivery model বেছে নিয়েছি।

এই ট্রেড-অফ adoption barrier কমিয়েছে এবং initial ব্যবহার পর্যন্ত সময় ছোট করেছে।

চালুর পর প্রভাব

চালুর পর নিচের চারটি প্রভাব নিশ্চিত হয়েছে:

  1. স্ক্রিন-ভিত্তিক export পদ্ধতি স্থির হওয়ায় extraction request-প্রতি ব্যাখ্যার চাপ কমেছে।
  2. Database View তৈরিতে ServiceNow UI-তে WHERE clause হাতে লেখা কমেছে।
  3. period শর্তে bulk attachment collection সম্ভব হওয়ায় পুনরাবৃত্ত তদন্ত কাজের সময় কমেছে।
  4. saved settings ব্যবহারে instance name ও credential পুনরায় ইনপুট কমেছে।

এটি চমকপ্রদ পরিবর্তন নয়, কিন্তু অপারেশন টিমের পুনরাবৃত্ত কাজের সময় ধারাবাহিকভাবে কমানোর বাস্তব মূল্য আছে।

সীমাবদ্ধতা ও সতর্কতা

  • table list sys_db_object নির্ভর; ACL সেটিং অনুযায়ী retrieval ব্যর্থ হতে পারে (manual input workaround)।
  • কিছু পরিবেশে WHERE/JOIN definition auto-save সীমাবদ্ধ থাকায় ServiceNow-এ manual completion দরকার হতে পারে।
  • এই টুল ServiceNow, Inc. থেকে স্বাধীন; কোম্পানির endorsement, warranty, support পায় না।

উপসংহার

PS1 SNOW Utilities তৈরি করা হয়েছে ডেটা extraction ও Database View definition-এর বাস্তব bottleneck কমানোর জন্য।

ব্যক্তিগতভাবে জানতাম PowerShell দিয়ে GUI বানানো যায়, কিন্তু নিজে উদ্যোগ নিয়ে এখানে পৌঁছাব বলে ভাবিনি। generative AI-এর সহায়তায় প্রায় no-code ধাঁচে নির্দেশভিত্তিক উন্নয়নে টুলটি গড়ে তুলতে পেরেছি। এতে AI-এর দ্রুত অগ্রগতি স্পষ্ট হয়েছে। একই সঙ্গে আমার মনে হয়েছে প্রচলিত low-code/no-code টুলগুলোকেও এখন নিজেদের সুবিধা নতুন করে সংজ্ঞায়িত করতে হবে, কারণ commoditization চাপ দ্রুত বাড়ছে।