Всем привет!
Есть задача: синхронизация данных 1С и внешней системы (не 1С). Нужен двухсторонний обмен.
Причем 1С должна передавать только изменения данных. Т.е. если 1С передала контрагента, то в следующий раз нужно передать его во внешнюю систему только в том случае, если у контрагента что-то поменялось, какой-то реквизит.
Была мысль сделать план обмена, реализовать нужную регистрацию изменений объектов, анализировать изменения и выгружать их в какой-то файл или напрямую во внешнюю систему (есть описания таблиц SQL внешней системы, т.е. можно напрямую пихать туда данные).
Но все сейчас говорят про веб-сервисы. Мол их очень удобно использовать как раз для задач синхронизации с внешними системами, к тому же это безопасно, потому что нет прямых подключений к внешним базам, и наоборот, в твою базу никто не лазает. В общем это сейчас очень популярно, и главное, как я понял, очень правильно. Хочется попробовать и научиться этому.
Я только начинаю в этом разбираться, но пока не могу понять, реализуема ли моя задача через веб-сервисы в принципе?
Пока всё что я понял - это возможность публикации определенных методов, которые клиент будет вызывать, получая мои данные. Либо наоборот, изменять мои данные.
Но как сделать, чтобы клиент получал только изменения данных? Т.е. тут в любом случае получается связка "План обмена + Web-сервисы"? Без плана обмена не обойтись? Т.е. в методах нужно просто через план обмена получать изменения?
И небольшая путаница с веб-сервисами, ибо в 1С они разделяются на http-сервисы и собственно на веб-сервисы. Первые для меня понятнее, тем более что я как клиент уже использовал их, забирал данные с различных площадок через опубликованные API. Но что лучше в моем случае...
Просьба поделиться соображениями, что в моем случае лучше использовать, в какую сторону мне копать.

(82) я это и имел ввиду, обмен из 1С во внешку подразумевает, что 1С выкладывает, а внешка стучится и забирает

(84) Да. Но и обратно тоже будет, пока просто непонятно какой объем информации на какой стороне будет вестись.

(78) Ну так - то да.

(81) почему?

(83) это НСИ и документы
Их надо будет как то синхронизировать по неким ID, кодам (уид) или наборам признаков-реквизитов

(89) https://infostart.ru/1c/articles/792952/

(85) а учет где будет основной вестись? Если в 1с, то поидее 1ска должна руководить обменом, отдавать, как ввелись данные, и периодически стучатся, забирая данные с сайта.

(89) всё по ГУИД. Сложнее только с регистрами сведений

(80) "Т.е. мы должны опубликовать сервис. Ну и от них тоже будет" А вот это вот плохая идея.
Сервис должен быть один и на одной стороне. А другая сторона будет либо забирать с этого сервиса свои данные или отдавать.

(91) основной учет в 1С

(92) если один вид сущности вводится в разных системах то дубли неизбежны

(93) тут пока не понимаю. Если обмен двухсторонний, то всё-равно должен быть один сервис???

(93) а пойдет это по сценарию …. Сервисов на 1с по причине «там все есть»

(95) это исключено. Источник данных всегда один

(96) достаточно одного сервиса который умеет и туды и сюды
второй лишний

(98) это фантастика и сказки

(96) сервис на стороне 1с удобен например для корзины, к примеру перед оплатой сайт постучался в 1с и убедился что товар есть в наличие и дал оплатить онлайн. А если же речь о получении заказов, то 1ска сама может по крону спрашивать у сайта, а есть ли для меня заказики и загружать если есть. Смысл для этого поднимать сервис со стороны 1с, чтобы сайт пихал заказ сразу как создался, эти 3 мин в большинстве случаев роли не играют.

(101) опять же надо понимать какая нагрузка будет на 1с в этом случае. К примеру тысячи клиентов начнут по 100 раз запрашивать статусы заказов, данные по скидкам/товарам и т.д. и дергать 1ску.

(99) ясно. Просто пока не очень понимаю как реализуется.
(100) нет-нет, это реальность)

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

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

(104) я прост общую логику расписал с примерами, когда сервис удобен со стороны 1с.

(103) У сервиса есть входные параметры (как минимум данные авторизации) и может возвращать какие-то ответы. Все. Этого достаточно.
Например запрос за цены - на входе коды номенклатуры и тип цен, на выходе - табличка цен.
Запрос на создание заказа - на входе код покупателя и табличка заказа. На выходе - табличка резервов. (Ну это так... Пример)

(104) дык опубликуй из 1С http сервис, стандартную ODATA или свое и пусть "Дергать будет внешняя система, по расписанию"

В общем то все уже обозначено. Осталось ТС определиться с тем что он будет пытаться реализовать.
Я - за ПланыОбмена + http сервис на стороне 1С.

https://infostart.ru/1c/articles/899200/

(109) я за планы обмена и http сервис со стороны сайта)

(111) в некоторых случаях напрямую в sql базу 1С

(109) а я за планы обмена + выгрузка во внешний источник

(104) А почему дергать должна внешняя система, если регламент? Дергай из 1С по регламенту - тогда и http-сервис не нужен будет на стороне 1С.

(104) Раз у тебя на той стороне такие умельцы, то пусть все сами и сделают. Скажи им что сумеешь по регламенту дергать ихний rest и засылать им json с примитивными типами. А дальше они сами все разрулят и дадут тебе протокол с форматами. И ты просто будешь через http-соединение работать как им надо.

(115) а те умельцы ждут умельцев на 1с . Кто кого переждет.

А в финале “ а это ваш сервис такой … :)

"трансграничная передача данных"

(0) пусть внешники ваяют на свой стороне все.
Вы дергайте и …. Оперативно тикет во внешний хелп - сервис не доступен просьба разобраться.

(105) "в веб сервис ты можешь постучаться с целью выплюнуть данные, или наоборот - запросить. Вот тебе и двухсторонний обмен."
Т.е. если делаем один http-сервис, допустим на стороне 1С, то это значит, что внешняя система будет запускать методы сервиса для получения данных из 1С. А если нужно наоборот, получить данные из внешней системы в 1С, то опять же внешняя система будет запускать методы сервиса 1С, которые что-то пишут в базу 1С, передавая в эти методы какие-то объемы данных. Так?

(120) к примеру у вас поднят сервис СожриФайл, сайт стукнет гет запросом в 1ску, та возьмет и проверит определенный каталог, если там есть файлы, то сожрет их. Либо поднять POST метод, тогда сайт будет в тушке запроса пихать данные, а 1ска загружать из нее и отвечать, мол спс было вкусно.

(121) на я бы все же эту головную боль переложил на сайт, а 1ска пущай регламенты юзает.

в общем решили, что будет брокер сообщений. Только хотят не RabbitMQ, а Кафку.
Знаю, что крутая штука, но как 1С с ней общается пока не ясно.

Да. Без брокера тут не обойтись. Побольше middleware, нужных и не очень. Нужно же что-то админить.

(123) а много будет систем для обмена? Сколько примерно сообщений в день? А то может получиться, что все эти брокеры будут выглядеть, как С-300 против мухи)

(124) угу и ВК добавить обязательно для работы с брокером

Не, ну если у них kafka уже юзается в качестве эдакой корпоративной шины, тогда может и норм.

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

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

Я к тому, что обмен через брокера сложнее, если все по уму делать.

(128)Если у сообщений нет адресации то нужен ли брокер? Положил в папочку - забрал.

(131) а если 2 системы принимают, то положил в 2 папочки?)

(128) Тогда при обработке данных в шину валится сообщение "перешлите данные пакета Х" или "перешлите данные, начиная с пакета Х". И это сообщение надо обработать на стороне 1С.
Что такого сложного в работе с шиной?

(133) это уже RPC описываешь

(0)

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

А в целом логичнее взять БСП, забрать от туда п/с ОбменыДанными (+ обязательные подсистемы) и использовать типовой функционал, там уже есть и транспорт через WS, и через файл, и через FTP, почту...

(127) Да, кафка для каких-то задач уже юзается, либо собираются на неё переходить. Руководство высшее ИТ-шное там уже всё решило, они за кафку.

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

(132) тогда  можно подумать)

(0) "Если все в одной сети веб сервисы, как по мне, не нужны."
А что надо? Лампово-древний COM?
Откуда стереотипчик?

(4) "разработчики внешней базы против прямого подключения. Говорят, что это не правильно, что это прошлый век. "
Все правильно говорят. Ибо покупать мотыгу вместо мотоблока (или древние инструменты против современных) - это так себе.
Даже если площадь маленькая и "кажется что все будет на одном участке в 2 сотки".

(139) Правильно. Давайте ставить кролика для передачи сообщений между двумя соседними комптютерами

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

(141) А если не вырастет, а деньги уже потрачены и создано грандиозное, никому не нужное, сооружение по ГОСТ 26074-84 ?

(47) Чем это отличается от варианта прямого доступа к базе SQL? OData - это не про обмены с внешними системами.

(142) веб сервисы в 1С делать проще, чем с COM и прямыми селектами ковыряться.
- делать проще
- архитектура прозрачнее
- поддержка проще
- изоляция одного от другого - меньше потенциальных багов

+(144) Даже самую малую фигню передать - лучше сразу сделать правильно.
Т.к. даже если контора не вырастет, то хотелки вырастут многократно.
И безобидный "прямой коннектор" превратится со временем в генератор проблем, который к тому же и развивать будет экспоненциально сложнее по мере роста.
А кому оно надо?
Нормально делай, нормально будет.

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

(128) Ничто не мешает настроить 2 очереди. Первая - данные от 1С к внешней системе, вторая - от внешней системы к 1С с квитанциями об успешной обработки. Но тут уже не удастся реализовать на планах обмена, так как уже 3 состояния у объекта: зарегистрирован, отправлен, получено подтверждение.

(142) Что грандиозного в обычном REST или SOAP API? Нет в инфраструктуре шины или брокера и нет уверенности ,то он будет нужен - ну и не надо его вводить. А простые API - это нормально. COM и прямой доступ к БД - это дно.

(148) Что днового в обычном COM-соединении?

(149) долго устанавливается и отваливается по истечении определенного интервала.

(149)
1. Работа COM сильно зависит от окружения. REST или SOAP API универсальны и стабильны.
2. Если для COM-соединения не написан программный интерфейс в приемнике (а если выбрали COM для новой интеграции, то его, скорее всего, не будет), то имеем все риски после обновления нарваться на ошибки, связанные с изменением методов. И система приемник может даже не знать, что ее изменения что-то сломают. REST и SOAP API в этой части намного прозрачнее.
3. COM - это медленно и ресурсоемко.

Вопрос был что вместо COM без шлюза в интернете в качестве сервера для обмена между двумя базами на одном носителе с тем же интерфейсом что и для разных компов в локальной сети?

Офигеть
Казалось бы простейший вопрос и столько обсуждений.
План обмена + шареная папка в сети + там две папки inbox и outbox + файлы json с именем дата в формате ddmmyyyyhhMMss_guid.json - всё! файл загрузил и положил в архивю

(149) Это прям вопрос на собеседование =)
Уже выше писал несколько минусов прямых подключений. Это я ещё забыл проблемы с отладкой.
Самое простое: Если приёмник "Лежит" - у тебя копится очередь - это как минимум.

Проще файлами на шару.

То есть, папка с файлами с некоторых пор надёжнее чем РИБ.

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

(155)
Сам Риб не делал, но других обменов делал очень много
Я чё то запутался, РИБ же вроде тоже через папку с файлами делается?

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

(141) "А когда контора вырастет в несколько раз и разными базами будут заниматься разные люди (команды) ..."

У нас уже всё так)
Контора очень большая, во многих регионах, 20 тысяч сотрудников.
Много команд разработчиков под разные системы.

(153) Вариант неплохой только тем что достаточно быстро переделывается на http/rest или брокер

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

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

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

Ну и формат файла двнных не важен - есть только два формата:
Файлы с последовательным доступом (txt,json,xml и т.п.)
Файлы с произвольным доступом (dbf,pdf и т.п.)
Для передачи данных файлы с произвольным доступом преимущество не дают,т.к.все равно читаются все данные,поэтому,формат может быть любой,если грамотно написаны функции помещения объекта в файл и чтение объекта обратно,то никаких проблем.

Это ж очевидно, вам нужна событийная архитектура, делаете обмен через очередь сообщений на ваш вкус. Однако, если нужна синхронность в обеих системах, то тут без REST никак.

(164) кроме REST есть куча других методик
например gRPC прекрасный штук

Grpc из 1с? 1c может в HTTP/2?

(166) gRPC и без HTTP/2 пашет
через ВК вполне можно

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

(161) очень разумно на  счет хэша, спасибо

(164) это пока не очень понимаю. REST-интерфейс, как я понял, слегка ограничивает возможности HTTP-сервиса. Если речь о протоколе OData

(137) Тут стандартный trade-off синхронность vs асинхронность. Асинхронность теоретически прикольнее, но она небесплатна. И надо понимать, когда она хорошо окупается, а когда не окупается вообще. В твоей ситуации на первый взгляд она окупается плохо. Но я не знаю всех деталей и могу ошибаться.
(169) Не надо хэш. В том смысле, что хранить его не надо и именно хэш нет необходимости вычислять. Нужен обычный план обмена, только с отключенной автоматической регистрацией. А в перед записью объектов сравниваешь новые данные объекта с хранящимися в БД. И если эти изменения критичны с точки зрения внешней системы - тогда разрешаешь регистрацию изменения к обмену (добавляешь нужные узлы в ОбменДанными.Получатели).

(171) А что в плане производительности? Реализовывали уже такую штуку в нагруженной базе, где тысячами документов в день регистрируют? Так же надо где то структуру проверяемых реквизитов хранить еще и в разрезе объектов, чтобы не по всем проверять.

(172) Типа еще один простой запросик в перед записью станет бутылочным горлышком интегральной производительности? Пфффф.

(126) "угу и ВК добавить обязательно для работы с брокером"
Да, ВК для кафки нужна, и походу она только одна существует, и стоит очень дорого...
А через REST с кафкой нельзя работать? Ну т.е. как я это представляю, дергать её API-методы, через http-запросы...

(174) можно все
и ВК на заказ и через REST с чем угодно, если нельзя напрямую то через прокладку микросервис

На стороне 1С реализуйте как вам нравится, на стороне сайта не ваша проблема. Логично что там API и вам все на блюдечке преподнесли, что туда отправлять. С вашей стороны WEB сервисы для получения данных с сайта. Настройка регистра сведений отправки изменений или план обмена, это ваше решение. Не думаю , что у вас там мега объемы данных, чтобы обсуждать всякие сложности.

(176) У нас мегаобъемы данных)
И уже решено кафку. Решение свыше, не обсуждается. Но оно обдуманное, кафка уже есть в организации, в ней море разных сервисов крутится. Нет там только 1С пока)

(174) Способы дергать Kafka из 1С:
1. Confluent REST Proxy - фирменный REST API, но он глючный - в одной версии норм работал, а в другой по таймауту отваливался.
2. Написать свой REST Proxy на Java, Python, Golang, you name it. Мы написали на Flask.
3. ВК от Серебрянной Пули, у меня она есть, использовал. Но видимо я "неасилил" просто.

В итоге на проде используется способ №2, я там уже не работаю, инфа может быть уже неактуальна.
RabbitMQ удобнее для 1Са, для него есть аж 2 компоненты, и одна использовалась на проде, на одном из прошлых мест работы.

В итоге реализация может быть следующей:
На стороне 1С правила обмена для каждого справочника и т. д, потом реализуете обработчики - обработчики отдают JSON без пробелов и это дело пуляется в Kafka регламентным заданием.
Обратный путь - загружаете сообщения в справочник одним заданием, обходите справочник другим.
По какому-нибудь стандартному заголовку - типа "type" загружаете сущности в БД через обработчики завязанные на этот type.

(178) компонента медленной оказалась очень, возможно где-то нужно было подергать "правильные" ручки, но как и написал выше - "неасилил"

-


НУ ВЫ БЛИН ДАЕТЕ
Столько флуда)


-

Какие веб-сервисы 1С, если 1С передает данные?
Если во внешней системе реализовано API - работать через это API - если нет, то вариантов как бы то и нет))

_

(181) это нормально для мисты, было бы странно, если бы ответили сразу ))

(178) "По какому-нибудь стандартному заголовку - типа "type" загружаете сущности в БД через обработчики завязанные на этот type."
Не понял этого, можно поподробнее?

ну и web-сервисы - это уже давно не "новое" и не такое уж и "удобное".
сейчас более в ходу и востребованы и безглючны и быстры http-сервисы.

(182) не архитектуру же мне за вас придумывать. у нас было сделано на rabbitmq и обработчиках.
в обработчиках в зависимости от отправляемых сущностей формируется json, 1 объект имеет 2 обязательных реквизита.
id, type.
id может быть null, type идетифицирует что мы посылаем.
в attributes лежат данные сущности. вот и посылаем через RabbitMQ массив сущностей в json:

"sender": "petya",
"timestamp": 123 unix time,
"data": [
{"id": 1, "type": "penoplast", "attributes": {"blaBlaBla": "BlaBla"}},
{"id": 112, "type": "sosnovyeShishki", "attributes": {"blaBlaBla1": "BlaBla1"}}
]

вот и все...
а что делать с данными решает принимающая система, ваше дело малое - пульнуть изменения