Подієва модель Oracle Siebel CRM (Частина 3)

Введення
У попередніх статтях (частина 1, частина 2) я розглянув особливості запуску і обробки основних подій бізнес-компонент: SetFieldValue і WriteRecord. Тепер я хочу звернутися до інтерфейсу і подивитися на те, як аплет обробляє натискання на кнопку.



Практично на кожному аплеті ми бачимо набір стандартних кнопок, які дозволяють виконувати базові операції, такі як створення, видалення, запит. Крім них часто зустрічаються кнопки, які викликають більш специфічні процедури: складний розрахунок параметрів, верифікація та генерація даних, запит даних з зовнішньої системи і т.д.

Принцип роботи всіх кнопок однаковий, як стандартних, так і специфічних. Фактично, кожна з них викликає на аплеті подія InvokeMethod, якому в якості параметру передається той метод, який заздалегідь визначений на конкретній кнопки:



Схема обробки події
Схема обробки події виглядає наступним чином:



1. Система перевіряє, чи є обробник події на гілці Pre-Branch цієї події на рівні аплету. Якщо цього обробника немає, або він є і відпрацював без помилок, то система звертається до стандартного сценарію обробки аплету.

2. Стандартний обробник аплету дивиться, чи вміє він обробляти викликаний метод. Якщо не вміє, чи вміє і обробник відпрацював без помилок, то стандартний обробник аплету ініціює подія InvokeMethod на бізнес-компоненті, на якій заснований аплет.

3. Система знову перевіряє, чи є обробник на Pre-Branch цієї події для даної бізнес компоненти. Вже після цього управління передається на рівень стандартного обробника бізнес компоненти.

4. Стандартний обробник дивиться на метод, який йому передали разом з подією InvokeMethod, і, якщо він його не впізнає, то система зупинить обробку і відобразить помилку. Якщо цей метод знаком бізнес-компоненті, то вона обробить його, і після цього управління перейде на гілку Post-Branch події InvokeMethod на рівні бізнес компоненти.

5. Якщо на даній гілці визначений якийсь обробник, то він зробить свою роботу. У разі якщо тут не сталося ніяких помилок, то далі управління перейде вже на гілку Post Branch події InvokeMethod на рівні аплету.

Доступ до натискання кнопки
Знаючи цю схему, можна легко розширити функціональність будь-яких стандартних обробників і ставити свою бізнес-логіку, але найчастіше розробники визначають зовсім нові методи, які стандартні оброблювачі події InvokeMethod ні на аплеті, ні на бізнес компоненті не знають. Виходячи з схеми, виходить, що якщо обробка такого методу дійде до рівня бізнес-компонент, то користувач отримає помилку.

Крім цієї проблеми, виникає ще питання доступу до виклику події InvokeMethod для конкретного методу. За замовчуванням Siebel, якщо він не знає метод, визначений на кнопці, то кнопка не доступна для натискання.





Вирішити цю проблему можна декількома способами. Одним з найпоширеніших способів є скрипт на рівні аплету:

function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke)
{
if (MethodName == "TestMethod")
{
CanInvoke = "TRUE";
return (CancelOperation);
}

return (ContinueOperation);
}



Таке рішення є досить гнучким і дозволяє писати складну логіку для визначення доступу до даного методу, а, відповідно, і до натискання кнопки. Тим не менш, є більш елегантні варіанти рішення. Наприклад, це можна визначити User Property на рівні аплету CanInvokeMethod: <Ім'я методу>. Значенням цієї властивості може бути будь-логічний вираз, написаний на мові Siebel Query Language, включаючи використання функції ParentFieldValue для доступу до полів батьківського бізнес-компоненти.





Помилка стандартного обробника
Як тільки кнопка стає доступною для натискання, з'являється можливість написати власний обробник. Тим не менш, як я вказував раніше, ми отримаємо помилку, яку повертає стандартний обробник події InvokeMethod на рівні бізнес-компоненти:



Є два підходи до того, як уникнути цієї помилки. Перший заснований на тому, щоб не дати системі дійти до стандартного обробника на рівні бізнес-компоненти. Це можна зробити, якщо зупинити обробку на Pre-Branch аплету або бізнес-компоненти через скрипт:

function BusComp_PreInvokeMethod (MethodName)
{
if (MethodName == "TestMethod")
{
// Do Something

return (CancelOperation);
}

return (ContinueOperation);
}

Оператор return (CancelOperation); зупиняє всю подальшу обробку.

Другий підхід заснований на тому, щоб сказати стандартного сценарію обробки, що на даний метод ніяких помилок виводити не треба. Тут знову з'являється два способи це зробити. Перший пов'язаний з використанням User Property «Named Method n» на рівні аплету або на рівні бізнес компоненти. Використання цієї властивості я планую розглянути в наступній статті. Тут же ми подивимося на найбільш простий і цікавий спосіб, пов'язаний з використанням префікса EventMethod в імені методу.

Суть дуже проста: коли вказуєте назву методу для кнопки, якщо він не є стандартним, його потрібно починати з EventMethod. Коли стандартний обробник події InvokeMethod на бізнес компоненті отримує таку назву методу, він просто нічого сам не робить, а передає керування далі за схемою. Якщо в розглянутому прикладі назву методу змінити на EventMethodTestMethod, то отримаємо таку картину:





Кнопка активна, і натискання на неї не призводить до помилок. Можна ще відзначити той факт, що я ніяким чином не змінював логіку активації кнопки: скрипта ніякого немає, властивість CanInvokeMethod займається активацією суворо методу TestMethod. Таким чином, це рішення відразу двох проблем.

Використовуючи такий підхід, ми змінюємо основну парадигму. Тепер все, що не заборонено, дозволено. Значить, після додавання кнопки потрібно обов'язково задуматися на тему того, як обмежити доступ до даної кнопці. Для цього можна використовувати вже розглянутий вище CanInvokeMethod.

Важливе зауваження: для того, щоб трюк з EventMethod працював правильно, необхідно, щоб клас бізнес-компоненти, на якому заснований аплет, який дорівнював або CSSBCBase, або будь успадкованому від нього. Це означає, що для класу CSSBusComp, який за замовчуванням прописується для кожної нової бізнес-компоненти, таке рішення працювати не буде.

Висновки
1. При створенні нових бізнес-компонент завжди вказуйте ім'я класу CSSBCBase. Він дає досить багато корисних речей, в тому числі функціональність, пов'язану з EventMethod.

2. При створенні кнопок, які автоматизують функціонал системи, рекомендую використовувати у назві методу EventMethod для її активації і CanInvokeMethod для правил розмежування доступу. Це суттєво допоможе скоротити кількість скриптів і полегшить процес розробки.

3. За умови дотримання попереднього пункту, обробники натискання кнопок можна вішати на будь-яку гілку, як на Pre-Branch, так і на Post-Branch. Бажано ставити логіку саме на рівні аплету.

4. За допомогою властивості CanInvokeMethod можна обмежувати по заздалегідь заданій умові доступ до стандартних методів аплету: NewRecord, DeleteRecord, NewQuery, ExecuteQuery. При цьому при обмеженні доступу до методу NewRecord не варто використовувати поля поточної сутності. Швидше за все, там буде звернення до профільних атрибутів через функцію GetProfileAttr() або до полів батьківського запису через функцію ParentFieldValue().

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.