В данной статье будет рассмотрен обучающий пример использования событийной модели.
Кроме того, будет представлен инструмент Workflow, позволяющий реализовать различные обработчики событий.
Задача: пользователь вводит данные в поле «Рабочий телефон» и перемещает курсор в другое место интерфейса.
На этом этапе система должна прочитать введенное значение, удалить ненужные символы и применить заданный формат. Например, пользователь вводит «7999)44-333-22», выходит из поля, и значение меняется на «+7(999)443-33-22».
Oracle Siebel CRM имеет специальный тип данных DTYPE_PHONE, который позволяет автоматически форматировать текстовое поле, но имеет ряд ограничений.
В данном случае я рассматриваю вариант, где поле «Рабочий телефон» представляет собой обычное текстовое поле.
Немедленное изменение публикации
Чтобы решить эту проблему, вам необходимо написать собственный обработчик событий SetFieldValue. Поскольку он должен срабатывать при смене фокуса с поля [Work Phone #] на другую область экрана, мы должны установить для свойства Immediate Post Change этого поля значение «Y».
Событие времени выполнения и рабочий процесс
Номер телефона будет очищен обработчиком, созданным с помощью Workflow, который, в свою очередь, будет запущен через событие времени выполнения.
Для начала я создам простую заглушку на основе Workflow, которая пока ничего не будет делать: 
Это интерактивный рабочий процесс, который будет работать с бизнес-объектом «Контакт».
Теперь, если этот Рабочий процесс вызывается через Событие времени выполнения на экране (Представление), основанном на бизнес-объекте Контакт, то он получит весь контекст, с которым работал пользователь, и все действия (обновление записей, удаление , создание, запрос данных) будет происходить от имени этого пользователя.
Сам Workflow на этом этапе будет выглядеть так: 
Первый вариант обработчика готов, теперь его нужно привязать к событию SetFieldValue. Вопрос в том, к какой ветке его привязать: Pre-Branch или Post-Branch? Поскольку нам нужен доступ к вновь введенному значению, то логично привязать его именно к Post-Branch, то есть после того, как сработал стандартный обработчик события SetFieldValue.
Для начала необходимо создать Набор действий (Администрирование – События во время выполнения --> Наборы действий) с одним действием, параметры которого необходимо заполнить следующим образом:
| Тип действия | АвтобусСервис |
| Название бизнес-услуги | Менеджер рабочих процессов |
| Метод бизнес-услуг | ЗапуститьПроцесс |
| Контекст бизнес-услуг | «ProcessName», «Процесс преобразования телефона SBL» |
После очистки кэша событий времени выполнения и активации рабочего процесса мы можем проверить с помощью журнала, что заглушка срабатывает в нужный для нас момент. Уровень журналирования рабочего процесса задается для каждой активированной версии на странице Администрирование – Бизнес-процесс --> Развертывание рабочего процесса --> Активный рабочий процесс:
Лучше всего установить третий уровень журналирования во время отладки.
Теперь факт запуска вы можете увидеть на странице Администрирование – Бизнес-процесс --> Монитор экземпляра рабочего процесса --> Экземпляры процесса: 
На этом этапе все готово для написания самого обработчика, который будет читать введенный пользователем номер телефона, обрабатывать его и обновлять поле бизнес-компоненты новым значением.
Чтение данных
Как говорилось ранее, созданный Workflow получит весь контекст, с которым работал пользователь, и начнет действовать от его имени.То есть нет необходимости делать какой-либо запрос по бизнес-компоненту «Контакт» — в этом случае вы можете сразу прочитать значение интересующего нас поля.
Чтобы прочитать данные в Workflow, вам необходимо объявить новую переменную Phone: 
Это будет внутренняя текстовая переменная.
Я рекомендую читать значения полей бизнес-компонентов в Workflow следующим образом:
- Создайте шаг с типом Бизнес-услуга.
- Заполните свойство этого шага:
- Имя: Читать телефон
- Название бизнес-услуги: Утилиты рабочих процессов
- Метод бизнес-услуг: Echo
- Для каждого поля, значение которого необходимо прочитать, на вкладке Выходные аргументы создайте запись со следующими свойствами:
- Имя свойства: Телефон (имя переменной рабочего процесса, в которую следует считывать данные)
- Тип: Бизнес-компонент
- Имя бизнес-компонента: Контакт (название бизнес-компонента, из которого будут взяты данные)
- Поле бизнес-компонента: Рабочий телефон № (название поля бизнес-компонента, из которого будут взяты данные)
Я настоятельно не рекомендую использовать шаг с типом операции Siebel для чтения данных из полей бизнес-компонентов.
Если сейчас активировать новую версию Workflow, установить для нее 3-й уровень журналирования и обновить поле, то в журнале Workflow появится значение номера рабочего телефона, введенное пользователем: 
Плагин трансформации телефона
После проделанных действий процессор научился считывать необходимые данные в нужный момент. Теперь имеет смысл написать алгоритм, который будет преобразовывать полученный номер телефона в заданный формат. Для этого вы можете создать отдельный бизнес-сервис или новый Workflow. Какой именно инструмент мы используем для реализации этого алгоритма сейчас не имеет особого значения, поэтому здесь я сделаю небольшой заполнитель, который просто добавит «+» к введенному значению.Для решения этой проблемы вам потребуется воспользоваться бизнес-сервисом Workflow Utility, который уже использовался ранее.
Он нужен именно для обновления значений переменных Workflow: считать данные из полей бизнес-компонента или применить какую-то формулу.
В этом случае переменная Phone обновляется значением, полученным путем объединения текущего значения переменной и символа «+».
[&Phone] — доступ к переменной Workflow.
Обновление поля
После преобразования телефона созданному Workflow нужно объяснить, как записать данные обратно в то же поле.
Для этого используйте шаг с типом Siebel Operation: 
В этом случае нам нужна операция обновления бизнес-компонента «Контакт».
Поле, которое необходимо обновить, — [Work Phone #], значение следует взять из переменной Phone. Вы можете проверить промежуточный результат, сначала активировав новую версию Workflow и установив для новой версии 3-й уровень журналирования.
Это ошибка, которую пользователь получает при обновлении поля со значением 1234567890: 
Система жалуется, когда мы пытаемся записать слишком длинное значение в поле [Номер рабочего телефона].
Текущее значение в этом поле: «++++++++++++++++++++++++++++++++1234567890».
На экране мониторинга рабочего процесса отображается следующий список: 
Фактически система вошла в рекурсию, что в целом логично, так как при обработке события SetFieldValue мы снова инициировали это же событие.
Это означает, что нам нужно каким-то образом запретить системе вызывать этот обработчик, если она выполняет этот рабочий процесс.
Атрибуты профиля
Эту проблему можно решить с помощью инструмента «Атрибуты профиля».По сути, атрибуты профиля — это набор глобальных переменных, которые хранятся в текущем сеансе пользователя.
Общую идею решения проблемы можно описать так: перед обновлением поля в Workflow устанавливается определенный флаг, который будет сигнализировать системе о том, что трансформацию телефона сейчас начинать не нужно, а после обновления флаг сброшен.
На практике реализация будет выглядеть так:
- Перед выполнением шага рабочего процесса, который обновляет поле [№ рабочего телефона], атрибут профиля, например SBLNoTransformContactWorkPhone, объявляется и ему присваивается значение «Y».
- В рамках события времени выполнения система проверяет наличие этого атрибута и его значение.
Если он существует и его значение равно «Y», то никакой обработчик запускать не нужно.
- После выполнения шага рабочего процесса, который обновляет поле [№ рабочего телефона], тот же атрибут профиля объявляется со значением «N».
Проверка значения атрибута профиля в событии времени выполнения условного выражения:
После обновления кеша и активации новой версии Workflow вы увидите следующие результаты.
Ввод данных: 
Переход к следующему полю: 
Если вы посмотрите на базу данных, вы заметите, что это новое значение уже есть.
Отсюда вывод: шаг Workflow с типом Siebel Operation, который обновляет поля бизнес-компонента, вызывает не только событие SetFieldValue, но и событие WriteRecord. После того как система научилась считывать данные и обновлять их, можно начинать процедуру преобразования.
Этот материал выходит за рамки событийной модели, поэтому здесь рассматриваться не будет.
выводы
Понимание событийной модели может существенно упростить жизнь как архитектору, проектирующему систему, так и разработчикам, которым необходимо реализовать все максимально быстро и эффективно.Предложенное решение задачи далеко от идеала и используется здесь лишь для демонстрации возможностей системы.
Теги: #Siebel CRM RTE
-
Первые Ингредиенты
19 Oct, 24 -
Микрофронтенд: Как Не Попасть К Черту
19 Oct, 24 -
Страхование Киберрисков
19 Oct, 24 -
Стоит Ли Идти В Управление И Зону
19 Oct, 24 -
Bitcasa Продолжает Ускоряться
19 Oct, 24 -
Первый Неуверенный Шаг На Пути К Cio!
19 Oct, 24
