Обмен данными. Консистентность vs Многопоточность

Публикация № 1117071 03.09.19

Интеграция с оборудованием и сервисами - Интеграция с сервисами

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

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

В принципе, основным местом любой программы является предсказуемость/стабильность результата. В этом смысле от обмена мы прежде всего ждем гарантий предсказуемости, согласованности и воспроизводимости. Если мы изменяем документ в УТ - мы хотим быть уверены, что этот документ приедет в бухгалтерию, при этом либо целостность всех его ссылок будет гарантирована какими-то свойствами самого обмена, либо документ будет содержать все необходимое "на борту" (как например выгрузка объектов по ссылкам в конвертации). Если обобщать, то:

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

При этом есть важное замечание: подразумевается, что для системы А состояния А1 и А2 - валидные, т.е. мы не рассматриваем случаев, когда перевод системы в новое состояние выполнено нелегитимным способом: есть битые ссылки, была прямая запись в SQL или тому подобные случаи. Для системы Б требование только одно: валидность состояния Б1, а обеспечение валидности состояния Б2 - это полностью ответственность обмена. Иными словами:

не должно быть такого валидного изменения системы А, которое приведет к тому, что обмен переведет систему Б в невалидное состояние

Какие же возможны варианты? Все богатство случаев с битыми ссылками, не хватающими остатками, разными ставками НДС и прочим и прочим можно свести к трем следующим вопросам:

  • Если в базе-источнике объекты были записаны в порядке: сначала А1, затем А2, гарантируем ли мы, что в базе-приемнике объекты запишутся в соответствующем порядке: Б1, затем Б2? Или мы можем записать сначала Б2, затем Б1?

  • Если в базе-источнике объект изменялся дважды: из Версии1 перешел в Версию2, затем в Версию3, гарантируем ли мы, что в базе-приемнике этот объект запишется в соответствующем порядке: 1 - 2 - 3? Или, при каких-то условиях, мы можем пропустить версию 2 и перевести объект в приемнике из версии 1 сразу в версию 3?

  • Если в базе-источнике объекты А1 и А2 записаны в одной транзакции - гарантируем ли мы что в базе-приемнике мы запишем соответствующие им Б1 и Б2 в одной транзакции? Или мы можем себе позволить выделить один из них, который мы запишем первым и таким образом он будет существовать в базе-приемнике без "напарника"?

В зависимости от того, какие ответы на эти вопросы вы даете - вы получите следующие виды гарантий целостности данных

 

Транзакционная последовательность

Этот уровень последовательности похож на то как SQL сервер делает бэкапы: он просто хранит лог транзакций и в случае необходимости накатывает их последовательно на БД.

Это единственный вариант, который гарантированно разрулит вообще все возможные недоразумения, включая перекрестные ссылки. Но в 1С он не достижим: мы не можем контролировать начало и фиксацию транзакции в 1С с тем, чтобы повторить тоже самое в источнике. Можно конечно попробовать опуститься на уровень SQL, но этот путь полон граблей и мы тут в общем про 1С, а не про MS SQL.

 

Хронологическая последовательность

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

Как реализовать.

Нужно складывать все версии всех объектов в отдельное место, не допуская никаких пропусков, подобно тому, как это делает подсистема Версионирование объектов и на стороне приемника воспроизводить эту последовательность.

Плюсы.

Этот обмен с высокой долей вероятности разрулит перекрестный ссылки (если они организованы пользователем, а не кодом в одной транзакции). Также он справится с жесткими последовательными переходами (это пояснено чуть ниже).

Минусы.

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

Что вообще может пойти не так

На самом деле, случаев когда ни один уровень гарантии последовательности (кроме транзакционной или хронологической) не может обеспечить согласованность данных больше чем кажется.

  • Во-первых это перекрестные ссылки. Если А ссылается на Б, а Б на А и вы не предприняли никаких специальных мероприятий - падение почти гарантировано, стоит только попытаться получить что-нибудь через соответствующий реквизит при записи этого объекта или в параллельном потоке.
  • Во-вторых это последовательные состояния: иллюстрируется проще всего статусами документов: если у вас где-то написано, что документ должен сначала быть записан в статусе "новый", а потом может перейти только в "проверенный", а далее только в "на исполнение", то если вы передадите новый документ, а далее попытаетесь передать сразу версию на исполнение - у вас будет нарушение последовательности. Без специальной логики, отключающей проверку для обменов не обойтись. Собственно отсюда все эти костыли с "ОбменДанными.Загрузка".
  • В-третьих это состояние влияющих объектов. Если для проведения документа вы используете, например, какой-то признак контрагента, то мало того что этот контрагент в базе приемнике должен быть. Он еще и должен находится в том же самом состоянии, в котором он находился в базе-источнике в момент проведения. Обратите внимание: не в самом актуальном состоянии, а в точности в том, в котором он был в момент проведения.
  • В-четвертых это логические зависимости бизнес-уровня: например, если у вас есть всего один пиджак и он находится на складе1, вы его перемещаете на склад2, далее на склад3 - ни один алгоритм уровня ниже хронологической последовательности не способен гарантировать такой кульбит с первого раза.

 

Партионно-последовательная

В этом типе обмена фиксируется некий промежуток времени и изменения в рамках него (партию изменений) и обмен гарантирует последовательность партий, но не последовательность объектов внутри партий. Например, если были записаны два объекта А и Б в следующих версиях: А1, далее объект Б1, далее объект А2 - нужно просто запомнить, что есть изменения объектов А и Б и обработать их внутри одной пачки изменений. Таким образом можно точно утверждать, что по завершении сессии обмена данными в приемнике будут присутствовать объекты А и Б, версий 2 и 1 соответственно, но вот порядок того как их записал обмен не гарантируется никак.

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

Как реализовать.

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

Плюсы.

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

Минусы.

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

 

Последовательность основанная на данных

Этот алгоритм точно знает, что бизнес-логика такова, что одни объекты надо прогружать раньше чем другие (например, номенклатуру раньше поступлений, поступления раньше реализаций) и гарантирует эту последовательность. Вообще, в "чистой" реализации, этот принцип должен быть доведен до следующего абсолюта:

  • записываем в источнике объекты А1 и Б1
  • обмен знает, что объекты А приоритетнее объектов Б и начинает загрузку объекта А в приемник
  • в это время в источнике записывается объект А2
  • обмен, закончив загрузку объекта А1 игнорирует тот факт, что объект Б1 записан раньше и руководствуюсь более высоким приоритетом объекта А2 - начинает загрузку объекта А2

На практике же, обмены редко бывают онлайновыми и скорее всего, последовательность основанная на данных будет применяться внутри какой-то сессии обмена (а это собственно и есть уровень гарантий Конвертации данных)

Как реализовать

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

Плюсы.

Возможно какое - никакое преодоление накапливания проблем. Если имеется ошибка в объекте с 50-м приоритетом - это будет тормозить только объекты с приоритетом 51 и ниже, объекты с приоритетом 49 и выше смогут загружаться, пока проблема не решена. (в типовых обменах это так работать не будет: база-источник не в курсе проблем базы-приемника и будет упорно выгружать все)

Минусы.

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

 

Последовательность Шредингера или согласованность в конечном счете

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

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

Как реализовать

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

Плюсы

Можно развернуться с многопоточностью. Если у вас центральная база и 300 узлов - многопоточность - это то, без чего ваш обмен будет проходить с периодичностью раз в неделю. Также этот алгоритм абсолютно не накапливает проблемы: если один объект не записывается - из-за него могут страдать только непосредственно связанные с ним объекты, а не те, что имеют гипотетическую связь. Производительность на несколько порядков (да, именно в 10-100 раз) выше чем жестко-последовательные алгоритмы.

Минусы

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

  1. Бизнес-логика конфигурации должна быть предельно толерантна к битым ссылкам. Например, если при проведении документа и что-то зависит от ставки НДС - она не должна доставаться через ссылку от номенклатуры - ставка должна присутствовать в самой таб.части документа. С одной стороны это жесткая денормализация, с другой если известное правило разработки типовых: если документ перепроводится без изменения - его движения не должны измениться - и это правило сильно способствует толерантности к битым ссылкам (хотя полной гарантии не дает).
  2. Необходимо исключить те участки кода, которые такой толерантностью не обладают. А это, предже всего, логика проведения. И, если мы говорим об идентичных конфигурациях, - проведение это то от чего отказаться не легко, а очень легко! Просто передавайте движения как есть.
  3. Можно просто позволить коду падать: согласованность в конечном счете - штука предельно гибко реагирующая на неудачи и при падании она попробует позже, к тому времени соответствующая ссылка появится. Но тут стоит понимать, что если на 100 попыток записи 1 неудача - это приемлемый уровень, и при нем производительность этого обмена, вместе с падениями даст 100 очков вперед любому другому, пусть даже работающему без сбоев (такое кто-то видел?). Но если каждый объект записывается с 10-го раза - это уже не то к чему стоит стремиться.
  4. Можно попробовать поиграть в проверку битых ссылок. Самый простой вариант - выполнить запрос к соответствующей таблице данных и посмотреть - есть ли там данные. Но такие проверки угробят всю производительность.

О транспортном уровне

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

  • подгоняем грузовик изменений
  • один кладовщик начинает пересчитывать товар поштучно (грузовик ждет)
  • если где-то не хватает одной штуки - загружаем все обратно в грузовик и отправляем обратно

Сами понимаете, на складах это так не работает. Работает так:

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

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

 

Графовая согласованность

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

Как реализовать

Так же как согласованность в конечном счете, с дополнительной проверкой ссылочной целостности

Плюсы

Высокая производительность (оценить выше/ниже согласованности в конечном счете не так просто, поскольку дополнительные затраты на проверку графа в одном случае могут нивелироваться отсутствием некоторого количества неудачных попыток в другом), учет связей между объектами при независимости реализации от условий конкретной конфигурации.

Минусы

Это нереализуемо на 1С: реляционная БД не позволит выстраивать граф с приемлемой производительностью. Для этого потребуются noSQL решения вроде ElasticSearch.

Отдельная боль - это перекрестные (а возможно и кольцевые) ссылки. Такие ситуации на практике встречаются довольно часто, но в силу особенностей их использования в бизнес-логике, как правило, не вызывают проблем. Алгоритм обнаружения таких ссылок не прост, но в общем не бином Ньютона, а после того как они обнаружены, можно попробовать следующие варианты (если не брать вариант с решением проблемы на уровне бизнес-логики):
1. Собрать все такие закольцованные объекты в транзакции по группам закольцованности (от проверок битых ссылок и/или исключений перед/при записи это не спасет, но никто другой битых ссылок не увидит)
2. Попытаться таки записать объекты с битыми ссылками: если один записать удастся - остальные подтянутся
3. Далее очень аккуратно: намеренно испортить объект: найти и заменить битую ссылку на пустую, разорвать таким образом кольцо, затем записать остальные объекта, затем вернуть "испорченный" реквизит на место. Это весьма спорный шаг, но разработчики КД2 считали иначе (они так делают со всеми битыми ссылками, даже не возвращая их назад).

R03;R03;R03;R03;R03;R03;R03;

Заключение

Как наверно уже понятно, обмен, не основанный на бизнес-логике не может гарантировать полной консистентности данных. Единственный путь для того чтобы гарантированно согласованно переводить систему из одного состояния в другое - повторять бизнес-логику системы в обмене. Естественно, при этом обмен начнет валиться по бизнесовым причинам, что требует отдельных ресурсов на поддержку этих обменов. Но по правде говоря, такой уровень гарантий никому не нужен. Обмены основанные на принципе согласованности в конечном счете, хоть и имеют очевидные провалы в гарантиях, но по факту являются настолько быстрыми, что этого никто не успевает замечать, а когда успевает - ответить раз в месяц на вопрос "а что значит Объект не найден?" гораздо проще чем поднимать упавший в очередной раз по остаткам обмен. Ну и производительность обмена на согласованности в конечном счете просто завораживает: 300 узлов 1С:Розница поддерживаются с актуальностью в 5 - 10 минут, самостоятельно исправляя свои же ошибки.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Рейтинг всех уровней
1. savostin.alex 74 05.09.19 16:32 Сейчас в теме
Доброе время суток. Присоединяюсь к теме публикации со скромным дополнением (не сочтите за рекламу, оформил 2 часа назад) https://infostart.ru/public/1118499/
2. Nubsdale 29.07.21 14:46 Сейчас в теме
статье плюс, но хотелось бы примеры реального использования (схема обмена - и реальный пример где это реализовано)
Оставьте свое сообщение

См. также

Тонкости и подводные камни работы типового модуля интеграции Битрикс24 и 1С (Часть 2)

WEB Интеграция с сервисами v8 1cv8.cf Россия Бесплатно (free)

Это вторая часть цикла статей, посвящённых типовому модулю интеграции 1С Предприятия и Битрикс24. Цель данной части: рассмотреть тонкости, связанные с обменом товарами и сопутствующими сущностями (спойлер - единицы измерения и свойства товаров). Также затронем некоторые нюансы связи сущностей 1С и Б24 (относящиеся не только к товарам) и их побочное влияние при переносе данных из модуля в модуль (при смене конфигурации, переустановки или обновлении модуля).

вчера в 08:00    116    freegman74    0    

Тонкости и подводные камни работы типового модуля интеграции Битрикс24 и 1С

WEB Интеграция с сервисами v8 1cv8.cf Россия Бесплатно (free)

Цель статьи - указать на подводные камни и нюансы, о которых “не пишут на заборах” и которые встретились мне за время внедрения типового модуля интеграции 1С и Битрикс24. Будет интересна для людей, кто подумывает о том, чтобы настроить интеграцию, и хотят понять, с чем столкнутся. А также для тех, кто уже работает с подобным обменом, столкнулся с какими-то из описанных ситуаций и хочет понять, что пошло не так и “как жить дальше”. Постараюсь все описать “человеческим” языком с минимальной долей терминов, так как статья, надеюсь, будет полезна не только программистам.

07.11.2021    1178    freegman74    10    

Окей, Google

Интеграция с сервисами Искусственный интеллект (AI) docker v8 Россия Бесплатно (free)

Пример интеграции Google Ассистента с 1С. В основе которого лежит платформа Dialogflow CX для понимания естественного языка.

28.10.2021    1154    Soloist    6    

Готовые модули для работы с Telegram

Интеграция с сервисами v8 1cv8.cf Бесплатно (free)

Готовые модули для отправки сообщений и файлов с логами в Телеграм.

05.10.2021    1935    M_A_D    6    

Сравнительный анализ вариантов интеграции между системами

Интеграция с сервисами v8 Бесплатно (free)

На Infostart Meetup «Интеграционные решения для 1С» выступил Сергей Наумов – руководитель центра аналитики и консалтинга WiseAdvice. Сергей поделился с коллегами кейсами из собственной практики: какие интеграционные решения остаются актуальными до сих пор, а каких приемов стоит избегать – даже в безвыходных ситуациях.

30.07.2021    2013    SergeyN    1    

Собираем данные для отчетов из +100 баз

Поиск данных Интеграция с сервисами Управленческие v8 Бесплатно (free)

Ведущий разработчик ГАОУ ДПО ТемоЦентр Василий Попов на онлайн-митапе Инфостарта «Интеграционные решения в 1С» поделился кейсом о том, как собрать данные для отчетов из +100 баз, какой стек технологий для этого использовать, и к каким проблемам нужно быть готовым.

23.07.2021    1914    pallid    8    

Описание формата 1С JDTO (JSON data transfer object)

Интеграция с сервисами Перенос данных из 1C8 в 1C8 v8 Бесплатно (free)

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

16.07.2021    6463    zhichkin    32    

Пример организации HTTP сервиса на 1С: Документооборот. Источник 1С: ЕРП => Приемник 1С: Документооборот

Интеграция с сервисами Документооборот и делопроизводство v8 ДО Бесплатно (free)

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

13.05.2021    2656    Flover    0    

Настраиваем авторизацию пользователей 1С через Okta

Интеграция с сервисами v8 Бесплатно (free)

Чем больше в компании различных конфигураций и сервисов, тем актуальнее становится проблема единой системы авторизации single Sign-On. Его лидером практически безоговорочно считается Okta. Но на просторах интернета очень мало информации про интеграцию 1С с Okta через протокол OpenID Connect. Что ж, настало время восполнить недостающие пробелы и перевернуть эту печальную страницу в вашей истории

30.04.2021    3902    ripreal1    15    

«БИП: Бизнес-Процессы». Интеграция с Telegram и Конструктор чат-ботов

Управление бизнес-процессами (BPM) Интеграция с сервисами v8 УУ Бесплатно (free)

В статье приводятся примеры настройки автоматических оповещений в системе «БИП: Бизнес-Процессы» с использованием мессенджера Telegram. Также, приводятся примеры создания и настройки произвольных чат-ботов с использованием Конструктора чат-ботов.

15.02.2021    1243    YuriYuriev    0    

Архитектурное решение интеграции баз 1С с использованием брокера сообщений Rabbit MQ

Интеграция с сервисами v8 1cv8.cf Бесплатно (free)

При решении задач интеграции баз данных можно использовать различные средства «транспорта» сообщений. Одним из таких механизмов является брокер сообщений «Rabbit MQ». Такие механизмы очередей сообщений удобно использовать для организации обмена между информационными системами с различной структурой данных, когда велик объем передаваемой информации и требуются гарантии успешной доставки сообщений, а также когда поддержание работоспособности иных способов передачи, например через файлы, становиться слишком трудоемким. Брокер сообщений Rabbit MQ широко описан в сети, но 1С пока не имеет штатных механизмов работы с ним, поэтому их приходится дорабатывать. Рассмотрим пример архитектуры 1С с его использованием.

12.02.2021    1908    Koder_Line    6    

HTML редактор/editor (Wysiwyg) для WebKit 1С (CMS, B2B), альтернатива TinyMCE и стандартному ФорматированныйДокумент

WEB Интеграция с сервисами v8 v8::УФ 1cv8.cf Бесплатно (free)

Suneditor - отличная замена HTML редактору TinyMCE (бесплатному), в публикации с открытым кодом подключим его в 1С с WebKit, скачать HTMLeditor обработку можно бесплатно.

28.12.2020    4151    SizovE    25    

Чтение вложенных свойств Структур Структуры, Соответствий, свойства через точку, разбор JSON

WEB Интеграция с сервисами Универсальные функции Практика программирования v8 Бесплатно (free)

JSON: {user.device.type} - как получить значение {type}? А если вложенность значительно глубже? Как проверить, что оно заполнено или удалить его - всё это в публикации с открытым кодом и даже без рекурсии. Бонусом разбор дерева значений - ДанныеФормыЭлементДерева, СтрокаДереваЗначений.

17.11.2020    2324    SizovE    2    

Сказ о том, как в одной крупной компании документооборот внедряли, или проблемы типовых обменов между КА и ДО

Интеграция с сервисами Перенос данных из 1C8 в 1C8 Документооборот и делопроизводство v8 ДО КА2 Бесплатно (free)

Приветствую всех. Сегодня пойдет речь о том, как на одной крупной компании внедряли 1С:Документооборот 2.1 в связке с КА 2.4. Вроде бы системы типовые, мы практически не добавляли ничего в них, но проблем было столько, что я решил изложить их в статье. Может, кому-то пригодится это в дальнейшем, и не придется тратить кучу времени на поиск решений.

10.11.2020    7527    maks_20    30    

Структура обработки загрузки номенклатуры поставщика с примерами и комментариями (часть 2)

Интеграция с сервисами Практика программирования v8 1cv8.cf Бесплатно (free)

В статье опишу вариант обработки для загрузки номенклатуры поставщика, блок загрузки номенклатуры и доп. реквизитов.

17.10.2020    1061    malikov_pro    3    

Управление соляриями из 1С через Arduino

Интеграция с сервисами v8 1cv8.cf Здравоохранение, медицина, стоматология УУ Бесплатно (free)

Мой опыт автоматизации сети соляриев с интеграцией 1С и оборудования соляриев с помощью платформы Arduino.

01.10.2020    3145    impextr    32    

Взаимодействие 1С со сторонними продуктами посредством REST и Golang (middleware). Часть 3 - ElasticSearch

Интеграция с сервисами Журнал регистрации v8 1cv8.cf Бесплатно (free)

Как в статье №1 этого цикла выгрузим через прослойку журнал регистрации (xml формат) в ElasticSearch. Статья будет иметь практическую направленность в минималистичном стиле

14.09.2020    2305    dmitry-irk38    4    

Интеграции с сервером SQL. Быстро и просто

Интеграция с сервисами Внешние источники данных v8 1cv8.cf Бесплатно (free)

Решаем вопросы экспорта/импорта данных в базы отличного от 1С происхождения.

06.07.2020    4662    Infector    4    

Мониторинг факта выполнения обмена с помощью сервиса healthchecks.io

Интеграция с сервисами Администрирование ИТ-инфраструктуры v8 1cv8.cf Россия Бесплатно (free)

В статье опишу вариант простого мониторинга обработчиков, запускаемых по расписанию.

30.06.2020    2651    malikov_pro    7    

Как мы запилили в АЙТАТ.РФ обработку-бота, чтобы ускорить отгрузку в 2 раза или Реальный опыт внедрения нового механизма "Трансляция событий" от 1С-Коннект

Интеграция с сервисами v8 Бесплатно (free)

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

24.06.2020    2357    direwest    4    

Маркировка лекарственных препаратов. Часть первая "Быстрая интеграция"

Интеграция с сервисами Розничная торговля v8 1cv8.cf Фармацевтика, аптеки Россия УУ Бесплатно (free)

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

23.06.2020    10270    IssakN    38    

Диадок. Подключаемый модуль. Отладка

Интеграция с сервисами Внешние источники данных v8 1cv8.cf Бесплатно (free)

Небольшой пример, как работать с подключаемым модулем Диадок (для изменения УПД перед выгрузкой на сайт Диадок.). Отладка подключаемого модуля, если не смогли подключить стандартную отладку.

17.06.2020    14381    John_d    17    

1C# – 1С моей мечты

Интеграция с сервисами v8 Бесплатно (free)

Встроенных в платформу 1С возможностей не всегда хватает для построения сложных интеграционных схем между различными 1С и не-1С-решениями на базе MS SQL Server. Как сделать интеграцию между SQL-базами более гибкой с помощью платформы 1С# на конференции Infostart Event 2019 Inception рассказал Дмитрий Жичкин.

01.06.2020    13277    zhichkin    36    

Обработчик "После завершения транзакции" своими руками

Интеграция с сервисами Практика программирования v8::blocking Бесплатно (free)

Обработчик "Сразу после завершения транзакции" очень востребован в механизме обмена мгновенными сообщениями, развитием которого фирма 1С заинтересовались настолько, что уже создала "Сервисы интеграции". Но платформа 8.3.17 всё еще не имеет полноценного обработчика "После записи" в подписках на события.

31.05.2020    4059    barelpro    63    

Интеграция Camunda BPM и 1С

WEB Интеграция с сервисами v8 Бесплатно (free)

Быстрый старт. Только практические примеры. Установка, запуск и публикация бизнес-процесса на сервере Camunda BPM. Управление бизнес-процессами из 1С при помощи Camunda REST API.

12.05.2020    6720    zhichkin    31    

Как мы загружаем данные в "Центр управления кассами Магнита"

Внешние источники данных Интеграция с сервисами v8 1cv8.cf Бесплатно (free)

Статья о том, как мы делали механизм загрузки больших объемов данных в "Центр управления кассами Магнита"

08.05.2020    5895    chernenko_vv    26    

Интеграция СуперОкна7 и УНФ

Интеграция с сервисами Внешние источники данных v8 УНФ Россия Бесплатно (free)

Изучаем базу данных СуперОкна7, смотрим возможности передачи и получения информации.

08.05.2020    3248    vostok1.dz    3    

Синхронизация БИТ:СКУД 8 с Parsec.Net 2.5

Интеграция с сервисами Внешние источники данных v8 1cv8.cf Бесплатно (free)

Настройка синхронизации БИТ:СКУД 8 с Parsec.Net.2.5, выгрузка данных из внешней системы контроля доступа.

04.05.2020    4980    RPGrigorev    0    

Измерительная лаборатория с использованием 1С+Ардуино

Периферийные устройства Интеграция с сервисами v8 Россия Бесплатно (free)

1С в автоматизации "научных" и около... экспериментов.

02.05.2020    5261    maxlab    16    

Интеграция БИТ:СКУД с типовой конфигурацией

Интеграция с сервисами v8 1cv8.cf Россия Бесплатно (free)

Интеграция БИТ:СКУД с типовой конфигурацией, обновление БИТ:СКУД в составе конфигурации и отдельно. Обновление системы защиты.

26.04.2020    6415    RPGrigorev    0    

Интеграция 1С и BI-системы: мой опыт с коннектором ATK BIView

Интеграция с сервисами v8 1cv8.cf Россия Бесплатно (free)

Интеграция 1С и BI-системы: мой опыт с коннектором ATK BIView.

06.04.2020    6170    Flyerink    2    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

HighLoad оптимизация WEB Интеграция с сервисами Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    16135    informa1555    35    

Использование таблиц SQL Server в качестве очередей сообщений

Интеграция с сервисами v8 Бесплатно (free)

Статья о событийно-ориентированной интеграции и об асинхронной обработке данных в контексте 1C под управлением SQL Server. Подробно разбирается вопрос использования таблиц СУБД в качестве очередей сообщений.

23.03.2020    4418    zhichkin    9    

Интеграция "Библиотеки интеграции МДЛП 1.1.2.7" с типовой конфигурацией

Интеграция с сервисами Конфигурирование 1С v8 Здравоохранение, медицина, стоматология Россия Бесплатно (free)

Инструкция для интеграции “Библиотеки интеграции МДЛП 1.1.2.7” в типовые конфигурации, на примере конфигурации “Управление нашей фирмой, редакция 1.6 (1.6.18.168)”.

02.03.2020    9319    RPGrigorev    3    

Бесшовная интеграция через обмен по правилам - миссия выполнима

Интеграция с сервисами Перенос данных из 1C8 в 1C8 Практика программирования v8 ДО ERP2 Бесплатно (free)

При организации работы с договорами в ERP 2, с помощью бесшовной интеграции с Документооборотом, «типовой» методикой является создание договоров в ЕРП. После создания договора в ЕРП, пользователь «отправляет» договор в ДО по бесшовной интеграции. На практике, весьма часто пользователи хотят видеть обратную схему: вводить договоры в ДО и при этом получать их в ЕРП без «лишних телодвижений». Или даже вводить их независимо в обеих системах – так, чтобы потом «стыковать» по каким-то определенным правилам.

24.01.2020    7168    e-9    8    

Передача данных с сервера на клиент через WebSocket NativeAPI и Centrifugo

Интеграция с сервисами v8::УФ 1cv8.cf Россия Бесплатно (free)

В статье описываю реализацию обмена для замены передачи сообщений через 1С Сервер взаимодействия.

23.09.2019    9269    malikov_pro    11    

Оповещения боту из 1С за 31 минуту

Интеграция с сервисами Практика программирования v8::УФ 1cv8.cf Бесплатно (free)

Поделюсь опытом, как быстро сделать бота с оповещениями в Телеграмм из 1С без лишних затрат.

18.09.2019    20225    feva    44    

Подсистема обмена данными в рамках РИБ

Распределенная БД (УРИБ, УРБД) v8 Бесплатно (free)

Публикация оформлена после прочтения https://infostart.ru/public/1117071/ (автор https://infostart.ru/profile/586627/) на основе опыта реализации обмена между базами 1С (в том числе с разными конфигурациями) и разработки двухмесячной давности для обмена в рамках РИБ. Платформа начиная с 8.2.19.130

05.09.2019    8230    63    savostin.alex    8