Рекомендации разработчиков бизнес-сообществу по вопросу “Ветис.API: технические вопросы взаимодействия”

На встрече 23 июля Алексей Тимофеев (архитектор системы) начал с самой распространенной проблемы с которой многие столкнулись: ошибка APLM0012.

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

Рекомендации:

  1. Оптимизация существующих операций получения списков
  2. Выделение отдельной очереди для “тяжелых” запросов
  3. Новый функционал загрузки истории изменений

То есть уменьшение интенсивности запроса, запрашивать истории изменений ровно тогда когда это необходимо.

Настройка параметра запроса, в первую очередь — запрашиваемый период. Сегодня встречаются запросы за неделю, месяц, за год и т.д.

По мнению Алексея, оптимальное значение периода- это запрос за сутки, не более. Запрос создан для того, чтобы смотреть историю последних изменений. Для актуальных сведений по ЭВСД за какой- то период — для этого есть отдельная операция получение списка, где вы можете установить фильтр по дате создания этого документа, и получить документы для построения аналитики, статистики и т.д.

Следующий момент- определение страниц. Размер страниц сейчас ограничен 1000 записями. Это зависит от характеристик каждого предприятия, от общего объема документов, которые содержатся в базе, от интенсивности оформления, которые существуют для каждой определенной площадки.

Рекомендации: эмпирически подбирать это значение.

То есть в зависимости от объема документа, от количества документа, сейчас во время пускового периода рекомендуется начать со страницы размером 500 записей и далее подбирать для своего предприятия, то значение которое вас устраивает.

4. пункт- Очень часто запрашиваются все списки, всех документов независимо от потребностей.

Рекомендации: В операции предусмотрены набор фильтров. Если вы конкретизируете для каждого запроса что хотите получить, то запрос будет эффективнее по времени обработки документов, и по размеру передаваемых данных. То же самое и по статусу данных.

Общая рекомендация: тонко настраивать по каждому конкретному случаю.

Сейчас разрабатывается механизм который обеспечит стабильную работу остальных операций путём вынесения в отдельную дополнительную очередь запросов тяжелых на историю получения изменений. Тестируют несколько вариантов доп. операций, функционал по получению историй изменений, в том числе до возможного варианта истории загрузки в виде архива. Как будет готово представят бизнес-сообществу чтобы улучшить работу в истории загрузки изменений в работе со шлюзом.

Вопрос не количества запросов- вопрос характера профиля нагрузки и алгоритма который используют.

Основные моменты, которые вызывают беспокойство:

  1. Опрос истории изменений каждую минуту / 5 минут.

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

О том, как эти же ошибки решает ЗАО АСП рассказал в своем интервью Сергей Барышев ген. директор. 

Чтобы уменьшить нагрузку и повысить производительность (проблема APLM0012) с учетом того, что ориентированы на большие объемы данных  и на большое количество ЭВСД мы делаем очередь заявок и очередь ответов, при этом распределяем приоритеты по каждой заявке. Таким образом система формирует изначально эти очереди. А что делать когда возникает ошибка APLM0012 при условии, что некорректно заполнен сам сертификат? Смотрите ответы на эти и другие вопросы в видео.

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

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

3. Неравномерный поток запросов-  надо выполнять сглаживание трафика.

4. Интенсивный опрос результата обработки заявок. -Определить в системах тайм-аут (задержку) между последующими обращениями к сервису к каждой корректной операции.

5.Запрос результата по “старым” заявкам. -Шлюз хранит в системе определенный период заявок- 3 суток. Заявки старше 3-х дней переносятся в архив и недоступны для  получения.- однако большой поток запросов на получение заявок свыше 3-х суток.

6. Повторное получение результата заявки.Наблюдают повторное получение результата. Зачем? проверьте мониторинг у себя.

7. Загрузка реестров с offsetOutOfRange- просьба следить за своим мониторингом.

8. Злоупотребление объединением и инвентаризацией.

9. Отсутствие обработки системных ошибок.

10. Отсутствие реакции на бизнес-ошибки. Если свыше 10% от числа общих операций, то это повод задуматься. Для ряда пользователей шлюза превышает 70- 80%. Настраивать необходимо мониторинг у себя. Это не пользовательский запрос, операция выполняется в автоматическом режиме и система на нее никаким образом не реагирует.

11. Интеграция “через веб”- попытка интегрироваться через веб интерфейс. Веб интерфейс предназначен для работы пользователей, для автоматизированных есть шлюз. Веб- интерфейс не использовать не по назначению.

 В своих системах предусматривать подсказки уберегающие пользователей от действий: например, ошибочное гашение. Количество систем которые будут интегрированы в финале с Меркурием и достигнет примерно сотни тысяч систем в не отдаленном будущем. Поэтому все разработчики представляйте свои решения. Резюмировал выступление Алексея Тимофеева Николай Власов.