Событийная модель Oracle Siebel CRM (Часть 2)

  • Tutorial
В данной статье будет рассмотрен учебный пример использования событийной модели. Кроме того, будет представлен инструмент Workflow, который позволяет реализовывать различные обработчики событий.

Задача: пользователь вводит данные в поле «Рабочий телефон» и перемещает курсор на другое место в интерфейсе. В этот момент система должна считать введенное значение, очистить от лишних символов и применить заранее установленный формат. Например, пользователь вводит «7999)44-333-22», уходит из поля, а значение меняется на «+7(999)443-33-22».

В Oracle Siebel CRM существует специальный тип данных DTYPE_PHONE, который может автоматически накладывать формат на текстовое поле, но у него есть ряд ограничений. В данном случае я рассматриваю вариант, когда поле «Рабочий телефон» является обычным текстовым полем.

Immediate Post Change


Для решения поставленной задачи необходимо написать свой обработчик события SetFieldValue. Поскольку требуется, чтобы он сработал в момент смены фокуса с поля [Work Phone #] на другую область экрана, в свойстве Immediate Post Change этого поля мы должны выставить значение «Y».



Run-Time Event и Workflow


Очисткой телефонного номера займется обработчик, сделанный с помощью Workflow, который в свою очередь будет запущен через Run-Time Event.

Для начала я создам простую заглушку на основе Workflow, которая пока ничего делать не будет:



Это Interactive Workflow, и он будет работать с бизнес-объектом Contact. Теперь, если этот Workflow будет вызван через Run-Time Event на экране (View), который основан на бизнес-объекте Contact, то он получит весь контекст, с которым работал пользователь, и все действия (обновление записей, удаление, создание, запрос данных) будут происходить от лица этого пользователя.

Непосредственно сам Workflow на данном этапе будет выглядеть вот так:



Первая версия обработчика готова, теперь его нужно привязать к событию SetFieldValue. Вопрос в том, к какой ветке его привязать: Pre-Branch или Post-Branch? Поскольку нам нужен доступ к вновь введенному значению, логично его привязать именно к Post-Branch, то есть после того, как отработает стандартный обработчик события SetFieldValue.

Сначала нужно создать Action Set (Administration – Run-Time Events --> Action Sets) с одним действием, параметры которого должны быть заполнены следующим образом:
Action Type BusService
Business Service Name Workflow Process Manager
Business Service Method RunProcess
Business Service Context «ProcessName», «SBL Phone Transformation Process»

Затем можно привязать этот обработчик к соответствующему событию:



После очищения кэша Run-Time Events и активации Workflow можно будет убедиться через логирование, что заглушка срабатывает в нужный для нас момент.

Уровень логирования Workflow устанавливается для каждой активированной версии на странице Administration – Business Process --> Workflow Deployment --> Active Workflow Process:



Лучше всего на момент отладки выставлять 3-й уровень логирования. Теперь увидеть факт запуска можно на странице Administration – Business Process --> Workflow Instance Monitor --> Process Instances:



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

Чтение данных


Как уже было сказано ранее, созданный Workflow получит весь контекст, с которым работал пользователь, и начнет действовать от его лица. То есть не надо делать какой-либо запрос по бизнес-компоненте Contact – в данном случае можно сразу считывать значение интересующего нас поля.

Для чтения данных в рамках Workflow потребуется объявить новую переменную Phone:



Это будет внутренняя текстовая переменная.

Чтение значений полей бизнес-компонент в рамках Workflow я рекомендую делать следующим образом:
  1. Создать шаг с типом Bussiness Service
  2. Заполнить свойство этого шага:
    • Name: Read Phone
    • Business Service Name: Workflow Utilities
    • Business Service Method: Echo

  3. Для каждого поля, значение которого необходимо считать, на закладке Output Arguments создать запись со следующими свойствами:
    • Property Name: Phone (имя переменной Workflow, в которую необходимо считать данные)
    • Type: Business Component
    • Business Component Name: Contact (имя бизнес-компоненты, из которой будут браться данные)
    • Business Component Field: Work Phone # (имя поля бизнес-компоненты, из которого будут браться данные)





Очень не рекомендую использовать шаг с типом Siebel Operation для чтения данных из полей бизнес-компоненты.

Если теперь активировать новую версию Workflow, установить для нее 3-й уровень логирования и обновить поле, то в журнале Workflow появится значение рабочего телефона, который ввел пользователь:



Заглушка для трансформации телефона


После проделанных шагов обработчик научился считывать нужные данные в нужный момент. Теперь имеет смысл написать алгоритм, который будет трансформировать полученный телефон в заданный формат. Для этого можно сделать отдельный бизнес-сервис или новый Workflow. Какой именно инструмент мы используем для реализации данного алгоритма, сейчас не имеет большого значения, поэтому здесь я сделаю небольшую заглушку, которая будет просто прибавлять «+» к введенному значению.

Чтобы решить эту задачу, потребуется использовать бизнес-сервис Workflow Utility, который уже был задействован ранее. Он нужен именно для того, чтобы обновлять значения переменных Workflow: считывать данные из полей бизнес-компонент или применять какую-то формулу.



В данном случае переменная Phone обновляется значением, которое получается из конкатенации текущего значения переменной и символа «+».

[&Phone] – обращение к переменной Workflow.

Обновление поля


После трансформации телефона созданному Workflow нужно объяснить, как записывать данные обратно в то же самое поле. Для этого используется шаг с типом Siebel Operation:



В данном случае нужна операция Update на бизнес-компоненте Contact. Поле, которое нужно обновить, равно [Work Phone #], а значение должно браться из переменной Phone.

Можно проверить промежуточный результат, предварительно активировав новую версию Workflow и выставив 3-й уровень логирования для новой версии.

Вот такую ошибку получает пользователь при обновлении поля значением 1234567890:



Система «ругается» на нашу попытку записать слишком длинное значение в поле [Work Phone #]. Значение, которое сейчас находится в этом поле, равно: «++++++++++++++++++++++++++++++1234567890».

На экране с мониторингом Workflow после этого отображается вот такой список:



Фактически система вошла в рекурсию, что, в общем, логично, так как мы при обработке события SetFieldValue опять инициировали то же самое событие. Значит, нужно каким-то образом запретить системе вызывать этот обработчик, если она выполняет данный Workflow.

Профильные атрибуты


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

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

  1. До выполнения шага Workflow, в котором обновляется поле [Work Phone #], объявляется профильный атрибут, например, SBLNoTransformContactWorkPhone, и ему присваивается значение «Y».
  2. В рамках Run-Time Event система проверяет наличие данного атрибута и его значение. Если он существует и его значение равно «Y», то никакого обработчика запускать не надо.
  3. После выполнения шага Workflow, в котором обновляется поле [Work Phone #], тот же профильный атрибут объявляется значением «N».


Обновление профильного атрибута внутри Workflow:



Проверка значения профильного атрибута в Conditional Expression Run-Time Event:



После обновления кэша и активации новой версии Workflow можно увидеть следующие результаты.

Ввод данных:



Переход в соседнее поле:



Если при этом посмотреть в базу данных, то можно заметить, что это новое значение уже там. Отсюда вывод: шаг Workflow с типом Siebel Operation, который обновляет поля бизнес-компоненты, вызывает не только событие SetFieldValue, но и WriteRecord.

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

Выводы


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

Комментарии 0

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое