Вход | Регистрация
    1  2
1С:Предприятие :: 1С:Предприятие 8 общая

Web-сервисы, как передать только изменения данных

Web-сервисы, как передать только изменения данных
Я
   Антиквар
 
10.09.21 - 01:19
Всем привет!
Есть задача: синхронизация данных 1С и внешней системы (не 1С). Нужен двухсторонний обмен.
Причем 1С должна передавать только изменения данных. Т.е. если 1С передала контрагента, то в следующий раз нужно передать его во внешнюю систему только в том случае, если у контрагента что-то поменялось, какой-то реквизит.
Была мысль сделать план обмена, реализовать нужную регистрацию изменений объектов, анализировать изменения и выгружать их в какой-то файл или напрямую во внешнюю систему (есть описания таблиц SQL внешней системы, т.е. можно напрямую пихать туда данные).
Но все сейчас говорят про веб-сервисы. Мол их очень удобно использовать как раз для задач синхронизации с внешними системами, к тому же это безопасно, потому что нет прямых подключений к внешним базам, и наоборот, в твою базу никто не лазает. В общем это сейчас очень популярно, и главное, как я понял, очень правильно. Хочется попробовать и научиться этому.
Я только начинаю в этом разбираться, но пока не могу понять, реализуема ли моя задача через веб-сервисы в принципе?
Пока всё что я понял - это возможность публикации определенных методов, которые клиент будет вызывать, получая мои данные. Либо наоборот, изменять мои данные.
Но как сделать, чтобы клиент получал только изменения данных? Т.е. тут в любом случае получается связка "План обмена + Web-сервисы"? Без плана обмена не обойтись? Т.е. в методах нужно просто через план обмена получать изменения?
И небольшая путаница с веб-сервисами, ибо в 1С они разделяются на http-сервисы и собственно на веб-сервисы. Первые для меня понятнее, тем более что я как клиент уже использовал их, забирал данные с различных площадок через опубликованные API. Но что лучше в моем случае...
Просьба поделиться соображениями, что в моем случае лучше использовать, в какую сторону мне копать.
   Kassern
 
101 - 10.09.21 - 11:45
(96) сервис на стороне 1с удобен например для корзины, к примеру перед оплатой сайт постучался в 1с и убедился что товар есть в наличие и дал оплатить онлайн. А если же речь о получении заказов, то 1ска сама может по крону спрашивать у сайта, а есть ли для меня заказики и загружать если есть. Смысл для этого поднимать сервис со стороны 1с, чтобы сайт пихал заказ сразу как создался, эти 3 мин в большинстве случаев роли не играют.
   Kassern
 
102 - 10.09.21 - 11:46
(101) опять же надо понимать какая нагрузка будет на 1с в этом случае. К примеру тысячи клиентов начнут по 100 раз запрашивать статусы заказов, данные по скидкам/товарам и т.д. и дергать 1ску.
   Антиквар
 
103 - 10.09.21 - 11:47
(99) ясно. Просто пока не очень понимаю как реализуется.
(100) нет-нет, это реальность)
   Антиквар
 
104 - 10.09.21 - 11:50
(102) у нас не торговля. Синхронизация будет по расписанию. Т.е. неожиданно никто не начнет дергать. Дергать будет внешняя система, по расписанию, определенный набор объектов, каждый раз разный (в течении дня)
   Kassern
 
105 - 10.09.21 - 11:50
(103) в веб сервис ты можешь постучаться с целью выплюнуть данные, или наоборот - запросить. Вот тебе и двухсторонний обмен.
   Kassern
 
106 - 10.09.21 - 11:50
(104) я прост общую логику расписал с примерами, когда сервис удобен со стороны 1с.
   Василий Алибабаевич
 
107 - 10.09.21 - 11:51
(103) У сервиса есть входные параметры (как минимум данные авторизации) и может возвращать какие-то ответы. Все. Этого достаточно.
Например запрос за цены - на входе коды номенклатуры и тип цен, на выходе - табличка цен.
Запрос на создание заказа - на входе код покупателя и табличка заказа. На выходе - табличка резервов. (Ну это так... Пример)
   Garykom
 
108 - 10.09.21 - 11:52
(104) дык опубликуй из 1С http сервис, стандартную ODATA или свое и пусть "Дергать будет внешняя система, по расписанию"
   Василий Алибабаевич
 
109 - 10.09.21 - 11:54
В общем то все уже обозначено. Осталось ТС определиться с тем что он будет пытаться реализовать.
Я - за ПланыОбмена + http сервис на стороне 1С.
   Garykom
 
110 - 10.09.21 - 11:59
   Kassern
 
111 - 10.09.21 - 12:00
(109) я за планы обмена и http сервис со стороны сайта)
   Garykom
 
112 - 10.09.21 - 12:05
(111) в некоторых случаях напрямую в sql базу 1С
   BeerHelpsMeWin
 
113 - 10.09.21 - 12:12
(109) а я за планы обмена + выгрузка во внешний источник
   fisher
 
114 - 10.09.21 - 12:17
(104) А почему дергать должна внешняя система, если регламент? Дергай из 1С по регламенту - тогда и http-сервис не нужен будет на стороне 1С.
   fisher
 
115 - 10.09.21 - 12:21
(104) Раз у тебя на той стороне такие умельцы, то пусть все сами и сделают. Скажи им что сумеешь по регламенту дергать ихний rest и засылать им json с примитивными типами. А дальше они сами все разрулят и дадут тебе протокол с форматами. И ты просто будешь через http-соединение работать как им надо.
   rsv
 
116 - 10.09.21 - 12:24
(115) а те умельцы ждут умельцев на 1с . Кто кого переждет.
   rsv
 
117 - 10.09.21 - 12:25
А в финале “ а это ваш сервис такой … :)
   Garykom
 
118 - 10.09.21 - 12:26
"трансграничная передача данных"
   rsv
 
119 - 10.09.21 - 12:39
(0) пусть внешники ваяют на свой стороне все.
Вы дергайте и …. Оперативно тикет во внешний хелп - сервис не доступен просьба разобраться.
   Антиквар
 
120 - 10.09.21 - 12:42
(105) "в веб сервис ты можешь постучаться с целью выплюнуть данные, или наоборот - запросить. Вот тебе и двухсторонний обмен."
Т.е. если делаем один http-сервис, допустим на стороне 1С, то это значит, что внешняя система будет запускать методы сервиса для получения данных из 1С. А если нужно наоборот, получить данные из внешней системы в 1С, то опять же внешняя система будет запускать методы сервиса 1С, которые что-то пишут в базу 1С, передавая в эти методы какие-то объемы данных. Так?
   Kassern
 
121 - 10.09.21 - 13:51
(120) к примеру у вас поднят сервис СожриФайл, сайт стукнет гет запросом в 1ску, та возьмет и проверит определенный каталог, если там есть файлы, то сожрет их. Либо поднять POST метод, тогда сайт будет в тушке запроса пихать данные, а 1ска загружать из нее и отвечать, мол спс было вкусно.
   Kassern
 
122 - 10.09.21 - 13:52
(121) на я бы все же эту головную боль переложил на сайт, а 1ска пущай регламенты юзает.
   Антиквар
 
123 - 10.09.21 - 15:44
в общем решили, что будет брокер сообщений. Только хотят не RabbitMQ, а Кафку.
Знаю, что крутая штука, но как 1С с ней общается пока не ясно.
   fisher
 
124 - 10.09.21 - 16:08
Да. Без брокера тут не обойтись. Побольше middleware, нужных и не очень. Нужно же что-то админить.
   Kassern
 
125 - 10.09.21 - 16:18
(123) а много будет систем для обмена? Сколько примерно сообщений в день? А то может получиться, что все эти брокеры будут выглядеть, как С-300 против мухи)
   Garykom
 
126 - 10.09.21 - 16:20
(124) угу и ВК добавить обязательно для работы с брокером
   fisher
 
127 - 10.09.21 - 16:24
Не, ну если у них kafka уже юзается в качестве эдакой корпоративной шины, тогда может и норм.
   fisher
 
128 - 10.09.21 - 16:32
Просто обмен через брокера еще и больше ньюансов предполагает.
Вот запулит туда 1С свою чехарду. Считать это сразу успешной доставкой? А потом при выгребании окажется что там фигня какая-то оказалась и данные валидацию не проходят. Что дальше делать?
   Kassern
 
129 - 10.09.21 - 16:36
(128) что делать что делать, грохаешь все сообщения, шлешь полную выгрузку и ждешь еще такой подставы)
   fisher
 
130 - 10.09.21 - 16:43
Я к тому, что обмен через брокера сложнее, если все по уму делать.
 
 
   2mugik
 
131 - 10.09.21 - 16:45
(128)Если у сообщений нет адресации то нужен ли брокер? Положил в папочку - забрал.
   Kassern
 
132 - 10.09.21 - 16:56
(131) а если 2 системы принимают, то положил в 2 папочки?)
   BeerHelpsMeWin
 
133 - 10.09.21 - 17:24
(128) Тогда при обработке данных в шину валится сообщение "перешлите данные пакета Х" или "перешлите данные, начиная с пакета Х". И это сообщение надо обработать на стороне 1С.
Что такого сложного в работе с шиной?
   Garykom
 
134 - 10.09.21 - 17:30
(133) это уже RPC описываешь
   _KaA
 
135 - 10.09.21 - 18:12
(0)

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

А в целом логичнее взять БСП, забрать от туда п/с ОбменыДанными (+ обязательные подсистемы) и использовать типовой функционал, там уже есть и транспорт через WS, и через файл, и через FTP, почту...
   Антиквар
 
136 - 10.09.21 - 19:42
(127) Да, кафка для каких-то задач уже юзается, либо собираются на неё переходить. Руководство высшее ИТ-шное там уже всё решило, они за кафку.
   Антиквар
 
137 - 10.09.21 - 19:44
(125) ну вообще как я понял, главная причина - это стабильность. Типа сервис ляжет и кури бамбук. Кафка масштабируемая, производительная, безглючная) Ну и если она объединит в целом всё по компании, то наверное это всё же лучше, чем каждый сервис будет сам по себе барахтаться.
   2mugik
 
138 - 11.09.21 - 12:54
(132) тогда  можно подумать)
   MyNick
 
139 - 11.09.21 - 18:46
(0) "Если все в одной сети веб сервисы, как по мне, не нужны."
А что надо? Лампово-древний COM?
Откуда стереотипчик?
(4) "разработчики внешней базы против прямого подключения. Говорят, что это не правильно, что это прошлый век. "

Все правильно говорят. Ибо покупать мотыгу вместо мотоблока (или древние инструменты против современных) - это так себе.
Даже если площадь маленькая и "кажется что все будет на одном участке в 2 сотки".
   ДенисЧ
 
140 - 11.09.21 - 18:49
(139) Правильно. Давайте ставить кролика для передачи сообщений между двумя соседними комптютерами
   MyNick
 
141 - 11.09.21 - 19:09
(140) правильно давайте плюнем на концепцию API и будем напрямую в базы писать.
А когда контора вырастет в несколько раз и разными базами будут заниматься разные люди (команды), мы полностью все переделаем в авральном режиме (ресурсов и денег ведь докуа, да и не скучно хоть будет). И сделаем наконец так, как нужно было в самом начале.
   ДенисЧ
 
142 - 11.09.21 - 20:03
(141) А если не вырастет, а деньги уже потрачены и создано грандиозное, никому не нужное, сооружение по ГОСТ 26074-84 ?
   1CnikPetya
 
143 - 11.09.21 - 20:19
(47) Чем это отличается от варианта прямого доступа к базе SQL? OData - это не про обмены с внешними системами.
   MyNick
 
144 - 11.09.21 - 20:32
(142) веб сервисы в 1С делать проще, чем с COM и прямыми селектами ковыряться.
- делать проще
- архитектура прозрачнее
- поддержка проще
- изоляция одного от другого - меньше потенциальных багов
   MyNick
 
145 - 11.09.21 - 20:34
+(144) Даже самую малую фигню передать - лучше сразу сделать правильно.
Т.к. даже если контора не вырастет, то хотелки вырастут многократно.
И безобидный "прямой коннектор" превратится со временем в генератор проблем, который к тому же и развивать будет экспоненциально сложнее по мере роста.
А кому оно надо?
Нормально делай, нормально будет.
   acanta
 
146 - 11.09.21 - 20:36
Правильно ли я понимаю, что изменение одного реквизита контрагента (например, ИНН) не приведет к выгрузке всей связанной с контрагентом информации (т.е. будет выгружено только гуид и ИНН)?
   1CnikPetya
 
147 - 11.09.21 - 20:39
(128) Ничто не мешает настроить 2 очереди. Первая - данные от 1С к внешней системе, вторая - от внешней системы к 1С с квитанциями об успешной обработки. Но тут уже не удастся реализовать на планах обмена, так как уже 3 состояния у объекта: зарегистрирован, отправлен, получено подтверждение.
   1CnikPetya
 
148 - 11.09.21 - 20:41
(142) Что грандиозного в обычном REST или SOAP API? Нет в инфраструктуре шины или брокера и нет уверенности ,то он будет нужен - ну и не надо его вводить. А простые API - это нормально. COM и прямой доступ к БД - это дно.
   ДенисЧ
 
149 - 11.09.21 - 20:52
(148) Что днового в обычном COM-соединении?
   acanta
 
150 - 11.09.21 - 20:56
(149) долго устанавливается и отваливается по истечении определенного интервала.
   1CnikPetya
 
151 - 11.09.21 - 20:58
(149)
1. Работа COM сильно зависит от окружения. REST или SOAP API универсальны и стабильны.
2. Если для COM-соединения не написан программный интерфейс в приемнике (а если выбрали COM для новой интеграции, то его, скорее всего, не будет), то имеем все риски после обновления нарваться на ошибки, связанные с изменением методов. И система приемник может даже не знать, что ее изменения что-то сломают. REST и SOAP API в этой части намного прозрачнее.
3. COM - это медленно и ресурсоемко.
   acanta
 
152 - 11.09.21 - 21:05
Вопрос был что вместо COM без шлюза в интернете в качестве сервера для обмена между двумя базами на одном носителе с тем же интерфейсом что и для разных компов в локальной сети?
   Megas
 
153 - 11.09.21 - 21:32
Офигеть
Казалось бы простейший вопрос и столько обсуждений.
План обмена + шареная папка в сети + там две папки inbox и outbox + файлы json с именем дата в формате ddmmyyyyhhMMss_guid.json - всё! файл загрузил и положил в архивю
   Megas
 
154 - 11.09.21 - 21:37
(149) Это прям вопрос на собеседование =)
Уже выше писал несколько минусов прямых подключений. Это я ещё забыл проблемы с отладкой.
Самое простое: Если приёмник "Лежит" - у тебя копится очередь - это как минимум.

Проще файлами на шару.
   acanta
 
155 - 11.09.21 - 21:40
То есть, папка с файлами с некоторых пор надёжнее чем РИБ.
   acanta
 
156 - 11.09.21 - 21:43
А есть в типовых конфигурациях механизм создания периферийной риб с определенной даты?
   Megas
 
157 - 11.09.21 - 21:48
(155)
Сам Риб не делал, но других обменов делал очень много
Я чё то запутался, РИБ же вроде тоже через папку с файлами делается?
   acanta
 
158 - 11.09.21 - 21:55
(157)Да, но в риб должно без получения подтверждения выгружаться повторно, а без риб выгрузка изменений однократная, по событию.
   Антиквар
 
159 - 12.09.21 - 00:41
(141) "А когда контора вырастет в несколько раз и разными базами будут заниматься разные люди (команды) ..."

У нас уже всё так)
Контора очень большая, во многих регионах, 20 тысяч сотрудников.
Много команд разработчиков под разные системы.
   Garykom
 
160 - 12.09.21 - 00:52
(153) Вариант неплохой только тем что достаточно быстро переделывается на http/rest или брокер
 
 
   ДедМорроз
 
161 - 12.09.21 - 08:17
Если хочется надежную систему,то передачу данных нужно отделить от момента изменения данных,а в изменении просто регистрировать объект к обмену.
Есть такая вещь - правила регистрации объектов в стандартной КД,очень удобно,если можно использовать их.

Если хочется,то можно и свой велосипед,например регистр,где будет ссылка на объект и хэш от его передаваемых полей, если хэш поменялся,то объект нужно отправить.
Только хэш можно рассчитывать или при записи или уже при отправке - это определяется требованием к производительности.
Если,например,из номенклатуры передается несколько полей,а записывается она часто,то каждый раз при записи считать хэш смысла нет - просто регистрируем к отправке,а вот при отправке считаем хэш,и если он поменялся,то отправляем.
   ДедМорроз
 
162 - 12.09.21 - 08:20
И еще раз,не стоит при проектировании обмена на транспорт закладываться.
От транспорта требуется наличие интерфейса к каналу с определенным набором функций,позволяющих отправить пакет,проверить наличие пакета в канале,получить пакет и подтвердить получение пакета из канала (удалить его) тогда потом можно работать в любом режиме и через что угодно.
   ДедМорроз
 
163 - 12.09.21 - 08:25
Ну и формат файла двнных не важен - есть только два формата:
Файлы с последовательным доступом (txt,json,xml и т.п.)
Файлы с произвольным доступом (dbf,pdf и т.п.)
Для передачи данных файлы с произвольным доступом преимущество не дают,т.к.все равно читаются все данные,поэтому,формат может быть любой,если грамотно написаны функции помещения объекта в файл и чтение объекта обратно,то никаких проблем.
   novichok79
 
164 - 12.09.21 - 10:09
Это ж очевидно, вам нужна событийная архитектура, делаете обмен через очередь сообщений на ваш вкус. Однако, если нужна синхронность в обеих системах, то тут без REST никак.
   Garykom
 
165 - 12.09.21 - 10:20
(164) кроме REST есть куча других методик
например gRPC прекрасный штук
   novichok79
 
166 - 12.09.21 - 10:26
Grpc из 1с? 1c может в HTTP/2?
   Garykom
 
167 - 12.09.21 - 10:29
(166) gRPC и без HTTP/2 пашет
через ВК вполне можно
   novichok79
 
168 - 12.09.21 - 10:32
Тут основной вопрос в синхронности - если нужна можно любой синхронный способ, если нет - очередь. Не представляю как в 1с писать protobuf и использовать кодогенерацию для gRPC.
   Антиквар
 
169 - 12.09.21 - 21:45
(161) очень разумно на  счет хэша, спасибо
   Антиквар
 
170 - 12.09.21 - 21:50
(164) это пока не очень понимаю. REST-интерфейс, как я понял, слегка ограничивает возможности HTTP-сервиса. Если речь о протоколе OData
   fisher
 
171 - 13.09.21 - 09:24
(137) Тут стандартный trade-off синхронность vs асинхронность. Асинхронность теоретически прикольнее, но она небесплатна. И надо понимать, когда она хорошо окупается, а когда не окупается вообще. В твоей ситуации на первый взгляд она окупается плохо. Но я не знаю всех деталей и могу ошибаться.
(169) Не надо хэш. В том смысле, что хранить его не надо и именно хэш нет необходимости вычислять. Нужен обычный план обмена, только с отключенной автоматической регистрацией. А в перед записью объектов сравниваешь новые данные объекта с хранящимися в БД. И если эти изменения критичны с точки зрения внешней системы - тогда разрешаешь регистрацию изменения к обмену (добавляешь нужные узлы в ОбменДанными.Получатели).
   Kassern
 
172 - 13.09.21 - 09:31
(171) А что в плане производительности? Реализовывали уже такую штуку в нагруженной базе, где тысячами документов в день регистрируют? Так же надо где то структуру проверяемых реквизитов хранить еще и в разрезе объектов, чтобы не по всем проверять.
   fisher
 
173 - 13.09.21 - 09:35
(172) Типа еще один простой запросик в перед записью станет бутылочным горлышком интегральной производительности? Пфффф.
   Антиквар
 
174 - 14.09.21 - 12:26
(126) "угу и ВК добавить обязательно для работы с брокером"
Да, ВК для кафки нужна, и походу она только одна существует, и стоит очень дорого...
А через REST с кафкой нельзя работать? Ну т.е. как я это представляю, дергать её API-методы, через http-запросы...
   Garykom
 
175 - 14.09.21 - 12:58
(174) можно все
и ВК на заказ и через REST с чем угодно, если нельзя напрямую то через прокладку микросервис
   Я_в_каске
 
176 - 14.09.21 - 15:07
На стороне 1С реализуйте как вам нравится, на стороне сайта не ваша проблема. Логично что там API и вам все на блюдечке преподнесли, что туда отправлять. С вашей стороны WEB сервисы для получения данных с сайта. Настройка регистра сведений отправки изменений или план обмена, это ваше решение. Не думаю , что у вас там мега объемы данных, чтобы обсуждать всякие сложности.
   Антиквар
 
177 - 14.09.21 - 18:40
(176) У нас мегаобъемы данных)
И уже решено кафку. Решение свыше, не обсуждается. Но оно обдуманное, кафка уже есть в организации, в ней море разных сервисов крутится. Нет там только 1С пока)
   novichok79
 
178 - 19.09.21 - 11:14
(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.
   novichok79
 
179 - 19.09.21 - 11:15
(178) компонента медленной оказалась очень, возможно где-то нужно было подергать "правильные" ручки, но как и написал выше - "неасилил"
   dmitryds
 
180 - 19.09.21 - 17:41
-


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


-

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

_
   novichok79
 
181 - 19.09.21 - 18:48
(181) это нормально для мисты, было бы странно, если бы ответили сразу ))
   Антиквар
 
182 - 20.09.21 - 23:42
(178) "По какому-нибудь стандартному заголовку - типа "type" загружаете сущности в БД через обработчики завязанные на этот type."
Не понял этого, можно поподробнее?
   серый КТУЛХУ
 
183 - 21.09.21 - 00:49
ну и web-сервисы - это уже давно не "новое" и не такое уж и "удобное".
сейчас более в ходу и востребованы и безглючны и быстры http-сервисы.
   novichok79
 
184 - 21.09.21 - 18:50
(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"}}
]

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

Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.