Assets Cloud: ищем зависимости через входящие и исходящие ссылки AQL

Задача и границы применимости

Перед изменением общего приложения нужно получить список действующих сервисов, которые непосредственно на него ссылаются. В Assets это можно проверить запросом AQL, но сначала следует договориться о направлении связи. Если сервис хранит ссылку на приложение, для сервиса она исходящая, а для приложения — входящая. Перестановка функции в запросе меняет смысл поиска, даже когда названия объектов выглядят одинаково знакомыми.

Ниже приведён учебный пилот для Assets Cloud с собственными типами объектов. Он не настраивает операционные Services в Jira Service Management, не меняет заявки и не запускает автоматизацию. Cloud обновляется непрерывно и не имеет единой установленной версии, которую нужно указать для этого примера. В Data Center тоже есть AQL и ссылки, однако навигацию, права и ограничения нужно сверять со справкой вашей версии, а не переносить облачные шаги целиком.

Предпосылки и контроль доступа

Убедитесь, что Assets уже доступен на вашем сайте и создание нескольких учебных объектов укладывается в согласованные ограничения использования. Наличие функции и включённый объём проверяются по действующему плану организации. Для упражнения не нужно включать платные возможности, увеличивать лимит или подключать внешние приложения. При отсутствии доступа остановитесь на проектировании модели.

Подготовьте отдельную учебную схему Pilot Dependencies без рабочих и персональных данных. Для создания типов и атрибутов нужен подходящий административный доступ, например Object Schema Manager; для повседневного поиска используйте отдельную запись с правом просмотра. В Assets права задаются на уровне схемы и типов объектов. Не расширяйте роль пользователя до администратора только потому, что поисковая выборка оказалась пустой.

Перед началом сохраните имена объектов, значения атрибутов, назначения ролей и тексты используемых фильтров. Если учебная схема уже существует, проверьте, кто её использует, и не перезаписывайте чужие примеры. В журнале достаточно нейтральных ключей объектов и согласованного плана изменения; учётные данные туда не включаются.

Создайте одну явно направленную связь

В Assets откройте Schemas и выбранную учебную схему. Создайте типы Pilot Service и Pilot Application. В обоих оставьте атрибут имени Name, в Pilot Service добавьте текстовый атрибут State со значениями active или retired по договорённости пилота. Не заменяйте этим полем общий корпоративный жизненный цикл: здесь это простой учебный признак для проверки фильтра.

В Attributes типа Pilot Service добавьте Applications: тип Object, Type value — Pilot Application, Additional Value — согласованный тип связи, например существующий Dependency. Это ссылка на объект, а не текст с названием приложения. В нашем примере у сервиса будет не более одного значения Applications; дополнительные ссылки и цепочки пока не нужны.

Если интерфейс показывает отдельно Display name и Name, сверьте системное Name перед копированием запросов: AQL использует именно его. Далее предполагаются точные имена схемы, типов и атрибутов из этого материала. При других именах замените их во всех запросах. Не создавайте второй атрибут только ради совпадения с примером.

Pilot Service.Applications  ->  Pilot Application

Для Pilot Service: исходящая ссылка на приложение.
Для Pilot Application: входящая ссылка от сервиса.

Подготовьте данные с положительными и отрицательными примерами

Сначала создайте приложения Shared API и Other API. Затем вручную создайте четыре сервиса по схеме ниже. У Payroll и Archive ссылка ведёт на Shared API, у Portal — на Other API, у Empty атрибут Applications оставьте пустым. Значения State вводите без случайных пробелов. Открывайте выбранный объект ссылки и сверяйте его ключ: одинаковый текст в имени ещё не гарантирует, что выбрана нужная запись.

Таблица описывает ожидаемые учебные данные, а не результаты проверки реального экземпляра Assets. На этом этапе не подключайте импорт или синхронизацию: иначе они могут перезаписать ручное исправление и затруднить понимание результата. Все четыре сервиса нужны, чтобы отличить корректную выборку от запроса, случайно возвращающего всё подряд.

Тип Pilot Application: Shared API; Other API

Тип Pilot Service | State   | Applications
Payroll           | active  | Shared API
Portal            | active  | Other API
Archive           | retired | Shared API
Empty             | active  | пусто

Найдите действующие сервисы с исходящей ссылкой

Выберите тип Pilot Service, откройте вкладку Objects, затем Filter → Advanced AQL. Вставьте приведённый запрос и нажмите Update filter. Поиск в этом интерфейсе дополнительно ограничен выбранным типом, поэтому не оставляйте открытым Pilot Application. Сначала убедитесь, что простой запрос по схеме и типу показывает все четыре учебных сервиса, затем добавляйте условия.

Для подготовленной модели ожидается только Payroll. Portal должен исключаться из-за другого приложения, Archive — из-за State, Empty — из-за отсутствующей ссылки. Сравните ключи результатов с подготовленным списком. Если хотя бы один отрицательный пример попал в выборку, не используйте фильтр в отчёте или автоматизации до выяснения причины.

objectSchema = "Pilot Dependencies"
AND objectType = "Pilot Service"
AND "State" = "active"
AND object HAVING outboundReferences(
  objectType = "Pilot Application" AND Name = "Shared API"
)

Проверьте то же ребро с обратной стороны

Теперь переключите выбранный тип на Pilot Application и выполните второй запрос. Для той же модели ожидается Shared API: на него ссылается действующий Payroll. Здесь возвращается приложение, а не сервис, потому что изменён внешний objectType и проверяется входящая связь. Other API не должно попадать в результат.

Дополнительно замените Payroll внутри условия на несуществующее учебное имя: результат должен стать пустым. Затем верните исходный фильтр. Это проверка направления конкретной связи, а не поиск всех косвенно затронутых объектов. Цепочка из нескольких уровней требует отдельной модели и проверки; два запроса из примера описывают только непосредственные ссылки.

objectSchema = "Pilot Dependencies"
AND objectType = "Pilot Application"
AND object HAVING inboundReferences(
  objectType = "Pilot Service"
  AND "State" = "active"
  AND Name = "Payroll"
)

Разберите пустой результат и лишние зависимости

При пустом результате проверьте выбранный тип, фактические Name сущностей, наличие сохранённой ссылки и права той записи, под которой выполняется поиск. Не исправляйте запрос снятием всех ограничений сразу: убирайте по одному условию и записывайте, на каком шаге меняется результат. Для поиска конкретного известного объекта можно отдельно использовать его Key из карточки вместо предположения по имени.

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

Повторите поиск под предполагаемым читателем. Расхождение с администратором требует разбора ролей, а не немедленной выдачи широкого доступа. Даже правильный AQL показывает зарегистрированные связи: он не доказывает полноту инвентаризации, актуальность данных или фактический ущерб от отказа приложения. Решение о рабочем изменении требует подтверждения владельцев сервисов.

Откат и критерии готовности фильтра

Сами поисковые запросы не меняют объекты. Чтобы вернуть интерфейс, восстановите прежний текст фильтра и выбранный тип. Если в ходе проверки исправлялись State или Applications, откройте нужный объект, восстановите исходные значения по журналу и сохраните их. Повторите оба направления поиска и убедитесь, что результат соответствует восстановленной модели.

Не удаляйте рабочие объекты, типы и атрибуты как универсальный способ отката. Новую учебную схему оставьте отдельно до согласования её дальнейшей судьбы, а временные назначения доступа верните к исходным значениям. Для передачи фильтра сохраните назначение, направление связи, имена сущностей, ожидаемые ключи и отрицательные примеры. Отдельно укажите, что рабочие автоматизации на основании этой выборки ещё не запускались.

Материал подготовлен по официальной документации; запросы не выполнялись в реальном Assets Cloud. Приёмка в вашей среде завершена только после проверки положительного результата, всех исключений и доступа обычного читателя. Такой ограниченный пилот позволяет проверить понимание модели до включения фильтра в обработку изменений или инцидентов.