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

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

Разработка - Системная интеграция - Интеграция

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

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

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

если имеются интегрированные системы А и Б, при этом состоянию А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 79 05.09.19 16:32 Сейчас в теме
Доброе время суток. Присоединяюсь к теме публикации со скромным дополнением (не сочтите за рекламу, оформил 2 часа назад) https://infostart.ru/public/1118499/
Оставьте свое сообщение

См. также

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

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

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

17.11.2020    800    SizovE    2    

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

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

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

10.11.2020    3650    maks_20    21    

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

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

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

17.10.2020    558    malikov_pro    2    

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

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

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

01.10.2020    1833    impextr    28    

Интеграция с Трелло. Готовый код

Обмен данными 1С Интеграция Agile (XP, SCRUM, Канбан) v8 Бесплатно (free)

Код основных действий, интеграция с API Трелло.

19.08.2020    2727    Yashazz    14    

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

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

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

06.07.2020    2110    Infector    4    

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

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

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

30.06.2020    1794    malikov_pro    5    

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

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

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

24.06.2020    1644    direwest    4    

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

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

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

23.06.2020    4515    IssakN    30    

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

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

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

17.06.2020    4638    John_d    8    

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

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

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

01.06.2020    11283    zhichkin    35    

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

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

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

31.05.2020    2894    barelpro    63    

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

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

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

12.05.2020    3890    zhichkin    20    

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

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

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

08.05.2020    5148    chernenko_vv    25    

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

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

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

08.05.2020    2243    vostok1.dz    3    

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

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

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

04.05.2020    4048    RPGrigorev    0    

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

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

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

02.05.2020    4458    maxlab    16    

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

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

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

26.04.2020    5262    RPGrigorev    0    

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

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

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

06.04.2020    4544    Flyerink    0    

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

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

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

31.03.2020    13438    informa1555    31    

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

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

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

23.03.2020    3020    zhichkin    7    

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

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

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

02.03.2020    6661    RPGrigorev    3    

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

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

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

24.01.2020    5341    e-9    2    

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

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

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

23.09.2019    7773    malikov_pro    11    

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

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

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

18.09.2019    17493    feva    42    

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

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

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

05.09.2019    5971    5    savostin.alex    6    

Как организовать консолидацию данных из трех десятков предприятий, не привлекая программистов на местах?

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

Какую архитектуру и технологии выбрать для организации обмена между «зоопарком» разных конфигураций и системой, принципиально отличающейся от 1С, как наладить такой обмен без изменения конфигурации и организовать мониторинг из единого центра, расскажет докладчик конференции INFOSTART EVENT 2018 EDUCATION Александр Бобрышов. 

15.07.2019    4674    ShurikDM    4    

Система питания в офисе: как совместить вендинговые автоматы, 1С, облачную кассу и веб-технологии

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

В начале 2019 года тенденция развития автоматов питания в России привела к появлению проекта нового формата питания на работе — МикроМаркета “Го!Поедим”. Потребовалось создать новый формат зоны питания сотрудников: интегрировать в офисные кухни полноценные МикроМаркеты с бесконтактной оплатой, кофе-машинами, лаунж-зоной. Если правильно совместить вендинговые автоматы, облачную кассу, 1С и веб-технологии, то в результате будут не только сытые сотрудники, но и корректная работа всей системы офисного питания.

22.06.2019    6727    antonovintervolga    6    

1С + TecDoc + CMS Битрикс. Трудности перевода

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

Варианты подключения номенклатурных данных базы TecDoc, если у вас автобизнес.

12.04.2019    7185    n.saltsina    11    

RabbitMQ + Конвертация Данных 3.0

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

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

21.03.2019    27031    barelpro    82    

Переход на "Зарплату и управление персоналом 3.1"

Интеграция Управление персоналом (HRM) Пользователю системы Бухгалтерский учет Управление персоналом (HRM) v8 v8::СПР ЗУП2.5 ЗУП3.x Россия БУ Бесплатно (free)

Сменила я тут работу и уже после того, как я приступила к исполнению обязанностей, мой новый начальник мне призналась, что выбор пал на меня только из-за того, что я знаю программу. Справедливости ради, эта уверенность была основана только на том, что я прошла тестирование, включающее только основные операции кадрового делопроизводства. Так или иначе, а работодатель попал в точку, нанимая меня в надежде, что я решу проблему: нужно перейти «с 8.2 на 8.3». Ничего сложного, скажет большинство, я тоже так говорю, но ситуация осложнялась некоторым количеством предшественников, которые уже «нафеячили» в программах до меня. Взять и сделать все заново мне не разрешили, так что пришлось исходить из того, что есть, и именно это дало пищу для размышлений и, в конце концов, привело к написанию этих рекомендаций. Если перед Вами стоит задача перехода с ЗУП 2.5 на ЗУП 3.1, я попробую облегчить Вам жизнь этой статьей.

01.02.2019    13548    VKuser24804875    33    

Выбор программы 1С

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

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

16.01.2019    9460    itworks    22    

Проектирование архитектуры и модификация программных продуктов как технология в сложных проектах системной интеграции и автоматизации на базе 1С: СППР

Управление проектом Интеграция СППР v8 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

03.10.2018    17263    roman72    19    

Планы обмена 1С

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

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

10.09.2018    63128    zhichkin    32    

Создание web-площадки на технологиях 1С, или как Водоканал сделал "Личный кабинет потребителя"

WEB Интеграция v8 Энергетика и ЖКХ Бесплатно (free)

Гончаров Максим делится опытом создания «Личного кабинета потребителя» на сайте водоканала. Он описывает архитектуру системы и объясняет, какую роль в ней играют технологии: «Битрикс», OData, веб-сервисы, «1С:БСП». Также в статье раскрываются возможности использования подсистемы «Анкетирование» в «1С:БСП» как конструктора документов.

25.06.2018    17946    maxx    33    

На что действительно способны HTTP-сервисы

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

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

14.06.2018    36206    dalgaso2010    45    

Как написать обмен с 50 поставщиками и не сойти с ума. Теория

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

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

09.04.2018    11734    m-rv    12    

Может ли 1С выйти на рынок B2C

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

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

15.08.2017    13631    WanGoff    76    

Обмен сообщениями. Что это?

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

Большая часть моей работы посвящена интеграции приложений. Очень странно, что для «1С:Предприятие 8» нигде не описаны промышленные шаблоны интеграции, а если и есть какая-то информация — то ее очень мало. Цель данной статьи (или цикла статей, как получится) стало желание поделится опытом, источниками информации и самое главное полезными книгами.

27.10.2016    22782    pbazeliuk    11