Size: a a a

1С, БСП, DevOps и Архитектура

2020 March 12

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
Anton Selin
Не пофиг. До тех пор, пока система А не приняла данные из системы Б, то система Б может эти данные менять у себя сколько хочет. Но как только система А получила из системы Б (уведомила её об этом) порцию данных, то внесение изменений системой Б в эти данные невозможны.
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
Anton Selin
не спрашиваете что за архитектура и почему такая. Что есть, с тем приходится работать....
А есть какой то смысл в формировании пачки из списка документов?
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
В моем понимании никакого противоречия нет и это только подтверждает  https://t.me/ssl1c/46281
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
John Doe
В моем понимании никакого противоречия нет и это только подтверждает  https://t.me/ssl1c/46281
Возможно я уже уработался и что-то упускаю)
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Oleg Tymko
Возможно я уже уработался и что-то упускаю)
"система А по каждому документу отправляет в систему Б уведомление, что "начинаю работать с документом №4444", потом есть очередной запрос в систему Б - получить данные по документу"
Т.е. он сначала провозглашает - мол, приступаю к обработке, в источнике блокирует от изменения и затем уже сосет данные заблокированного от изменений документа.
источник

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
Причём тут транзакции тогда? Есть три события, блокировка, чтение, разблокировка.
источник

AS

Anton Selin in 1С, БСП, DevOps и Архитектура
Oleg Tymko
А есть какой то смысл в формировании пачки из списка документов?
Система Б у себя сформировала некий список документов.. Эти документы не обработаны системой А.. За это отвечает специальный признак "Заблокирован".. До тех пор, пока этот признак в системе Б для документов не установлен, то в системе Б её владелец может по разным причинам менять что-то в документах...

Система Б предлагает следующее решение:
1. Постучаться по HTTP запросом и получить список номеров документов, которые еще не обработаны,
2. Постучаться по HTTP запросом и установить документу признак "Заблокирован" в Истина,
3. Постучать по HTTP запросом и получить по номеру документа его "внутренности" - реквизиты, ТЧ и т.п.
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
"уработался" // А, ну да, ты ж +4 МСК, да и воздухом черным дышите там как шахтеры)
источник

OT

Oleg Tymko in 1С, БСП, DevOps и Архитектура
John Doe
"уработался" // А, ну да, ты ж +4 МСК, да и воздухом черным дышите там как шахтеры)
Про воздух вообще обидно) но так оно и есть
источник

AS

Anton Selin in 1С, БСП, DevOps и Архитектура
Так вот, когда я в своей системе на пункте третьем забрал данные документа, и начал у себя что-то обрабатывать и у меня случился в системе казус..
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Oleg Tymko
Про воздух вообще обидно) но так оно и есть
Я и не старался обидеть, сам там прожил N лет
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Anton Selin
Так вот, когда я в своей системе на пункте третьем забрал данные документа, и начал у себя что-то обрабатывать и у меня случился в системе казус..
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Если тебя смущает, что в случаях факапа у тебя документы остаются заблокированными долгое время, то это без дополнительного контура контроля никак не решается
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Т.е. тебе придется мониторить, а нет ли слишком долго заблокированных, с эмпирической выработкой критерия этого "слишком долго"
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
При обнаружении слишком долгих - повторное засасывание и обработка
источник

AS

Anton Selin in 1С, БСП, DevOps и Архитектура
John Doe
Т.е. тебе придется мониторить, а нет ли слишком долго заблокированных, с эмпирической выработкой критерия этого "слишком долго"
Вот так и придется делать...
источник

JD

John Doe in 1С, БСП, DevOps и Архитектура
Anton Selin
Вот так и придется делать...
Это неизбежно в любой схеме сосания (если тебе надо до начала обработки что-то помечать)
источник

AS

Anton Selin in 1С, БСП, DevOps и Архитектура
John Doe
Это неизбежно в любой схеме сосания (если тебе надо до начала обработки что-то помечать)
ну.. когда это всё болото крутится внутри одной базы, то я лишь помещаю в НачатьТранзакцию()..... ЗафиксироватьТранзакцию() и делов.. при факапе идет полный откат..
В таких вот системах так не прокатит.
источник

AS

Anton Selin in 1С, БСП, DevOps и Архитектура
Мне раньше не приходилось об этом задумываться.. теперь нужно, а опыта нет.
источник

AO

Andrey Ovsiankin in 1С, БСП, DevOps и Архитектура
Nikita Gryzlov
Сменить схему с пулл на пуш не предлагать? Системе источнику в целом должно быть пофиг, приняты ли приёмником данные, это не её забота
Мы про транзакции. В условии я упомянул возможность отката бизнес-операции. Пуш уже не прокатывает
источник