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

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

Интеграция и обмен данными - Обмен между базами 1C

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

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

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

если имеются интегрированные системы А и Б, при этом состоянию А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/
2. Nubsdale 29.07.21 14:46 Сейчас в теме
статье плюс, но хотелось бы примеры реального использования (схема обмена - и реальный пример где это реализовано)
Оставьте свое сообщение

См. также

Ни в ЗУП ногой!? А мне нравится! Часть 4. Главное - правильный перенос данных! Промо

Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 2.5 1С:Зарплата и кадры бюджетного учреждения 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Бесплатно (free)

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

30.05.2022    4061    biimmap    26    

Переход с УПП на ERP с сохранением документов. Фантастика или реальность?

Внедрение ИТ-системы Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 Бесплатно (free)

В последнее время задача перехода с УПП становится все более актуальной. Причина – ожидаемое снятие УПП с поддержки и более продвинутые возможности последних версий конфигураций 1С. О том, какие методики переноса данных из УПП в ERP можно применить, и как в автоматическом режиме убедиться, что все перенеслось корректно, на конференции Infostart Event 2021 Moscow Premiere рассказал Сергей Сорокин.

28.04.2022    2433    primat    2    

Порядок слияния баз ЗУП 3.1, используя Конвертацию данных 2.1

Обмен между базами 1C Платформа 1С v8.3 1С:Конвертация данных 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

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

14.12.2021    1420    gshirok    11    

Выполнение синхронизации (обмен) по событию 1С (двусторонний обмен)

Обмен между базами 1C Платформа 1С v8.3 1С:Бухгалтерия 2.0 1С:Управление нашей фирмой 1.6 Бесплатно (free)

Выполнить синхронизацию(обмен) с другой базой 1С по событию в 1С (проведение документа). Запустить синхронизацию из другой базы 1С.

16.11.2021    3586    Swamt    0    

Выгрузка документа по условию Промо

Обмен между базами 1C Платформа 1С v8.3 Бесплатно (free)

Что делать, если документы нужно выгружать не все подряд, а по какому-то фильтру: статусу, дате, набору условий... А что если он соответствовал этим условиям, а потом перестал? А если потом опять начал? Такие ситуации заставили попотеть не одного программиста.

25.04.2019    18781    m-rv    4    

Что делать, когда обмены между разными базами данных портят вам жизнь…

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Если при обмене между базами данных наблюдаются следующие симптомы: • Процедуры обмена занимают неприемлемо много времени. • Процессы обмена периодически вылетают «по ошибке» и их приходится запускать заново. • Поиск ошибок обмена превращается в ужасающий квест. То, скорее всего вы используете конфигурацию «Конвертация данных». А если при этом вам надоело получать сообщения службы поддержки о новых ошибках и вы бережете свои нервы, то данная статья написана прямо для вас. Чуть ниже я расскажу вам, как навсегда забыть проблемы, связанные со словом "обмен".

10.09.2021    2776    director04    9    

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

Обмен между базами 1C Платформа 1С v8.3 Бесплатно (free)

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

16.07.2021    9788    zhichkin    32    

Повышаем эффективность разработки правил обмена Промо

Групповая разработка (Git, хранилище) Обмен между базами 1C Платформа 1С v8.3 1С:Конвертация данных Бесплатно (free)

Как повысить скорость и качество разработки правил обмена? Как вести групповую разработку правил обмена? Как облегчить сопровождение правил обмена после передачи в эксплуатацию? Об этом и многом другом вы можете узнать из этой статьи.

25.06.2018    31628    olegtymko    48    

Добавление нового документа в формат обмена EnterpriseData (получение)

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Данная статья - логическое продолжение (ссылка на первую часть ниже) доработки обмена, но уже на стороне базы приемника.

27.04.2021    2390    con-men    2    

Добавление нового документа в формат обмена EnterpriseData (отправка)

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Для меня встала задача добавить новый документ, созданный в расширении, в формат обмена EnterpriseData, между БП - УНФ. Изначальный поиск решения не дал результата. Методом проб и ошибок у меня сформировалось свое решение, которым спешу поделиться, чтобы систематизировать информацию в текст и услышать плюсы, минусы подхода. Все доработки осуществляются в расширении, в котором и был создан новый документ.

21.04.2021    4624    con-men    7    

Правила обмена больше не нужны

Внешние источники данных Обмен между базами 1C WEB-интеграция Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Бесплатно (free)

Есть несколько общепринятых подходов к написанию обмена между 1С-системами, каждый из которых упирается в длительное изучение технологии, мучительную отладку правил конвертации и написание большого количества сервисного кода, в котором потом тяжело разобраться. О принципах работы универсального фреймворка liteExchange, который реализует быстрые обмены между 1С и внешними системами, и берет на себя всю техническую обвязку по стандартному преобразованию данных, на INFOSTART MEETUP Saint Petersburg.Online рассказал Николай Крылов.

17.03.2021    17535    Nikola23    40    

Универсальный обмен между идентичными конфигурациями через REST интерфейс OData. Часть І: Справочники Промо

Обмен между базами 1C Платформа 1С v8.3 Бесплатно (free)

Сейчас все чаще интеграции различных конфигураций проектируются через HTTP-сервисы - они и работают быстрее, и "войти" в режим отладки гораздо проще, тем самым обойдя "черный ящик" универсального обмена через xml, например. Более года назад я начал работать в компании, в которой разработчики работали с конфигурациями 1С в режиме совместимости еще 8.2.16 (менять режим совместимости в типичных базах мы не хотели) - а как Вы наверное знаете, если интересовались HTTP-сервисами в 1С, их использование в режиме совместимости 8.3.4 и ниже недопустимо - и здесь я уже не надеялся на разработку и использование HTTP-сервисов. Но позже меня заинтересовал такой "сервис" как REST интерфейс OData, так как его можно использовать не меняя режим совместимости конфигурации - именно он и стал для меня идеальным вариантом решения "нетривиальных" задач.

11.05.2018    26649    V.Stavinsky    11    

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

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

12.02.2021    3579    Koder_Line    6    

Перенос данных из ЗУП 2.5 в ЗУП 3.1

Зарплата Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 2.5 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Бесплатно (free)

Довольно часто сталкиваюсь с тем, что у коллег возникает вопрос, как правильно выполнить перенос данных из ЗУП 2.5 в ЗУП 3.1. (Неужели еще кто-то до сих пор работает в ЗУП 2.5? Да, и очень много людей)

25.01.2021    15101    VAAngelov    81    

Взаимодействие между базами 1С через COM Промо

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрено много особенностей взаимодействия между базами 1С по COM технологии

10.08.2015    194120    tormozit    72    

Объединение баз ЗУП

Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Бесплатно (free)

Есть база ЗУП 3.1, в которой ведется одна организация, все данные из нее нужно перенести в общий ЗУП, обе базы типовые. Используем для переноса КД 2.0.

10.01.2021    4692    roger83    5    

Неожиданное использование XDTO

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

05.12.2020    3722    simon_sidoruk    22    

Использование инструментов разработчика для отладки обменов КД 2.0 Промо

Обмен между базами 1C Платформа 1С v8.3 1С:Конвертация данных Бесплатно (free)

Пара трюков, благодаря которым жить становится намного проще...

05.05.2017    29622    unichkin    6    

XDTO на службе надежности обмена

Обмен между базами 1C Платформа 1С v8.3 Бесплатно (free)

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

28.09.2020    1944    m_kislyak    4    

Лайфхаки конвертации данных 2.1 (часть 2)

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье будут рассмотрены десять приемов работы с конвертацией данных 2.1. Указанные приемы явно не описываются в документации (справке), но их полезно знать и применять. Для наглядности приёмы работы сопровождаются описанием реализации и практическими примерами.

14.09.2020    24431    Shining_ninja    17    

Восстановление узла РИБ по магазинам на примере 1С:Розница 2.3.4

Обмен между базами 1C Платформа 1С v8.3 1С:Розница Россия Бесплатно (free)

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

15.06.2020    14727    maxon    13    

РИБ 200 узлов. Середина пути Промо

Обмен между базами 1C Платформа 1С v8.3 1С:Розница Россия Бесплатно (free)

Между настройкой и поддержкой РИБ на 2 узла и на 10 большой разницы нет, а вот когда число удаленных точек переваливает за сотню, приходится решать уже совсем другие вопросы

25.10.2016    42488    comol    215    

Конвертация данных 2. Использование подключаемых обработок в правилах обмена. Конвертация дерева значений

Обмен между базами 1C Платформа 1С v8.3 1С:Конвертация данных Бесплатно (free)

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

15.06.2020    8392    Drivingblind    10    

Конвертация данных 2.1. Методика переноса остатков

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Бесплатно (free)

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

12.06.2020    19546    aximo    22    

Лайфхаки конвертации данных 2.1

Обмен между базами 1C Платформа 1С v8.3 1С:Конвертация данных Россия Бесплатно (free)

В данной статье будут рассмотрены десять приемов работы с конвертацией данных 2.1. Указанные приемы явно не описываются в документации (справке), но их полезно знать и применять. Для наглядности приёмы работы сопровождаются описанием реализации и практическими примерами.

07.06.2020    22475    Shining_ninja    13    

Приемы обработки больших данных в 1С Промо

Универсальные обработки Математика и алгоритмы Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассказ об эффективных приемах организации обработок больших объемов данных на платформе 1С

07.08.2015    74252    tormozit    29    

Как мы РИБ на веб-сервисы переводили

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Решение проблем обмена РИБ с 10+ баз с помощью веб-сервисов и базы обмена.

13.05.2020    6588    RSConsulting    22    

Механизм XDTO

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

12.05.2020    8035    totchaz    4    

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

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

26.04.2020    7417    RPGrigorev    0    

Механизмы проведения документов при обмене по универсальному формату

Обмен между базами 1C БСП (Библиотека стандартных подсистем) Платформа 1С v8.3 Бесплатно (free)

Как проводятся документы при обмене по универсальному формату. Пример доработки типовых правил обмена с переносом состояния документа: проведен/не поведен/пометка удаления.

04.03.2020    8177    partizand    7    

Установка расширений конфигурации, модифицирующих структуры данных, в фоновом задании запрещена

Обмен между базами 1C Платформа 1С v8.3 Бесплатно (free)

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

20.02.2020    5784    fristaller    7    

Отладка правил обмена 7.7, 8 Промо

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Конвертация данных Бесплатно (free)

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

29.10.2013    53753    pyrkin_vanya    71    

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

Обмен между базами 1C Платформа 1С v8.3 1С:Документооборот 1С:ERP Управление предприятием 2 Бесплатно (free)

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

24.01.2020    8633    e-9    8    

Как сделать обмен данными через универсальный формат быстрее? Реализация многопоточного обмена данными

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

31.12.2019    10947    ids79    17    

Заметки по Конвертации данных 3.0

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Написал небольшие заметки по конвертации данных 3.0.

18.11.2019    26256    John_d    20    

Кэширование COM-соединения. Три способа Промо

Внешние источники данных WEB-интеграция Обмен между базами 1C Платформа 1С v8.3 Россия Бесплатно (free)

Статья о трех способах кэширования COM-соединения в 1С:Предприятии 8.x.

11.04.2013    44384    Infostart    42    

Обсудим планы обмена. Способы регистрации объектов к обмену

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

16.11.2019    66301    aximo    47    

Простой пример кода для работы с переносом данных (ЗУП)

Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

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

13.11.2019    5650    aaguselnikova    4    

Конвертация ставок НДС: из Перечисления в Справочник (правила обмена в конвертации 2.0)

Обмен между базами 1C Платформа 1С v8.3 1С:Конвертация данных Россия НДС Бесплатно (free)

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

09.11.2019    10698    vikulinamari    8    

Обмен по расписанию типовыми средствами. Промо

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Часто перед интеграторами стоит задача организовать автообмен (по расписанию или при наступлении какого-либо события) данными между различными конфигурациями. В этой статье я попробую изложить простую инструкцию, как это можно сделать средствами, заложенными в типовые конфигурации 1С (ЗУП, БП, УПП и т.д.). Для обмена используется подсистема "Обмен данными" из БСП

20.06.2012    107822    kser87    52    

И снова "Конфигурация узла распределенной ИБ не соответствует ожидаемой"

Обмен между базами 1C Платформа 1С v8.3 Бесплатно (free)

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

05.11.2019    7712    Kobra_RU    11    

Конвертация данных из 1С 8.3 в 7.7 (версия КД 2.1). Перенос данных из 8.3 в 7.7. Создание в современной 1С 8.3 XML в формате КД2. Инструкции и примеры переноса данных из любой современной 1С 8.3 в устаревшую конфигурацию 1С 7.7, через Конвертацию данных 2

Обмен между базами 1C Платформа 1С v7.7 Платформа 1С v8.3 1С:Конвертация данных Бесплатно (free)

При переходе на новую версию 1С в период параллельной эксплуатации может возникнуть необходимость обратной конвертации данных (по правилам КД версии 2.1) из 1С:Предприятие 8.3 в 1С:Предприятие 7.7 для переноса данных из 1С:Предприятие 8.3 в 7.7. Сделать это поможет следующая инструкция по КД2 о том, как создать новую конвертацию из 8.3 в 7.7, сохранить модуль и правила загрузки данных, сделать загрузку данных. КД2.

17.10.2019    11787    ksnik    0    

Объединение организаций в ЗУП при реорганизации с переносом данных из ЗУП 2.5 в ЗУП 3.1

Зарплата Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 2.5 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Бесплатно (free)

В этой статье описан опыт объединения 2-х организаций при реорганизации в ЗУП 3.1 с переносом данных одной организации из ЗУП 2.5 (релизы баз более или менее свежие, но не самые последние на момент перехода, примерно двух- и трехмесячной давности). За основу было взято решение из этой статьи https://infostart.ru/public/833658/, в которой описан алгоритм решения задачи, за что автору статьи огромная благодарность! Здесь же даны некоторые комментарии и пояснения к алгоритму переноса и объединения, описаны выявленные мною ошибки. Также приведена небольшая инструкция по использованию обработки ирПодборИОбработкаОбъектовБД — она будет полезна для пользователей — «не программистов», впервые работающих в не управляемых формах.

09.10.2019    10440    Neti    2    

EnterpriseData: простой способ защиты данных в базе получателя при одностороннем обмене

Обмен между базами 1C Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Очень часто бухгалтеры ругаются, когда уже отраженные документы в бухгалтерском учета меняются сотрудниками.

04.10.2019    8642    handscenter    12    

Дозагрузка измененных данных при помощи КД2

Обмен между базами 1C Платформа 1С v8.3 Россия Бесплатно (free)

Иногда во время каких-то регламентных действий по обслуживанию базы(например, при обновлении измененной базы на много релизов) требуется обеспечить бесперебойность работы пользователей. Если конфигурации баз до и после идентичны, то тут сам Бог велел воспользоваться обработкой "ВыгрузкаЗагрузкаДанныхXML", либо такой же но с отбором(на Инфостарте есть такая). Но что если конфигурации баз различаются/значительно различаются? Ниже опишу, как вышел из положения я.

12.09.2019    5700    al_zzz    2    

Конвертация Данных. Нюансы использования конструкции "НеЗамещатьОбъект = Истина" в обработчике события "ПриЗагрузке"

Обмен между базами 1C Платформа 1С v8.3 1С:Конвертация данных Бесплатно (free)

У конвертации данных есть «особенности», которые «пьют кровь» программистов. Эта статья про очередную обнаруженную «особенность».

10.09.2019    14862    ivanek    25