А вот и Шина подъехала! Часть 2

21.08.23

Интеграция - Перенос данных 1C

Кому и для чего нужна 1С:Шина? Какие проблемы она решает, а каких добавляет? Продолжим начатое в первой части статьи построение концепции, позволяющей эффективно использовать этот продукт. Подкрепим это описанием очередной порции аспектов работы как непосредственно с самой Шиной, так и работы с ней со стороны конфигурации 1С: "гарантированная недоставка" сообщений, принципы построения групп участников обмена, "неявная маршрутизация" сообщений.

Во второй части статьи я продолжаю начатую ранее тему про работу с 1С:Шиной и про свое видение построения эффективной системы по обмену данными в развитой информационной инфраструктуре.

Здесь можно ознакомиться с остальными частями статьи:

А вот и Шина подъехала! Часть 1
А вот и Шина подъехала! Часть 3. Итоги

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

 

Практические моменты

"Гарантированная недоставка" сообщений

Одним из основных преимуществ 1С:Шины я считаю ее поддержку принципа "гарантированной доставки" сообщений, декларируемый разработчиками продукта.
В справке говорится об этом следующее: "Сообщение хранится в приложении «1С:Шины» до тех пор, пока «1С:Шина» не получит подтверждение о том, что получатель это сообщение принял".
И приводится следующая схема (без моих красных вставок, разумеется), отображающая обмен данными двух конфигураций 1С через Шину с демонстрацией жизненного цикла сообщения в разных системах (отправитель-Шина-получатель):

Принцип гарантированной доставки в случае использования баз 1С в качестве отправителя и/или получателя распространяется и на них.

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

К слову, в 1С инициализирует фоновые задания отправки/получения сообщений вызов метода СервисыИнтеграции.ВыполнитьОбработку(), который рекомендуется вызывать регламентным заданием каждые две минуты.
И надо иметь в виду, что этот рекомендованный 1С интервал не означает, что задержка получения данных после их отправки будет в максимуме составлять те же две или даже четыре минуты.
Используемые внутренние механизмы каналов в конфигурации и шине позволяют сообщению при таком интервале попадать к получателю, обычно, практически сразу.

Проблемы с сообщением могут начаться на стороне получателя. То есть, когда Шина на самом деле свою работу уже сделала.
До этого проблемы, конечно же, тоже могут возникнуть: недоступность Шины или программные проблемы маршрутизации или обработки данных внутри нее. Но тут все достаточно очевидно и есть определенные механизмы мониторинга и отладки в Шине, чтобы это исправить.

Несомненно, и в 1С тоже есть механизмы выявления проблем в каналах сервиса интеграции. Если из одной системы вы  благополучно отправили абсолютно невинное сообщение типа "Hello, World!", через Шину оно также прошло, увеличив счетчики сообщений на каналах входа/выхода процесса интеграции, а в системе-получателе 1С его получить не можете, то самое время заглянуть в канал получения системы.
То есть, определить количество сообщений в канале получения (<СервисИнтеграции>.<КаналСервисаИнтеграции>.ВыбратьСообщения().Количество()).
Наверняка вы получите ненулевое число. Причем ваше безобидное "Hello, World!" тут будет, скорее всего, ни при чем.

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

В самой же обработке получения сообщения (а обрабатываются они в коде 1С по одному за раз) можно оперировать параметром Отказ.
Если его установить в значение Истина, то сообщение не просто не будет "обработано" и потеряно, а будет повторно стучаться к вам до тех пор, пока не будет обработано так, чтобы параметр Отказ имел значение Ложь.

Причем, все остальные сообщения, полученные позже "сбойного", будут терпеливо ждать своей очереди. Попыток их обработать система делать не будет пока вы не разберетесь со сбойным.
Ваше "Hello, World!" скорее всего будет где-то среди них, а сообщение-"виновника" вы отправили раньше него, и, возможно, даже совсем из другой системы.

Таким образом, можно спровоцировать "гарантированную недоставку" сообщений, как непосредственно "сбойного", так и всех следующих за ним. Сколько их скопится в канале базы 1С (тут еще интересно - а какова его емкость?) - вопрос скорости реакции на ситуацию. Причем вашей реакции. Ну, или кого-то еще из ответственных за обмен данными...

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

Как поведет себя система, если обработка получения проводится вне транзакции, я сказать не могу, такого эксперимента не ставил. Подозреваю, что аналогично.
В любом случае, эта настройка - использование транзакции - находится на уровне канала сервиса интеграции в конфигурации, управлять динамически ей нельзя. Но, если нужно, можно сделать пару каналов получения и передавать то что подлежит транзакционной обработке через один, а что не подлежит - через второй.

Но я отвлекся...
В начале моих экспериментов с Шиной мне пришлось осознать и принять такой подход.
Он тоже является частью реализации постулата "гарантированной доставки": ни одно сообщение не должно быть не просто не потеряно, но еще и обрабатываться сообщения должны в строгой последовательности!

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

Как решать такую проблему "гарантированной недоставки"? Да, в общем-то, тривиально: обрабатывать ошибки при обработке сообщений и не устанавливать параметр Отказ в значение Истина.
Но тут важно решить вопрос: нужно ли разрешать при наличии ошибок загрузку следующих сообщений или нет. В случае, если вы не разрешаете загрузку, оставляя "сбойное" сообщение вместе со всеми следующими за ним в канале получения, то кто-то должен достаточно оперативно отреагировать на такую ситуацию. Поскольку загрузка через канал будет остановлена.
Эта оперативность, в свою очередь, может зависеть от критичности  всего комплекса передаваемых через этот канал в систему данных.
Можно ранжировать критичность и самого "сбойного" сообщения, опираясь на его параметры, несущие информацию о характере данных сообщения.
Можно ранжировать по характеру возникающей ошибки, локализовав место ее возникновения.
А можно даже создать несколько каналов получения, направляя разной критичности данные через разные каналы, чтобы самые важные данные меньше зависели от остальных.

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

Поле для фантазии как именно решить эту проблему широкое.
Но результат должен быть один: обеспечение целостности и актуальности данных в связанных системах!

 

Общая группа информационных систем в проекте Шины

В элементе "Процесс интеграции" проекта 1С:Шины можно разместить блоки типа "Группа участников":

В приложении 1С:Шины эти группы участников объединяют информационные системы, описанные в системном справочнике Шины Инфосистемы.

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

На одном из вебинаров, посвященных Шине, демонстрировался внедренный и реально работающий проект по интеграции достаточно большого количества систем одного из крупных ВУЗов страны. Так там я наблюдал отдельную группу участников для каждой информационной системы проекта.
В таком варианте ошибиться, наверное, сложнее, но сам проект, опять же, на мой вкус, выглядел ну совсем нечитаемым  и плохо масштабируемым - огромный "паук". Хотя говорилось о том, что после внедрения Шины затраты на управление интеграциями снизились многократно. Видимо, до этого, было совсем все "не очень"...

В любом случае, мне эстетически всегда приятнее минимизировать количество элементов в проекте. Причем в любом - про Шину ли это, про схему ли бизнес-процесса или про что-либо еще.

Шина вполне позволяет это сделать. Как говорилось в первой части статьи, управлять адресацией сообщений можно через свойство сообщения КодПолучателя, в котором можно перечислить коды всех Инфоосистем, которые должны получить сообщение.
Сообщение, "долетев" в процессе интеграции до блока группы участников, будет доставлено только тем Инфосистемам, чьи коды присутствуют в этом свойстве. Остальные будут проигнорированы.

При этом, вполне допустимо использовать на весь проект вообще единственную группу участников, в которую будут входить все отправители и получатели сообщений. Просто каналов входа/выхода к этой группе будет присоединяться несколько. Например, вполне допустим такой вариант:


На рисунке в процессе интеграции присутствует единственная группа участников, которая в данном случае может содержать базы 1С и системы, работающие с Кроликом (RabbitMQ). Пара каналов Получение1С и Отправка1С отвечает за базы 1С, ПолучениеRMQ и ОтправкаRMQ - за системы с Кроликом.

Адресация сообщений с помощью свойства сообщения КодПолучателя решает вопросы корректной доставки. Но, при этом, важно понимать, что система-отправитель должна четко знать в какие системы идет сообщение, чтобы это свойство инициализировать.
Либо этим должна заниматься Шина, неважно. Важно, что где-то и как-то (в общей системе, управляющей интеграцией) должна содержаться информация о том кому должны адресоваться те или иные данные, передаваемые из тех или иных  систем. И эта информация должна быть доступна и использоваться при формировании и/или передаче сообщения.

Есть еще момент подключения базы, добавленной в группу УчастникиОбмена (см. рисунок) к "нужным" каналам отправки/получения.
Для Кролика, например, параметров подключения чуть больше чем много.
Проще всего осуществить подключение с помощью реквизитов, добавленных в справочник Инфосистем в проекте Шины.
Как добавить справочник и его реквизиты в проект показано в первой части статьи под спойлером "Описание доработки проекта 1С:Шины для реализации синхронного обмена".
А вот такие реквизиты нужно добавить для работы с Кроликом:

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

Инициализироваться реквизиты требуемыми значениями уже должны в работающем приложении Шины при добавлении новой Инфосистемы. Можно отредактировать их и после добавления. Естественно, только для тех систем, которые должны работать с Шиной через Кролика. Для остальных Инфосистем их инициализировать не нужно.

А вот трансляция этих параметров подключения к Кролику из Инфосистемы в каналы ПолучениеRMQ и ОтправкаRMQ осуществляется через свойства соответствующих блоков в схеме процесса интеграции следующим образом:

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

Схожим образом (через реквизиты Инфосистем и свойства блоков-каналов) можно осуществлять подключение и к другим типам источников/получателей, доступным на текущий момент: Ftp, Jms, ОчередьШины, Файл.

Все это, по сути, свободное изложение справочной информации, но без нее дальше не двинемся. А может, кому-то и полезно/интересно будет)...

Подключение к блокам-каналам по реквизитам Инфосистем, когда группа участников с некоторым количеством "разнотипных" систем подключена сразу к нескольким "разнотипным" блокам-каналам, имеет пару неприятных, но не смертельных моментов.

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

В несовершенном интерфейсе шины выглядит это именно так. Но при наведении на строку события можно увидеть текст полностью:
Ошибка при выполнении процесса Основной::ПроцессИнтеграции в узле ОтправкаRMQ: Остановлено получение сообщений от участника "ШинаТест2" в узле "ОтправкаRMQ" из-за ошибки вычисления выражения в свойстве "Хост" узла. Проверьте значения реквизитов данного участника.

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

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

К счастью, этот момент решается довольно несложно с помощью, как я это назвал, "неявной маршрутизации сообщений". Но рассмотрю я его решение уже в третьей части статьи, поскольку вторая уже на текущий момент получается достаточно объемной.

А нужно еще поговорить об эмпиреях, то есть, о построении концепции эффективного использования 1С:Шины.

 

Концепция эффективного использования 1С:Шины. Первые шаги

Здесь и сейчас мы подведем только промежуточные итоги по материалам этой и предыдущей статьи. Завершить построение концепции попробуем в следующей, надеюсь, последней статье цикла.

Что же на текущий момент нам известно?

При построении нашей информационной инфраструктуры мы можем связать проектом 1С:Шины определенное количество типов информационных систем. Только те, для которых можем в процессе интеграции проекта "прикрутить" готовые блоки-каналы (или коннекторы).
Наличие среди них, например, коннектора для Кролика (RabbiMQ) очень существенно расширяет перечень подобных систем.

Если среди ваших систем нет такой, которая является абсолютно обязательной для участия в общей системе обмена данными, и которая при этом не может подключиться ни к к одному из коннекторов 1С:Шины (давайте обмен с помощью файлов все-таки не рассматривать), то это уже можно рассматривать как показание к ее (Шины) использованию.

Далее. Самый "родной" коннектор в Шине обеспечивает соединение с базами 1С (а также с системами, имеющими возможность обмениваться информацией по протоколу AMQP).
При этом, реализация каналов сервисов интеграции в платформе 1С, также как и Шина, обеспечивает принцип "гарантированной доставки" сообщений.
Поэтому, если в вашей информационной инфраструктуре находятся преимущественно базы 1С (или вообще, только они и есть), то это тоже можно рассматривать как еще один плюс в сторону использования 1С:Шины.

Стоп! Вот здесь есть еще и проблема!
Предположим, базы 1С, да, есть. И их сразу несколько. И характер передаваемой между ними информации носит очень разнородный характер. И самих структур "тип данных-отправитель-получатель" получается очень много.
Выходит, в каждой отдельной базе придется прописывать систему, реализующую формирование и отправку "специфичных" для системы данных через Шину или прием и обработку получаемых и таких же специфичных данных?

Сейчас, обычно, обмен так и выглядит: зарегистрированные в планах обмена, специфичных для каждой конфигурации, данные  выгружаются в файлы или "напрямую" передаются в системы-получатели. От формата данных зависит как их будет загружать система-получатель.
То есть, помянутые структуры "тип данных-отправитель-получатель" живут практически сами по себе. Вернее в каждой паре отправитель-получатель. При необходимости корректировки нужно "ковырять" и отправителя, и систему формирования сообщений (КД2, например), и, зачастую, получателя.

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

Значит, нужна единая система, которая агрегировала бы в себе всю информацию по всем используемым Инфосистемам. Описывала бы все возможные интеграции между ними (те самые структуры "тип данных-отправитель-получатель").
Крайне желательно, чтобы не просто описывала, а являлась "настраивающей" интеграции системой. То есть, изменение в описании тут же приводило бы к изменениям в процессах обмена.
А значит, описание должно содержать информацию и о форматах обмена (о правилах конвертации КД2 или версии формата EnterpriseData, например).

А раз "тут же приводило бы к изменениям в процессах обмена", то и передача "настроечных" данных из системы управления интеграциями (назовем ее СУИ), тоже должна осуществляться быстро и качественно в "заинтересованные" системы.

Вот это, как раз, 1С:Шина вполне может обеспечить. Просто форматы для сообщений обмена данными и "настроечных" сообщений могут несколько отличаться.

СУИ, в идеале, должна управлять процессами регистрации изменений, выгрузки, передачи и загрузки данных. А еще неплохо бы добавить в нее передачу произвольных наборов данных по запросу. Ну, и управление синхронными обменами тоже, если в первой части статьи я не смог уговорить вас от них отказаться...
Еще она должна обязательно предотвращать "несанкционированный обмен" (см. также первую часть статьи) и обеспечивать единый формат информационных сообщений.
Она может выступать отдельной системой, также включенной в общий процесс интеграции через проект 1С:Шины, передавая свои данные всем вовлеченным в этот процесс системам. Может и не выступать, но об этом в третьей части).

Но от идеи использовать для организации такой системы сам проект Шины я отказался - на момент принятия решения там даже еще Регистров сведений не добавили. Да и интерфейс приложения Шины для подобной затеи - так себе решение...

Да, сама по себе 1С:Шина всего этого, как кому бы ни хотелось, не обеспечивает. Да, чтобы написать нечто подобное нужно потратить N-ое количество ресурсов.
Но, если ваша информационная инфраструктура начинает давить на вас проблемами с интеграцией, если вам приходится часто перенастраивать ваши рабочие и тестовые контуры, если вы начинаете организовывать обмен заново там, где он уже есть и нужно только чуть подправить - вам придется этим заняться...однозначно)...

 

Окончание не за горами!..

В заключительной третьей части статьи я постараюсь завершить формирование "крупными мазками" концепции системы управления интеграциями (СУИ), основанной на том небольшом пока опыте, что я приобрел, работая с 1С:Шиной. Ну, и нас ждет еще пара практических моментов работы с Шиной и с системой 1С, которая должна быть связана с Шиной в рамках реализации этой концепции.

Шина обмен данные канал сообщение интеграция конвертация EnterpriseData управление регистрация отправка получение квитирование

См. также

SALE! 10%

Перенос данных 1C Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

50722 45650 руб.

04.08.2015    165050    383    275    

369

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.234.x) и БП 3.0 (3.0.161.x). Правила подходят для версии ПРОФ и КОРП.

28000 руб.

15.12.2021    23084    158    47    

117

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

26280 руб.

12.06.2017    140100    781    295    

409

Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020    24344    23    1    

25

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой

50722 45650 руб.

15.04.2019    71484    180    148    

120

SALE! 10%

Перенос данных 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)

Можно проверить до покупки, оставьте заявку! Воспользовались более 268 компаний! Перенос данных из УТ 10.3 в УТ 11 | из УТ 10.3 в КА 2 | из УТ 10.3 в ERP. Предлагаем качественное и проверенное временем решение для перехода с УТ 10.3. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам. При выходе новых релизов конфигураций 1C оперативно выпускаем обновление переноса данных.

50722 45650 руб.

24.04.2015    194123    148    242    

279

SALE! 10%

Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Правила переноса данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных) Воспользовались более 122 предприятий! |

50722 45650 руб.

31.10.2014    235988    99    333    

304

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

48278 43450 руб.

03.12.2020    35991    90    62    

86
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Torin 815 21.08.23 12:22 Сейчас в теме
+. Жду продолжение
Алексей Воробьев; +1 Ответить
2. user-z99999 70 21.08.23 13:26 Сейчас в теме
Я правильно понимаю, что конфигурация Шина нужна для тех,
кто обменивается в 10 разных форматах с внешним миром? (цифра 10, это условно, много разных форматов)

Просто у меня между базами http-сервисы, и зачем мне Шина, не понимаю?
3. Алексей Воробьев 276 21.08.23 14:00 Сейчас в теме
(2) Шина - это не конфигурация. Написана она не на 1С. Это сервис для транспорта сообщений обмена данными с возможностью широкой кастомизации: вы сами рисуете блоками процессы интеграции и прописываете где вам нужно программный код управления обменами.

По поводу синхронного обмена (на http-сервисах, например) почитайте, пожалуйста, первую часть статьи.

Но, раз уж они уже есть, нормально работают, вас все устраивает в их функционировании, никаких проблем доработки в системах не вызывают, все обмены документированы и документация актуализируется чтобы условно "новый" человек мог легко во всем разобраться - вам Шина, возможно, не нужна вовсе...
7. dsdred 3526 22.08.23 09:48 Сейчас в теме
(2)Простыми словами.

Есть уличные музыканты(http-сервисы\брокеры\файлы и т.д), а есть ансамбль\группа\оркестр(все тоже само но в едином контуре).

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

Вот эта группа с художественным руководителем и\или дирижером как раз и есть Шина.
zamaraev_ev; abasovit; +2 Ответить
10. user-z99999 70 22.08.23 10:38 Сейчас в теме
(7)
Спасибо, мне этот ансамбль\группа\оркестр пока не нужен.

Возможно, это для случая, когда в организации "зоопарк" технологий.
11. Алексей Воробьев 276 22.08.23 10:56 Сейчас в теме
(10)Зачастую вопрос даже не в многообразии технологий, а в однообразии управления всем "хозяйством". В Ваших комментариях нет местоимений "у нас", "нам". Есть "у меня" и "мне".
Это приводит к мысли, что все интеграции были настроены и/или разработаны Вами непосредственно.

Если так, то, конечно, смысла в Шине мало. Ровно до тех пор, пока вы не перестанете принимать участие в поддержке всей системы.
Как только это произойдет, актуальность в адекватном описании всех обменов будет более чем очевидна - новому человеку придется иметь с этим дело.

Еще чуть про синхронные обмены (http-сервисы). Этот, несомненно, очень полезный инструмент, сам по себе является потенциальным источником "зоопарка". Каждый http-сервис может использоваться явно и неявно в большом количестве систем.
Если отсутствует внятное описание всех использований, то любые модификации самого сервиса или его отключение могут повлечь непредсказуемые проблемы...
Это тоже можно рассматривать как показание к переводу синхронных обменов на асинхронные. По крайней мере там, где это возможно...
4. maksa2005 544 21.08.23 14:21 Сейчас в теме
Честно не понимаю так же, зачем мне эта Шина, у меня все на "подкрышках" сделано. 7 обменов по планам обмена между ЗУП и БП. 6 Обменов между БП-БП. Кучу http
5. 1CUnlimited 320 21.08.23 14:54 Сейчас в теме
Проблемы с сообщением могут начаться на стороне получателя. То есть, когда Шина на самом деле свою работу уже сделала.

Из опыта обработки по нескольку миллионов XML сообщений в Rabbit MQ в день.
Шина конечно предоставляет возможности буферизации, но без собственного буфера не обойтись хотябы для гарантированной доставки.
Сообщение может быть кривым (Payload в Rabbit не типизирован) и Вам могут прислать сообщение которое даже по типам данных будет генерить ошибку. Собственный буфер позволяет
а) Сохранить сообщение и после фиксации транзакции, отпустить сообщение в шине.
в) отдельно собирать Payload для невалидных сообщений на анализ потом.
главное разгрести очередь, иначе она попадет на диск, диск кончится , кончится шина (выже там не одни)
Сразу решается куча проблем - например 1С упал, сообщение не записалось в буфер. Но оно останется в шине, поскольку отпускается после фиксации транзакции для буфера.
Единственный вариант когда оно потеряется это падение самой шины - но тут нужно реализовывать протокол с квититированием (что то по мотивам TCP) . Отправитель как правило к этому не готов
Буфер поможет справится с обработкой сообщений - например когда их миллионы, производительности кластера не хватит обрабатывать их в режиме Online. А сохраненные обработать проце.
P S Коллеги и не надо забывать что 1С Шина это обертка над серьезными решениями, лучше сразу изучать RabbitMQ и код примеров на любимом языке (Java, C# , C и т.д.) , там буду видны все нюансы и проблемы 1С Шина
olexi2012; TimkoNzt; quazare; Алексей Воробьев; +4 Ответить
6. quazare 3764 22.08.23 09:29 Сейчас в теме
всегда уважуха человеку, который вот так берет, разбирает материал - выкладывает в общем доступе.... есть же энтузиасты
annapam1983; aM4Ze; Алексей Воробьев; +3 Ответить
8. Somebody1 69 22.08.23 09:51 Сейчас в теме
Так и не могу понять, в чём отличие Шины от Кролика. И тот и другой "гарантированно доставляют сообщения", Может кто-то пояснить?
9. Алексей Воробьев 276 22.08.23 10:22 Сейчас в теме
(8)Вообще, очень многие не понимают концепцию подобных продуктов в принципе.
Для чего, если все и так работает?) Пять обменов тут, семь там, набор веб- и/или http-сервисов. Все летает и живет!..

Постараюсь таки донести свою точку зрения на этот вопрос в последней третьей части статьи. Не уверен, что получится. Тем более донести до всех. Но тогда это будет вина не читателей, а горе-писателя)

Сравнительную характеристику Шины и Кролика делать не буду, увольте) Не ощущаю у себя достаточных компетенций, особенно в отношении Кролика.

Но, в отношении 1С:Шины могу сказать еще раз то, о чем писал в этой части статьи. Помимо гарантированной доставки в Шине, 1С обеспечило поддержку этого принципа и в сервисах интеграции баз 1С.
То есть, если большинство ваших систем в информационной инфраструктуре это базы 1С, то 1С:Шину использовать точно предпочтительней.

Про это, кстати, коллега написал в 5-м комментарии... Не про предпочтительность 1С:Шины, а про необходимость обеспечения этого принципа в системах, работающих с Кроликом)
12. 1CUnlimited 320 22.08.23 17:47 Сейчас в теме
(8) Просто 1С сделала свою шину, для удобной интеграции 1С продуктов. Попутно сделали возможность подключение к RabbitMQ
Из обзора уже все видно https://v8.1c.ru/static/1c-shina/?
и там же есть ответ от 1С
Стоило ли 1С делать свою шину? Ведь тот же Rabbit он рассчитан на большие нагрузки, написан на Erlang, и еще для него есть много клиентов
Не проще ли было просто написать хороший клиент 1С для rabbit плюс еще для других шин?

Что отличает 1С:Шину от других ESB-продуктов?
1С:Шина использует механизм сервисов интеграции для работы с системами 1С.
Типовые конфигурации 1С могут дорабатываться для отправки\получения сообщений в 1С:Шину через механизм расширений — это сохраняет их на поддержке.
Продукт включен в реестр отечественного ПО.
Низкие требования к уровню подготовки технических специалистов — простота разработки и эксплуатации.
Конкурентная стоимость.
Техническая поддержка и обновление продукта входит в подписку ИТС.


С какой скоростью работает 1С:Шина? Выдержит ли она большую нагрузку?
Скорость передачи сообщений может зависеть от множества факторов, например, от производительности оборудования и сетевого окружения, на котором развернут сервер 1С:Шины, от размера сообщения, от сложности трансформации и условий маршрутизации сообщений при передаче. Сценариев большое количество и разброс может быть значительным. Для примера мы проводили тест, на котором через механизм сервисов интеграции отправляли в 1С:Шину около 20 000 сообщений размером 256 Кб каждую минуту и она с этим успешно справлялась.

333 сообщения в секунду как нагрузочный тест ;) . Вообще на практике там по мегабайту и больше в XML сообщения должны летать
В Rabbit даже Persistence несколько видов https://www.rabbitmq.com/persistence-conf.html
В 1С еще сделали возможность трансформации XML JSON на лету. Как это будет коррелировать с производительностью?
Думаю это тот случай когда лучше присоединятся к более сильному продукту чем делать свое
Ну 1С большой ему видней
Алексей Воробьев; +1 Ответить
13. Алексей Воробьев 276 22.08.23 19:32 Сейчас в теме
(12)Тут для многих контор может быть решающей фраза в описании: "Продукт включен в реестр отечественного ПО"
Безопасники государственных и окологосударственных структур будут пропускать только такое...
14. rozer 310 23.08.23 10:51 Сейчас в теме

К слову, в 1С инициализирует фоновые задания отправки/получения сообщений вызов метода СервисыИнтеграции.ВыполнитьОбработку(), который рекомендуется вызывать регламентным заданием каждые две минуты.
И надо иметь в виду, что этот рекомендованный 1С интервал не означает, что задержка получения данных после их отправки будет в максимуме составлять те же две или даже четыре минуты.
Используемые внутренние механизмы каналов в конфигурации и шине позволяют сообщению при таком интервале попадать к получателю, обычно, практически сразу.


Тут не понял, если 1с сама вызывает СервисыИнтеграции.ВыполнитьОбработку() то зачем еще РЗ делать?
Только чтобы чаще раз в 2 минуты скидывать сообщение из канала в шину?
Оч. странно - могли бы и в канале параметр на интервал сделать...
15. Алексей Воробьев 276 23.08.23 11:10 Сейчас в теме
(14)Извините, я не говорил что 1С сама вызывает этот метод)
Вызывать его нужно самостоятельно...откуда и с каким интервалом (или вообще по какому-то событию) - решать разработчику)
16. rozer 310 23.08.23 11:19 Сейчас в теме
(15) да, про это в курсе )
но практика показала что сама платформа вызывает ...но... иногда... закономерность на поняли - после отправки сообщения в канал ВыбратьСообщения() показывает 0 а счетчик сообщений в шине увеличивается хотя СервисыИнтеграции.ВыполнитьОбработку() не запускали. В ЖР кстати тоже событие появляется. Вот такие "чудеса".
17. Алексей Воробьев 276 23.08.23 11:35 Сейчас в теме
(16)Проверьте всю конфигурацию на предмет вызова этого метода - наталкивался в БСП на него...
Если счетчик увеличился уже в шине, то канал отправки в 1С будет пуст. Как только шина подтверждает получение, в канале сервиса интеграции сообщение удаляется. Попробуйте "положить" шину и отправить сообщение. Вот тогда оно должно быть в канале...
18. rozer 310 31.08.23 10:46 Сейчас в теме
Как поведет себя система, если обработка получения проводится вне транзакции, я сказать не могу, такого эксперимента не ставил.


ИТС:


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

● Флажок установлен. Перед вызовом обработчика получения сообщения начинается транзакция. Затем выполняется вызов обработчика.

Если обработчик отказался от обработки сообщения (параметр Отказ установлен в значение Истина или в обработчике вызвано исключение), то выполняется отмена транзакции и следующее сообщение не обрабатывается до тех пор, пока не будет успешно обработано текущее сообщение.

Если обработчик успешно завершился, то сообщение помечается как обработанное, а транзакция фиксируется.

● Флажок сброшен. Перед вызовом обработчика получения сообщения транзакция не начинается.

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

Если обработчик успешно завершился, то сообщение помечается как обработанное.

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

Показать


сервисы интеграции
19. Алексей Воробьев 276 31.08.23 11:28 Сейчас в теме
(18) Речь шла несколько не об этом. На ИТС описана очевидная банальщина и не описано главное - если из обработчика получения прилетит "отказ" или исключение, то как будет вести себя очередь следующих сообщений: так же, как и при транзакционной обработке застопорится, или таки следующим сообщениям будет позволено обработаться?

В приведенном фрагменте описан стопор очереди именно для транзакционной обработки. Неясность остается, нужно просто попробовать будет))
20. rozer 310 31.08.23 12:41 Сейчас в теме
(19) ИМХО флаг транзакция - это неявная транзакция и всего-то а отказ=истина это да будет "пробка" как вы и писали. Это разные вещи и флаг сам по себе а "отказ" - отдельно.
Оставьте свое сообщение