Дата актуализации: 08.10.2025.
Причина актуализации: Добавление примечания в конце статьи.
Сервис печатных форм (СПФ) – это компонент Витрины данных, предназначенный для формирования электронных документов в форматах XML и PDF на основе предварительно подготовленных шаблонов. Сформированные документы могут быть затем подписаны квалифицированной электронной подписью. Такие документы, в соответствии с Федеральным законом от 06.04.2011 № 63-ФЗ «Об электронной подписи», признаются равнозначными документам на бумажном носителе, подписанным собственноручной подписью.
Примечание
За подписание документов отвечает Агент СМЭВ4
СПФ решает следующие задачи:
1) Формирует документ на основе поступившего в Витрину регламентированного запроса (РЗ) типа «Печатные формы».
2) Отправляет сформированный документ на подпись Агенту СМЭВ4.
3) Отправляет сформированный и подписанный документ в качестве ответа на РЗ в СМЭВ4.
Обработка запроса на предоставление документа происходит в следующем порядке:
1) Запрос поступает через Агент СМЭВ4 в Витрину данных.
2) Модуль рodd-adapter-query, входящий в состав Витрины данных, считывает запрос и передаёт его в СПФ.
3) СПФ запускает pebble-шаблон, соответствующий запрошенному типу документа, собирает данные из БД Витрины данных и формирует на основании этих данных json-файл.
4) Из содержащейся в json-файле информации формируется итоговая форма документа. Для этого используется pebble-шаблон, предназначенный для генерации документов в формате XML или PDF.
Pebble-шаблоны (.peb) в Витрине данных – это заранее подготовленные совокупности правил, по которым собираются данные из Витрины и формируется документ
Для реализации межведомственного взаимодействия с использованием СПФ Поставщику необходимо выполнить следующие действия:
1. Создать и зарегистрировать в СМЭВ4 РЗ типа «Печатные формы».
2. Установить и настроить компонент СПФ.
3. Подготовить pebble-шаблоны.
4. Произвести настройку Агента СМЭВ4 для подписания документа, сформированного при помощи СПФ.
5. Проверить работу СПФ.
Создание РЗ типа «Печатные формы»
Для создания РЗ типа «Печатные формы» выполните следующие действия:
1) Авторизуйтесь в ЕИП НСУД.
2) На левой панели выберите Модель данных > Регламентированные запросы > Запросы SQL.
3) Нажмите кнопку «Добавить запрос».
4) Из предложенного перечня выберите тип РЗ – «Печатные формы» (см. Рисунок 1).
Рисунок 1 – ЕИП НСУД. Создание РЗ типа «Печатные формы»
В результате откроется карточка создания нового регламентированного запроса типа SQL.
5) В карточке создания нового РЗ типа SQL заполните обязательные поля.
a) В блоке Общие сведения (см. Рисунок 2) введите следующие данные:
- Владелец – наименование ведомства-владельца РЗ;
- Мнемоника – техническое наименование РЗ;
- Наименование – название РЗ;
- Дата начала действия РЗ – дата начала действия РЗ (можно указать текущую);
- Описание – для чего предназначен РЗ.

Рисунок 2 – ЕИП НСУД. Карточка создания РЗ. Блок «Общие сведения»
b) В блоке Характеристики запроса (см. Рисунок 3) установите флажок Оптимизация (должен быть установлен по умолчанию):

Рисунок 3 – ЕИП НСУД. Карточка создания РЗ. Блок «Характеристики запроса»
Примечание
Оптимизация запроса позволяет преобразовать его в процессе выполнения для ускорения обработки
c) В блоке Данные запроса (см. Рисунок 4):
- Поставщики данных – укажите ведомство-Поставщика данных;
- Витрины данных – выберите Витрину данных, к которой будет выполняться РЗ;

Рисунок 4 – ЕИП НСУД. Карточка создания РЗ. Блок «Данные запроса»
- Входные параметры – добавьте необходимые входные параметры РЗ и укажите их значения (см. Рисунок 5).
Рисунок 5 – ЕИП НСУД. Карточка создания РЗ. Блок «Данные запроса». Входные параметры
Добавление входных параметров РЗ
Важно!
Параметр DocType присутствует по умолчанию. Он необходим для передачи сведений о формате, в котором будет формироваться документ (XML или PDF), его значение передается в РЗ в позиции 1
Для добавления необходимых дополнительных входных параметров, соответствующих бизнес-логике работы запроса, выполните для каждого из них последовательно следующие шаги:
I) Нажмите «Добавить», чтобы добавить один входной параметр. Откроется карточка добавления нового параметра (см. Рисунок 6).

Рисунок 6 – ЕИП НСУД. Карточка создания РЗ, блок «Данные запроса». Добавление входного параметра
II) Передвиньте переключатель Выбрать из ВД вправо. В результате в поле Атрибут витрины данных будет доступен выпадающий список атрибутов из таблицы Витрины данных.
III) Выберите наименование атрибута, соответствующее добавляемому входному параметру.
IV) Заполните обязательные поля (отмечены *) для данного параметра:
- Мнемоника параметра – мнемоника (техническое наименование) параметра (будет заполнено автоматически);
- Наименование – логическое наименование параметра (будет заполнено автоматически);
- Тип данных – тип данных параметра (будет заполнено автоматически);
- Описание параметра – описание параметра (будет заполнено автоматически);
- Позиция – порядковый номер позиции в РЗ, в которой будет передаваться данный входной параметр.
V) В поле Значение по умолчанию укажите значение, которое данный параметр будет иметь по умолчанию (при необходимости).
VI) Нажмите Сохранить. Новый входной параметр отобразится в карточке создания РЗ, в списке входных параметров в блоке Данные запроса (см. Рисунок 5).
Добавление выходных параметров РЗ
Выходные параметры – по умолчанию заданы следующие:
- DocType – формат, в котором сгенерирован документ;
- FileName – название, присвоенное сгенерированному документу;
- Content – содержимое документа.
Рисунок 7 – ЕИП НСУД. Карточка создания РЗ. Блок «Данные запроса». Выходные параметры
Выходных параметров, заданных по умолчанию, достаточно для того, чтобы отобразить ответ со сформированным документом. При необходимости можно скорректировать имеющиеся параметры или добавить дополнительные.
Подробное описание, как создать РЗ типа «Печатные формы», приведено в Инструкции по работе в ЕИП НСУД (п. 4.7.1 Создание регламентированного запроса).
Для стабильной работы СПФ в составе Витрины данных должны быть установлены два модуля:
1) printable-form-service – модуль формирования документов. Реализует следующие задачи:
- формировать документ, на основе поступившего в Витрину запроса, в формате (XML и PDF);
- отправлять сформированные документы на подпись в сервис Notarius;
- отправлять сформированные и подписанные документы в СМЭВ4 в виде ответа на пришедший запрос.
2) counter-provider – модуль генерации уникального номера. Реализует следующие функции:
- позволяет создавать уникальные порядковые номера для сквозной нумерации файлов;
- обеспечивает долговременное хранение неограниченного списка счетчиков;
- выполняет автономное изменение счетчика при параллельном использовании.
Примечание
В данной статье описаны настройки модулей:
– printable-form-service – версии 1.16.0 и выше;
– counter-provider – версии 1.16.0 и выше.
Важно!
По умолчанию для модуля printable-form-service используется порт 8080, а для модуля сounter-provider – порт 9000. Убедитесь, что эти порты не задействованы под другие приложения. В противном случае укажите нужные номера портов в конфигурационных файлах .env соответствующих приложений.
Модули, входящие в компонент СПФ, можно установить и настроить на Витрине данных без оркестратора или с оркестратором. В качестве оркестратора используется ПО Datamart Studio.
Установка и настройка СПФ на Витрине данных без оркестратора
Модуль printable-form-service
Для резвертывания модуля printable-form-service на Витрине без оркестратора выполните следующие шаги:
1. Создайте рабочий каталог printable-form-service. Для этого перейдите на сервер, где планируется развернуть модуль; под соответствующим пользователем с необходимыми правами создайте рабочий каталог и выдайте права на эту директорию пользователю $USER с помощью следующих команд:
|
sudo mkdir /opt/printable-form-service sudo chown -R $USER:$USER /opt/printable-form-service |
2. В рабочем каталоге printable-form-service создайте каталог templates для размещения pebble-шаблонов:
|
sudo mkdir /opt/printable-form-service/templates sudo chown -R $USER:$USER /opt/printable-form-service/templates |
3. Скопируйте в рабочий каталог файл printable-form-service-1.16.0.jar (входит в комплект поставки ПО «Витрина данных»), необходимый для установки модуля, шаблон конфигурационного файла printable-form-service (application.yml) и файл логирования logback.xml.
Если в поставке ПО «Витрина данных» отсутствуют файлы application.yml и logback.xml, создайте их самостоятельно, как описано в соответствующих разделах ниже, и задайте в них необходимые настройки.
Для удобства копирования можно воспользоваться программным продуктом WinSCP.
4. Разместите pebble-шаблоны в каталоге templates (примеры pebble-шаблонов представлены ниже).
Рабочий каталог printable-form-service будет иметь следующую структуру:
/opt/printable-form-service/…
…/templates/
└── extract.peb
└── generate_pdf.peb
└── generate_xml.peb
… printable-form-service-1.16.0.jar
… logback.xml
… application.yml
- templates – каталог для хранения pebble-шаблонов:
> generate_xml.peb – pebble-шаблон, предназначенный для преобразования полученных данных в XML-документ.
- printable-form-service-1.16.0.jar – jar-файл модуля printable-form-service для развертывания его на сервере (входит в комплект поставки ПО «Витрина данных»);
- logback.xml – файл логирования модуля printable-form-service;
- application.yml – конфигурационный файл модуля printable-form-service.
5. В системном каталоге /etc/systemd/system/ создайте файл printable-form.service для запуска сервиса. Для этого:
1) Выполните следующую команду:
|
sudo nano /etc/systemd/system/printable-form.service |
Создаваемый файл будет открыт в редакторе.
2) Скопируйте содержимое из примера ниже:
|
[Unit] Description=Service Printable Form [Service] WorkingDirectory=/opt/printable-form-service User=$USER Group=$USER ExecStart=/usr/bin/java -jar printable-form-service-1.16.0.jar -migrate application.yml #java --add-exports=java.base/sun.security.util=ALL-UNNAMED --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALUNNAMED --add-exports=java.base/sun.security.provider=ALL-UNNAMED --add-exports=java.base/sun.security.tools.keytool=ALL-UNNAMED -jar printable-form-service-1.16.0.jar
Environment="JDK_JAVA_OPTIONS=--add-exports=java.base/sun.security.util=ALL-UNNAMED --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALL-UNNAMED --add-exports=java.base/sun.security.provider=ALL-UNNAMED --add-exports=java.base/sun.security.tools.keytool=ALL-UNNAMED"
[Install] WantedBy=multi-user.target |
3) Вставьте скопированное содержимое в создаваемый файл, внесите правки в соответствии с данными пользователя, запускающего сервис, и сохраните файл сервиса.
Команды для управления сервисом printable-form.service:
– Перезапустить службу:
|
sudo systemctl daemon-reload |
– Включить сервис printable-form.service в автозагрузку:
|
sudo systemctl enable printable-form.service |
– Запустить сервис:
|
systemctl start printable-form.service |
– Проверить статус:
|
systemctl status printable-form.service |
– Перезапустить сервис после внесения изменений в конфигурацию printable-form-service:
|
systemctl restart printable-form.service |
– Просмотреть лог сервиса:
|
journalctl -f -u printable-form.service |
Модуль counter-provider
Для запуска модуля counter-provider на Витрине без оркестратора выполните следующие шаги:
1. Создайте рабочий каталог сounter-provider. Для этого перейдите на сервер, где планируется развернуть модуль Витрины; под соответствующим пользователем с необходимыми правами создайте рабочий каталог и выдайте права на эту директорию пользователю $USER с помощью следующих команд:
|
sudo mkdir /opt/сounter-provider sudo chown -R $USER:$USER /opt/сounter-provider |
2. Скопируйте в рабочий каталог файл сounter-provider-1.16.0.jar (входит в комплект поставки ПО «Витрина данных»), необходимый для установки модуля, шаблон конфигурационного файла сounter-provider (application.yml) и файл логирования logback.xml.
Если в поставке ПО «Витрина данных» отсутствуют файлы application.yml и logback.xml, создайте их самостоятельно, как описано в соответствующих разделах ниже, и задайте в них необходимые настройки.
Для удобства копирования можно воспользоваться программным продуктом WinSCP.
Содержимое каталога сounter-provider будет иметь следующую структуру:/opt/сounter-provider/…
… сounter-provider-1.16.0.jar
… logback.xml
… application.yml
- сounter-provider-1.16.0.jar – jar-файл модуля counter-provider для развертывания его на сервере;
- logback.xml – файл логирования модуля counter-provider;
- application.yml – конфигурационный файл модуля counter-provider.
3. Создайте в системном каталоге /etc/systemd/system/ файл counter-provider.service для запуска сервиса. Для этого выполните следующую команду:
|
sudo nano /etc/systemd/system/counter-provider.service |
Файл будет открыт в редакторе.
В создаваемый файл скопируйте содержимое примера, приведенного ниже, внесите правки в соответствии с данными пользователя, запускающего сервис, и сохраните файл сервиса:
|
[Unit] Description=Service Counter Provider [Service] WorkingDirectory=/opt/counter-provider User=$USER Group=$USER ExecStart=/usr/bin/java -jar counter-provider-1.16.0.jar -migrate application.yml #java --add-exports=java.base/sun.security.util=ALL-UNNAMED --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALUNNAMED --add-exports=java.base/sun.security.provider=ALL-UNNAMED --add-exports=java.base/sun.security.tools.keytool=ALL-UNNAMED -jar printable-form-service-1.16.0.jar [Install] WantedBy=multi-user.target |
Команды для управления сервисом counter-provider:
– Перезапустить службу:
sudo systemctl daemon-reload |
– Включить сервис counter-provider.service в автозагрузку:
sudo systemctl enable counter-provider.service |
– Запустить сервис:
systemctl start counter-provider.service |
– Проверить статус:
systemctl status counter-provider.service |
– Перезапустить сервис после внесения изменений в конфигурацию counter-provider:
systemctl restart counter-provider.service |
– Просмотреть лог сервиса:
journalctl -f -u counter-provider.service |
Установка и настройка СПФ на Витрине данных с оркестратором
Действия по установке модулей для работы СПФ описаны в статье «Установка витрины в конфигурации стандарт. Дополнительные компоненты». Общие принципы работы в Datamart Studio (далее – Студия) описаны в документации Datamart Platform Studio.
После установки модулей, необходимых для работы СПФ, выполните последовательно их настройку. Для настройки модуля printable-form-service вам понадобится архив с предварительно созданными pebble-шаблонами. Создание pebble-шаблонов описано ниже.
Настройка инсталляции модуля printable-form-service
1. В карточке Витрины перейдите на вкладку Инсталляции (см. Рисунок 8).
Рисунок 8 – Datamart Studio. Вкладка Инсталляции
2. Найдите в списке инсталляцию printable-form-service и щелкните по её названию (см. Рисунок 9).

Рисунок 9 – Datamart Studio. Инсталляция printable-form-service
В результате откроется карточка с настройками инсталляции.
3. В карточке настроек инсталляции переведите переключатель «Показать все» вправо, чтобы включить отображение всех настроек (см. Рисунок 10).

Рисунок 10 – Datamart Studio. Настройки инсталляции printable-form-service
4. Найдите настройку COUNTER_SERVICE_PORT – номер порта для модуля сounter-provider. Задайте для нее значение 9000 (см. Рисунок 11).

Рисунок 11 – Datamart Studio. Настройка COUNTER_SERVICE_PORT
5. Найдите настройку JAVA_TOOL_OPTIONS для файла логирования logback (см. Рисунок 12).

Рисунок 12 – Datamart Studio. Настройка JAVA_TOOL_OPTIONS
Удалите предлагаемое значение и оставьте поле пустым (см. Рисунок 13).

Рисунок 13 – Datamart Studio. Настройка JAVA_TOOL_OPTIONS
6. После изменения настроек в окне с настройками нажмите на название инсталляции, в результате отобразится карточка инсталляции (см. Рисунок 14).

Рисунок 14 – Datamart Studio. Настройки инсталляции printable-form-service
7. В карточке инсталляции printable-form-service выберите раздел Файлы, в этом разделе – вкладку Загрузка файлов (см. Рисунок 15).

Рисунок 15 – Datamart Studio. Карточка инсталляции printable-form-service
Загрузите необходимые файлы:
- в Файл конфигурации – конфигурационный файл модуля printable-form-service с нужной мнемоникой РЗ и названиями pebble-шаблонов;
- в pebble-шаблоны – подготовленный архив с pebble-шаблонами.
Примечание
Если конфигурационный файл модуля printable-form-service отсутствует в поставке ПО «Витрина данных», создайте его самостоятельно, как описано ниже в соответствующем разделе. Файл логирования logback.xml модуля printable-form-service формирует Студия
8. Вернитесь на вкладку Инсталляции и примените настройки. Для этого нажмите на значок гаечного ключа напротив инсталляции printable-form-service и
в выпадающем списке выберите Действия > Применить конфигурацию (bind) (см. Рисунок 16).

Рисунок 16 – Datamart Studio. Применение настроек
Настройка инсталляции модуля сounter-provider
1. В списке инсталляций выберите инсталляцию сounter-provider и нажмите на ее название (см. Рисунок 17).

Рисунок 17 – Datamart Studio. Инсталляция сounter-provider
В результате откроется карточка с настройками инсталляции.
2. В карточке настроек инсталляции переведите переключатель «Показать все» вправо, чтобы включить отображение всех настроек.
3. Найдите настройку PERSISTENCE_MODE. Она предназначена для хранения счетчиков во внешнем модуле персистентности, в качестве которого может выступать Prostore или ZooKeeper.
Примечание
По умолчанию для настройки PERSISTENCE_MODE задано значение persistence. Если оставить его без изменений, то в логе модуля сounter-provider может отображаться следующая ошибка (см. Рисунок 18)

Рисунок 18 – Лог модуля сounter-provider
Для хранения счетчиков необходимо задать значение prostore или zookeeper, в соответствии с конфигурацией Витрины. В качестве примера указано значение zookeeper (см. Рисунок 19).

Рисунок 19 – Datamart Studio. Настройка PERSISTENCE_MODE
4. Найдите настройки PS_HOST и PS_PORT – IP-адрес и порт Prostore. Укажите хост и порт сервера, на котором развернуто приложение (инсталляция dtm_query_execution_core) (см. Рисунок 20).

Рисунок 20 – Datamart Studio. Настройки PS_HOST и PS_PORT
5. Вернитесь на вкладку Инсталляции и примените настройки. Для этого нажмите на значок гаечного ключа напротив инсталляции сounter-provider, из выпадающего списка выберите Действия > Применить конфигурацию (bind):

Рисунок 21 – Datamart Studio. Применение настроек
Примечание
Загрузка файлов конфигурации и логирования для модуля counter_provider не требуется, их формирует Студия
Конфигурационный файл модуля printable-form-service
Описание настроек конфигурационного файла модуля printable-form-service представлено в Руководстве администратора Типового ПО «Витрина данных НСУД», размещенном на портале ЕСКС в разделе "ПО для Участников СМЭВ".
Если данный файл отсутствует в комплекте поставки ПО «Витрина данных», то создайте его самостоятельно, выполнив следующие шаги:
1) Создайте в каталоге printable-form-service файл application.yml с помощью следующих команд:
|
cd /opt/printable-form-service sudo nano application.yml |
Файл будет открыт в редакторе.
2) Скопируйте содержимое из примера конфигурационного файла printable-form-service, представленного ниже:
http-server:
port: ${HTTP_PORT:8080}
executor:
reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
prostore-rest-client:
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:20}
metrics:
port: ${METRICS_PORT:9837}
vertx:
web-client:
max-pool-size: 20
counter-service:
host: ${COUNTER_SERVICE_HOST:localhost}
port: ${COUNTER_SERVICE_PORT:9000}
serviceName: ${COUNTER_SERVICE_NAME:printableform}
timeout: ${COUNTER_SERVICE_TIMEOUT:30}
sign-service:
url: ${SIGN_SERVICE_URL:http://localhost:8192}
timeout: ${SIGN_SERVICE_TIMEOUT:30}
pool-size: ${SIGN_SERVICE_POOL_SIZE:5}
notarius:
host: ${NOTARUIS_HOST:localhost}
port: ${NOTARUIS_PORT:8192}
enabled: ${NOTARIUS_ENABLED:FALSE}
props:
maxContentLength: ${NOTARUIS_MAX_CONTENT_LENGTH:104857600}
signatureURI: ${NOTARUIS_SIGNATURE_URI:urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256}
digestMethod: ${NOTARUIS_DIGEST_METHOD:http://www.w3.org/2001/04/xmldsig-more#gostr3411}
printable-forms:
reports:
# имя документа
- report: v1_<rz_mnemonic>
# настройки по извлечению данных
extract:
# путь pebble шаблона, который будет извлекать данные
template: /opt/printable-form-service/templates/extract.peb
# настройки по формированию xml документа
xml:
# путь pebble шаблона, который будет формировать xml документ
template: /opt/printable-form-service/templates/generate_xml.peb
# Id подписываемого элемента, если не указано, то подписывается весь xml
elementId: elementToSign
# имя элемента, куда добавлять ЭП, если не указано, то в корень
elementName: signature
# имя файла, если не указано, то <Id_ПФ + ".xml">
fileName: document_1.xml
# настройки по формированию xml документа с открепленной подписью
xml_detached_sig:
# имя файла, если не указано, то <Id_ПФ + ".xml">
fileName: document_1.xml
# имя файла p7s, если не указано, то <Id_ПФ + ".p7s">
fileSign: xmlSign.p7s
# настройки по формированию pdf документа
pdf:
# путь pebble шаблона, который будет формировать pdf документ
template: /opt/printable-form-service/templates/generate_pdf.peb
# имя файла, если не указано, то <Id_ПФ + ".pdf">
fileName: pdfFileName.pdf
# настройки по формированию pdf документа с открепленной подписью
pdf_sig:
# путь pebble шаблона, который будет формировать подписываемый pdf документ, задается в .pdf.template
# (для генерации "pdf без ЭП" и "pdf с ЭП" используется единый pebble-шаблон)
# имя файла, если не указано, то <Id_ПФ + ".pdf">
fileName: pdfFileName.pdf
# имя файла p7s, если не указано, то <Id_ПФ + ".p7s">
fileSign: pdfSign.p7s
- <rz_mnemonic> – мнемоника РЗ типа «Печатные формы» из ЕИП НСУД, (например, pf_gorodarf – РЗ для вывода в документ списка городов РФ);
- template: /opt/printable-form-service/templates/extract.peb,
template: /opt/printable-form-service/templates/generate_xml.peb – абсолютные пути к pebble-шаблонам.
Примечание
Если модуль printable-form-service был развернут через docker-контейнер, в том числе с помощью Datamart Studio – при установке на Витрину с оркестратором, то абсолютным путем к pebble-шаблонам является путь из запущенного docker-контейнера.
Просмотреть путь к pebble-шаблонам в таком случае можно следующим образом: войдите в запущенный контейнер printable-form-service, для чего на сервере с установленным модулем printable-form-service выполните команду:
|
docker exec -it printable-form-service sh |
Пример проверки расположения pebble-шаблонов в запущенном docker-контейнере printable-form-service приведен на Рисунке 22.

Рисунок 22 – Проверка расположения pebble-шаблонов в контейнере printable-form-service
В данном примере абсолютный путь к шаблонам выглядит следующим образом: /opt/printable-form.
Файл логирования printable-form-service
Если данный файл отсутствует в поставке ПО «Витрина данных», создайте его самостоятельно с помощью следующих команд:
|
cd /opt/printable-form-service sudo nano logback.xml |
Затем скопируйте содержимое файла логирования из примера, представленного ниже:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property name="LOG_LEVEL_PATTERN" value="${LOG_LEVEL_PATTERN:-%X{requestId} %X{subRequestId} %5p}"/>
<property name="LOG_FORMAT" value="${LOG_FORMAT:-TEXT}"/>
<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
<include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<if condition='property("LOG_FORMAT").contains("JSON")'>
<then>
<encoder class="net.logstash.logback.encoder.LogstashEncoder" />
</then>
<else>
<encoder>
<pattern>${CONSOLE_LOG_PATTERN}</pattern>
<charset>${CONSOLE_LOG_CHARSET}</charset>
</encoder>
</else>
</if>
</appender>
<root level="INFO">
<appender-ref ref="CONSOLE"/>
</root>
<logger name="ru.datamart.prostore" level="ERROR"/>
<logger name="ru.itone.dtm.printableform" level="DEBUG"/>
<logger name="ru.itone.dtm.adapter.healthcheck" level="DEBUG"/>
</configuration>
Вставьте в созданный файл скопированное содержимое, задайте в нем необходимые настройки и сохраните его.
Важно!
Обязательны для заполнения следующие блоки:
– prostore-rest-client – адрес (host) и порт сервера, где
располагается Prostore (по умолчанию используется порт 9090);
– counter-service – адрес (host) и порт сервера, где располагается
модуль counter-provider (по умолчанию используется порт 9000);
– sign-service – URL сервера, на котором
располагается Агент СМЭВ4, в случае с Витриной данных он отвечает за подписание
(по умолчанию используется порт Агента СМЭВ4: 8192)
Конфигурационный файл модуля counter-provider
Если данный файл отсутствует в комплекте поставки ПО «Витрина данных», то создайте его самостоятельно, выполнив следующие шаги:
1) Создайте в каталоге counter-provider файл application.yml с помощью следующих команд:
|
cd /opt/counter-provider sudo nano application.yml |
Файл будет открыт в редакторе.
2) Скопируйте содержимое из примера конфигурационного файла модуля генерации уникального номера application.yml, представленного ниже:
environment:
name: ${ENVIRONMENT_NAME:test}
http-server:
port: ${HTTP_PORT:9000}
counter:
start-number: ${COUNTER_START_NUMBER:1}
retry-after-failure: ${COUNTER_RETRY_AFTER_FAILURE:3}
update-timeout: ${COUNTER_UPDATE_TIMEOUT:}
reset-period: ${COUNTER_RESET_PERIOD:}
increment-gap: ${INCREMENT_GAP:1}
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000}
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore | zookeeper
prostore-rest-client:
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:5}
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
counter-prefix: ${COUNTER_PREFIX:counter_}
migration:
enabled: ${MIGRATION_ENABLE:false}
old-connection-string: ${OLD_ZOOKEEPER_DS_ADDRESS:localhost}
backup:
mode: ${BACKUP_MODE:rest} # kafka | rest
rest:
uri: ${BACKUP_URI:/backup}
zk-path: ${COUNTER_BACKUP_ZK_PATH:/${environment.name}/counter-provider/counters}
commandTopic: ${BACKUP_COMMAND_TOPIC:adapter.command}
backupTopic: ${BACKUP_TOPIC:adapter.backup}
statusTopic: ${STATUS_TOPIC:adapter.status}
kafka:
consumer:
property:
bootstrap.servers: ${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
group.id: ${COUNTER_BACKUP_GROUP_ID:counter_provider_adapter_command}
auto.offset.reset: latest
producer:
property:
bootstrap.servers: ${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
metrics:
port: ${METRICS_PORT:9837}
3) Вставьте скопированное содержимое в создаваемый файл, задайте в нем необходимые настройки и сохраните файл.
Важно!
Обязательны для заполнения следующие блоки:
– zookeeper:
connection-string – адрес (host) сервера, где располагается Zookeeper;
– persistence-mode – место для хранения
счётчиков. Модуль counter-provider хранит счетчики во внешнем модуле персистентности, в качестве которого
может выступать Prostore или ZooKeeper. В тестовых целях рекомендуется использовать значение zookeeper. Если счетчики будут храниться в Prostore, укажите значение prostore;
– prostore-rest-client – адрес
(host) и порт сервера, где располагается Prostore (по умолчанию используется
порт 9090)
Файл логирования модуля counter-provider
Если данный файл отсутствует в поставке ПО «Витрина данных», создайте его самостоятельно с помощью следующих команд:
|
cd /opt/сounter-provider sudo nano logback.xml |
Создаваемый файл будет открыт в редакторе.
Скопируйте в него содержимое файла логирования из примера, представленного ниже, и сохраните файл:
<configuration>
<property name="LOG_LEVEL_PATTERN" value="${LOG_LEVEL_PATTERN:-%X{requestId} %X{subRequestId} %5p}"/>
<property name="LOG_FORMAT" value="${LOG_FORMAT:-TEXT}"/>
<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
<include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<if condition='property("LOG_FORMAT").contains("JSON")'>
<then>
<encoder class="net.logstash.logback.encoder.LogstashEncoder" />
</then>
<else>
<encoder>
<pattern>${CONSOLE_LOG_PATTERN}</pattern>
<charset>${CONSOLE_LOG_CHARSET}</charset>
</encoder>
</else>
</if>
</appender>
<root level="INFO">
<appender-ref ref="CONSOLE"/>
</root>
<logger name="ru.itone.dtm.counter.provider" level="DEBUG"/>
<logger name="ru.itone.dtm.adapter.healthcheck" level="DEBUG"/>
</configuration>
Подготовка pebble-шаблонов
Примечание
Рекомендуется заполнять шаблон с описанием условий и параметров строго в нижнем регистре
В качестве примера приведены три pebble-шаблона: для извлечения данных из Витрины, для вывода перечня городов РФ в документ в формате XML и в формате PDF:
1. extract_1.peb – пример pebble-шаблона для извлечения данных из Витрины:
{#формируем sql запрос в переменную gorodarfquery#}
{% var gorodarfquery %}
{% if params[0] is empty %}
select * from i_u038_gorodarf.gorodarf limit 10
{% else %}
select * from i_u038_gorodarf.gorodarf limit {{ params[0] }}
{% endif %}
{% endvar %}
{# выполняем sql запрос и помещаем результат выполнения в переменную rows.searchgoroda #}
{{ sql("searchgoroda", gorodarfquery) }}
{% var json_data %}
{
"gorodarf": [
{% for p in rows.searchgoroda %}
{# формируем json динамически #}
{% if loop.first %}
{% else %}
,
{% endif %}
{
"id": "{{ p.id }}",
"city": "{{ p.city }}",
"region": "{{ p.region }}",
"code_region": "{{ p.code_region }}",
"federal_district": "{{ p.federal_district }}",
"population": "{{ p.population }}",
"date_of_foundation": "{{ p.date_of_foundation }}"
}
{% endfor %}
]
}
{% endvar %}
{#выведем полученный json в неэкранированной форме#}
{{ json_data | raw }}
2. generate_pdf_1.peb – пример pebble-шаблона, который преобразует данные, собранные с применением шаблона extract_1.peb, в PDF-документ:
<html>
<head>
<style>
table, th, td {
border: 1px solid black;
}
</style>
</head>
<body>
<h3>Certificate</h3>
<table>
<tr>
<th>Организация</th>
<th>Сертификат</th>
<th>Издатель</th>
<th>Действителен с</th>
<th>Действителен по</th>
</tr>
<tr>
<td>{{ certification_info.subjectDN.commonName }}</td>
<td>{{ certification_info.serialNumber }}</td>
<td>{{ certification_info.issuerDN.commonName }}</td>
<td>{{ certification_info.notBefore }}</td>
<td>{{ certification_info.notAfter }}</td>
</tr>
</table>
<h3>Gorodarf</h3>
<table>
<tr>
<th>№</th>
<th>Город</th>
<th>Регион</th>
<th>Код региона</th>
<th>Федеральный округ</th>
<th>Численность населения</th>
<th>Дата основания</th>
</tr>
{% for p in data.gorodarf %}
<tr>
<td>{{ p.id }}</td>
<td>{{ p.city }}</td>
<td>{{ p.region }}</td>
<td>{{ p.code_region }}</td>
<td>{{ p.federal_district }}</td>
<td>{{ p.population }}</td>
<td>{{ p.date_of_foundation }}</td>
</tr>
{% endfor %}
</table>
</body>
</html>
Данный pebble-шаблон представляет собой форму с описанием параметров и заголовков для включения данных в документ. В начале документа будет отображаться таблица с информацией о сертификате, подписывающем документ, затем – таблица с перечнем городов РФ, собранным из массива полей, заданных на шаге создания шаблона extract_1. peb.
3. generate_xml.peb – пример pebble-шаблона, который преобразует данные, собранные с применением шаблона extract_1.peb, в XML-документ:
<root>
<gorodarf Id="elementToSign">
{% for p in data.gorodarf %}
<goroda>
<id>{{ p.id }}</id>
<city>{{ p.city }}</city>
<region>{{ p.region }}</region>
<code_region>{{ p.code_region }}</code_region>
<federal_district>{{ p.federal_district }}</federal_district>
<population>{{ p.population }}</population>
<date_of_foundation>{{ p.date_of_foundation }}</date_of_foundation>
</goroda>
<cert>
<organization>{{ certification_info.subjectDN.commonName }}</organization>
<serial>{{ dec_to_hex(certification_info.serialNumber) }}</serial>
<issuer>{{ certification_info.issuerDN.commonName }}</issuer>
<valid-from>{{ certification_info.notBefore | date("dd.MM.yyyy") }}</valid-from>
<valid-until>{{ certification_info.notAfter | date("dd.MM.yyyy") }}</valid-until>
</cert>
{% endfor %}
</gorodarf>
<signature/>
</root>
Данный pebble-шаблон представляет собой форму с массивом полей, который будет выводить данные в соответствии с параметрами, заданными на шаге создания шаблона extract_1.peb. В начале документа будет отображаться перечень городов РФ, затем – информация о сертификате, подписывающем документ.
Подготовка архива с pebble-шаблонами
1. Перейдите в каталог с pebble-шаблонами.
2. Щелкните на свободном месте окна правой кнопкой мыши и запустите командную строку Git Bash (см. Рисунок 23).

Рисунок 23 – Запуск командной строки Git Bash
В результате откроется окно консоли.
В консоли введите следующую команду:
|
tar -czf peb_templates_archive.tgz extract_1.peb generate_pdf_1.peb generate_xml_1.peb |
где через пробел перечисляются все подготовленные pebble-шаблоны (см. Рисунок 24).

Рисунок 24 – Архивирование pebble-шаблонов
В результате в каталоге будет создан архив с названием peb_templates_archive.tgz, в который вложены подготовленные pebble-шаблоны. Этот архив необходимо приложить в файлы инсталляции printable-form-service.
Настройка Агента СМЭВ4
Вся необходимая документация и дистрибутивы для установки и настройки Агента СМЭВ4 опубликованы на портале ЕСКС в разделе "ПО для Участников СМЭВ".
Агент СМЭВ4 необходим для подписания документа, сформированного сервисом печатных форм. Для того чтобы Агент выполнял подписание, необходимо в его конфигурационном файле (application.yml) задать настройку для СПФ:
|
printable-form: max-content-length: 268435456 signature: printable-form-keys: - keystoreType: JCP certificate-alias: '*** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro ***' private-key-alias: '*** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro ***' private-key-pass: '*** ПАРОЛЬ КЛЮЧА CryptoPro ***' signatureAlgorithm: GOST3411_2012_256withGOST3410_2012_256 signatureURI: urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256 digestMethod: http://www.w3.org/2001/04/xmldsig-more#gostr3411 useSmevTransform: false #Пары значения "имя_печатной_формы": "алиас сертификата" forms: v1_<rz_mnemonic_1>: '*** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro ***' |
где:
- v1 – параметр, указывающий порядковый номер РЗ при формировании документа на основе нескольких РЗ;
- <rz_mnemonic_1> – мнемоника РЗ с типом «Печатные формы» из ЕИП НСУД, (например, pf_gorodarf – РЗ для создания документа со списком городов РФ) с порядковым номером v1;
- certificate-alias – идентификатор (alias) контейнера ключей;
- private-key-alias – также идентификатор (alias) контейнера ключей (повторить из предыдущей строки);
- private-key-pass – пароль от контейнера ключей.
Примечание
Если есть необходимость использовать несколько РЗ с типом «Печатные формы»
(например, при необходимости формирования документов по двум и более разным
таблицам, с разной бизнес-логикой), то следует включить в файл все эти РЗ по
порядку, с указанием контейнера закрытого ключа сертификата для подписания документа.
Например:
forms:
v1_<rz_mnemonic_1>: '*** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro ***'
v2_<rz_mnemonic_2>: '*** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro ***'
…
Подробнее об идентификаторе ключа и о том, как получить контейнер закрытого ключа электронной подписи, читайте в статье «Работа с ЭП в СМЭВ».
Для того чтобы проверить работу СПФ, Потребителю данных необходимо получить доступ к РЗ с типом «Печатные формы». Как получить доступ к РЗ, описано в Руководстве пользователя ЛК УВ в Документах ЛК УВ (п.п. 5.7.5 Получение доступов к регламентированным запросам типа SQL-запрос).
Проверьте работоспособность СПФ одним из двух способов:
1. Через командную строку:
1) Убедитесь, что Агент СМЭВ4 запущен и выполняет тестовый запрос Select 1.
2) Отправьте РЗ типа «Печатные формы».
Пример успешного ответа на РЗ типа «Печатные формы» от Витрины данных gorodarf представлен на Рисунке 25:
Рисунок 25 –
Результат РЗ с формированием ответа в виде документа в формате XML
Результат отображается в виде XML-файла, преобразованного в base64.
2. С помощью ПО DBeaver:
Для удобства взаимодействия рекомендуется настроить Агент СМЭВ4 на работу через jdbc-драйвер. Как настроить jdbc-драйвер, описано в статье «Настройка Агента для получения данных через JDBC».
1) Запустите ПО DBeaver и проверьте связь Агента с Ядром СМЭВ4 тестовым запросом Select 1.
2) Создайте новый запрос SQL и пропишите РЗ с типом «Печатные формы», например, РЗ pf_gorodarf (см. Рисунок 26).
Рисунок 26 – Результат РЗ с формированием ответа в виде документа в формате PDF
3) Запустите запрос.
Ответ будет получен в виде файла.
4) Сохраните полученный ответ.
Примечание
Формат документа, формируемого СПФ, задаётся в самом запросе
Результат ответа на запрос на
примере РЗ к Витрине данных gorodarf в виде PDF-документа представлен ниже:
Рисунок 27 – PDF-документ, сформированный СПФ
Результат ответа на запрос на примере РЗ к Витрине данных gorodarf в виде XML-документа представлен ниже:

Рисунок 28 – XML-документ, сформированный СПФ
Возможные ошибки при работе с сервисом печатных форм
Ошибки, возникающие в процессе установки и настройки модулей
Если модули printable-form-service и сounter-provider не запускаются или контейнеры модулей самопроизвольно перезапускаются, то необходимо изучить описания ошибок в логах модулей – они могут подсказать причину сбоев. Чаще всего ошибки бывают связаны с отсутствием настроек или некорректными настройками в конфигурационных файлах модулей.
Ошибки при вызове РЗ типа «Печатные формы»
Если ошибка возникает при вызове РЗ, следует изучить сообщение об ошибке, на основании чего можно сделать вывод о её причине:
1. «Ошибка обращения к сервису печатных форм»
Такая ошибка означает наличие проблемы со стороны Витрины Поставщика. Потребителю данных необходимо связаться с владельцем Витрины. Для этого нужно оформить заявку в СЦ с пометкой «Назначить на ведомство поставщика».
На стороне Поставщика данных следует проверить настройки для СПФ в конфигурационном файле Агента СМЭВ4 (application.yml).

Рисунок 29 – Ошибка обращения к сервису печатных форм
2. «Поле ‘certificate’ не может быть пустым»
Такая ошибка возникает, если в конфигурационном файле Агента СМЭВ4 (application.yml) не задана настройка для подписания документа, формируемого в результате выполнения РЗ, – идентификатор ключа CryptoPro:
| forms:
v1_<rz_mnemonic>: '*** ИДЕНТИФИКАТОР КЛЮЧА CryptoPro ***' |
Информация о наличии сертификата должна передаваться в нулевой позиции при отправке РЗ к Витрине данных. При отсутствии этой информации в качестве нулевой позиции будет прочитана следующая по порядку (необходимо убедиться, что для вызываемого РЗ в настройке был прописан идентификатор ключа CryptoPro).

Рисунок 30 – Ошибка «Поле ‘certificate’ не может быть пустым»
3. «Отсутствует шаблон для документа: extract»
Такая ошибка означает, что не найден pebble-шаблон для извлечения данных из Витрины. Необходимо проверить, все ли шаблоны были размещены в директории templates или прикреплены в виде архива в Студии. Также следует проверить правильность написания наименованиий pebble-шаблонов в конфигурационном файле СПФ (application.yml).

Рисунок 31 – Ошибка «Отсутствует шаблон для документа: <название документа>.extract»
4. «Ошибка по запросу … [/report]: 500 Internal Server Error {"errorMessage":”Error executing query [select * …]: Entity <…> does not exist”}»
Такая ошибка означает, что СПФ не смог получить шаблон для преобразования ответа на РЗ в документ. Необходимо проверить пути к pebble-шаблонам, указанным в конфигурационном файле СПФ в блоке reports (см. п. Конфигурационный файл СПФ).

Рисунок 32 – Ошибка: «Error executing query [select * …]: Entity <…> does not exist»
5. «Ошибка по запросу … [/report]: 500 Internal Server Error {"errorMessage":”Ошибка формирования отчёта по шаблону <…>.pdf”}»
Такая ошибка может возникать по следующим причинам:
- в конфигурационном файле СПФ отсутствует настройка для формирования документа в формате, указанном при вызове РЗ (PDF или XML);
- pebble-шаблон (generate_pdf.peb или generate_xml.peb) для формирования документа («отчёта») составлен неправильно. Шаблон должен содержать в себе массив полей, который будет выводить данные в соответствии с параметрами, заданными при создании extract-шаблона.

Рисунок 33 – Ошибка формирования отчёта по шаблону <…>.pdf(xml)
Примечание
Обращаем ваше внимание, что после внесения изменений в конфигурационные файлы сервисов и контейнеров ПО Агента СМЭВ4 и СПФ их необходимо перезапускать, предварительно перезагрузив все файлы служб (юнитов) командой: systemctl daemon-reload
При возникновении подобных ошибок Потребителям данных рекомендуется оформить заявку в СЦ с указанием: Назначить на ведомство поставщика (при необходимости приложить лог Агента СМЭВ4).
Если самостоятельно определить причину ошибки и устранить ее невозможно, следует обратиться с заявкой в СЦ. Для детального разбора проблем следует приложить к ней логи модулей, где наблюдаются ошибки.
Для помощи в составлении заявки рекомендуем воспользоваться статьёй «Алгоритм действия при возникновении проблем в работе витрины данных».
Наиболее частые ошибки, возникающие при работе с Агентом СМЭВ4 и Витриной данных, разбираются в статье «Как найти причину ошибки обмена СМЭВ4».