Сервисы

Перенос конфигурации 🔗

Сервис предназначен для выгрузки всей или части конфигурации с одного сервера До́кви и ее загрузки на другой.

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

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

При загрузке все существующие типы документов и журналы заменяются теми, что присутствуют в загружаемой конфигурации. Значения полей (включая настроечные) документов и сами документы сохраняются. В отличие от остальных, в типе документа НАСТРОЙКА сохраняются все имеющиеся настроечные поля, т. е. вы можете добавлять свои поля и обновлять конфигурацию без риска их утери. Список сохраняемых полей можно расширить, добавив в него любые поля любого типа документа при помощи настройки SavedFieldUIDsOnImportConf.

Планировщик задач 🔗

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

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

Для добавления существующей задачи необходимо нажать на строку с ней в таблице запланированных задач, а для создания новой — нажать на кнопку «Новая задача».

В окне задачи необходимо определить:

  • Время запуска. Задача может запускаться ежеминутно, ежечасно в заданную минуту, ежедневно в определенные час и минуту, еженедельно в заданный день недели (с понедельника по воскресенье) и определенные час и минуту, ежемесячно в заданные число, час и минуту и ежегодно в заданные месяц, день месяца, час и минуту. Время запуска может быть только одного. Для добавления еще одного времени запуска необходимо продублировать задачу.
  • Действие задачи. Доступны следующие действия:
    • Создание. Это действие позволяет создать документ заданного типа. Необходимо выбрать этот тип и настроечное поле с автором создаваемого документа. Если в поле будет несколько сотрудников, будет создано несколько документов, равное количеству авторов. Если в поле будет подразделение, будет создано по одному документу для каждого сотрудника в выбранном подразделении (а также во всех дочерних).
    • Запись. Действие предназначено для записи определенного значения в заданное настроечное поле.
    • Перемещение. Действие позволяет переместить один или несколько документов, идентификаторы которых находятся в заданном поле.
    • Выполнение. Действие позволяет выбрать документы заданного типа (все или по заданным условиям) или загрузить документы из заданного настроечного поля, и запустить во всех этих документах контекст перехода выбранной точки маршрута. Причем, документы не перемещаются на эту точку, оставаясь на тех точках, на которых они находились до выполнения этой операции (если только на выполняемой точке не будет запущено перемещение на другую точку, тогда документы переместятся).
    • Резервное копирование. Действие формирует zip-файл с дампом базы данных, и / или файлового хранилища (каталоги storage/files, storage/fpreviews, storage/doclogs; для уменьшения размера архива можно ввести год, чтобы файлы, добавленные в хранилище Doc-v до этого года (включительно), не включались в резервную копию, не забыв при этом создать резервную копию более старых файлов и сохранить ее в надежном месте), и / или архивной базы данных. Резервные копии сохраняются по умолчанию в каталог storage/backup (путь можно переопределить при помощи ключа Backup). Сервис для работы использует утилиту mysqldump, которая должна быть доступна До́кви (при возникновении ошибок в лог-файле info.log будут появляться соответствующие записи; в случае необходимости добавьте в системную переменную path операционной системы или в ключ MySQLPath полный пусть к mysqldump).
      При необходимости восстановление базы данных можно осуществить через команду mysql (.exe), а каталоги с файлами распаковать и скопировать в директорию storage.
    • Оптимизация данных. Действие выполняет оптимизацию базы данных, проверяет конфигурацию, очищает данные и осуществляет прочие проверки. Рекомендуется запускать задачу ежедневно в часы наименьшей нагрузки, т. к. оптимизация может способствовать повышению быстродействия системы и уменьшению объема используемого дискового пространства, но ее выполнение может занять продолжительное время. Задача также выполняет очистку версий типов документов. По умолчанию, версии старше 180 дней автоматически удаляются. Количество дней можно изменить при помощи ключа General / VersionTTL в doc-v.conf.
    • Автообновление. Действие обращается к серверу обновления До́кви(необходимо сетевой доступ к update.doc-v.com:443) для проверки наличия для проверки наличия (и установки) более поздней версии системы в сравнении с установленной (обновляется только система, конфигурация не обновляется). Действие имеет следующие настройки:
      • Политика обновления: функциональная или консервативная. Если выбрать функциональную политику обновления, то будут устанавливаться самые последние (нестабильные) версии со всеми существующими новыми функциями, но с большей вероятностью наличия ошибок. Консервативная политика обновления может не включать все функции, но и количество ошибок в ней может быть меньше. Стабильные версии отличаются от нестабильных нумерацией — у стабильных вторая цифра в номере четная. Например, 4.0.1 — стабильная, а 4.1.1 — нестабильная.
      • При наличии новой версии: уведомлять администраторов или автоматически устанавливать обновление и перезагружать сервер.
      • Обновление конфигурации. Если выбрать в предыдущем параметре автоматическую установку становится доступен переключатель для обновления конфигурации. Обновление конфигурации выполняется всякий раз при запуске задачи при отсутствии обновлений системы (если есть обновление системы, для обновления конфигурации задачу необходимо запустить повторно). Используйте этот переключатель с осторожностью, т. к. обновление конфигурации может привести к утере ваших изменений конфигурации.
    • Перезагрузка. Задача выполняет перезапуск системы.
    • Удаление пользовательских сессий. После запуска задачи все пользователи должны будут заново пройти процедуру аутентификации.

Active Directory 🔗

Для аутентификации пользователей в системе через Active Directory необходимо, чтобы каждый пользователь из активного каталога имел учетную запись в До́кви с именем, совпадающим с UPN каталога. И, разумеется, эта учетная запись должна иметь соответствующую связь с документов «Структуры», который, в свою очередь, должен быть связан с «Сотрудником» и «Должностью». Все эти документы можно создавать вручную или доверить эти операции описываемому сервису, который автоматически, на основе данных из Active Directory, создает перечисленные документы и актуализирует их в будущем при изменении данных в каталоге. На саму аутентификацию в До́кви через Active Directory сервис никак не влияет.

После создания или изменения любого документа «Структуры», «Сотрудника», «Должности» или «Учетной записи» в измененном документе принудительно запускается контекст проверки.

Настройка сервиса выполняется после того, как будет включена аутентификация через Active Directory. Сервис имеет следующие настройки:

  • Состояние. Включен или отключен сервис.
  • Контроллер домена. Доменное имя или IP-адрес сервера с ролью контроллера домена Active Directory. По умолчанию, используется порт 389. Название домена сервис получит из настроек аутентификации.
  • Имя пользователя. UPN пользователя, входящего в группу Managed Service Account.
  • Пароль пользователя, входящего в группу Managed Service Account.
  • Должность. В схеме каталога Active Directory нет поля для ввода должности. Здесь можно ввести название атрибута, который будет использован для получения должности из Active Directory. Например, если вы вводите должности в поле описание пользователя, введите в этот параметр description.
  • Исключаемые OU. Перечисленные в этом параметре через запятую организационные единицы (OU) не будут загружаться из Active Directory. Настройка применима только к OU верхнего уровня и распространяется на все дочерние единицы.
  • Период синхронизации. Запуск следующей синхронизации будет осуществляться через указанное в этом параметре количество секунд. Минимальное значение: 30. Измененное значение вступит в силу после запуска запланированной по прежнему значению операции синхронизации.
  • Автор. Выберите сотрудника, который будет являться автором всех создаваемых документов в системе при загрузке новых данных из Active Directory.
  • Выполнение точки маршрута документа «Структура» / «Сотрудник» / «Должность». Можно выбрать точку маршрута документа соответствующего типа, которая будет выполнена, после того, как документ будет изменен данным сервисом.
  • Время последнего изменения. Время последней синхронизации с Active Directory, при которой в систему были загружены новые (измененные) данные, в формате ГГГГММДДЧЧММСС по UTC. При необходимости в повторной синхронизации можно изменить это время; если такой необходимости нет, время изменять не следует.

REST API 🔗

Данный сервис позволяет публиковать REST API сервисы, к которым можно обращаться извне по адресу http(s)://доменное-имя/api/название-сервиса. Каждый вызов такого API создает документ заданного типа, в котором можно определить любую логику, доступную в системе.
ВНИМАНИЕ! Мы не рекомендуем использовать REST API сервисы без настроенного протокола HTTPS на сервере!

Каждый сервис имеет следующие настройки:

  • Название сервиса. Это название используется только в списке сервисов для удобства администратора.
  • URL-адрес сервера. Если ввести, например, test, то внешние системы должны будут обращаться к сервису по адресу http(s)://ваше-доменное-имя/api/test.
  • HTTP-метод сервиса: GET, POST, PUT, PATCH или DELETE. Комбинация адреса сервиса и HTTP-метода должна быть уникальной. Если, к примеру, вы проектируете сервис получения количества входящих документов по заданному контрагенту, используйте метод GET. При выборе метода POST можно определить формат данных: сообщение в виде JSON или данные от HTML-формы (используйте multipart/form-data, если форма передает файлы).
  • Документ обработки запроса. Когда поступит запрос извне, сервис создаст документ заданного типа. Поскольку в До́кви каждый документ должен иметь автора, необходимо выбрать настроечного поле, которое будет содержать документ «Структуры» сотрудника, который будет автором созданного документа. По завершении обработки документа запроса и загрузки ответа (если он будет настроен) сервис может удалить документ обработки, чтобы не нагружать базу данных.
  • Параметры запроса. Возвращаясь к примеру получения количества входящих, заметим, что для его работу необходимо знать контрагента, по которому нужно вернуть количество документов. Поскольку мы выбрали метод GET, для обращения к нашему сервису спроектируем следующий запрос:
    http(s)://ваше-доменное-имя/api/test?name=Контрагент, где name — это параметр, который необходимо добавить в данной таблице, указав название name, сделав его обязательным (если вызывающая сторона не передаст этот параметр, она получит ошибку, и документ не будет создан), и выбрав поле документа обработки запроса, в которое будет записано значение параметра name, то есть нужный контрагент.
  • Форма. Этот блок становится доступным для метода POST с данными от HTML-формы и определяет параметры (элементы) формы и их соответствие полям создаваемого сервисом документа (в эти поля будут записаны значения элементов формы)
  • Сообщение. Этот параметр доступен для методов POST(для данных в формате JSON), PUT, PATCH и позволяет передать сервису тело сообщения в формате JSON. Этот JSON будет записан в выбранное поле для дальнейшей обработки в созданном документе. JSON может быть массивом — в этом случае для каждого элемента массива будет создан отдельный документ обработки запроса. Если обработку на параллельную, каждый документ будет работать в отдельном потоке, что позволит повысить скорость обработки запроса в случаях, когда для каждого документа будет много вычислений.
  • Аутентификация. Чтобы ограничить доступ к сервису, можно включить аутентификацию. Для этого необходимо выбрать параметр запроса (см. настройку «Параметры запроса» выше), который будет содержать авторизационный ключ. Поиск ключа будет осуществляться во всех документах выбранного типа документа в указанном поле. Если ни в одном из документов полученный из параметра ключ не будет найден, запрос будет отклонен.
    Например, мы можем предоставить наш гипотетический сервис с количеством документов по контрагентам разным отделам нашей организации. Чтобы можно было определить чей запрос получен, можно создать дополнительный тип документа, например, «Ключи для сервиса» из двух полей: «Ключ» и «Отдел». Добавив параметр key (и получив полный адрес сервиса: (s)://ваше-доменное-имя/api/test?name=Контрагент&key=xxx) и включив аутентификацию по типу документа «Ключи для сервиса» и полю «Ключ», мы получим сервис, к которому можно обратиться только при наличии ключа (а в документе обработки запроса, используя действия маршрута, можно будет получить отдел по ключу, например, при помощи действия «Выборка»).
  • Ответ. Сервис может вернуть ответ, загрузив его из выбранного поля документа обработки. В нашем примере, документ обработки должен будет записать в этом поле количество документов контрагента (или соответствующий JSON). При параллельной обработке документов запроса (см. настройку «Сообщение» выше) будет сформирован JSON-массив, состоящий из всех значений выбранного поля всех документов запроса.
  • Доступ. Можно ограничить доступ к сервису только для клиентов заданных IP-адресов. Можно ввести один или несколько IP, разделив их запятой, при необходимости можно использовать маски подсети CIDR (например, 192.168.0.1/24 - все IP-адреса, начинающиеся с 192.168.0). Если оставить параметр пустым, доступ к сервису будет предоставлен всем.

Приведенный ниже пример демонстрирует передачу произвольной строки и файла из действия «HTTP-запрос» в сервис «REST API»:

1. Создайте документ для выполнения запроса к сервису. 2. Создайте тип документов, которые будут создаваться сервисом REST API: 3. Настройте сервис REST API:

IMAP-клиент 🔗

Этот сервис позволяет загружать письма из заданных почтовых ящиков по протоколу IMAP и на их основе создавать документы определенного типа с записью в их поля данных из писем.

Для добавления почтового ящика необходимо указать следующие настройки:

  • Название. Используется только для отображения в списке проверяемых почтовых ящиков. Название можно передавать в документ, создаваемые в До́кви на поступившее письмо.
  • Адрес сервера (:порт). Например, imap.gmail.com:993
  • Имя пользователя.
  • Пароль пользователя. При использовании общедоступных почтовых сервисов обратите внимание, что вам, как правило, потребуются пароли приложений. Вот ссылки на некоторые инструкции: Google, Yandex, Mail.ru.
  • Документ, который будет создан на каждое письмо, поступившее в указанный почтовый ящик:
  • Тип документа.
  • Автор из поля. Если поле с автором будет содержать несколько сотрудников, для каждого автора будет создан отдельный документ.
  • Название сервиса. Это название сервиса, который настраивается. Название может быть полезным, если возникнет потребность определения из какого ящика поступило сообщение. Здесь и далее необходимо выбрать поле, в которое будет записано соответствующее значение (при его наличии).
  • Почтовый адрес отправителя.
  • Имя отправителя - 'это имя'<mail@gmail.com> .
  • Тема письма.
  • Дата письма.
  • Содержимое письма.
  • Почтовые вложения — доступны только поля типа «Файл».
  • Временные параметры включают: задержку между операциями проверки почтовых сообщений в ящике (в минутах) и время, начиная с которого будет выполняться поиск необработанных сообщений

Сканер файловой системы 🔗

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

Можно сканировать разные директории, создавая для каждой собственный сканер.

Для добавления нового сканера необходимо указать следующие настройки:

  • Сканируемая директория. Сканируемая директория. Необходимо ввести название относительно корневой директории (ключ FSScanRootDir секции [File] конфигурационного файла doc-v.conf), которая по умолчанию установлена в каталог_системы/storage/fsscan/
  • Документ, который будет создаваться при появлении в сканируемой директории каталога или файла.
    • Тип документа.
    • Автор из поля. Документ заданного ранее типа будет создан от имени первого сотрудника, находящегося в данном настроечном поле.
    • Поле для типа объекта. Если сканируемой директории появится новый каталог, то в данное поле создаваемого документа будет записан символ d, а если появится файл, то - символ f.
    • Поле для файлов. В это поле создаваемого документа будет загружен новый файл в сканируемой директории.
    • Поле для полного пути к объекту — полный путь к каталогу / файлу.
    • Поле для документа родительского каталога. Если новый каталог / файл создан во вложенном каталоге, и для этого вложенного каталога существует созданный ранее сканером документ, ссылка на этот документ записывается в данное поле. Например, если в сканируемой директории появится каталога А1, внутри которого будет каталога А2, внутри которого будут два файла Ф1 и Ф2, сервис создаст 4 документа: для каталога А1, каталога А2 со ссылкой на документ А1 и два документа для файлов со ссылкой на документ А2.

Сканер выполняет проверку корневой директории раз в секунду. При количестве вложенных каталогов и файлов в сканируемой директории более 100, время опроса увеличивается и может достигать одной проверки в 10 секунд.