BiTel

Добрый день!

Пишу скрипты для экшенов, для прерывания в случае ошибки использую BGMessageException, но бывают ситуации, когда нужно дать выбор оператору, что делать.
Есть ли данная возможность в существующем API?

_________________

Нет, такого нет. И непонятно как сделать архитектурно. Дин код выполняется на сервере асинхронно от потока клиент-сервер.

_________________
I'm clever. I've got a computer.

Жаль, очень нужный функционал....

_________________

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

_________________
I'm clever. I've got a computer.

а setError как для параметров договора?

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

_________________
I'm clever. I've got a computer.

Ну как делаю проверку на уникальность паспортных данных в договоре, например приходит абонент с кредитным договором не гасит старый долг, и заключает договор на другой адрес. В случае проверки паспортных данных мы можем отловить таких хитрецов. Ноо бывают ситуации когда это порядочный абонент и он может заключить 2 договора, один на себя, а другой на родителей. Сейчас решили выкидывать исключение и запрещать оформлять такой договор если он не является субдоговором.

В случае если б была возможность предоставить оператору выбор, могли бы предложить оператору варианты решения. Либо пропустить создание договора, либо создать иерархию с субдоговорами или нажать отмену.

Ну это одна из возможных ситуаций, где это можно применить.

_________________

Ух. Это из разряда кнопки "Песдато!". Единственное, что считаю тут возможным - это аля Confirm, т.е. передается запрос серверу, но экшин кидает ошибку с запросом подтвердждения, на что клиент выдает "Всё равно выполнить?" и при утвердительном выборе посылается повторный запрос, в который добавляется параметр ignoreError=1, который должен как-то обрабатываться экшином. Как-то так.

1) Можно перед добавлением договора просто сделать поиск по номеру паспорта. Адрес подключения также проверять. Отдать на откуп манагерам под наставлением обещания сурового наказание за неисполнение и по расписанию запускать задачу проверки.

2) Зачем дублировать поля для субдоговора? для них можно ставить свой набор параметров и указывать только уникальные - типа адрес, дата подключения, контакт и еще может чего немного.

Да, в таком именно случае, т.е. просто обработка события, "обратная связь" в каком-то общем виде проблематична.
Либо в неком кастрированном виде, типа как barguzin2 предложил. Подобный механизм Confirm/ignoreError уже используется в некоторых местах (в cerbercrypt при добавлении/удалении пакетов и обработках коллизий в них, например). Но это несколько в другом виде уже получается, просто требует ручной обработки этого механизма на клиенте, посылания повторного запроса с ignoreError=1 итд. Потому тут сложно что-то универсальное предложить.

_________________
I'm clever. I've got a computer.

возможность создавать диалоговые окна с кнопками да/нет и обрабатывать их?

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

так-то вся тема об этом, начиная с самого первого сообщения

_________________
I'm clever. I've got a computer.

я про то что дать нам возможность так создавать в динкоде

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

_________________

что создавать? окно на сервере? ок

_________________
I'm clever. I've got a computer.

АПну тему.
Появился ли инструмент для создания диалоговых окон?
При написании скриптов иногда появляется потребность вызова окна не только типа ERROR, когда скрипт прерывается, но и INFO (сообщить о каком то результате), и WARNING (OK/Cancel).

_________________

BGMessageException по-прежнему работает для этих целей. Как сделать из дин.кода интерактивные диалоги — по-прежнему идей нет.

_________________
I'm clever. I've got a computer.

текущая схема работы

1) клиент посылает запрос на сервер
2) на сервер некий код обрабатывает запрос и посылает ответ
3) клиент обрабатывает ответ

в каком месте здесь вставить диалог?

Ну, очевидно что только о п.3 тут речь, но для этого и есть BGMessageException для выдачи статического сообщения/ошибки. Любое другое что-то требует кастомной логики в каждом случае (вообще никак не связанной с механизмом дин.кода!), например в месте где выше хочется проверять паспортные данные, ну то есть в клиенте на "сохранение параметра договора" надо обработать вдруг кто-то придумает переопределить что-то в дин.коде и что-то (неизвестно пока что) вернёт, а нам надо это что-то обработать и отправить что-то обратно (куда?) чтобы дин.код снова что-то сделал. Ну и так в каждый другой потенциальный чих добавить похожий механизм. Совершенно непонятно как это предлагается сделать. И я чувствую своё объяснительное бессилие в этом вопросе.

_________________
I'm clever. I've got a computer.

Хм, получается можно только INFO выкидывать. На втором этапе при обработке экшена, заполняем текстовую переменную. И на третьем этапе, клиент выведет это сообщение оператору. Что уже весьма не плохо.

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

_________________

Просто BGMessageException не всегда уместно, ведь это исключение, даже выполненное в конце doAction, не известно как повлияет на результат. А заполнение переменной, просто выведет сообщение оператору и код выполнится корректно.

И на счет OK/Cancel, у нас в экшене есть метод doAction, добавить метод preCheck, он будет выполняться до метода doAction, что то проверит, и в зависимости, что выберет оператор в клиенте, будет принято решение выполнять ли doAction, а возможно doAction с каким то параметром.

_________________

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

Да именно отправлять, какой-то предзапрос, который сделает нужные проверки, а затем уже выполнять doAction (прослойка до выполнения doAction). Например оператор делает какое то действие, вызывается экшен, возьмем для примера добавление субдоговора. Оператор выбирает добавить субдоговор, клиент отправляет запрос к серверу на проверку, вот на этом этапе как раз уместно будет вызывать диалоговые окна, затем, как нужные данные для doAction собраны, отправлять запрос на выполнение экшена.

_________________

подобное можно сделать в каком то конкретном месте(ах) клиента, но в общем это работать не будет без переписывая всех вызовов из клиента

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

Что насчет INFO сообщений, т.е. чисто информационные сообщения, которые не прерывают работу скрипта в отличии от BGMessageException?

_________________

при использовании механизма акшенов это я как то могу себе представить, а вот для вебсервисов с трудом...

Ну я акшены и имел ввиду. А разве вэбсервисы тоже можно обрабатывать? Как раз пытаюсь отловить событие изменения статуса договора в логах клиента вижу, что клиент дергает вэб сервис ContractStatusMonitorService:changeContractStatus, только не пойму, как с этим работать. Видимо, что то упустил, как вызвать знаю, а вот как акшен повесить?

_________________

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

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

_________________
I'm clever. I've got a computer.