Введение

По мере развития эксплуатации и сопровождения ServiceNow способ создания Database View часто становится зависимым от конкретного человека, потому что опирается на базовые знания RDB. Даже при попытке использовать данные через GUI возникают практические проблемы: при больших объёмах упираются в лимиты экспорта, набор выбранных колонок меняется в зависимости от состояния list view, а вложения разбросаны по отдельным записям и их дорого собирать. Чтобы закрыть эти проблемы, я разработал утилиту PowerShell с GUI, поддерживающую экспорт сырых данных и определение Database View.

В статье системно разобраны предпосылки, политика реализации, дизайн и операционный эффект на основе публичной реализации в репозитории.

  • Название инструмента: PS1 SNOW Utilities
  • Репозиторий: https://github.com/arimagml-collab/PS1SOWUtilities
  • Реализация: PowerShell 5.1 + WinForms (локальный запуск в Windows)
  • Источники: README, основной скрипт и проектная заметка (docs/)

Предпосылка 1: экспорт возможен, но операционно тяжёл

Стандартный UI ServiceNow позволяет экспортировать данные. В реальной эксплуатации накапливаются следующие сложности:

  1. Командам нужен одинаковый состав колонок каждый раз, но изменения list view влияют на результат.
  2. Если нужен фиксированный экспорт со всеми колонками и internal names, резко растут затраты на документацию и передачу знаний.
  3. На больших наборах данных сам GUI-экспорт становится тяжёлым, а повторные запуски сложнее контролировать.

В итоге команда сопровождения тратит время на объяснение «как выгрузить данные», а не «как использовать данные». Поэтому я сменил подход и подготовил схему, где подразделения сами запускают стандартизированный экспорт через API.


Предпосылка 2: создание Database View вскрывает пробелы в знании RDB

Database View полезен, но порог входа высок для неинженеров и пользователей с ограниченным опытом RDB.

  • sys_db_view и sys_db_view_table обрабатываются в разных контекстах, что требует множества переходов между экранами.
  • Трудно проверить internal names колонок в одном месте.
  • В средах без прав admin иногда приходится искать internal names в других местах и переносить вручную.
  • Ручное написание WHERE/JOIN увеличивает риск опечаток и ошибок ссылок.

Поэтому я пришёл к выводу, что нужен GUI-подход, позволяющий собирать определения, одновременно видя кандидатов.


Что было сделано: PS1 SNOW Utilities

PS1 SNOW Utilities — это инструмент PowerShell, который объединяет частые операционные задачи ServiceNow в одном GUI. Основная структура вкладок:

1. Вкладка Export

  • Выбор целевой таблицы (или ручной ввод)
  • Настройка фильтра (все записи / период sys_updated_on)
  • Выбор формата вывода (CSV / JSON / Excel)
  • Разделение CSV-экспорта при больших объёмах
  • Выбор папки вывода и просмотр логов выполнения

Операционная цель — стандартизировать процедуры извлечения и снизить различия между операторами.

2. Вкладка Database View Editor

  • Ввод internal name и label представления
  • Задание base table и префикса
  • Добавление JOIN (левая/правая колонка, variable prefix, опция LEFT JOIN)
  • Обновление кандидатов колонок и выбор отображаемых полей
  • Создание view и вывод ссылки на результат

Сборка определения при просмотре кандидатов снижает нагрузку от ручного ввода WHERE/JOIN и постоянных переходов по экранам ServiceNow.

3. Вкладка Attachment Harvester

  • Пакетный сбор связанных вложений по периоду обновления
  • Избежание конфликтов имён файлов за счёт sequence numbers
  • Фиксация процесса извлечения в логах

Это помогает выполнять сбор вложений для аудита и расследований по воспроизводимой процедуре.

4. Вкладка Truncate

  • Полное удаление таблицы для задач разработки
  • Ввод кода подтверждения, отображение данных цели, настройки повторных попыток

Операция опасная, поэтому для production не рекомендуется. Предназначена для тестов перезагрузки данных в верификационных средах.

5. Вкладка Settings

  • Имя instance
  • Способ аутентификации (user ID + password / API key)
  • Настройка языка (Japanese/English)
  • Настройка темы (Dark / Light)
  • Настройка подключения custom domain (instanceDomain)

Ввод сохраняется в settings.json, чувствительные значения шифруются через Windows DPAPI (CurrentUser).

Ключевые проектные решения

В реализации я приоритезировал дизайн, уменьшающий нагрузку сопровождения в эксплуатации.

  1. Централизация сетевой обработки в общих функциях
    Основа — Invoke-SnowRequest, который оборачивает GET/POST/PATCH/DELETE/получение вложений, чтобы аутентификация, обработка исключений и логирование не расползались по коду.

  2. Разделение сборки UI и управления отображением
    Элементы UI создаются через Build-*, а переключение отображения выполняется через Apply-*Language и Set-Theme.

  3. Стабилизация сохранения настроек
    Через Load-Settings / Save-Settings и Request-SaveSettings удалось уменьшить и пропуски сохранения, и избыточные записи.

  4. Многослойные подтверждения для опасных операций
    В Truncate добавлены коды подтверждения и отображение цели для снижения риска ошибочного запуска.

  5. Реализация с упором на трассируемость логов
    Через вкладку Logs и ConvertTo-LogCompactJson можно ретроспективно отслеживать результаты выполнения.


Практические trade-offs реализации

В корпоративной среде часто сложно распространять инсталляторы или внедрять резидентные приложения. Поэтому я выбрал модель поставки PowerShell-скрипта, который можно запускать даже как plain text.

Этот trade-off снизил барьеры внедрения и сократил время до первого применения на месте.


Эффекты после внедрения

После внедрения подтвердились четыре ключевых эффекта:

  1. Процедуры экспорта стали фиксированными на экране, снизилась нагрузка на объяснение каждого запроса на выгрузку.
  2. Сократился ручной ввод WHERE при создании Database View в UI ServiceNow.
  3. Пакетный сбор вложений по периодным условиям сократил время повторяющихся расследований.
  4. Сохранённые настройки уменьшили повторный ввод имени instance и учётных данных.

Эффект не «яркий», но практическая ценность в стабильном сокращении времени повторяемых операций очевидна.


Ограничения и оговорки

  • Список таблиц зависит от sys_db_object; в зависимости от ACL получение может не сработать (ручной ввод — обходной путь).
  • В некоторых средах есть ограничения на автосохранение WHERE/JOIN, поэтому часть шагов приходится завершать вручную в ServiceNow.
  • Инструмент независим от ServiceNow, Inc. и не имеет её endorsement, warranty или support.

Заключение

PS1 SNOW Utilities был создан для снижения практических узких мест в экспорте данных и определении Database View.

Лично я знал, что PowerShell позволяет собирать GUI, но не думал, что сам доведу это до полноценного инструмента. С поддержкой generative AI удалось реализовать утилиту почти в no-code стиле, через точные инструкции. Этот опыт ещё раз показал скорость эволюции AI. Одновременно, на мой взгляд, классические low-code/no-code платформы входят в фазу, где им придётся заново формулировать своё преимущество под давлением commoditization.