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

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

Web-сервисы, как передать только изменения данных
Я
   Антиквар
 
10.09.21 - 01:19
Всем привет!
Есть задача: синхронизация данных 1С и внешней системы (не 1С). Нужен двухсторонний обмен.
Причем 1С должна передавать только изменения данных. Т.е. если 1С передала контрагента, то в следующий раз нужно передать его во внешнюю систему только в том случае, если у контрагента что-то поменялось, какой-то реквизит.
Была мысль сделать план обмена, реализовать нужную регистрацию изменений объектов, анализировать изменения и выгружать их в какой-то файл или напрямую во внешнюю систему (есть описания таблиц SQL внешней системы, т.е. можно напрямую пихать туда данные).
Но все сейчас говорят про веб-сервисы. Мол их очень удобно использовать как раз для задач синхронизации с внешними системами, к тому же это безопасно, потому что нет прямых подключений к внешним базам, и наоборот, в твою базу никто не лазает. В общем это сейчас очень популярно, и главное, как я понял, очень правильно. Хочется попробовать и научиться этому.
Я только начинаю в этом разбираться, но пока не могу понять, реализуема ли моя задача через веб-сервисы в принципе?
Пока всё что я понял - это возможность публикации определенных методов, которые клиент будет вызывать, получая мои данные. Либо наоборот, изменять мои данные.
Но как сделать, чтобы клиент получал только изменения данных? Т.е. тут в любом случае получается связка "План обмена + Web-сервисы"? Без плана обмена не обойтись? Т.е. в методах нужно просто через план обмена получать изменения?
И небольшая путаница с веб-сервисами, ибо в 1С они разделяются на http-сервисы и собственно на веб-сервисы. Первые для меня понятнее, тем более что я как клиент уже использовал их, забирал данные с различных площадок через опубликованные API. Но что лучше в моем случае...
Просьба поделиться соображениями, что в моем случае лучше использовать, в какую сторону мне копать.
   PR
 
1 - 10.09.21 - 01:45
План обмена плюс любой транспорт, который тебе больше нравится
   2mugik
 
2 - 10.09.21 - 06:36
Если все в одной сети веб сервисы, как по мне, не нужны.
   RomaH
 
3 - 10.09.21 - 06:50
план обмена + из БСП подсистему истории данных (для регистрации только измененных)
   Антиквар
 
4 - 10.09.21 - 08:36
(1) т.е. связка План обмена плюс http-сервисы это норм?
(2) в одной сети, но разработчики внешней базы против прямого подключения. Говорят, что это не правильно, что это прошлый век. Руководство их поддерживает. А я просто плохо знаю эти механизмы веб-сервисов, чтобы дать оценку что лучше. Но если это действительно правильный подход, как везде пишут и говорят, то я тоже за то, чтобы попробовать.
(3) Не совсем понял, план обмена и так содержит регистрацию только измененных, зачем БСП?
   RomaH
 
5 - 10.09.21 - 08:39
(4) да ну?
   Megas
 
6 - 10.09.21 - 08:44
(0)
ИМХО
Прямое подключение - зло.
- Если изменилась структура таблиц - ошибка.
- Необходимо знать структуру таблиц sql и иметь прямой доступ.
- Если тупит база sql - ожидание, пока протупит.
- Если лежит база sql - ожидание пока отлежится -и у тебя копится очередь.

Http-сервисы - возможно зло.
- Если тупит сервис- ожидание, пока протупит.
- Если лежит сервис- ожидание пока отлежится -и у тебя копится очередь.


Можно выкладывать файликами на обменник ftp(в сетевую папку)
Можно поднять менеджер очередей RabbitMQ - и выкладывать туда сообщения.
   Антиквар
 
7 - 10.09.21 - 09:08
(5) Я наверное что-то не понимаю, но делал обмен между двумя 1с-ками. Есть план обмена, в нем нужные объекты метаданных. В коде регистрирую изменения только нужных элементов объектов метаданных. Они автоматически видны в обработке регистрации изменений (как-то так она называется). Т.е. все нужные измененные объекты сами автоматически попадали в регистрацию изменений. Затем правила обмена в КД написаны, по которым идет выгрузка.
Но я не работал с этим вне стандартной обработки обмена, без правил обмена. Т.е. не знаю как самому вытащить зарегистрированные измененные объекты. Но думал что это просто.
   Антиквар
 
8 - 10.09.21 - 09:16
(6) "Можно поднять менеджер очередей RabbitMQ - и выкладывать туда сообщения"
А в этом случае реализация на стороне 1С уже будет без всяких веб-сервисов?
   rsv
 
9 - 10.09.21 - 09:21
(7) таблички Изменения.  . Выбрать …
   AneJIbcuH
 
10 - 10.09.21 - 09:22
(3) Реально, зачем подсистему истории данных из БСП ?
   mikecool
 
11 - 10.09.21 - 09:22
при больших объемах изменений - планы обмена зло
   RomaH
 
12 - 10.09.21 - 09:22
(7) что ты имеешь в виду под "изменением" 
вот сколько раз пользователь изменил документ нажав на кнопки "Записать" - "Провести" - "Провести и закрыть"?
   RomaH
 
13 - 10.09.21 - 09:25
(10) ну это я загнул - там одна функция нужна - сравнение объекта со ссылкой через сериализацию
   Garykom
 
14 - 10.09.21 - 09:25
(12) 0
   RomaH
 
15 - 10.09.21 - 09:26
(14) вот - и зачем мне обмениваться этим документом?
а бывает надо перепровести ВСЕ документы
   Garykom
 
16 - 10.09.21 - 09:26
(0) Для начала уточни что значит "у контрагента что-то поменялось, какой-то реквизит"?

Его перезаписали в базу или именно поменяли реквизит? А что если поменяли на точно такой же?
   rsv
 
17 - 10.09.21 - 09:27
+(9) в идеале через файлики. Никто не отвечает .  Файлик есть - загрузил.
Все остальное - деление на зоны ответственности и поддержка доп. функционала
за теже деньги.
   Garykom
 
18 - 10.09.21 - 09:27
(15) Угу и задачка (0) становится очень нетривиальной
Особенно с перепроведением для восстановления последовательности при закрытии месяца
   Garykom
 
19 - 10.09.21 - 09:28
(17) Причем файлики отдельные по измененным объектам а не все в один пихать
Если что много файликов в один слепить не проблема
   rsv
 
20 - 10.09.21 - 09:30
(19) как они будут создаваться - дело десятое.
Лучше в екселе. Выгрузил - забыл.кто и когда заберет- неважно.
   Garykom
 
21 - 10.09.21 - 09:31
(0) Что бы сделал я:
1. Подписки на события записи, там смотреть ОбменДанными.Загрузка = Истина
Если не служебное то в очередь (РС)
2. Фоновое обслуживает очередь, сериализуя в JSON и отправляя куда то (по http/rest или брокер сообщений или в файлики)
   rsv
 
22 - 10.09.21 - 09:32
На приеме - вы чего мне выгрузили . Ответ - смотри строку номер 5 файла ексель.
   Garykom
 
23 - 10.09.21 - 09:32
(20) муахаха
это говноподход нубский
   Garykom
 
24 - 10.09.21 - 09:32
(23)+ обмен через эксель это только когда иначе никак
   rsv
 
25 - 10.09.21 - 09:32
(23) надежен потому как прост . А лом надежен на 99 процентов
   Garykom
 
26 - 10.09.21 - 09:34
(25) ты реально кучу разных форматов экселя сравниваешь с ломом?
у меня например экселя нет, я либру юзаю
а в другой системе может этот эксель совершенно нечем читать...
   fisher
 
27 - 10.09.21 - 09:34
(4) > т.е. связка План обмена плюс http-сервисы это норм?
Это можно сказать стандарт де-факто для обмена с внешними системами. А внутри json (структуры/массивы на примитивных типах).
Но так как формат обмена будет полностью рукопашный - то чем сложнее структура передаваемых данных, тем геморнее получается. Для простых обменов - вообще минусов нет, одни плюсы.
А web-сервисы - это SOAP. С XDTO внутри - удобно для обмена 1С-1С. Именно потому, что проще со сложными данными.
   Garykom
 
28 - 10.09.21 - 09:36
(27) план обмена есть смысл юзать когда требуется подтверждение доставки и повторная отправка много раз пока не получено подтверждение
если оно нафик не надо и контроль доставки самому сделать то нафик не нужны планы обмена
   Kassern
 
29 - 10.09.21 - 09:37
(27) иногда достаточно лишь плана обмена и пару регламентных заданий, для двухстороннего обмена, без всяких http сервисов)
   fisher
 
30 - 10.09.21 - 09:40
(28) Даже если не требуется подтверждение доставки - все равно удобно их задействовать. Почему нет? Регистрация измененных так или иначе какая-то нужна, если речь не про распределенные транзакции.
(29) http - это на текущий момент самая удобная "гальваническая развязка" между разными системами, которые потенциально могут менять свое окружение.
 
 
   fisher
 
31 - 10.09.21 - 09:42
(30) + "которые потенциально могут менять свое окружение" -> "окружение которых потенциально может меняться"
   Kassern
 
32 - 10.09.21 - 09:42
(30) да не спорю, прост иногда не нужна такая оперативность доставки данных и достаточен тупо регламент.
   VladZ
 
33 - 10.09.21 - 09:43
1. Для регистрации изменении нужен план обмена.
2. Для транспорта - http-сервис.
   fisher
 
34 - 10.09.21 - 09:43
(32) Речь не про оперативность. Речь про транспорт между системами. Если системы в одной локалке - тогда есть варианты. А если не в одной? А если завтра они могут разъехаться?
   fisher
 
35 - 10.09.21 - 09:47
Регламент или событийность какая-то или вообще распределенные транзакции - это отдельный вопрос обмена. Ничего же не мешает по регламенту через http меняться.
   fisher
 
36 - 10.09.21 - 09:52
(28) У меня сейчас так обмен с мобильным приложением сделан. План обмена регистрирует измененные на мобильном девайсе документы. Выгрузка их идет синхронно - то есть подтверждение успешной загрузки я получаю сразу. И в этот момент просто удаляю запись об изменении. Если будет сбой обмена - значит объект выгрузится при следующей попытке. Удобно, почему нет? Ну, можно тоже самое и на РС сделать. Но какой смысл?
   Garykom
 
37 - 10.09.21 - 09:52
если надо сохранять историю то план обмена не очень удобен
лучше свое на Справочниках/РС
   Kassern
 
38 - 10.09.21 - 09:54
(36) у меня было пару проектов, где достаточно раз в сутки выплюнуть данные на сайт, и каждые 3-5мин спрашивать у сайта, есть ли новые заказы, или нет. В это случае смысл какой то http сервис поднимать, всего 2 рег.задания и привет новый http соединение)
   fisher
 
39 - 10.09.21 - 09:56
(38) Так у тебя был http-сервис. Просто с другой стороны :)
   Василий Алибабаевич
 
40 - 10.09.21 - 09:56
(37) Для сохранения истории планы обмена вообще не предназначены.

Они придназначены исключительно для регистрации изменений. Что потом делать с этими объектами в РИБ решает система, в не РИБ - разработчик. Можно отправлять получателю, можно удалять, можно еще чего нибудь. В том числе логировать. Но уже не средствами планой обмена.
   Kassern
 
41 - 10.09.21 - 09:57
(39) ну это понятно, я именно про 1совкий думал тут речь в ветке)
   Garykom
 
42 - 10.09.21 - 09:58
(40) я в курсе
но иногда надо сохранять некий срок историю обмена для разборок
и тут удобней использовать нечто свое вместо планов обмена
   Kassern
 
43 - 10.09.21 - 09:59
(37) для сохранения истории можно архивировать файлики обмена. Там тебе будет и время выгрузки и состав отправленных/полученных данных.
   Garykom
 
44 - 10.09.21 - 10:00
(43) это внешнее хранилище, иногда лучше внутри 1С чтобы ее же средствами сделать поиск по истории
   Garykom
 
45 - 10.09.21 - 10:00
я не против планов обмена!
просто уточняю что они не всегда лучше
   fisher
 
46 - 10.09.21 - 10:01
(41) Ну, так-то да. Если можно все нормально порешать через http-сервис на той стороне, то конечно это будет намного проще. Плюс свою жопу в инет совать не придется.
   Garykom
 
47 - 10.09.21 - 10:01
Лично я бы опубликовал ODATA и сплавил задачу на разрабов "внешней системы" - типа ипитесь как хотите ))
   BeerHelpsMeWin
 
48 - 10.09.21 - 10:03
(42) для истории можно внешний источник задействовать, строка сообщения + файл выгрузки в base64.
   Kassern
 
49 - 10.09.21 - 10:03
(47) ахах, а в ответ - "у нас лапки". В итоге приходится самому разрабатывать протокол обмена, его странспорт и т.д.
   Megas
 
50 - 10.09.21 - 10:22
(25) Эксель совсем не прост =) особенно для загрузки - это OLE-с своими приколами,  либо Excellapplication - тяжёлый и как не странно тоже с приколами.
Ещё в экселе сложно с массивами(табличными частями)
Мне JSON нравится.

(40) Именно поэтому не люблю планы обмена =(

Ну и кстати логи в файлики - очень помогают поднять историю.
   Kassern
 
51 - 10.09.21 - 10:23
(50) ну так планом обмена получаешь данные для отправки и суй ты их в json в чем проблема)
   Megas
 
52 - 10.09.21 - 10:27
(51) История не хранится. Когда поместил в в обмен,  когда отправил. Нужно делать РС - тогда теряется смысл плана обмена.
У меня вообще РС,  Справочник и RAbbit участвуют в обмене, та ещё и логи пишутся в файлы. Зато можно быстро найти момент ошибки в случае проблемы.
   Kassern
 
53 - 10.09.21 - 10:29
(52) можно использовать журнал регистрации, создать отдельную ветку под  это.
   Kassern
 
54 - 10.09.21 - 10:31
(53) можно файл лога создавать. Но обычно достаточно просто зайти в папочку с выгрузкой/загрузкой, отфильтровать по дате и посмотреть что там внутри.
   Василий Алибабаевич
 
55 - 10.09.21 - 10:33
(52) Ошибки видимо можно быстро. Вопрос как быстро происходит именно регистрация и выборка.
   Василий Алибабаевич
 
56 - 10.09.21 - 10:34
(54) Порядка 20-ти торговых. Порядка 20-ти обменов в день от каждого. Прикинь объемы данных за 2 года работы.
   rsv
 
57 - 10.09.21 - 10:34
(47) + 100 . И бюджет одноэсника передать тем кто
будет таблички копать.
   Megas
 
58 - 10.09.21 - 10:37
(55) В РС пишутся объекты быстро и без разбора(ну только минимальный разбор что данный объект нужен обмену). Дальше Рег задание разбирает что оставить к отправке, а что удалить. В момент записи если разбирать, то крайне долго получается.
   Василий Алибабаевич
 
59 - 10.09.21 - 10:37
+ (56) Вообще ИМХО правильно разделять службу регистрации изменений, транспорт и службу логирования.
   Антиквар
 
60 - 10.09.21 - 10:37
Я думал про эксель в шутку написали)
Нет, формат конечно типа JSON будет.
Изменения у нас будут очень часто передаваться, много раз в день, много разных объектов. Причем из внешней системы в 1С тоже данные пойдут, но скорее всего в меньшем объеме.
На счет плана обмена правильно подметили. В самом деле, при массовом перепроведении документов как быть? При передаче во внешнюю систему не важны проводки и регистры, важна внутренность самого документа. И если она не меняется, а документ постоянно перепроводят, то план обмена сыграет злую шутку, если не отслеживать самому, изменились ли реквизиты документа. А вот как их отслеживать...
Если использовать подписки на события, то как отследить удаление объектов (физическое). Ну справочники, документы, не удаляем как правило. Но вот регистры сведений допустим, там записи могут удаляться. План обмена может зафиксировать удаление записи регистра.
 
 
   Megas
 
61 - 10.09.21 - 10:39
(47) (57)
Обратное Вебер даёт доступ к MySQL сайта и говорит "Обмен настроен",  а одно эсники уже читаю/пишут и всячески страдают!
   Василий Алибабаевич
 
62 - 10.09.21 - 10:40
(58) Первый же вопрос который возникает при таком подходе - когда система перестанет отмеченный объект передавать в обмен. Когда получит первый получатель (а остальные?) или когда получит последний (и все кто уже получил будут получать его повторно?). Или нужно иметь по одной записи на каждого получателя?
   rsv
 
63 - 10.09.21 - 10:44
(61) эта эта ситуация проще . Скажут в какие таблички инсертить.Обычный sql.
А вот обратное в 1с через прокладку метаданных …. Внешним долго обьяснять придется
   Антиквар
 
64 - 10.09.21 - 10:55
Ещё я пока не понял, если использовать брокер сообщений, типа RabbitMQ , то в этом случае не нужен http-сервис? Он его заменит?
   Megas
 
65 - 10.09.21 - 10:55
(62) Rabbit менеджер очередей. Он получает успешно и отмечается как отправлено.

(63) Зачем обратно? 1с Так же читает таблицу MySQL "и загружает отмеченные к обмену"
   Megas
 
66 - 10.09.21 - 10:56
(64) Да. Но и на другой стороне нужно уметь работать с Rabbit ом.
   Антиквар
 
67 - 10.09.21 - 11:03
(66) на другой стороне всё умеют, и с раббитом, и с http-сервисами. Вопрос в 1С, как в неё всё это реализовать
   rsv
 
68 - 10.09.21 - 11:04
(65) тогда да . 1ска инсертит во внешку и селектит из нее .
Файлики не нужны . Сервисы и гирлянды isonoв с xml тоже.
   VladZ
 
69 - 10.09.21 - 11:11
(60) Я как-то делал свой контроль изменений. Брал значения проверяемых реквизитов (проверялись не все, а критичные: контрагент, сумма и т.д.) по ссылке на объект до записи и сравнивал с тем, что указано в текущем объекте. Если не было расхождений - отменял регистрацию.
   Антиквар
 
70 - 10.09.21 - 11:14
(68) Не понял. Предлагаешь напрямую во внешнюю SQL писать, и читать из неё? Но мы как раз от этого хотим уйти
   Антиквар
 
71 - 10.09.21 - 11:15
вопрос уходить в http-сервисы, или в Раббит, и как это на стороне 1С реализовать (план обмена или что ещё)
   Галахад
 
72 - 10.09.21 - 11:17
(70) А чем текущая реализация не устраивает?
   Megas
 
73 - 10.09.21 - 11:20
(70) Я так делал раньше - это очень плохо, поверь мне
   Василий Алибабаевич
 
74 - 10.09.21 - 11:21
(71) Еще раз. Планы обмена - суть служба регистрации измененных объектов. "http-сервисы, или в Раббит" или файлы - суть транспорт. И это разные сущности. Нельзя ставить вопрос "или". Вопрос должен стоять "и".
   rsv
 
75 - 10.09.21 - 11:25
(70) так это работает сейчас ?
   Антиквар
 
76 - 10.09.21 - 11:29
(75) это работает сейчас с одной внешней системой. Будет переход на другую внешнюю систему, аналогичную этой, но другую. Эта система будет писаться с нуля, соответственно мы можем всё сделать правильно, уйти от прямых записей в базы. Ну и разработчики этой внешней системы крайне против такого подхода, они и предлагают веб-сервисы и прочее
   rsv
 
77 - 10.09.21 - 11:31
(76) они сервисы на своей стороне предлагают или ждут сервисов  от 1с ?
   Антиквар
 
78 - 10.09.21 - 11:32
(74) я поставил "или" между http-сервисы и Раббит, разве опять что-то не так понял? Т.е. не план обмена или раббит, а план обмена и какой-то транспорт (раббит или http-сервисы,...). Так ведь?
   Garykom
 
79 - 10.09.21 - 11:32
(76) а еще вопрос синхронизации объектов-сущностей встанет
   Антиквар
 
80 - 10.09.21 - 11:33
(77) основной обмен из 1С во внешку. Т.е. мы должны опубликовать сервис. Ну и от них тоже будет
   Garykom
 
81 - 10.09.21 - 11:33
(78) если будут входящие в 1С а не только исходящие то план обмена не але
   Kassern
 
82 - 10.09.21 - 11:34
(80) сервис публикуется наоборот, когда надо чтобы внешка постучалась в 1с
   Антиквар
 
83 - 10.09.21 - 11:35
(79) это кто такие, объекты-сущности? Справочники? Конечно будет такой обмен, а в чем разница?
   rsv
 
84 - 10.09.21 - 11:35
(80) т.е внешка ( инициатор) будет опрашивать сервис 1с .
   Антиквар
 
85 - 10.09.21 - 11:36
(82) я это и имел ввиду, обмен из 1С во внешку подразумевает, что 1С выкладывает, а внешка стучится и забирает
   Антиквар
 
86 - 10.09.21 - 11:37
(84) Да. Но и обратно тоже будет, пока просто непонятно какой объем информации на какой стороне будет вестись.
   Василий Алибабаевич
 
87 - 10.09.21 - 11:37
(78) Ну так - то да.
   Антиквар
 
88 - 10.09.21 - 11:37
(81) почему?
   Garykom
 
89 - 10.09.21 - 11:37
(83) это НСИ и документы
Их надо будет как то синхронизировать по неким ID, кодам (уид) или наборам признаков-реквизитов
   Garykom
 
90 - 10.09.21 - 11:38
   Kassern
 
91 - 10.09.21 - 11:39
(85) а учет где будет основной вестись? Если в 1с, то поидее 1ска должна руководить обменом, отдавать, как ввелись данные, и периодически стучатся, забирая данные с сайта.
   Антиквар
 
92 - 10.09.21 - 11:39
(89) всё по ГУИД. Сложнее только с регистрами сведений
   Василий Алибабаевич
 
93 - 10.09.21 - 11:40
(80) "Т.е. мы должны опубликовать сервис. Ну и от них тоже будет" А вот это вот плохая идея.
Сервис должен быть один и на одной стороне. А другая сторона будет либо забирать с этого сервиса свои данные или отдавать.
   Антиквар
 
94 - 10.09.21 - 11:40
(91) основной учет в 1С
   Garykom
 
95 - 10.09.21 - 11:41
(92) если один вид сущности вводится в разных системах то дубли неизбежны
   Антиквар
 
96 - 10.09.21 - 11:41
(93) тут пока не понимаю. Если обмен двухсторонний, то всё-равно должен быть один сервис???
   rsv
 
97 - 10.09.21 - 11:42
(93) а пойдет это по сценарию …. Сервисов на 1с по причине «там все есть»
   Антиквар
 
98 - 10.09.21 - 11:42
(95) это исключено. Источник данных всегда один
   Garykom
 
99 - 10.09.21 - 11:42
(96) достаточно одного сервиса который умеет и туды и сюды
второй лишний
   Garykom
 
100 - 10.09.21 - 11:42
(98) это фантастика и сказки
  1  2   

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