В поисках разработчика Siebel на проект в одном из крупных Российский розничных банков, я провел довольно много собеседований с кандидатами и, к моему удивлению, вопрос про обработку событий привел в замешательство большинство и них. Поэтому, желая принять участие в восполнении этого пробела в знаниях коллег, я просто оставлю свой вольный пересказ статьи Event Handling здесь.

Тема очередности обработки событий занимала мой ум с тех самых пор, как я начал работать со скриптингом — технологией, позволяющей расширять функциональность Siebel CRM.

Без всяких сомнений, большинство Siebel консультантов хорошо знакомы со скриптингом. К сожалению, зачастую в своих стараниях они заходят настолько далеко, что весь проект становится похожим на цирк с конями.

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

event-handling-applet-named-method

Для этого я провел небольшой эксперимент, для которого потребовалось:

  • Создать бизнес сервис для трассировки
  • Добавить скрипты на уровне аплета и бизнес компоненты
  • Создать именованные методы
  • Настроить события обработки

Конечной целью каждого из пунктов был вызов бизнес сервиса трассировки.

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

event-handling-trace-file

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

event-handling-chart (1)

Siebel не был бы собой, если бы это была полная картина мира. Есть ещё кое что… и это… Сигналы, но о них как-нибудь в другой раз.

Веселитесь.