Отправка документов - Сценарии ExtSdk2 — различия между версиями
(→Массовая отправка электронных документов) |
|||
| (не показано 38 промежуточных версий 2 участников) | |||
| Строка 2: | Строка 2: | ||
Поскольку многие информационные системы появилось задолго до электронного документооборота, то для тех из них, которые не умеют работать с JSON, BASE64, криптографией, шифрованием, HTTPS или делают это недостаточно эффективно – например работают исключительно синхронно (последовательно) в ExtSdk2 имеется набор вспомогательных инструментов помогающий решить эти проблемы. | Поскольку многие информационные системы появилось задолго до электронного документооборота, то для тех из них, которые не умеют работать с JSON, BASE64, криптографией, шифрованием, HTTPS или делают это недостаточно эффективно – например работают исключительно синхронно (последовательно) в ExtSdk2 имеется набор вспомогательных инструментов помогающий решить эти проблемы. | ||
| + | |||
| + | == Отправка электронного документа == | ||
Отправка любого комплекта документов в СБИС (запуск в документооборот) состоит из 3 этапов: | Отправка любого комплекта документов в СБИС (запуск в документооборот) состоит из 3 этапов: | ||
| Строка 8: | Строка 10: | ||
* '''Выполнение действия''' на этом этапе в СБИС выполняет требуемую операцию (в нашем случае отправку), кроме этого на этом этапе в СБИС как правило загружаются подписи и недостающие файлы. | * '''Выполнение действия''' на этом этапе в СБИС выполняет требуемую операцию (в нашем случае отправку), кроме этого на этом этапе в СБИС как правило загружаются подписи и недостающие файлы. | ||
| − | Для каждого из выше перечисленных этапов в ExtSdk2 есть | + | Для каждого из выше перечисленных этапов в ExtSdk2 есть отдельные методы, которые можно использовать для интеграции [[ WriteDocument_-_создает_/_обновляет_Документ_(ExtSdk2) | WriteDocument ]], [[ PrepareAction_-_подготовить_документ_к_действию_(ExtSdk2) | PrepareAction ]], [[ ExecuteAction_-_выполнение_действия_над_документом_(ExtSdk2) | ExecuteAction ]]. |
| − | == Запись документа в СБИС == | + | === Запись документа в СБИС === |
Результатом данной операции является созданный в одном из реестров СБИС объект Документ – карточка документа. Основными реквизитами Документа СБИС, определяющими его поведение в системе и атрибутный состав являются свойства «Тип» и «Регламент». Кроме этого к любому документу СБИС может быть прикреплено не ограниченное количество вложений (файлов) это могут быть как формализованные так и не формализованные документы любого размера. Загружать файлы вложения можно двумя способами: | Результатом данной операции является созданный в одном из реестров СБИС объект Документ – карточка документа. Основными реквизитами Документа СБИС, определяющими его поведение в системе и атрибутный состав являются свойства «Тип» и «Регламент». Кроме этого к любому документу СБИС может быть прикреплено не ограниченное количество вложений (файлов) это могут быть как формализованные так и не формализованные документы любого размера. Загружать файлы вложения можно двумя способами: | ||
| − | Либо вызвав для каждого вложения отдельный метод записи | + | Либо вызвав для каждого вложения отдельный метод записи [[ WriteAttachment_-_метод_записи_вложений_документа_(ExtSdk2) | WriteAttachment ]], либо передав данные вложения в метод записи документа [[ WriteDocument_-_создает_/_обновляет_Документ_(ExtSdk2) | WriteDocument ]]. |
| − | |||
| − | |||
| − | + | === Подготовка действия === | |
| − | + | Результатом данной операции является объект документ подготовленный к переходу на следующий этап документооборота. Метод [[ PrepareAction_-_подготовить_документ_к_действию_(ExtSdk2) | PrepareAction ]]. | |
| − | + | === Выполнение действия === | |
| − | |||
| − | + | Результатом данной операции является объект документ с выполненным действием для подготовленного документа к переходу на следующий этап документооборота. Метод [[ ExecuteAction_-_выполнение_действия_над_документом_(ExtSdk2) | ExecuteAction ]]. | |
| − | + | === Комплексный метод отправки электронного документа === | |
| − | + | Дополнительно для облегчения интеграции в ExtSdk2 реализован комплексный метод, выполняющий несколько операций за один вызов - [[ WriteDocumentEx_-_Расширенный_метод_создания_и_отправки_документа_(ExtSdk2)| WriteDocumentEx ]] выполняет [[ WriteDocument_-_создает_/_обновляет_Документ_(ExtSdk2) | WriteDocument ]] + [[ PrepareAction_-_подготовить_документ_к_действию_(ExtSdk2) | PrepareAction ]] + [[ ExecuteAction_-_выполнение_действия_над_документом_(ExtSdk2) | ExecuteAction ]]. | |
| − | + | Подробнее как вызывать методы и получать ответы от ExtSdk2 см. раздел [[ Подключение_к_ExtSdk2_через_OLE_-_Сценарии_ExtSdk2 | Подключение к ExtSdk2 через OLE ]] | |
| − | |||
| − | |||
| − | |||
| − | + | ==Массовая отправка электронных документов== | |
| − | + | [[Файл:Эффективность_способов_массовой_отправки_документов_в_СБИС.jpg|мини| Сравнение эффективности способов массовой отправки]] | |
| − | + | Задача - максимально эффективно сформировать и отправить пакеты документов. Данный алгоритм предназначен для систем с синхронным исполнением кода, которые будут использовать ExtSdk2 через OLE объект. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | Т.к. ExtSdk2 работает асинхронно алгоритм отправки для достижения максимального быстродействия (уменьшения ожиданий) более сложен в реализации, чем например алгоритм при отправке через SDK. Сравнение эффективности алгоритмов приведено на диаграмме. | ||
| − | |||
| − | |||
| − | + | [[ File:AlgMassSending.png|мини| Алгоритм массовой отправки документов ]] | |
| − | + | На входе имеем список внутренних идентификаторов документов (ссылок), на основании которых хотим сформировать комплекты электронных документов (далее пакеты) для отправки и идентификатор настроек описывающих правила формирования пакета. Это может быть как список отмеченных пользователем записей, так и список полученный для автоматической операции. | |
| − | + | Данный алгоритм желательно оформить в виде отдельного метода, каждый прямоугольник так же выделить в отдельный метод. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Ресурсы приемника документов в плагине и на сервисе СБИС ограничена, чтобы не создавать задержки из-за переполнения очереди, не потреблять лишние ресурсы по памяти, процессору, каналу и не получать ошибки истекшего таймаута (не усложнять алгоритм) отправка осуществляется параллельно в N потоков. Количество потоков по умолчанию равно 10, и может быть увеличено по обращению путем выделения дополнительных ресурсов. | |
| − | + | Общее время отправки документа складывается из следующих операций: | |
| + | # Получение данных из ИС для формирования электронного документа (интеграционный модуль). | ||
| + | # Формирование электронного документа (интеграционный модуль + ExtSdk2). | ||
| + | # Подписание, шифрование электронного документа (ExtSdk2 + СКЗИ). | ||
| + | # Загрузка и отправка электронного документа (ExtSdk2 + API СБИС) | ||
| + | # Получение статуса отправки (ExtSdk2 + API СБИС) | ||
| + | # Обновление статуса ЭДО в ИС (Интеграционный модуль) | ||
| − | + | Максимальная скорость работы достигается алгоритмом с наибольшей загруженностью всех параллельных потоков. | |
| − | |||
| − | + | В большинстве основное время приходится на операции 3 и 4, поэтому наиболее эффективен нижеследующий алгоритм: | |
| + | * Интеграционный модуль отслеживает, чтобы одновременно отправлялось не более N документов (countThread). | ||
| + | * Как только освобождается поток для отправки (поступило событие / статус что документ отправлен), сразу же в него передается следующий документ. | ||
| + | * Пока заняты всех потоки отправки, интеграционный модуль готовит к отправке следующие документы (п.1-2), как правило достаточно иметь запас не превышающий количеству потоков. | ||
| + | * В случаях когда заняты все потоки и запас сформирован происходит обновление статуса ЭДО, т.к. в ряде случаев это то же может быть длительной операцией, она выполняется по одной на итерацию. | ||
| − | + | Пояснения к схеме: | |
| − | + | * countAll - Количество документов которые требуется отправить | |
| + | * countThread - Количество потоков отправки | ||
| + | * countFreeThread - Количество свободных потоков отправки | ||
| + | * countSend - Количество документов по которым запущена процедура отправки | ||
| + | * countComplete - Количество документов по которым отправка завершена, в т.ч. обновлен статус отправки | ||
| + | * countError - Количество ошибок | ||
| + | * countPrepare - Количество подготовленных к отправке документов | ||
| + | * cachePrepare - Массив с данными подготовленных к отправке документами (это данные которые просто достаточно передать методу отправки). | ||
| + | * cacheAnswer - Массив с результатами отправки | ||
| − | + | * getData - Получает из информационной системы данные и формирует комплект электронных документов с необходимыми метаданными. Подготовленный объект сохраняет в cachePrepare. | |
| − | + | * sendDocFromCache - Берет первый документ из cachePrepare и вызывает метод отправки ExtSdk2.WriteDocumentEx. По идентификатору запроса регистрирует обработчик обратного вызова. Обновляет счетчики свободных потоков и количества подготовленных, отправленных документов. | |
| + | * readEvents - Получает одну страницу событий (OLE.ReadAll). Если пришел ответ результат отправки (есть зарегистрированный обработчик обратного вызова - вызываем) | ||
| + | * callback WriteDocumentEx - обработчик обратного вызова отправки документов, вызывается когда приходит событие с результатом отправки (положительным или отрицательным) - в любом случае помечаем что освободился поток отправки, положительный результат и критическую ошибку помещаем в массив с не обработанными результатами. Для временных ошибок если не достигнут лимит повторных отправок запускаем отправку документа заново. Пример алгоритма на отдельной схеме. | ||
| + | * processAnswer - берет первые N записей из chacheAnswer и обновляет статусы у документа. N определяем динамически исходя из времени работы метода. Начинаем с N = countThread и рассчитываем после каждого выполнения сколько влезает в 3 сек исходя из среднего времени на один статус. | ||
| + | * processAllAnswer - вызывает processAnswer пока chacheAnswer не опустеет. | ||
==Отправка нескольких электронных комплектов документов без формирования вложений== | ==Отправка нескольких электронных комплектов документов без формирования вложений== | ||
Текущая версия на 10:54, 17 мая 2021
В СБИС отправка документов похожа на отправку письма электронной почты. Т.е. вы формируете письмо (пакет = комплект электронных документов = объект API документ) указываете от кого кому собираетесь отправить, заполняете тему письма (набор вспомогательных реквизитов - тип документа, регламент документооборота и т.п.), прикладываете к нему вложения (электронные документы) и нажимаете отправить. В зависимости от содержимого вашего письма и настроек СБИС дополнительно может потребоваться подписать или зашифровать вложения перед отправкой.
Поскольку многие информационные системы появилось задолго до электронного документооборота, то для тех из них, которые не умеют работать с JSON, BASE64, криптографией, шифрованием, HTTPS или делают это недостаточно эффективно – например работают исключительно синхронно (последовательно) в ExtSdk2 имеется набор вспомогательных инструментов помогающий решить эти проблемы.
Содержание
Отправка электронного документа
Отправка любого комплекта документов в СБИС (запуск в документооборот) состоит из 3 этапов:
- Запись документа в СБИС – на данном этапе в СБИС записываются все необходимые данные, файлов может быть много или они могут быть большие, поэтому эта операция может выполнятся за один или несколько вызовов.
- Подготовка действия – на данном этапе вы говорите СБИС, какое действие хотите сделать с документом, СБИС проверяет достаточность данных, выполняет вспомогательные операции (например дописывает в документы идентификаторы участников документооборота, переименовывает вложения в соответствии с требованиями формата), конвертирует XML в PDF для контрагентов в роуминге, определяет какие файлы необходимо подписать, какой подписью и в каком формате это требуется сделать. Данный этап является не обязательным и его можно пропустить в случаях если информационная система реализовала на своей стороне всю необходимую логику работы и её не требуется помощь.
- Выполнение действия на этом этапе в СБИС выполняет требуемую операцию (в нашем случае отправку), кроме этого на этом этапе в СБИС как правило загружаются подписи и недостающие файлы.
Для каждого из выше перечисленных этапов в ExtSdk2 есть отдельные методы, которые можно использовать для интеграции WriteDocument , PrepareAction , ExecuteAction .
Запись документа в СБИС
Результатом данной операции является созданный в одном из реестров СБИС объект Документ – карточка документа. Основными реквизитами Документа СБИС, определяющими его поведение в системе и атрибутный состав являются свойства «Тип» и «Регламент». Кроме этого к любому документу СБИС может быть прикреплено не ограниченное количество вложений (файлов) это могут быть как формализованные так и не формализованные документы любого размера. Загружать файлы вложения можно двумя способами:
Либо вызвав для каждого вложения отдельный метод записи WriteAttachment , либо передав данные вложения в метод записи документа WriteDocument .
Подготовка действия
Результатом данной операции является объект документ подготовленный к переходу на следующий этап документооборота. Метод PrepareAction .
Выполнение действия
Результатом данной операции является объект документ с выполненным действием для подготовленного документа к переходу на следующий этап документооборота. Метод ExecuteAction .
Комплексный метод отправки электронного документа
Дополнительно для облегчения интеграции в ExtSdk2 реализован комплексный метод, выполняющий несколько операций за один вызов - WriteDocumentEx выполняет WriteDocument + PrepareAction + ExecuteAction .
Подробнее как вызывать методы и получать ответы от ExtSdk2 см. раздел Подключение к ExtSdk2 через OLE
Массовая отправка электронных документов
Задача - максимально эффективно сформировать и отправить пакеты документов. Данный алгоритм предназначен для систем с синхронным исполнением кода, которые будут использовать ExtSdk2 через OLE объект.
Т.к. ExtSdk2 работает асинхронно алгоритм отправки для достижения максимального быстродействия (уменьшения ожиданий) более сложен в реализации, чем например алгоритм при отправке через SDK. Сравнение эффективности алгоритмов приведено на диаграмме.
На входе имеем список внутренних идентификаторов документов (ссылок), на основании которых хотим сформировать комплекты электронных документов (далее пакеты) для отправки и идентификатор настроек описывающих правила формирования пакета. Это может быть как список отмеченных пользователем записей, так и список полученный для автоматической операции.
Данный алгоритм желательно оформить в виде отдельного метода, каждый прямоугольник так же выделить в отдельный метод.
Ресурсы приемника документов в плагине и на сервисе СБИС ограничена, чтобы не создавать задержки из-за переполнения очереди, не потреблять лишние ресурсы по памяти, процессору, каналу и не получать ошибки истекшего таймаута (не усложнять алгоритм) отправка осуществляется параллельно в N потоков. Количество потоков по умолчанию равно 10, и может быть увеличено по обращению путем выделения дополнительных ресурсов.
Общее время отправки документа складывается из следующих операций:
- Получение данных из ИС для формирования электронного документа (интеграционный модуль).
- Формирование электронного документа (интеграционный модуль + ExtSdk2).
- Подписание, шифрование электронного документа (ExtSdk2 + СКЗИ).
- Загрузка и отправка электронного документа (ExtSdk2 + API СБИС)
- Получение статуса отправки (ExtSdk2 + API СБИС)
- Обновление статуса ЭДО в ИС (Интеграционный модуль)
Максимальная скорость работы достигается алгоритмом с наибольшей загруженностью всех параллельных потоков.
В большинстве основное время приходится на операции 3 и 4, поэтому наиболее эффективен нижеследующий алгоритм:
- Интеграционный модуль отслеживает, чтобы одновременно отправлялось не более N документов (countThread).
- Как только освобождается поток для отправки (поступило событие / статус что документ отправлен), сразу же в него передается следующий документ.
- Пока заняты всех потоки отправки, интеграционный модуль готовит к отправке следующие документы (п.1-2), как правило достаточно иметь запас не превышающий количеству потоков.
- В случаях когда заняты все потоки и запас сформирован происходит обновление статуса ЭДО, т.к. в ряде случаев это то же может быть длительной операцией, она выполняется по одной на итерацию.
Пояснения к схеме:
- countAll - Количество документов которые требуется отправить
- countThread - Количество потоков отправки
- countFreeThread - Количество свободных потоков отправки
- countSend - Количество документов по которым запущена процедура отправки
- countComplete - Количество документов по которым отправка завершена, в т.ч. обновлен статус отправки
- countError - Количество ошибок
- countPrepare - Количество подготовленных к отправке документов
- cachePrepare - Массив с данными подготовленных к отправке документами (это данные которые просто достаточно передать методу отправки).
- cacheAnswer - Массив с результатами отправки
- getData - Получает из информационной системы данные и формирует комплект электронных документов с необходимыми метаданными. Подготовленный объект сохраняет в cachePrepare.
- sendDocFromCache - Берет первый документ из cachePrepare и вызывает метод отправки ExtSdk2.WriteDocumentEx. По идентификатору запроса регистрирует обработчик обратного вызова. Обновляет счетчики свободных потоков и количества подготовленных, отправленных документов.
- readEvents - Получает одну страницу событий (OLE.ReadAll). Если пришел ответ результат отправки (есть зарегистрированный обработчик обратного вызова - вызываем)
- callback WriteDocumentEx - обработчик обратного вызова отправки документов, вызывается когда приходит событие с результатом отправки (положительным или отрицательным) - в любом случае помечаем что освободился поток отправки, положительный результат и критическую ошибку помещаем в массив с не обработанными результатами. Для временных ошибок если не достигнут лимит повторных отправок запускаем отправку документа заново. Пример алгоритма на отдельной схеме.
- processAnswer - берет первые N записей из chacheAnswer и обновляет статусы у документа. N определяем динамически исходя из времени работы метода. Начинаем с N = countThread и рассчитываем после каждого выполнения сколько влезает в 3 сек исходя из среднего времени на один статус.
- processAllAnswer - вызывает processAnswer пока chacheAnswer не опустеет.
Отправка нескольких электронных комплектов документов без формирования вложений
На входе имеем список объектов «Документ» подлежащих отправке и набор относящихся к ним файлов вложений в каталоге. Нам требуется загрузить и запустить его в документооборот СБИС, при необходимости выполнив операции подписания и шифрования.
