Z-Integrator: интеграция с 1С на уровне данных

12 Comments

1. ifal 23.10.2016 at 15:20

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

   Reply ↓
2. zhichkin 23.10.2016 at 16:10

   (1) ifal,
   
   Реализована следующая стратегия разрешения коллизий:

   1. Всегда применяется правило «кто последний, тот и выиграл». То есть, если в базу приёмник приходит сообщение обновления, то версия записи в приёмнике не анализируется, она просто перезаписывается. Таким образом считается, что источник всегда последний и он всегда прав. Какой из узлов обмена А или В в данный момент является источником или приёмником определяется по направлению движения для конкретного сообщения обмена, которое обрабатывается в данный момент времени. Если сообщение движется из А в В, то А — это источник, а В — приёмник и, соответственно, наоборот.

   2. Если из источника в приёмник приходит сообщение вставки новой записи (insert), а в приёмнике запись с такими ключевыми полями уже есть, то источник снова считается последним и, соответственно, победителем в разрешении коллизии — insert превращается в update. Такая ситуация может возникнуть, например, тогда, когда в приёмнике завели цену в регистр сведений «Цены номенклатуры», а в источнике тоже завели по тем же ключевым значениям (новым в этом момент для источника) цену. В приёмник «летит» insert, но там уже есть такая запись — ошибка дублирования ключа превращается в обновление.

   3. Если из источника в приёмник «летит» update, но там нет такой записи, например её удалили или её там вообще никогда не существовало (такую коллизию называют update-delete), то update превращается в insert — запись успешно добавляется в приёмник.
   

   Reply ↓
3. zhichkin 23.10.2016 at 16:16

   (1) ifal,
   
   Правила разрешения коллизий бывают очень сложными. Зачастую они сильно зависят от бизнес-логики прикладного решения. В каждом случае нужно разбираться отдельно. Предложения по добавлению настроек какой-то более или менее типовой логики разрешения коллизий приветствуются =)

   Reply ↓
4. unpete 24.10.2016 at 09:47

   (0), Изобретение велосипедов — деятельность вполне достойная. Зачастую — необходимая.
   
   Без этого сложно понять условия задачи и математику альтернативных решений, но зачем результаты лабораторной работы помещать в production?
   
   Почитайте про репликацию couchdb — это позволить направить вашу энергию в мирное русло.
   
   В 2014-15 годах, я потратил более 2 тыс. человекочасов на собственный движок обмена, но познакомившись с couchdb — выкинул бОльшую часть проделанной работы на помойку, задействовав простые, изящные и современные технологии.

   Reply ↓
5. Константин С. 24.10.2016 at 10:20

   (бесплатная версия для ознакомления)

   Вот интересно было узнать, цену вопроса не для ознакомления)

   А то от количества нулей можно !!!!

   Reply ↓
6. zhichkin 24.10.2016 at 12:02

   (5) Константин С.,
   
   Выпуска платной версии не планируется. Планируется создание более или менее удобного инструмента для реализации проектов по интеграции на стыке технологий 1С:Предприятие 8 + .NET Framework (C#) + MS SQL Server. В том числе с учётом SOA (service-oriented architecture). Соответственно ответ такой: присылайте свои требования по проекту — дам оценку.

   Reply ↓
7. zhichkin 24.10.2016 at 12:09

   (4) unpete,
   
   Я прошу прощения, но я совсем не понял Ваш комментарий. PR couchdb ? Сравнение тёплого с мягким ? По моему упоминание SQL Server Integration Services было бы более к месту. Кроме того, моя публикация больше про интеграцию, чем про репликацию.

   Reply ↓
8. artbear 02.11.2016 at 19:55

   Подписался

   Reply ↓
9. maratimus 30.11.2016 at 23:19

   А есть такая же, но сделанная по технологии «Temporal Tables», а не «Change Tracking»?

   Reply ↓
10. zhichkin 01.12.2016 at 00:44

    (9) Какой у Вас use case ?
    
    Мне кажется, что именно для обмена данными temporal tables … как узнавать что данные по строке изменились ? Запрашивать все строки таблицы на предмет наличия версий в исторической таблице ? Тяжёлый может быть запрос …
    
    Или есть какой-то простой и достаточно лёгкий способ получить именно изменённые на какой-то момент времени строки ?

    Reply ↓
11. JohnnySE 15.01.2017 at 02:06

    Приветствую.
    
    1. Не удобно проставлять соответствия между источником и приемником.
    
    2. Нет четкого описания, что делать приперед обновлением конфигурации
    
    3. ОСНОВНОЕ: как настраивать фильтрацию для выгрузкизагрузки.

    С уважением.

    Reply ↓
12. zhichkin 15.01.2017 at 18:47

    (11) Огромное спасибо за конструктивную критику!

    Reply ↓