Verdi

Описание команд всех сервисов, которые входят в состав Verdi.

Список версий

v1.8

Важные изменения

• Добавлен функционал лицензирования (сервисы apigateway и oberto)
• В verdi-libs добавлен фильтр для поиска по нескольким значениям (CURS-2433)

• Исправлены разнообразные баги.

• Mon

  • Добавлен фильтр для полнотекстового поиска по ФИО пользователя (CURS-2246)
  • добавлено разлогинивание пользователя при его блокировке (CURS-149)
  • Подняты версии библиотек (CURS-2474)

• Oberto

  • Добавлены политики "по умолчанию" (CURS-111)

v1.7.1

Важные изменения

• Добавлены параметры подключения к базе данных в шаблон конфигурации и во все релевантные конфигурации сервисов (CURS-2415, SUP-118)
• Для лога реализована возможность отключения вывода в файл (CURS-2430, SUP-151)

v1.7

Важные изменения

• Verdi-libs

  • В целом по системе были подняты версии библиотек, чтобы избавиться от некоторых уязвимостей
  • В senderlib реализован ретраер при синхронном обращении напрямую к сервису (CURS-163, SUP-10)

• Mon

  • Добавлена настройка использования атрибутов пользователя из Keycloak в атрибутах пользователя сервиса Mon (CURS-2358, SUP-81)
  • Добавлена команда осуществляющая завершение сеансов пользователя (CURS-2331, SUP-135)
  • Журналируются изменения пользователя или его групп при аутентификации через Keycloak (CURS-2368, SUP-137)

v1.6.1

Важные изменения

• Verdi-libs

  • Добавлена возможность разделить учётные данные кафки для доступов producer и consumer (SUP-132, CURS-2307)

• Mon

  • Возможность завершить сеанс пользователя (SUP-135, CURS-2331)

• Oberto (и другие микросервисы)

  • Реализованы доработки позволяющие работать в системе без развернутого authzforce

v1.6

Важные изменения

• Verdi-libs

  • Изменена работа с топиками в Kafka (аутентификация) (CURS-294)
  • Сервисы теперь падают с ошибкой если на старте не смогли зарегистрироваться в консуле (CURS-303)
  • Добавлены логи в формате CEF в сервисы Cursor/Verdi (CURS-36, SUP-98)

• Erika

  • Erika теперь умеет работать с файлами, у которых расширение в верхнем регистре (CURS-301)

• Mon

  • Переработана схема авторизации пользователя через AD (CUR-2157)
  • Команда для получения групп ролей пользователей одним запросом (CURS-70, SUP-99)

• Nestor

  • Поддержка OpenSearch в Nestor (SUP-97)

• Oberto

  • Перенос функционала authzforze в сервис Oberto (CURS-2123) подзадачи (CURS-365, CURS-364, CURS-366)

• UI

  • Angular обновлен до 16 версии в Verdi в webclients, apigatewayclient, graph, ui-plugins и vespa (CUR-2083)
  • Создана библиотека "Конструктор схем" (CUR-2137)

• Исправлены множественные недочеты в Slate

• Полный список задач релиза зафиксирован в Confluence

v1.5.3

• Verdi-libs

  • StoredFile перенесен в fsClient (SUP-66)

• Erika

  • Исправлены ошибки при генерации документов с метками в таблицах (SUP-67)

• Mon

  • Содержимое jwt токена теперь генерируется корректно (SUP-100)
  • Значительное улучшение функционала связанного с логином через AD (SUP-59, CUR-2158)

• Oberto

  • XML для операции ActivateRoot теперь формируется правильно (CUR-2130)

• В нескольких сервисах выставлено дефолтное значение allowInternalCommands=true (SUP-77)

• Исправлены различные недочеты в Slate

v1.5.2

Технический хотфикс

v1.5.1

Версия от 27.06.2023. Список изменений:

• Verdi-libs

  • Исправлена работа с бакетами S3 (авторизация, алиасы)

• UI

  • Добавлена возможность конфигурации компонента cor-select (SUP-69)

v1.5

Версия от 06.06.2023. Список изменений:

• Общее

  • Исправлена и дополнена документация в различных разделах Verdi

• Verdi-libs

  • Изменена работа с бакетами S3 (авторизация) (SUP-50)

• ApiGateway

  • Настройки Akka HTTP связанные с таймаутами вынесены в переменные окружения (SUP-51)

• UI

  • Доработан компонент многострочного ввода (SUP-38)
  • Доработан компонент выпадающего списка (SUP-43)
  • Добавлена поддержка long-polling (SUP-55)

v1.4.1

Версия от 03.05.2023. Список изменений:

• Alexandrina:
  • Добавлен http-route для проверки жизни сервиса с помощью ServiceHealthApi
• Attila:
  • Добавлен http-route для проверки жизни сервиса с помощью ServiceHealthApi
• Mon:
  • Добавлен http-route для проверки жизни сервиса с помощью ServiceHealthApi
• Tech-constants:
  • Добавлен http-route для проверки жизни сервиса с помощью ServiceHealthApi

v1.4

Версия от 22.03.2023. Список изменений:

• Verdi-libs:
  • Переработан механизм создания Kafka-консьюмеров. Они принимают на вход актор для управления состоянием консьюмера. Актор отслеживает состояние консьюмера, выполняет перезапуск при ошибках
  • Добавлен ServiceHealthApi для отслеживания текущего статуса сервиса. Может интегрироваться с управляющим актором для Kafka-консьюмеров, в этом случае при падении консьюмера будет остановлен и сам сервис
  • Исправлена ошибка фильтрации открытых диапазонов
  • Добавлена библиотека validation для валидации входных данных команд и обработки ошибок в общем формате
• ApiGateway:
  • Добавлена обязательность настроек для подключения к S3-хранилищу. Теперь сервис падает, если не может подключиться, а не просто выводит ошибку в логах и 404 по url для файлов
• CommandStatus:
  • Увеличена надежность Kafka-консьюмера. Добавлено управление состоянием и перезапуски (аналогично verdi-libs)
• Erika:
  • Исправлена ошибка, из-за которой слова дробились на несколько спанов
  • Добавлена возможность использовать условную метку внутри абзаца
• Mon:
  • Добавлена команда смены пароля
  • Команды для списков пользователей теперь принимают Search
  • Добавлена поддержка kerberos-аутентификации
  • Команда верификации регистрации теперь не возвращает null
  • Исправлены ошибки в документации
• Buzzer-*:
  • Исправлена документация по buzzer-personal-page и buzzer-email
  • Команда для получения своих уведомлений в ЛК теперь принимает Search
  • Добавлена команда для получения уведомлений в ЛК для любых пользователей
  • Добавлена команда для отметки уведомлений прочитанными
  • Добавлена команда для получения списка ошибок отправки почтовых уведомлений
• Alexandrina:
  • Добавлено журналирование ошибок при вызове команд
• Attila:
  • Добавлена поддержка полей для ResourceType. Их должен публиковать сервис, отвечающий за соответствующий ResourceType. Добавлены команды для такой публикации.
• Oberto:
  • Исправлены ошибки с неотображением условий в политиках
  • Исправлены ошибки с журналированием операций обновления и удаления политик

Общие типы данных

Search

Search - универсальный тип параметров списочного запроса. Он состоит из полей

Sorting

Sorting - параметры сортировки

Paging

Paging - параметры пейджинга

Page

Страница списка элементов (часть списка с примененным пейджингом)

AuthorizationResult

Результат выполнения запроса авторизации

AttributeWithValues

Результат выполнения запроса авторизации

В качестве значения поля "cat" может быть использована любая строка (нет ограничений), но в данный момент мы используем только следующие значения:

• "urn:oasis:names:tc:xacml:3.0:attribute-category:action"
• "urn:oasis:names:tc:xacml:3.0:attribute-category:environment"
• "urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
• "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

UserId

ID пользователя. Соответствует типу UUID.

UserStatus

Список вариантов статуса пользователя в системе. Имеет тип String.

UserContext

Данные пользователя необходимые для передачи в контексте запроса каждой команды

UserContextWithJwtInvalidation

Данные пользователя необходимые для обработки запроса каждой команды

Функционал фильтров и сортировки

Для некоторых команд можно передавать параметры запроса в виде объекта Search, который содержит информацию о том как нужно отфильтровать, отсортировать запрос и как разделить его на страницы.

Фильтрация

  {
     "query": "count && (created || modified)",
     "context": {
       "count": "1_1000",
       "created": "1630326000_",
       "modified": "_1630327000"
     }
   }

Фильтрация состоит из двух полей:

• query описывает условие для фильтрации с использованием названий полей
• context описывает значение для полей, указанных в query

Query поддерживает операторы && и || + скобки.
В Context-е можно описать несколько видов проверок для полей:

1) Условие равенства переданному значению.
{ "context": { "fieldName": "какое-то значение" } }

2) Условие равенства какому-то одному значению из предоставленного списка.
{ "context": { "fieldName": "[первое значение, второе, другое]" } } или { "context": { "fieldName": "any[первое значение, второе, другое]" } }

3) Условие наличия всех значений из предоставленного списка в массиве всех значений objectFieldName, которые присутствуют в объектах поля arrayFieldName. Работает только для полей arrayFieldName, содержащих массив. Предоставленный в запросе список должен содержать не менее двух значений.
{ "context": { "arrayFieldName.objectFieldName": "all[первое значение, второе, другое]" } }

4) Условие соответствия паттерну
Значение поля обязательно должно начинаться со слова like.
{ "context": { "fieldName": "like какое%значен__" } }

5) Условие вхождения значения в заданный диапазон. В данный момент, поддерживаются только целые числа. Начало и конец диапазона разделяются знаком _. Оба конца диапазона опциональны и они включаются в диапазон. Если передать просто _, то результатом будет пустой диапазон, в который не входит ни один элемент и ответ тоже будет пустой.

6) Условие текствого поиска PGSQL
Значение поля обязательно должно начинаться со слова ts.
{ "context": { "fieldName": "ts (this | that) & the:*" } }

Сортировка

{
  "sorting": {
    "fieldName": "number",
    "order": "desc"
  }
}

Сортировка определяется двумя полями:

• fieldName название поля, по которому будет производиться сортировка
• order направление сортировки. Бывает двух видов: asc, desc.

Alexandrina

Сервис справочников.

Bibliotheca Alexandrina (лат.) - Александрийская библиотека. Команды могут приходить как по HTTP, так и через Kafka в топик alexandrina_commands.

В сервисе реализовано 19 команд:

1. Создать справочник
2. Изменить справочник
3. Удалить справочник
4. Список справочников
5. Получить данные справочника
6. Получить справочник по коду
7. Экспорт справочников
8. Парсинг справочников
9. Импорт справочников
10. Создать элемент справочника
11. Изменить элемент справочника
12. Архивировать элемент справочника
13. Удалить элемент справочника
14. Удалить все элементы из справочника
15. Список элементов справочника
16. Список элементов справочника по коду
17. Получить данные элемента справочника
18. Получить элемент справочника по его коду
19. Получить данные элементов справочников по списку id

Optimistic Lock

У многих команд реализован механизм оптимистичных блокировок. Для этого в данных присутствует поле version. Задача оптимистичных блокировок - предотвратить одновременное редактирование объекта из двух открытых форм. Сначала фронтэнд запрашивает данные объекта и получает в ответе версию данных - поле version. Он прикладывает эту версию в ответе. Если на бэкэнде она совпадает с исходной (не было других модификаций), тогда данные сохраняются, а версия поднимается. Иначе сохранения не происходит, данные не перетираются.

Конфигурирование Alexandrina

Требования к запуску Alexandrina

Запуск сервиса осуществляется локально через sbt, на стенде в docker на jvm.

Для корректной минимальной работы сервиса требуется обязательное подключение к PostgreSQL, Kafka, Consul. Для настройки подключения к ним нужно заполнить обязательные переменные окружения из раздела ниже.

Для нормальной работы сервису дополнительно требуется окружение Verdi: CommandStatus и ApiGateway. В этом случае нужно уделить внимание настройкам, связанным с ServiceDiscovery и CommandDiscovery.

Список переменных окружения Alexandrina

Все доступные переменные окружения для настройки сервиса модели данных.

Формат CEF для логов сервиса Alexandrina

У логов есть возможность включить формат CEF для логирования по следующему шаблону:
2022-12-14T16:56:31+0500 CEF:Version|Device Vendor|Device Product|Device Version|EventClassId|Message|Severity|src=? dst=? shost=? suid=? suser=? msg=? end=currentTimeMillis|.

Чтобы включить логирование в формате CEF, нужно задать переменную ALEXANDRINA_LOG_OUTPUT = STDOUT_CEF. Если логи пишутся в формате CEF, то необходимо задать следующие переменные, которые по умолчанию не заданы:

• ALEXANDRINA_LOGGING_SRC_IP, для параметра src в логах
• ALEXANDRINA_LOGGING_SRC_HOST, для параметра shost в логах
• ALEXANDRINA_LOGGING_DST_IP, для параметра dst в логах

В файле boot/src/main/resources/logback.xml можно поменять class path для основного класса приложения (переменная projectMainClassPath), если это необходимо.

Команды для сервиса Alexandrina

CreateCatalog (Alexandrina)

На входе данные справочника

{
  "code": "cities",
  "title": "Города",
  "metadata": {}
}

На выходе строка с id созданного справочника

"0effa436-06c2-42cc-befe-8ebec417fc5a"

Создание справочника. Отправляет событие о создании справочника.

Имя команды для вызова: createCatalog. Поддерживается асинхронный и синхронный вызов.

• На входе: CreateCatalogDTO
• На выходе: UUID string

UpdateCatalog (Alexandrina)

На входе данные справочника

{
  "id": "0effa436-06c2-42cc-befe-8ebec417fc5a",
  "code": "cities",
  "title": "Города",
  "metadata": {},
  "version": 2
}

На выходе количество обновленных записей

0

Изменение данных справочника. Использует оптимистичную блокировку. Если изменяемый справочник был изменен параллельно, тогда вернется 0, показывающий, что не произошло обновления из-за некорректной версии. Отправляет событие об обновлении справочника.

Имя команды для вызова: updateCatalog. Поддерживается асинхронный и синхронный вызов.

• На входе: UpdateCatalogDTO
• На выходе: integer - количество обновленных записей (0 - не было успешного обновления, 1 - было)

RemoveCatalog (Alexandrina)

На входе ID справочника

"0effa436-06c2-42cc-befe-8ebec417fc5a"

На выходе признак успешности

true

Удаление справочника и всех его элементов. Отправляет событие об удалении справочника и всех его элементов.

Имя команды для вызова: removeCatalog. Поддерживается асинхронный и синхронный вызов.

• На входе: UUID string
• На выходе: boolean. True - удаление успешно, false - неуспешно.

ListCatalogs (Alexandrina)

Входных данных нет

На выходе список справочников

[
  {
    "id": "0effa436-06c2-42cc-befe-8ebec417fc5a",
    "code": "cities",
    "title": "Города",
    "metadata": {},
    "modified": 1632978484446,
    "version": 1,
    "items": 4
  }
]

Получение списка всех справочников. Пока без пейджинга, сортировки, и т.п.

Имя команды для вызова: listCatalogs. Поддерживается только синхронный вызов.

• Команда не принимает параметров
• На выходе: List[Catalog]

GetCatalog (Alexandrina)

На входе ID справочника

"0effa436-06c2-42cc-befe-8ebec417fc5a"

На выходе данные справочника

{
  "id": "0effa436-06c2-42cc-befe-8ebec417fc5a",
  "code": "cities",
  "title": "Города",
  "metadata": {},
  "modified": 1632978484446,
  "version": 1,
  "items": 4
}

Получение данных справочника по ID.

Имя команды для вызова: getCatalog. Поддерживается только синхронный вызов.

• На входе: UUID string
• На выходе: Catalog

GetCatalogByCode (Alexandrina)

На входе код справочника

"cities"

На выходе данные справочника

{
  "id": "0effa436-06c2-42cc-befe-8ebec417fc5a",
  "code": "cities",
  "title": "Города",
  "metadata": {},
  "modified": 1632978484446,
  "version": 1,
  "items": 4
}

Получение данных справочника по коду.

Имя команды для вызова: getCatalogByCode. Поддерживается только синхронный вызов.

• На входе: string
• На выходе: Catalog

ExportCatalogs (Alexandrina)

На входе ID справочников и признак исключения из выгрузки (опциональный)

{
  "ids": ["ac94000f-3b61-4327-b2db-2ed0c2f01b38", "0c69afa4-2a1f-45ad-8269-a9d14d7b7a7d"],
  "exclude": false
}

На выходе URL сформированного JSON-файла

"export/71ab0531-f916-4b46-9bb5-e7684940d3df"

Выгрузка массива справочников в хранилище файлов в формате JSON. Результат команды - url этого файла, который можно передать в метод /download. Параметр exclude: false позволяет выгрузить справочники с переданными ID (по умолчанию), true - все справочники, кроме справочников с переданными ID.

Имя команды для вызова: exportCatalogs. Поддерживается только синхронный вызов.

• На входе: ExportParams
• На выходе: file URL string

ParseCatalogs (Alexandrina)

На входе ID файла

"71ab0531-f916-4b46-9bb5-e7684940d3df"

Пример JSON файла с указанным ID

{
  "version" : "1.0",
  "dataType" : "catalogs",
  "data" : [
    {
      "code": "cities",
      "title": "Города",
      "metadata": {},
      "items": [
        {
          "code": "Moscow",
          "title": "Москва",
          "archived": false,
          "metadata": {
            "status": "federal"
          }
        },
        {
          "code": "Tyumen",
          "title": "Тюмень",
          "archived": false,
          "metadata": {}
        }
      ]
    },
    {
      "code": "countries",
      "title": "Страны",
      "metadata": {},
      "items": []
    }
  ]
}

На выходе массив справочников с элементами и признаком наличия

[
  {
    "code": "cities",
    "title": "Города",
    "metadata": {},
    "items": [
      {
        "code": "Moscow",
        "title": "Москва",
        "archived": false,
        "metadata": {
          "status": "federal"
        }
      },
      {
        "code": "Tyumen",
        "title": "Тюмень",
        "archived": false,
        "metadata": {}
      }
    ],
    "present": true
  },
  {
    "code": "countries",
    "title": "Страны",
    "metadata": {},
    "items": [],
    "present": false
  }
]

Парсинг JSON-файла со справочниками.

Параметр present: true - справочник с таким кодом существует, false - отсутствует.

Имя команды для вызова: parseCatalogs. Поддерживается только синхронный вызов.

• На входе: UUID string - ID json-файла со справочниками из временного бакета temp
• Формат файла: ExchangeTemplate
• На выходе: CatalogParseDTO array

ImportCatalogs (Alexandrina)

На входе массив справочников с элементами

[
  {
    "code": "countries",
    "title": "Страны",
    "metadata": {},
    "items": [
      {
        "code": "Russia",
        "title": "Россия",
        "archived": false,
        "metadata": {}
      }
    ]
  }
]

На выходе количество обновленных/добавленных справочников

1

Импорт массива справочников и массивов их элементов. Если справочник или элемент с таким кодом существует, он будет обновлен, если нет - будет создан новый. Допускается наличие посторонних полей, при импорте они будут игнорироваться. Отправляет события о созданных/обновленных справочниках и элементах.

Имя команды для вызова: importCatalogs. Поддерживается асинхронный и синхронный вызов.

• На входе: CatalogExchangeDTO array
• На выходе: integer - количество обновленных/добавленных справочников

CreateCatalogItem (Alexandrina)

На входе данные элемента справочника

{
  "catalogId": "0effa436-06c2-42cc-befe-8ebec417fc5a",
  "code": "moscow",
  "title": "Москва",
  "metadata": {}
}

На выходе строка с ID созданного элемента справочника

"cee05b97-ca41-4355-8565-d667c6807cbd"

Создание элемента справочника. Отправляет событие о создании элемента справочника, а также событие об обновлении справочника, так как изменилось количество элементов.

Имя команды для вызова: createCatalogItem. Поддерживается асинхронный и синхронный вызов.

• На входе: CreateCatalogItemDTO
• На выходе: UUID string

UpdateCatalogItem (Alexandrina)

На входе данные элемента справочника

{
  "id": "cee05b97-ca41-4355-8565-d667c6807cbd",
  "code": "moscow",
  "title": "Москва",
  "metadata": {},
  "version": 2
}

На выходе количество измененных записей

0

Изменение элемента справочника. Использует оптимистичную блокировку. Если изменяемый элемент был изменен параллельно, тогда вернется 0, показывающий, что не произошло обновления из-за некорректной версии. Отправляет событие об обновлении элемента справочника.

Имя команды для вызова: updateCatalogItem. Поддерживается асинхронный и синхронный вызов.

• На входе: UpdateCatalogItemDTO
• На выходе: integer - количество обновленных записей (0 - не было успешного обновления, 1 - было)

ArchiveCatalogItem (Alexandrina)

На входе ID элемента справочника и признак архивности

{
  "id": "cee05b97-ca41-4355-8565-d667c6807cbd",
  "archived": true
}

На выходе признак успешности

true

Архивирование элемента справочника. Отправляет событие об обновлении элемента справочника.

Имя команды для вызова: archiveCatalogItem. Поддерживается асинхронный и синхронный вызов.

• На входе: ArchiveCatalogItemDTO
• На выходе: boolean. True - признак архивности изменен успешно, false - признак архивности не изменен.

RemoveCatalogItem (Alexandrina)

На входе ID элемента справочника

"cee05b97-ca41-4355-8565-d667c6807cbd"

На выходе признак успешности

true

Удаление элемента справочника. Отправляет событие об удалении элемента справочника, а также об обновлении справочника, так как количество элементов изменилось.

Имя команды для вызова: removeCatalogItem. Поддерживается асинхронный и синхронный вызов.

• На входе: UUID string
• На выходе: boolean. True - удаление успешно, false - неуспешно.

RemoveItemsFromCatalog (Alexandrina)

На входе ID справочника

"0effa436-06c2-42cc-befe-8ebec417fc5a"

На выходе количество удаленных элементов справочника

15

Удаление всех элементов из справочника.

Имя команды для вызова: removeItemsFromCatalog. Поддерживается асинхронный и синхронный вызов.

• На входе: UUID string
• На выходе: integer

ListItemsByCatalog (Alexandrina)

На входе параметры для поиска элементов справочника, ID которого указан

{
  "data": "0effa436-06c2-42cc-befe-8ebec417fc5a",
  "search": {
    "query": "",
    "context": {},
    "sorting": {
      "fieldName": "title",
      "order": "asc"
    },
    "paging": {
      "page": 1,
      "count": 10
    }
  }
}

На выходе список элементов справочника

{
  "items": [
    {
      "id": "cee05b97-ca41-4355-8565-d667c6807cbd",
      "catalogId": "0effa436-06c2-42cc-befe-8ebec417fc5a",
      "code": "moscow",
      "title": "Москва",
      "archived": false,
      "metadata": {},
      "created": 1632978484446,
      "modified": 1632979205601,
      "version": 2
    }
  ],
  "total": 1
}

Получение списка всех элементов указанного справочника.

Имя команды для вызова: listItemsByCatalog. Поддерживается только синхронный вызов.

• На входе: ListBy[CatalogId]
• На выходе: Page[CatalogItem]

ListItemsByCatalogCode (Alexandrina)

На входе параметры для поиска элементов справочника, код которого указан

{
  "data": "cities",
  "search": {
    "query": "",
    "context": {},
    "sorting": {
      "fieldName": "title",
      "order": "asc"
    },
    "paging": {
      "page": 1,
      "count": 10
    }
  }
}

На выходе список элементов справочника

{
  "items": [
    {
      "id": "cee05b97-ca41-4355-8565-d667c6807cbd",
      "catalogId": "0effa436-06c2-42cc-befe-8ebec417fc5a",
      "code": "moscow",
      "title": "Москва",
      "archived": false,
      "metadata": {},
      "created": 1632978484446,
      "modified": 1632979205601,
      "version": 2
    }
  ],
  "total": 1
}

Получение списка всех элементов указанного справочника по коду справочника.

Имя команды для вызова: listItemsByCatalogCode. Поддерживается только синхронный вызов.

• На входе: ListBy[CatalogCode]
• На выходе: Page[CatalogItem]

GetCatalogItem (Alexandrina)

На входе ID элемента справочника

"cee05b97-ca41-4355-8565-d667c6807cbd"

На выходе данные элемента

{
  "id": "cee05b97-ca41-4355-8565-d667c6807cbd",
  "catalogId": "0effa436-06c2-42cc-befe-8ebec417fc5a",
  "code": "moscow",
  "title": "Москва",
  "archived": false,
  "metadata": {},
  "created": 1632979205601,
  "modified": 1632979205601,
  "version": 1
}

Получение данных по элементу справочника.

Имя команды для вызова: getCatalogItem. Поддерживается только синхронный вызов.

• На входе: UUID string
• На выходе: CatalogItem

GetCatalogItemByCode (Alexandrina)

На входе код справочника и элемента

{
  "catalogCode": "cities",
  "itemCode": "moscow"
}

На выходе данные элемента

{
  "id": "cee05b97-ca41-4355-8565-d667c6807cbd",
  "catalogId": "0effa436-06c2-42cc-befe-8ebec417fc5a",
  "code": "moscow",
  "title": "Москва",
  "archived": false,
  "metadata": {},
  "created": 1632979205601,
  "modified": 1632979205601,
  "version": 1
}

Получение элемента справочника по коду.

Имя команды для вызова: getCatalogItemByCode. Поддерживается только синхронный вызов.

• На входе: GetCatalogItemDTO
• На выходе: CatalogItem

GetCatalogItemBatch (Alexandrina)

На входе список ID элементов справочников

["cee05b97-ca41-4355-8565-d667c6807cbd", "4a2424df-acf2-410f-8ed5-65b90675d5f1"]

На выходе список запрашиваемых элементов

[
  {
    "id": "cee05b97-ca41-4355-8565-d667c6807cbd",
    "catalogId": "0effa436-06c2-42cc-befe-8ebec417fc5a",
    "code": "moscow",
    "title": "Москва",
    "archived": false,
    "metadata": {},
    "created": 1632979205601,
    "modified": 1632979205601,
    "version": 1
  },
  {
    "id": "4a2424df-acf2-410f-8ed5-65b90675d5f1",
    "catalogId": "0effa436-06c2-42cc-befe-8ebec417fc5a",
    "code": "Tyumen",
    "title": "Тюмень",
    "archived": false,
    "metadata": {},
    "created": 1632979205601,
    "modified": 1632979205601,
    "version": 1
  }
]

Получение данных по элементам справочников по их id. Батчевая версия простого вызова данных одного элемента. При переданном пустом списке вернет все элементы всех справочников в базе.

Имя команды для вызова: getCatalogItemBatch. Поддерживается только синхронный вызов.

• На входе: List[UUID string]
• На выходе: List[CatalogItem]

Публикуемые события

События публикуются в ALEXANDRINA_CATALOG_EVENTS_TOPIC.

Модели сервиса Alexandrina

Типы данных, которые принимает на вход команд сервис справочников или возвращает в результате работы команды.

• CreateCatalogDTO
• UpdateCatalogDTO
• Catalog
• CreateCatalogItemDTO
• UpdateCatalogItemDTO
• CatalogItem
• GetCatalogItemDTO
• ArchiveCatalogItemDTO
• ExportParams
• CatalogItemExchangeDTO
• CatalogExchangeDTO
• CatalogParseDTO
• ExchangeTemplate
• ListBy[CatalogId]
• ListBy[CatalogCode]

CreateCatalogDTO (Alexandrina)

Создание справочника

UpdateCatalogDTO (Alexandrina)

Обновление справочника

Catalog (Alexandrina)

Справочник

CreateCatalogItemDTO (Alexandrina)

Создание элемента справочника

UpdateCatalogItemDTO (Alexandrina)

Обновление элемента справочника

CatalogItem (Alexandrina)

Элемент справочника

GetCatalogItemDTO (Alexandrina)

Получение элемента справочника по коду

ArchiveCatalogItemDTO (Alexandrina)

Данные для архивации/разархивации элемента справочника

ExportParams (Alexandrina)

Данные для экспорта справочника

CatalogItemExchangeDTO (Alexandrina)

Данные элемента справочника для обмена

CatalogExchangeDTO (Alexandrina)

Данные справочника для обмена

CatalogParseDTO (Alexandrina)

Данные парсинга справочника

ExchangeTemplate (Alexandrina)

Данные JSON-файла со справочниками

ListBy[CatalogId] (Alexandrina)

Параметры для запроса списка элементов по идентификатору каталога

ListBy[CatalogCode] (Alexandrina)

Параметры для запроса списка элементов по коду каталога

Api Gateway

Сервис является точкой входа в систему. Все общение между front-end и back-end происходит через этот сервис. Выполняет маршрутизацию команды в нужный сервис, а также обеспечивает извлечение из запроса необходимых данных, например, для авторизации.

Выполняет отправку команд в систему синхронным или асинхронным способом. Большинство команд может быть выполнено как синхронно, так и асинхронно. Для команды, выполняемой асинхронно, нужно запрашивать ее статус. Только так можно понять, закончила она свое выполнение или нет. Если команда еще не закончена, нужно попробовать запросить ее статус позднее.

Имеет следующие URL для взаимодействия с системой и командами:

• Синхронный запрос
• Асинхронный запрос
• Получение статуса
• Open API
• Загрузка файла в систему
• Скачивание файла из системы
• Метаданные файла

Конфигурирование Api Gateway

Требования к запуску Api Gateway

Запуск сервиса осуществляется локально через sbt, на стенде в docker на jvm.

Для корректной минимальной работы сервиса требуется обязательное подключение к Kafka и Consul. Для настройки подключения к ним нужно заполнить обязательные переменные окружения из раздела ниже.

Обеспечивает работу окружения Verdi. Требует еще CommandStatus для работы этого окружения.

Анонимный доступ

Отправка запросов для анонимных пользователей контролируется переменными окружения: APIGATEWAY_ANONYMOUS_ACCESS_MODE и APIGATEWAY_ANONYMOUS_ACCESS_COMMANDS.
Проверка доступа к командам осуществляется при каждой обработке запроса (sync/async отправка, проверка статуса).

Список переменных окружения Api Gateway

Формат CEF для логов сервиса Api Gateway

У логов есть возможность включить формат CEF для логирования по следующему шаблону:
2022-12-14T16:56:31+0500 CEF:Version|Device Vendor|Device Product|Device Version|EventClassId|Message|Severity|src=? dst=? shost=? suid=? suser=? msg=? end=currentTimeMillis|.

Чтобы включить логирование в формате CEF, нужно задать переменную APIGATEWAY_LOG_OUTPUT = STDOUT_CEF. Если логи пишутся в формате CEF, то необходимо задать следующие переменные, которые по умолчанию не заданы:

• APIGATEWAY_LOGGING_SRC_IP, для параметра src в логах
• APIGATEWAY_LOGGING_SRC_HOST, для параметра shost в логах
• APIGATEWAY_LOGGING_DST_IP, для параметра dst в логах

В файле src/main/resources/logback.xml можно поменять class path для основного класса приложения (переменная projectMainClassPath), если это необходимо.

Синхронный запрос

Отправляем команду на выполнение

import com.embedika.verdi.senderlib.Dispatcher
import com.embedika.verdi.models.command.CommandName
import com.embedika.verdi.models.RequestContext
import io.circe.Json

implicit val rc: RequestContext = RequestContext.builder().build()

val dispatcher: Dispatcher = VerdiFactory.dispatcher
dispatcher.sendCommandSync(CommandName("pingpong_ping_post"), Some(Json.obj("value" -> Json.fromString("ping"))))

POST /send/sync/pingpong_ping_post
{
  "value": "ping"
}

Синхронно получаем результат выполнения команды

import com.embedika.verdi.models.command.{CommandAggregatedStatus, CommandName}
import com.embedika.verdi.models.error.ErrorResponse
import com.embedika.verdi.models.RequestContext
import io.circe.Json
import scala.concurrent.Future
import io.circe.syntax._

implicit val rc: RequestContext = RequestContext.builder().build()

val commandResponse: Future[Either[ErrorResponse, CommandAggregatedStatus]] = dispatcher.sendCommandSync(CommandName("pingpong_ping_post"), Some(Json.obj("value" -> Json.fromString("ping"))))
val result = commandResponse.map { r => // Future response
  r.map { cs => // Either command status
      cs.value.as[PingResponse] // Option Json 
  }
}

{
  "bodyLength": 172,
  "value": "pong"
}

Отправляет команду на синхронное исполнение. Результат такого запроса возвращается сразу в ответе от Api Gateway. Запрос висит открытым все время обработки команды, пока не сформируется ответ. Применяется для простых команд, не требующих долгого выполнения. Например, запросы на чтение данных удобнее делать с помощью синхронных запросов.

Отправка команды

Чтобы синхронно выполнить команду необходимо знать ее название и формат данных, которые она принимает. Для этого нужно отправить POST-запрос, где в URL передать название команды в {command_name}:

POST /send/sync/{command_name}

Формат тела запроса зависит от формата данных, которые принимает команда. Подразумевается, что при вызове команды мы знаем, какой формат данных принимает команда.

Результат

Результат выполнения команды будет доступен сразу в ответе. Тип ответа - JSON или файл, зависит от типа команды. Формат JSON зависит от конкретной выполняемой команды. Подразумевается, что при вызове команды мы знаем, какой формат данных возвращает команда.

Синхронный запрос через GET

GET /get/CommandName?data=%7B%22foo%22%3A123%2C%22bar%22%3A%22parameter%22%7D

Отправка команды

Тело запроса принимается в query параметре data как закодированный в urlencode json.

Например, при таком json

{
  "foo": 123,
  "bar": "parameter"
}

Запрос будет выглядеть так

GET /get/CommandName?data=%7B%22foo%22%3A123%2C%22bar%22%3A%22parameter%22%7D

Результат

Аналогичен результату синхронного запроса

Запросом через GET удобно скачивать файл. Для этого нужно вызвать команду, возвращающую файл (см. документацию других сервисов)

Асинхронный запрос

Отправляем команду на выполнение

import com.embedika.verdi.senderlib.Dispatcher
import com.embedika.verdi.models.error.ErrorResponse
import com.embedika.verdi.models.command.{CommandAggregatedStatus, CommandId, CommandName, CommandStatus}
import com.embedika.verdi.models.RequestContext
import scala.concurrent.Future
import io.circe.Json

implicit val rc: RequestContext = RequestContext.builder().build()

val dispatcher: Dispatcher = VerdiFactory.dispatcher
val commandIdF: Future[Either[ErrorResponse, CommandId]] = dispatcher.sendCommandAsync(CommandName("pingpong_ping_kafka"), Some(Json.obj("value" -> Json.fromString("ping"))))

POST /send/async/pingpong_ping_kafka
{
  "value": "ping"
}

Получаем в ответе id созданной команды

import com.embedika.verdi.senderlib.Dispatcher
import com.embedika.verdi.models.error.ErrorResponse
import com.embedika.verdi.models.command.{CommandAggregatedStatus, CommandId, CommandName, CommandStatus}
import com.embedika.verdi.models.RequestContext
import scala.concurrent.Future
import io.circe.Json

implicit val rc: RequestContext = RequestContext.builder().build()

val dispatcher: Dispatcher = VerdiFactory.dispatcher
val commandIdF: Future[Either[ErrorResponse, CommandId]] = dispatcher.sendCommandAsync(CommandName("pingpong_ping_kafka"), Some(Json.obj("value" -> Json.fromString("ping"))))

"cd6fe966-9296-43bb-828d-7662cffb0c09"

Отправляет команду на асинхронное исполнение. Результат такого выполнения команды возвращается не сразу, а запрашивается дополнительно через некоторое время с помощью метода получения статуса. Запрос сразу возвращает id созданной команды и не висит открытым на протяжении всего выполнения команды. Применяется для сложных команд, выполнение которых может занять некоторое ощутимое время. Например, запросы на модификацию данных со сложными проверками, импорты, формирование документов, и т.п.

Отправка команды

Чтобы асинхронно выполнить команду необходимо знать ее название и формат данных, которые она принимает. Для этого нужно отправить POST-запрос, где в URL передать название команды в {command_name}:

POST /send/async/{command_name}

Формат тела запроса зависит от формата данных, которые принимает команда. Подразумевается, что при вызове команды мы знаем, какой формат данных принимает команда.

Результат

В результате асинхронного запроса будет содержаться только одна строка с id команды, которая начала выполняться. Стоит отметить, что ответ будет JSON-строкой, а значит, содержать свое значение в кавычках.

Получение статуса

Запрашиваем статус GET-запросом, указывая id в URL

import com.embedika.verdi.senderlib.Dispatcher
import com.embedika.verdi.models.error.ErrorResponse
import com.embedika.verdi.models.command.{CommandAggregatedStatus, CommandId, CommandName, CommandStatus}
import com.embedika.verdi.models.RequestContext
import scala.concurrent.Future
import io.circe.Json

implicit val rc: RequestContext = RequestContext.builder().build()

val commandId: CommandId = ???
val dispatcher: Dispatcher = VerdiFactory.dispatcher

dispatcher.status(commandId)
}

GET /status/eee8f8d3-6e28-462a-be42-7e3d13b3bec3

Получаем описание текущего состояния команды

import com.embedika.verdi.senderlib.Dispatcher
import com.embedika.verdi.models.error.ErrorResponse
import com.embedika.verdi.models.command.{CommandAggregatedStatus, CommandId, CommandName, CommandStatus}
import com.embedika.verdi.models.RequestContext
import scala.concurrent.Future
import io.circe.Json

implicit val rc: RequestContext = RequestContext.builder().build()

val commandId: CommandId = ???
val dispatcher: Dispatcher = VerdiFactory.dispatcher

val status: Future[Either[ErrorResponse, Option[CommandAggregatedStatus]]] = dispatcher.status(commandId)

status.flatMap {
  case Right(Some(CommandAggregatedStatus(CommandStatus.Completed, _, jsonValue, _))) =>
    // команда выполнилась
    doSomeUsefulAction()
  case Right(Some(CommandAggregatedStatus(CommandStatus.InProcess, _, jsonValue, _))) =>
    // команда еще выполнеяется
    Future.successful(true)
  case _ =>
    Future.successful(false)
}

// команда еще выполняется
{
  "status": "InProcess",
  "timestamp": "2021-03-23T09:00:15.674384Z"
}
// команда выполнилась
{
  "status": "Completed",
  "timestamp": "2021-03-23T09:01:20.190815Z",
  "value": {
    "value": "pong"
  }
}

Для запущенной команды получает ее текущий статус выполнения. Применяется для асинхронных запросов. Клиент, вызвавший команду асинхронно, должен на своей стороне организовать пуллинг состояний с помощью этого вызова. Пуллинг должен продолжаться до тех пор, пока не вернется состояние команды Completed. В этом случае в поле value будут данные с ответом по команде.

Также нужно иметь в виду, что если вызвать status сразу же после ответа async-запроса, то status может вернуть ошибку 404. Это вызвано тем, что статус команды не успевает дойти до сервиса CommandStatus через kafka. Механизм пуллинга должен это учитывать.

Получение статуса с задержкой

GET /pollStatus/eee8f8d3-6e28-462a-be42-7e3d13b3bec3

Работа с данной командой аналогична работе с командой status

Для запущенной команды получает ее текущий статус выполнения. Если результат выполнения еще не доступен, то команда ждет некоторое время (это время можно настроить с помощью переменной окружения). Если по прошествию этого времени результат все еще не доступен, то вместо него возвращается последний статус команды. Если нет никакого статуса (например, указан несуществующий ID команды), то команда точно так же ждет некоторое время, а потом выдает либо появившийся статус, либо ошибку 404. Таким образом, эта команда может быть использована как альтернатива "пуллингу" для быстрых команд.

Формат запроса

Для получения статуса запущенной команды нужно вызвать GET-запрос, в котором в URL передать id запущенной команды в {command_id}:

GET /status/{command_id}

Формат ответа

В ответе будет JSON с состоянием команды, временем последнего изменения этого состояния и значение, которое вернула команда. Это значение будет отсутствовать, если состояние команды отлично от Created.

Поля в JSON ответа:

Статусы команды

OpenAPI

{
  "openapi":"3.0.3",
  "info":{
    "title":"API Gateway",
    "version":"0.4"
  },
  "paths":{
    "/sync/UpdateObjectByCode/accessMatrixRoleRBAM/{entityId}":{
      "post":{
        "description":"Обновляет объект по его Code",
        "operationId":"postSyncUpdateobjectbycodeAccessmatrixrolerbamEntityid",
        "parameters":[
          {
            "name":"entityId",
            "in":"path",
            "required":true,
            "schema":{"type":"string"}
          }
        ],
        "requestBody":{
          "description":"Command arguments as JSON object",
          "content":{
            "text/plain":{"schema":{"type":"string"}}
          },
          "required":true},
        "responses":{
          "200":{
            "description":"Command execution result as JSON object",
            "content":{
              "text/plain":{"schema":{"type":"string"}}
            }
          }
        }
      }
    }
  }
}

// не применимо

По url /openapi.json доступна спецификация OpenAPI описывающая все доступные команды в виде разных URL. Применяется для интеграции Api Gateway с различными системами. Кроме того, полезно при разработке фронта.

Upload

Загрузка файла

POST /upload

// не применимо

Результат вызова

{
  "fileId": "1c689788-9617-4c93-bcee-6eae8909a0ba",
  "url": "temp/1c689788-9617-4c93-bcee-6eae8909a0ba"
}

// не применимо

Загрузить файл в систему. Загруженный файл помещается во временный бакет APIGATEWAY_TEMP_BUCKET. Файл передается в multipart-formdata в поле file. Принимается запрос POST на url /upload. На выходе возвращается объект, содержащий id загруженного файла и относительный URL, по которому доступен этот файл. Далее можно использовать этот id для передачи в сервисы.

При каждой загрузке, файл "привязывается" к текущему пользователю (ожидается, что в заголовках запроса будет Cookie с JWT), чтобы пользователи имели доступ только к "привязанным" файлам.
Анонимные пользователи воспринимаются как один и тот же пользователь, т.е. любой анонимный пользователь имеет доступ ко всем файлам, что были загружены другими анонимными пользователями.
В текущей реализации, анонимный пользователь отличается от "залогиненого", т.е. "залогиненый" пользователь не имеет доступа к файлам от "анонимов". Чтобы получить такой доступ, нужно выйти из системы и обратиться к файлу в качестве "анонима".

Download

При скачивании через этот метод не происходит проверки прав. Поэтому лучше использовать команду getFile синхронно.

Скачивание файла

GET /download/temp/1c689788-9617-4c93-bcee-6eae8909a0ba

// не применимо

Скачивание файла из системы. Для скачивания передается GET-запрос. В url после /download/ передать url файла. В этот url входит бакет, путь внутри бакета и id файла. HTTP-ответ формируется как файл.

При попытке обращения к файлу, происходит проверка наличия "связи" между пользователем и файлом (ожидается, что в заголовках запроса будет Cookie с JWT). Если такой связи нет - возвращается статус 404 Not Found, т.к. для данного пользователя файла не существует.
Создание "связи" описано в Загрузке файла в систему.

Metadata

Получение метаданных файла

GET /metadata/temp/1c689788-9617-4c93-bcee-6eae8909a0ba

// не применимо

Результат с метаданными

{
  "fileId": "1c689788-9617-4c93-bcee-6eae8909a0ba",
  "name": "Текстовый документ.pdf",
  "size": 301,
  "url": "temp/1c689788-9617-4c93-bcee-6eae8909a0ba",
  "md5": "953c3ff8a7afa87d759fb606eabc8438",
  "contentType": "application/pdf"
}

// не применимо

Получение метаданных файла в системе. Передается GET-запрос. В url после /metadata/ передать url файла. В этот url входит бакет, путь внутри бакета и id файла. Возвращается json с метаданными файла.

При попытке обращения к метаданным файла, происходит проверка наличия "связи" между пользователем и файлом (ожидается, что в заголовках запроса будет Cookie с JWT). Если такой связи нет - возвращается статус 404 Not Found, т.к. для данного пользователя файла не существует.
Создание "связи" описано в Загрузке файла в систему.

Attila-client: клиент для сервиса Attila

Предоставляемые методы: - TBD

Ключевые сущности: - TBD

Attila: сервис для работы с композитными правилами ограничения доступа

Данные сервиса хранятся в PostgreSQL. Команды могут приходить как по HTTP, так и по Kafka.

Сервис разбит на несколько модулей, в виде sbt проектов:

• domain, в котором содержатся все доменные модели и их различные представления.
• infrastructure, в котором содержатся базовые компоненты для взаимодействия с инфраструктурой.
• store, содержит сервисы для сохранения и чтения их разных хранилищ доменных моделей.
• service, содержит сервисы бизнес логии, которые определяют правила взаимодействия компонентов между собой.
• route, содержит HTTP роуты.
• boot, содержит зависимости и описание для сборки и запуска сервиса.

В сервисе реализованны следующие команды:

• Получение списка команд
• Получение списка ресурсов
• Получение списка полей для ресурсов
• Добавление полей для ресурса
• Удаление полей из ресурса
• Получение списка действий для "низкоуровневых" правил
• Получение списка UI действий для "высокоуровневых" правил
• Добавление данных для авторизации команды
• Удаление данных для авторизации команды
• Обновление правило с новой версией
• Удаление версии правила по ID
• Получение версии правила по ID
• Получение списка правил с указанием добавленных версий

Локальный запуск сервиса Attila

При запуске сервиса ожидается, что уже развернута необходимая инфраструктура:

• PostgreSQL база по адресу localhost:5432/attila_db
• Kafka по адресу localhost:9092
• Consul по адресу localhost:8500
• AuthZforce server по адресу http://localhost:8080/authzforce-ce
• В Consul будет добавлены следующие ключи или они указаны в application.conf:
  • адрес Kafka по ключу kafka_bootstrap_server
  • адрес AuthZforce по ключу authzforce_server_address
    • В рантайме, исходя из наличия адреса AuthZforce, будет попытка получить доступный DomainID для AuthZforce ( также его можно указать в application.conf)
• Добавлены необходимые переменные окружения:
  • ATTILA_DB_HOST
  • ATTILA_DB_PORT
  • ATTILA_DB_NAME
  • ATTILA_DB_USER
  • ATTILA_DB_PASSWORD

Запуск Attila из консоли с помощью SBT

ATTILA_DB_HOST=localhost ATTILA_DB_PORT=5432 ATTILA_DB_NAME=attila_db ATTILA_DB_USER=postgres ATTILA_DB_PASSWORD=12345 sbt boot/run

Список всех переменных окружения для сервиса Attila

Формат CEF для логов сервиса Attila

У логов есть возможность включить формат CEF для логирования по следующему шаблону:
2022-12-14T16:56:31+0500 CEF:Version|Device Vendor|Device Product|Device Version|EventClassId|Message|Severity|src=? dst=? shost=? suid=? suser=? msg=? end=currentTimeMillis|.

Чтобы включить логирование в формате CEF, нужно задать переменную ATTILA_LOG_OUTPUT = STDOUT_CEF. Если логи пишутся в формате CEF, то необходимо задать следующие переменные, которые по умолчанию не заданы:

• ATTILA_LOGGING_SRC_IP, для параметра src в логах
• ATTILA_LOGGING_SRC_HOST, для параметра shost в логах
• ATTILA_LOGGING_DST_IP, для параметра dst в логах

В файле boot/src/main/resources/logback.xml можно поменять class path для основного класса приложения (переменная projectMainClassPath), если это необходимо.

Список команд сервиса Attila

В описании команд используется путь/route для отправки команды в сам сервис, а не в ApiGateway. В качестве Input-а для команд, сервис всегда ожидает CommandRequest (как и любой другой сервис, принимающий команды), так что в описании команды указано лишь описание поля payload для CommandRequest.

Информация по добавлению команд можно прочитать в описании шаблона

Список реализованных в сервисе команд, моделей EntityType и действий Actions, которые можно использовать при настройке авторизации.

ListCommands (attila)

Payload для команды

{
  "query": "resource",
  "context": {
    "resource": "like %A"
  },
  "sorting": {
    "fieldName": "ruleAction",
    "order": "desc"
  },
  "paging": {
    "page": 1,
    "count": 3
  }
}

Результат выполнения команды

{
  "items": [
    "commandName_EoverA",
    "commandName_DoverA",
    "commandName_CoverA"
  ],
  "total": 5
}

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

• Payload: Search
• Result: Page[CommandName]

ListResources (attila)

Payload для команды

{
  "query": "resource",
  "context": {
    "resource": "like %A"
  },
  "sorting": {
    "fieldName": "ruleAction",
    "order": "desc"
  },
  "paging": {
    "page": 1,
    "count": 3
  }
}

Результат выполнения команды

{
  "items": [
    "resource_BA",
    "resource_A"
  ],
  "total": 2
}

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

• Payload: Search
• Result: Page[ResourceType]

ListRuleActions (attila)

Payload для команды

{
  "query": "resource",
  "context": {
    "resource": "like %A"
  },
  "sorting": {
    "fieldName": "ruleAction",
    "order": "desc"
  },
  "paging": {
    "page": 1,
    "count": 3
  }
}

Результат выполнения команды

{
  "items": [
    "ruleAction_EoverA",
    "ruleAction_DoverA",
    "ruleAction_CoverA"
  ],
  "total": 5
}

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

• Payload: Search
• Result: Page[RuleAction]

ListUIActions (attila)

Payload для команды

{
  "query": "resource",
  "context": {
    "resource": "like %A"
  },
  "sorting": {
    "fieldName": "ruleAction",
    "order": "desc"
  },
  "paging": {
    "page": 1,
    "count": 3
  }
}

Результат выполнения команды

{
  "items": [
    "uiAction_A"
  ],
  "total": 1
}

Возвращает список UI действий, которые удовлетворяют заданным фильтрам. Поддерживается только синхронный вызов.

• Payload: Search
• Result: Page[UIAction]

AddAuthorizationInfo (attila)

Payload для команды

[
  {
    "commandName": "Command_Executed_When_Viewing_Register",
    "dependencies": [
      ["resource_A", "view_register_of_a", ["SectionForA_View_Register"]],
      ["resource_A", "other_action_on_a", []]
    ]
  },
  {
    "commandName": "Other_Command",
    "dependencies": [
      ["AttractiveResourceName", "Some_Action_On_AttractiveResource", []]
    ]
  },
  {
    "commandName": "Command_With_Resource_A",
    "dependencies": [
      ["resource_A", "ruleAction_BoverA", ["uiAction_A"]]
    ]
  }
]

Результат выполнения команды

{
  "Other_Command": true,
  "Command_Executed_When_Viewing_Register": true,
  "Command_With_Resource_A": true
}

Возвращает список команд с результатом добавления соответствующей информации для авторизации. Поддерживается асинхронный и синхронный вызов.

Команда только внутренняя (нельзя вызвать через Api Gateway), не требует аутентификации.

• Payload: [List[CommandAuthorizationInfo]
• Result: Map[CommandName, Boolean]

DeleteAuthorizationInfo (attila)

Payload для команды

[
  "Other_Command"
]

Результат выполнения команды

1

Возвращает количество удаленных записей с информацией для авторизации. Одна запись это картеж из (CommandName, ResourceName, RuleAction, UiAction), т.е. количество записей не всегда равно количеству добавленных команд. Поддерживается асинхронный и синхронный вызов.

Команда только внутренняя (нельзя вызвать через Api Gateway), не требует аутентификации.

• Payload: List[CommandName]
• Result: Int

GetHighLevelRule (attila)

Payload для команды

"Rule_AccessTo_ResourceA"

Результат выполнения команды

{
  "id": "Rule_AccessTo_ResourceA",
  "name": "Rule_AccessTo_ResourceA",
  "description": "Some very high rule",
  "action": "SectionForA_View_Register",
  "condition": "User.groupId == 'users' && A.authorId == User.id",
  "priority": 100,
  "effect": true
}

Возвращает по указаному идентификатору высокоуровневое правило, если оно существует. Иначе возвращает статус 404 Not Found. Поддерживается только синхронный вызов.

• Payload: HighLevelRuleId
• Result: HighLevelRule

ListHighLevelRules (attila)

Payload для команды

{
  "query": "resource",
  "context": {
    "resource": "like %A"
  },
  "sorting": {
    "fieldName": "priority",
    "order": "asc"
  },
  "paging": {
    "page": 12,
    "count": 1
  }
}

Результат выполнения команды

[
  {
    "id": "Rule_AccessTo_ResourceA",
    "name": "Rule_AccessTo_ResourceA",
    "description": "Some very high rule",
    "action": "SectionForA_View_Register",
    "condition": "User.groupId == 'users' && A.authorId == User.id",
    "priority": 100,
    "effect": true
  },
  {
    "id": "Rule_View_List_Of_Data",
    "name": "Rule_View_List_Of_Data",
    "description": "Another rule",
    "action": "A_ViewList",
    "condition": "User.groupId == 'users'",
    "priority": 20,
    "effect": true
  },
  {
    "id": "Rule_Action_Over_A",
    "name": "Rule_Action_Over_A",
    "description": "Just a high rule",
    "action": "VerySmartAction",
    "condition": "User.groupId == 'users' && A.authorId == User.id",
    "priority": 30,
    "effect": true
  }
]

Возвращает список высокоуровневых правил с набором версий, версии которых удовлетворяют заданным фильтрам (paging игнорируется, т.к. возвращается весь список).
Для сортировки можно использовать следующие поля: "priority" (значение по-умолчанию), "id", "name", "description", "effect", "action", "modified".
Поддерживается только синхронный вызов.

• Payload: Search
• Result: List[HighLevelRule]

UpdateHighLevelRule (attila)

Payload для команды

{
  "id": "Rule_AccessTo_ResourceA",
  "name": "Rule_AccessTo_ResourceA",
  "previousId": "Rule_AccessTo_ResourceA",
  "description": "Some very high rule",
  "action": "SectionForA_View_Register",
  "condition": "User.groupId == 'users' && A.authorId == User.id",
  "priority": 100,
  "effect": true
}

Результат выполнения команды

true

Возвращает индикатор успеха добавления новой версии правила. Поддерживается асинхронный и синхронный вызов.

• Payload: HighLevelRuleUpdateDTO
• Result: Boolean

DeleteHighLevelRule (attila)

Payload для команды

"Rule_AccessTo_ResourceA"

Результат выполнения команды

true

Возвращает индикатор успеха удаления указанной версии правила. Поддерживается асинхронный и синхронный вызов.

• Payload: HighLevelRuleId
• Result: Boolean

GetResourceTypeFields (attila)

Payload для команды

{
  "query": "resourceType",
  "context": {
    "resource": "like %A"
  },
  "sorting": {
    "fieldName": "fieldName",
    "order": "asc"
  },
  "paging": {
    "page": 1,
    "count": 3
  }
}

Результат выполнения команды

{
  "Resource_A": {
      "field_1": "title_1",
      "field_2": "title_2"
  },
  "Resource_ABA": {
    "field_1": "title_123",
    "field_2": "title_2"
  }
}

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

Для данной команды, настройки пагинации игнорируются.
При сортировке не по полю "resourceType", resourceType будут сортироваться по мере появления (т.к. на беке список плоский, без вложенностей).
Например, при сортировке по "fieldName":
ABC(f1,t1), CBA(f23,t2), ABC(f30,t12), ZS(f2,t3), CBA(f0, t43), ABC(f3,t1) =>
CBA(f0, t43), ABC(f1,t1), ZS(f2,t3), ABC(f3,t1), CBA(f23,t2), ABC(f30,t12) =>
CBA((f0, t43), (f23,t2)), ABC((f1,t1), (f3,t1), (f30,t12)), ZS(f2,t3)

• Payload: Search
• Result: Map[ResourceType, Map[FieldName, Title]]

AddResourceTypeFields (attila)

Payload для команды

"Rule_AccessTo_ResourceA"

Результат выполнения команды

true

Добавление набора полей для определенного типа ресурсов. Поддерживается асинхронный и синхронный вызов.

Команда только внутренняя (нельзя вызвать через Api Gateway), не требует аутентификации.

• Payload: Map[ResourceType, Map[FieldName, Title]]
• Result: Map[ResourceType, Map[FieldName, Boolean]]

RemoveResourceTypeFields (attila)

Payload для команды

"Rule_AccessTo_ResourceA"

Результат выполнения команды

true

Удаляет указанные поля из определенного типа ресурсов. Поддерживается асинхронный и синхронный вызов.

Команда только внутренняя (нельзя вызвать через Api Gateway), не требует аутентификации.

• Payload: Map[ResourceType, List[FieldName]]
• Result: Map[ResourceType, Map[FieldName, Boolean]]

Модели сервиса Attila

CommandName

Наименование команды. Имеет тип String.

ResourceType

Наименование типа ресурса. Имеет тип String.

RuleAction

Наименование действия, которое используется в низкоуровневых правилах. Имеет тип String.

UIAction

Наименование UI действия, которое используется в высокоуровневых правилах. Имеет тип String.

FieldName

Наименование поля. Имеет тип String.

Title

Наименование чего-либо для отображения в интерфейсе. Имеет тип String.

CommandAuthorizationInfo

Информация для авторизации определенной команде.

HighLevelRuleId

Идентификатор высокоуровневого правила. Имеет тип String.

HighLevelRule

Описание версии высокоуровневого правила

HighLevelRuleUpdateDTO

Описание версии высокоуровневого правила

Attribute provider

Является расширением для Authzforce server (Community edition). В терминах XACML является PIP. Репозиторий Authzforce server: https://github.com/authzforce/server Wiki Authzforce server: https://github.com/authzforce/core/wiki/Attribute-Providers Спецификация XACML 3.0: http://docs.oasis-open.org/xacml/3.0/errata01/os/xacml-3.0-core-spec-errata01-os-complete.html