|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Всем привет. Вот такой вопрос созрел. Имеется две системы, обмен между которыми происходит посредством web service. Одна система (клиент) посылает в сервис действие, сервис у себя (сервер) создает кое какие проводки (все в пределах секунды) и возвращает результат действия - успешно или нет, и в зависимости от ответа происходит определенные действия на клиенте. Так вот возникают иногда обрывы соединения, т.е. действие отправляется, обрыв, нет ответа и соответственно нет продолжения, т.е. прекращение операции. Но сервер, получивший через сервис действия не знает об обрыве и успешно осуществляет проводки. И это приводит к разсинхронизации двух систем по действиям. Вопрос: какие есть механизмы защиты от этого? P.S.: клиент - это касса, сервер - система CRM, действия - это процесс списания бонусов, которое должна быть онлайн, при обрыве связи - на кассе нет списания, т.е. оплата бонусами не возможна, а в CRM - списание со счета проходит успешно. Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 12:05 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Semen81, используйте очереди для сервисов. Например, Rabbit MQ, IBM WebShpere MQ, MSMQ. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 12:31 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
AxeleronSemen81, используйте очереди для сервисов. Например, Rabbit MQ, IBM WebShpere MQ, MSMQ. И что это даст? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 09:06 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
>Semen81, 19606724 >... Имеется две системы ... Рассмотрите вариант циклической нумерации информационных пакетов действия и инфопакетов ответа. И введите дополнительный метод для запроса сервера на получение номера пакета, последнего штатно выполненного действия. С уважением, Владимир. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 09:53 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAAxeleronSemen81, используйте очереди для сервисов. Например, Rabbit MQ, IBM WebShpere MQ, MSMQ. И что это даст? Да, неудачный совет дал я. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 12:43 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
ВМоисеев>Semen81, 19606724 >... Имеется две системы ... Рассмотрите вариант циклической нумерации информационных пакетов действия и инфопакетов ответа. И введите дополнительный метод для запроса сервера на получение номера пакета, последнего штатно выполненного действия. С уважением, Владимир. Не могли бы Вы пояснить последнее предложение? Предлагаете, чтобы сервер запрашивал у кассы номер пакета, или наоборот? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2016, 08:26 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Semen81Вопрос: какие есть механизмы защиты от этого? Создавать логическую транзакцию. Не техническую. Логическую. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2016, 16:34 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Semen81, Если есть возможность организовать обратный запрос, то сделать так: 1. Инициировать транзакцию: клиент посылает в сервис действие и получает код транзакции. 2. Сервис, завершив транзакцию, обращается к клиенту и посылает результат действия. Если необходимо, клиент при первом обращении говорит сервису, куда послать результат действия. Если нет возможности организовать обратный запрос, то так: 1. Инициировать транзакцию: клиент посылает в сервис действие и получает код транзакции. 2. Через некоторое время (допустим, через 1-2 секунды), клиент обращается к сервису опять и с помощью полученного кода транзакции выясняет результат операции. Если операция ещё не завершена, клиент выжидает какое-то время и опять опрашивает, до тех пор пока не получит результат. Можно сделать систему более надёжной: когда клиент, получив результат действия, должен ещё послать подтверждение, что он согласен с этим результатом, таким образом завершив транзакцию. В таком случае состояние всей системы в целом будет гарантировано согласовано. Такая схема не зависит от используемых технологий. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2016, 17:49 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
>skyANA, 1 сен 16, 08:26 [19615609] >...Предлагаете, чтобы сервер ... В моём представление, за установление связи отвечает клиент. След. при потере оной клиент начинает телодвижения, а именно, пытается восстановить связь. При восстановлении связи посылает серверу (серверу приложений - многозвенка) запрос на получение номера последнего штатно выполненного действия и принимает нужное решение. С уважением, Владимир ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2016, 19:02 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Semen81Вопрос: какие есть механизмы защиты от этого? Распределённые транзакции . ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2016, 09:05 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
На мой взгляд касса вообще не должна зависеть от какой-то там CRM, что является каким-то там сервисом, или тетрадью тёти Маши. И следовательно вообще не должна ждать ответа от сервера, где сервис развёрнут, или из комнаты, где тётя Маша сидит. Следовательно мне видится такое решение: промежуточный буфер (файл, таблица, коллекция, очередь) на стороне кассы и синхронизация по мере доступности сервиса. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2016, 21:27 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
eventual consistency, йоба! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2016, 21:28 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAeventual consistency, йоба! Это из другой оперы. Ты говоришь про согласованность данных, а речь идёт о бизнес-транзакциях. Было снято бабло или нет. При чём даже если бабло и было снято, остаток может не измениться, или измениться не соответственно снятому баблу, соответственно что ты там будешь согласовывать по данным -- совершенно не понятно. Тут либо действие выполнено, либо нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2016, 08:46 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVostt, я о том, что факт списания бонусов в CRM можно и потом отразить. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2016, 08:54 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAhVostt, я о том, что факт списания бонусов в CRM можно и потом отразить. Ты смотришь на ситуацию с точки зрения данных. А проблема у ТС в том, чтобы определить факт успешного выполнения операции. А что там надо сделать в результате успеха -- до фанаря, бонусы списать, отправить письмо, отобразить поздравительный банер, выдать ачивку — вопрос другой. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2016, 09:16 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
CRM хранит историю взаимоотношений с клиентом. Историю, Карл :) Выполнение бизнес-транзакций, операций и т.д. и т.п. не должно от неё зависеть. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2016, 09:23 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANACRM хранит историю взаимоотношений с клиентом. Историю, Карл :) Выполнение бизнес-транзакций, операций и т.д. и т.п. не должно от неё зависеть. Что-то у тебя всё с ног на голову перевернулось. С какой кстати, клиент должен знать о какой-то там истории? Касса: я собираюсь деньги списать, давай платить бонусами? CRM: оплата прошла, бонусы списаны! Касса: спасибо, говорю что всё оплачено. Что присходит на деле: Касса: я собираюсь деньги списать, давай платить бонусами? CRM: оплата...аф34ывпыв... обрыв связи... Касса: чёрт! ну хрен с ним, извини, чувак — не получилось. Скажи мне, при чём тут история? Кассе надо знать, прошла оплата или нет. Списались ли бонусы при этом у CRM, или что там с ними произошло, кассе по барабану и фиолетово совершенно. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2016, 10:26 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANACRM хранит историю взаимоотношений с клиентом. Историю, Карл :) Выполнение бизнес-транзакций, операций и т.д. и т.п. не должно от неё зависеть. Что-то у тебя всё с ног на голову перевернулось. С какой кстати, клиент должен знать о какой-то там истории? Касса: я собираюсь деньги списать, давай платить бонусами? CRM: оплата прошла, бонусы списаны! Касса: спасибо, говорю что всё оплачено. Что присходит на деле: Касса: я собираюсь деньги списать, давай платить бонусами? CRM: оплата...аф34ывпыв... обрыв связи... Касса: чёрт! ну хрен с ним, извини, чувак — не получилось. Скажи мне, при чём тут история? Кассе надо знать, прошла оплата или нет. Списались ли бонусы при этом у CRM, или что там с ними произошло, кассе по барабану и фиолетово совершенно. С чего ты взял, что: 1. именно так всё устроено? 2. что это правильно? ТС написал: "Имеется две системы, обмен между которыми происходит посредством web service". Не одна система, состоящая из кассы и CRM, а две. Дак вот я выступаю за то, что первая система должна уведомлять последнюю постфактум :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.09.2016, 15:28 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAС чего ты взял, что: 1. именно так всё устроено? 2. что это правильно? Из сообщения ТС. Ну ещё в свой хрустальный шар пристально смотрел. Зуб даю, всё именно так skyANAТС написал: "Имеется две системы, обмен между которыми происходит посредством web service". Не одна система, состоящая из кассы и CRM, а две. Именно. Две. Независимые. Каким боком тут eventual consistency упала — не понятно до сих пор. skyANAДак вот я выступаю за то, что первая система должна уведомлять последнюю постфактум :) Ты бы пояснил что ты конкретно имеешь в виду. Конкретный механизм взаимодействия. А то какой-то буффер, какая-то синхронизация... О чём ты вообще? Это две _разных_ системы. Тем более речь вообще не шла о согласованности данных. Речь шла о согласованности действий. В общем у тебя какая-то каша в рассуждениях. Конечно можно присобачить какую-нибудь модную технику ради техники, только нафиг она нужна. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 06:01 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVostt, о какой модной технике речь? Тебе слово буфер расшифровать? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 10:12 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAhVostt, о какой модной технике речь? Тебе слово буфер расшифровать? :) hVosttТы бы пояснил что ты конкретно имеешь в виду. Конкретный механизм взаимодействия. Я написал что нужно, хотя если хочешь, можешь в догонку и слово буфер расшифровать )) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 11:27 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Semen81Всем привет. Вот такой вопрос созрел. Имеется две системы, обмен между которыми происходит посредством web service. Одна система (клиент) посылает в сервис действие, сервис у себя (сервер) создает кое какие проводки (все в пределах секунды) и возвращает результат действия - успешно или нет, и в зависимости от ответа происходит определенные действия на клиенте. Так вот возникают иногда обрывы соединения, т.е. действие отправляется, обрыв, нет ответа и соответственно нет продолжения, т.е. прекращение операции. Но сервер, получивший через сервис действия не знает об обрыве и успешно осуществляет проводки. И это приводит к разсинхронизации двух систем по действиям. Вопрос: какие есть механизмы защиты от этого? P.S.: клиент - это касса, сервер - система CRM, действия - это процесс списания бонусов, которое должна быть онлайн, при обрыве связи - на кассе нет списания, т.е. оплата бонусами не возможна, а в CRM - списание со счета проходит успешно. Спасибо В чем состоит "рассинхронизация"? Т.е. если оборвалась связь клиент не знает, как закончилась транзакция? Так это будет известно только после восстановления связи. После того как связь восстановлена клиент должен убедиться в результате конкретной транзакции, иначе все будет разболтано. Каждый запрос от клиента к серверу имеет свой ид, клиент долбит сервис запросом с одним и тем же ид пока не получит ответ, сервис отрабатывает запрос с определенным ид только один раз Т.е. для сервиса должен быть еще один запрос от клиента, подтверждающий транзакцию, если его нет - он должен не делать коммит или откатить и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 11:49 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Клиент в запрос вставляет ид операции, если от сервиса нет ответа, заносит его в "плохую" очередь. При возобновлении связи, первым делом шлет плохие ид и сервер отменяет операции, если они были. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 12:31 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANAhVostt, о какой модной технике речь? Тебе слово буфер расшифровать? :) hVosttТы бы пояснил что ты конкретно имеешь в виду. Конкретный механизм взаимодействия. Я написал что нужно, хотя если хочешь, можешь в догонку и слово буфер расшифровать )) Что я конкретно имею в виду: первая система (касса) выполняет списание бонусов и факт этого списания заносит в свою табличку, или коллекцию, или файл, или... Некий фоновый процесс (сервис, консьюмер, брокер) разгребает содержимое данной таблички, или коллекции, или файла и информацию по выполненым операциям отсылает всем внешним системам, что заинтересованы в них. В данном случае одна такая система - CRM. Так понятно? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 14:36 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAЧто я конкретно имею в виду: первая система (касса) выполняет списание бонусов и факт этого списания заносит в свою табличку, или коллекцию, или файл, или... Я думаю там в любом случае операции с бонусами как-то фиксируются. Незачем заводить ещё одну какую-то табличку, коллекцию или файл. skyANAНекий фоновый процесс (сервис, консьюмер, брокер) разгребает содержимое данной таблички, или коллекции, или файла и информацию по выполненым операциям отсылает всем внешним системам, что заинтересованы в них. А если операция не удалась и в табличку ничего не записано. Пусть сервисы ждут у моря погоды? Или выжидают время и считают, что всё — каюк? Хрень какая-то. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 16:34 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANAЧто я конкретно имею в виду: первая система (касса) выполняет списание бонусов и факт этого списания заносит в свою табличку, или коллекцию, или файл, или... Я думаю там в любом случае операции с бонусами как-то фиксируются. Незачем заводить ещё одну какую-то табличку, коллекцию или файл. skyANAНекий фоновый процесс (сервис, консьюмер, брокер) разгребает содержимое данной таблички, или коллекции, или файла и информацию по выполненым операциям отсылает всем внешним системам, что заинтересованы в них. А если операция не удалась и в табличку ничего не записано. Пусть сервисы ждут у моря погоды? Или выжидают время и считают, что всё — каюк? Хрень какая-то. Если операция не удалась, то не удалась. А сервисы ничего в моей схеме не ждут. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 17:43 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAЕсли операция не удалась, то не удалась. А сервисы ничего в моей схеме не ждут. :) Поэтому и не применимо к задачам ТС ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 22:31 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANAЕсли операция не удалась, то не удалась. А сервисы ничего в моей схеме не ждут. :) Поэтому и не применимо к задачам ТС Не понимаю почему. Хотелось бы увидеть объяснение. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2016, 23:05 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
>Semen81, 30 авг 16, 12:05 [19606724] >...Имеется две системы... Ситуация может быть более сложной, обрыв соединения может быть обусловлен клиентским компьютером - потеря питания, сбой и пр. Новая сессия может быть открыта и на другом компьютере. Поэтому информация о последнем штатно выполненном действии должна хранится на сервере данных в параметрах оператора. По запросу он должен получить исчерпывающую информацию по последнему штатному действию для принятия решения. С уважением, Владимир. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 01:14 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAНе понимаю почему. Хотелось бы увидеть объяснение Потому что нет конкретного и однозначного ответа на вопрос: выполнилось действие или нет, и с каким результатом. Всё, что есть: это какая-то рассылка брокером фактов списаний бонусов. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 08:03 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANAНе понимаю почему. Хотелось бы увидеть объяснение Потому что нет конкретного и однозначного ответа на вопрос: выполнилось действие или нет, и с каким результатом. Всё, что есть: это какая-то рассылка брокером фактов списаний бонусов. Как нет, есть в первой системе. Факт списания бонусов - это и есть выполненное действие. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 09:26 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAКак нет, есть в первой системе. Факт списания бонусов - это и есть выполненное действие. Факт списания боносов это факт списания бонусов :) Он либо есть, либо его нет. А у действия всегда есть какой-то результат. В этом и состоит проблема твоего решения, что ты не видишь разницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 10:03 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANAКак нет, есть в первой системе. Факт списания бонусов - это и есть выполненное действие. Факт списания боносов это факт списания бонусов :) Он либо есть, либо его нет. А у действия всегда есть какой-то результат. В этом и состоит проблема твоего решения, что ты не видишь разницы. Так в чём проблема-то? Зачем во второй системе, в CRM фиксировать действия из первой системы? Во время выполнения операции исключения могут вылетать в системе, они логируются. Может и их ещё в CRM передавать? Типа действие привело к ошибке, давайте это в CRM анализировать. Давай по другому сформулирую: у нас есть первая система, в ней есть жернал операций. Данные из этого журнала мы передаём другим системам для чего-то: анализа, принятия каких-то решений, просмотра истории своих операций клиентами. По мне времена взаимодейтсивя клиент сервер давно уже прошли, наступило время распределённой архитектуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 10:59 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
Пояснения к картинке: ИП - интерфейс пользователя ЛП - логика приложения ДД - доступ к данным БД - база данных ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 11:01 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAТак в чём проблема-то? Зачем во второй системе, в CRM фиксировать действия из первой системы? Потому что: А) там может сидеть юзер и ожидать реакции системы, не важно какой Б) сама система может принимать совершенно разные и удивительные решения на основе результата выполнения операции внешней системы В) на основе операций может генерироваться множество других изменений в данных и артефактов, кроме непосредственно факта списания бонусов Г) система на основе действий расширяема, без ковыряния левых брокеров, систем рассылки, ведения буферов и таблиц, от которых зависит всё, точка соприкасания систем фокусируется исключительно на действиях, что снижает связанность skyANAДавай по другому сформулирую: у нас есть первая система, в ней есть жернал операций. Данные из этого журнала мы передаём другим системам для чего-то: анализа, принятия каких-то решений, просмотра истории своих операций клиентами. Слишком широко. Клиенту важно получить результат выполненной операции, если он её инициировал. Я подозреваю, что некий журнал операций всё равно будет. Но про доставку это «записи», я уже говорил. Это один из кейсов: клиент говорит сервису, куда ему доставить результат и отрубается. Подписка на событие. Зачем клиенту получать вообще все записи из журнала, не ясно. skyANAПо мне времена взаимодейтсивя клиент сервер давно уже прошли, наступило время распределённой архитектуры Ну вот. Помнишь ты спрашивал про модные техники? Сам же и сказал ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 11:33 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANAТак в чём проблема-то? Зачем во второй системе, в CRM фиксировать действия из первой системы? Потому что: А) там может сидеть юзер и ожидать реакции системы, не важно какой Б) сама система может принимать совершенно разные и удивительные решения на основе результата выполнения операции внешней системы В) на основе операций может генерироваться множество других изменений в данных и артефактов, кроме непосредственно факта списания бонусов Г) система на основе действий расширяема, без ковыряния левых брокеров, систем рассылки, ведения буферов и таблиц, от которых зависит всё, точка соприкасания систем фокусируется исключительно на действиях, что снижает связанность skyANAДавай по другому сформулирую: у нас есть первая система, в ней есть жернал операций. Данные из этого журнала мы передаём другим системам для чего-то: анализа, принятия каких-то решений, просмотра истории своих операций клиентами. Слишком широко. Клиенту важно получить результат выполненной операции, если он её инициировал. Я подозреваю, что некий журнал операций всё равно будет. Но про доставку это «записи», я уже говорил. Это один из кейсов: клиент говорит сервису, куда ему доставить результат и отрубается. Подписка на событие. Зачем клиенту получать вообще все записи из журнала, не ясно. skyANAПо мне времена взаимодейтсивя клиент сервер давно уже прошли, наступило время распределённой архитектуры Ну вот. Помнишь ты спрашивал про модные техники? Сам же и сказал Всё что ты тут понаписал, никак не противоречит моей идее. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 13:21 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttСлишком широко. Клиенту важно получить результат выполненной операции, если он её инициировал. Я подозреваю, что некий журнал операций всё равно будет. Но про доставку это «записи», я уже говорил. Это один из кейсов: клиент говорит сервису, куда ему доставить результат и отрубается. Подписка на событие. Зачем клиенту получать вообще все записи из журнала, не ясно. Тут под клиентом я имел ввиду человека, что пришёл и купил что-то за бонусы. А в конце месяца сидит дома и смотрит в личном кабинете выписку по операциям за месяц. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 13:25 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVostt, и кстати раскрой что такое "система на основе действий". Для меня это попахивает управленческим учётом и бизнес-аналитикой и лежит мягко говоря в другой плоскости, чем проблема ТСа. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 13:30 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
skyANAТут под клиентом я имел ввиду человека, что пришёл и купил что-то за бонусы. А в конце месяца сидит дома и смотрит в личном кабинете выписку по операциям за месяц. Ты пошёл дальше, как я вижу :) Но проблема то обозначена весьма конкретно: одна система делает запрос на выполнение действия к другой системе. Возникает обрыв связи, и клиент считает, что действие не выполнилось. Считать, что действие в любом случае выполнилось клиент тоже считать не в праве. skyANAhVostt, и кстати раскрой что такое "система на основе действий". Для меня это попахивает управленческим учётом и бизнес-аналитикой и лежит мягко говоря в другой плоскости, чем проблема ТСа. Система на основе действий, это грубо говоря любой вызов функции и получение результата. В бизнесе, это это можно назвать бизнес-транзакцией. Приплетать сюда какую-то конкретную предметную область вовсе не обязательно. Представь, что ты вызываешь функцию, но вместо результата получаешь исключение. При этом на самом деле, всё выполнилось ОК, и все необходимые изменения закомитились (списались бонусы, отправились письма и СМС, да мало ли что). Что делать? Организовывать буффер и согласовывать данные? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 14:12 |
|
Обрыв соединения
|
|||
---|---|---|---|
#18+
hVosttskyANAТут под клиентом я имел ввиду человека, что пришёл и купил что-то за бонусы. А в конце месяца сидит дома и смотрит в личном кабинете выписку по операциям за месяц. Ты пошёл дальше, как я вижу :) Но проблема то обозначена весьма конкретно: одна система делает запрос на выполнение действия к другой системе. Возникает обрыв связи, и клиент считает, что действие не выполнилось. Считать, что действие в любом случае выполнилось клиент тоже считать не в праве.Вот я и предлагаю разорвать эту зависимость между системами, так как у них разное назначение: выполнить действие полностью в первой системе, результат зафиксировать. И отдельным процессом переслать результат всем заинтересованым. Весьма распространённая на данный момент практика, да и в прошлом. hVosttskyANAhVostt, и кстати раскрой что такое "система на основе действий". Для меня это попахивает управленческим учётом и бизнес-аналитикой и лежит мягко говоря в другой плоскости, чем проблема ТСа. Система на основе действий, это грубо говоря любой вызов функции и получение результата. В бизнесе, это это можно назвать бизнес-транзакцией. Приплетать сюда какую-то конкретную предметную область вовсе не обязательно.Хм... Ты таки об Activity-Based Information System (ABIS) или нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2016, 15:31 |
|
|
start [/forum/topic.php?all=1&fid=19&tid=1396754]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 255ms |
total: | 409ms |
0 / 0 |