- Головна
- /
- Стаття
Механізм бізнес-правил (BRE) у контакт-центрі Webex дозволяє клієнтам завантажувати певні дані, до яких система може отримати доступ під час виконання, щоб приймати рішення щодо маршрутизації або відображати інформацію для операторів зв'язку.
Cisco© Business Rules Engine – це застосунок, який допомагає швидко шукати дані в контакт-центрі Webex. Використовуючи Cisco© Business Rules Engine (BRE), ви можете виконувати пошук даних, налаштовувати маршрутизацію та загальне впровадження. Система отримує дані під час виконання та використовує їх для прийняття рішень щодо маршрутизації або відображення інформації агенту.
Наприклад, орендар хоче направляти дзвінки певній групі агентів на основі набраного номера автоматичної ідентифікації номера (ANI). У цьому сценарії орендар може просто завантажити список ANI. Якщо ANI вхідного виклику є у цьому списку, система спрямовує виклик до вказаної групи агентів. Якщо ANI немає у списку, система перенаправляє виклик до загальної черги.
Типова реалізація BRE включає такі основні компоненти:
-
Синхронізація даних BRE: Утиліта конфігурації BRE DataSync надає інтерфейс для визначення екземплярів Data Sync для імпорту даних до бази даних BRE. Після того, як клієнт визначить екземпляр Data Sync, він може завантажити CSV-файл. Система перетворює завантажені значення, розділені комами, на записи в базі даних BRE.
-
Механізм бізнес-правил: Утиліта Business Rules Engine надає інтерфейс для створення доменів та наборів правил. BRE вимагає, щоб вхідний запит на рішення був пов'язаний з доменом. Домен містить набір правил. Кожному правилу призначається пріоритет. BRE намагається зіставити правило з найвищим пріоритетом домену із запитом на рішення на основі умов у правилах.
-
Дизайнер потоків: Інтерфейс користувача з функцією перетягування, який використовується для визначення процесів, що координують та автоматизують компоненти контакт-центру Webex. Ви можете створити потік, який викликає дію BRE для виконання простого пошуку даних, подібного до дії HTTP-запиту. Однак у цьому випадку дані зберігаються в контакт-центрі Webex.
Керівні принципи обробки даних
Для підтримки цілісності та безпеки BRE необхідно дотримуватися наступних правил обробки даних:
-
Допустимі типи даних: Завантажте дані, необхідні для роботи та функціональності BRE. Це включає, але не обмежується, бізнес-правилами, конфігураціями та неконфіденційними операційними даними.
-
Обмеження щодо ідентифікаційної інформації: Не завантажуйте жодної особистої інформації (PII) до BRE, окрім даних ANI. Особиста інформація включає, але не обмежується:
- Повні імена
- Номери соціального страхування
- Адреси електронної пошти
- Фізичні адреси
- Фінансова інформація
Дані ANI відносяться до номера телефону, пов'язаного з абонентом, що телефонує. Дані ANI – це єдиний тип ідентифікаційної інформації, який дозволено завантажувати до BRE. Цей виняток призначений для підтримки певних бізнес-функцій, які залежать від даних ANI.
Механізм бізнес-правил складається з механізму правил реального часу, який викликається потоком, пов'язаним з точкою входу. Цей механізм правил зазвичай консультується зі сховищем даних, щоб оцінити бажаний спосіб обробки викликів.
Пошук BRE — це простий провал даних у вашому потоці, як-от HTTP-запит. Однак дані для пошуку BRE знаходяться в центрі обробки даних контакт-центру Cisco Webex. На наступному зображенні показано різні процеси, що беруть участь у пошуку даних BRE.
Перш ніж почати
Перш ніж впроваджувати BRE:
- Налаштуйте екземпляр BRE DataSync для вашої реалізації з чітким розумінням моделі даних.
- Ознайомтеся з наступною термінологією, що використовується в цьому посібнику:
Attribute:attribute— це іменована змінна або поле даних, створене в утиліті BRE. Він служить контейнером для інформації, яку BRE використовує для обробки запитів та генерації результатів.Context:contextв основному використовується як приклад назви атрибута, що вказує на цільовий домен для дії запиту BRE.Label:Label— це специфічний тип атрибута, призначений для зберігання виводу або результату оцінки правила.
Див. розділ Найчастіші запитання для отримання додаткової інформації.
Налаштування екземпляра BRE DataSync
Утиліта BRE DataSync отримує доступ до бази даних для прийняття рішень щодо маршрутизації. Забезпечте періодичне оновлення бази даних відповідною інформацією. У цьому розділі описано, як налаштувати утиліту BRE DataSync для оновлення репозиторію BRE.
Адміністратор клієнта повинен створити екземпляр BRE DataSync для кожного набору даних, з яким звертаються механізми правил під час процесу прийняття рішень. Адміністратор може створити набір даних або завантажити CSV-файл. Дані конвертуються в записи в репозиторії BRE.
Перш ніж почати
Зверніться до менеджера з обслуговування клієнтів Cisco, щоб отримати доступ до облікового запису BRE DataSync.
BRE DataSync наразі ввімкнено лише для ролі Повний адміністратор. Орендарі з роллю повного адміністратора можуть завантажувати дані або за допомогою CSV-файлу, або за допомогою пар ключ-значення. Користувачі з цією роллю можуть завантажувати лише дані, що стосуються їхньої організації.
Адміністратор-партнер, зовнішній адміністратор, агенти та керівники не мають доступу до утиліти BRE DataSync.
| 1 |
Як адміністратор, увійдіть до утиліти BRE DataSync. Відповідно до нещодавніх удосконалень у BRE Hosting and Scalability, URL-адреси для утиліти DataSync змінилися. Обов’язково використовуйте оновлені URL-адреси для завантаження даних у BRE. URL-адреси BRE DataSync для регіонів: https://bre-datasync.produs1.ciscoccservice.com/datasync/ https://bre-datasync.prodeu1.ciscoccservice.com/datasync/ https://bre-datasync.prodeu2.ciscoccservice.com/datasync/ https://bre-datasync.prodanz1.ciscoccservice.com/datasync/ https://bre-datasync.prodca1.ciscoccservice.com/datasync/ https://bre-datasync.prodjp1.ciscoccservice.com/datasync/ https://bre-datasync.prodsg1.ciscoccservice.com/datasync/
Клацніть URL-адреси, щоб перейти на сторінку Вхід із використанням спільної ідентифікації. Для регіону США виберіть кластер США (а не другий кластер США) , щоб продовжити. URL-адреси інтерфейсу адміністратора BRE для регіону: https://bre.produs1.ciscoccservice.com/bre/ https://bre.prodeu1.ciscoccservice.com/bre/ https://bre.prodeu2.ciscoccservice.com/bre/ https://bre.prodanz1.ciscoccservice.com/bre/ https://bre.prodca1.ciscoccservice.com/bre/ |
| 2 |
Виберіть Список даних BRE, щоб переглянути всю інформацію, пов’язану з організацією-орендарем. |
| 3 |
Щоб додати дані у вигляді пар ключ-значення до репозиторію BRE: Виберіть Додати дані BRE |
| 4 |
Щоб завантажити CSV-файл до репозиторію BRE: Виберіть Завантажити дані BRE CSV. |
Доступ до програми BRE
Ви можете отримати доступ до програми Business Rules Engine з порталу адміністрування Webex Contact Center.
- Увійдіть на портал адміністрування контакт-центру Webex.
- Натисніть Бізнес-правила, щоб відкрити панель інструментів Business Rules Engine.
BRE використовує службу ідентифікації та взаємодію єдиного входу. Якщо ви вже ввійшли за допомогою Common Identity, ви можете отримати доступ до утиліти BRE для вашої організації, не входячи повторно.
Система відкриває програму Business Rules Engine (BRE) у новій вкладці браузера. З’явиться сторінка «Інформаційна панель» із графічним представленням кількості правил та виконань.
Створення набору правил

Відкрийте портал BRE та налаштуйте атрибут, мітку, контекст і правила, як описано нижче.
| 1 |
Щоб створити атрибут для зв’язку з вашою організацією: |
| 2 |
Мітка додає сенсу вашим даним. Щоб створити мітку: |
| 3 |
Натисніть Контексти, щоб перейти на сторінку Контексти. Натисніть +Add Контекст. |
| 4 |
Щоб створити правила, перейдіть на сторінку Контексти. Натисніть +Add Редактор правил та налаштуйте такі деталі:
Створіть два правила: один, якщо система знаходить збіг, і інший, коли система не знаходить збігу. Наведений нижче приклад коду повертає значення NotFound для атрибута routeInfo. Це трапляється, якщо номер, з якого набрав абонент (ANI), не відповідає ANI у списку орендарів, завантажених до бази даних BRE. Скопіюйте та вставте наступне правило в редактор правил: |
| 5 |
Клацніть Зберегти. |
Запит на BRE
Використовуйте дію запиту BRE, щоб отримати дані з механізму бізнес-правил (BRE) вашої організації для використання в потоці. Дія запиту BRE використовує стандартні протоколи HTTP для отримання даних з BRE.
У наступних розділах можна налаштувати дію запиту BRE:
Загальні налаштування
|
Параметр |
Опис |
|---|---|
|
Мітка активності |
Введіть назву для активності. |
|
Опис діяльності |
(Необов’язково) Введіть опис дії. |
Параметри запиту
Як частину запиту BRE, ви можете передавати параметри, надані у виклику API, до BRE. У стовпцях «Ключ-значення» можна ввести ключ для запиту та пов’язане з ним значення, яке потрібно надіслати разом із запитом. Ви також можете використовувати синтаксис подвійних фігурних дужок для передачі значень змінних.
Діяльність BRE має один попередньо визначений параметр запиту: context. Цей параметр запиту передається у виклику API до BRE.
TenantID автоматично вводиться як параметр і не потребує налаштування.
|
Параметр |
Опис |
|---|---|
|
Контекст |
Містить причину запиту. Цей обов'язковий параметр не можна редагувати або видаляти. Цей параметр повинен містити те саме значення, що й значення, вказане в атрибуті |
|
ANI |
Містить номер телефону, з якого було здійснено дзвінок. Це параметр за замовчуванням, який можна редагувати або видаляти залежно від конфігурації правил у BRE. Приклад значення для ANI: |
|
Час очікування відповіді | Визначає час очікування з'єднання для запиту BRE. За замовчуванням встановлено значення 2000 мілісекунд. |
|
Кількість повторних спроб |
Вказує кількість спроб виконання запиту BRE після невдачі. Цей параметр використовується, якщо код стану 5xx; наприклад, 500 або 501. |
Щоб додати параметр запиту, натисніть Додати новий. Це додає рядок, куди можна ввести пари ключ-значення. Ви можете додати стільки параметрів запиту, скільки потрібно, як частину запиту BRE.
Налаштування розбору
Цей розділ дозволяє вам розбити відповідь із запиту BRE на різні змінні:
|
Параметр |
Опис |
|---|---|
|
Змінна відповіді |
Виберіть змінну, в яку потрібно витягти певний розділ з об'єкта відповіді запиту BRE. Ви можете вибрати лише змінні Custom Flow зі спадного списку. |
|
Вираз шляху |
Визначте вираз шляху для розбору об'єкта відповіді. Залежно від типу структури даних об'єкта відповіді та випадків використання для вилучення підмножини цієї інформації, вираз шляху змінюється. Дані нормалізуються до ієрархії об'єктів перед виконанням Path Expression, тому JSONPath використовується в об'єкті відповіді незалежно від налаштованого типу вмісту. |
Налаштування розшифрування
Ви можете розшифрувати вихідні змінні дії запиту BRE. Якщо розшифрування ввімкнено на рівні потоку, користувачі з доступом до розшифрування налагодження можуть переглядати немасковані вихідні значення активності запиту BRE у журналах налагодження потоку. Вимкніть перемикач Увімкнути розшифрування, щоб вимкнути розшифрування на рівні активності для додаткового захисту.
Вихідні змінні
Запит BRE повертає дві вихідні змінні:
-
BRERequest1.httpResponseBody: Повертає тіло відповіді для запиту BRE. -
BRERequest1.httpStatusCode: Повертає код стану запиту BRE.Ці коди відповідей класифікуються за такими категоріями:
-
Інформаційні відповіді (100–199)
-
Успішні відповіді (200–299)
-
Перенаправлення (300–399)
-
Помилки клієнта (400–499)
-
Помилки сервера (500–599)
-
Формати типів вмісту
У наведених нижче прикладах описано зразки форматів вхідних типів вмісту та відповідь JSON.
Тип вмісту XML
Використовуйте цей інструмент для конвертації XML у формат JSON https://codeshack.io/xml-to-json-converter/.
Формат вхідних даних XML:
Tove
Jani
Reminder
Test application
Data/JSON Нормалізована відповідь
{
"note": {
"to": "Tove",
"from": "Jani",
"heading": "Reminder",
"body": "Test application"
}
}
Приклад виразу шляху JSON: Використайте $.note.from, щоб отримати значення як Jani.
Тип вмісту TOML
Використовуйте цей інструмент для конвертації TOML у формат JSON https://www.convertjson.com/toml-to-json.htm.
Формат вхідних даних TOML:
title = "TOML Example"
[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00
Data/JSON Нормалізована відповідь
{
"title": "TOML Example",
"owner": {
"name": "Tom Preston-Werner",
"dob": "1979-05-27T15:32:00.000Z"
}
}
Приклад виразу шляху JSON: Використайте $.owner.name, щоб отримати значення як ‘Tom Preston-Werner’.
Тип контенту YAML
Використовуйте цей інструмент для конвертації YAML у формат JSON https://www.convertjson.com/yaml-to-json.htm.
Формат вхідних даних YAML:
# An employee record
martin:
name: Martin D'vloper
job: Developer
skill: Elite
Data/JSON Нормалізована відповідь
{
"martin": {
"name": "Martin D'vloper",
"job": "Developer",
"skill": "Elite"
}
}
Приклад виразу шляху JSON: Використайте $.martin.job, щоб отримати значення Developer.
Тип вмісту JSON
Використовуйте оцінювач виразів JSON https://jsonpath.com/.
Формат вхідних даних JSON:
{
"martin": {
"name": "Martin D'vloper",
"job": "Developer",
"skill": "Elite"
}
}
Data/JSON Нормалізована відповідь
{
"martin": {
"name": "Martin D'vloper",
"job": "Developer",
"skill": "Elite"
}
}
Приклад виразу шляху JSON: Використайте $.martin.job, щоб отримати значення Developer.
Створення потоку з активністю запиту BRE
Ви можете створювати потоки за допомогою інтерфейсу Flow Designer, доступного в контакт-центрі Webex. Створіть потік за допомогою дії Запит BRE у конструкторі потоків Webex Contact Center.
Для отримання додаткової інформації про налаштування потоку див. Запит BRE.
Поширені запитання
- Яке призначення
attribute?Attributesє фундаментальними для зв'язування вхідних запитів пошуку BRE з певними наборами правил, визначеними в BRE, та для зберігання результатів оцінки правил. - Як ви створюєте
attributes?Створити
attributesу розділі в утиліті BRE. Наприклад, ви можете створити атрибут з назвоюcontext. - Яке призначення
context?Contextвизначає конкретний сценарій або тип пошуку, який застосовує BRE. Коли потік викликає дію запиту BRE, він повинен повідомити BRE, який набір правил оцінювати. Атрибут, який часто називаютьContext, встановлюється на ім'я конкретного домену. - Що таке
domain?Таблиця
domainу BRE містить відповідні дані. Доменне ім'я спрямовує BRE до правильних даних та відповідного набору правил. - Що таке
label?Після того, як BRE оцінить свої правила, воно має повідомити результат назад до системи, що викликає (наприклад, потік контакт-центру Webex, що містить дію запиту BRE). Правила налаштовано для встановлення значення призначеного атрибута мітки на основі їхніх умов.
- Який зв'язок між атрибутом, контекстом та міткою?
Ви можете створити
Attribute, наприклад, з назвоюcontext. Ви можете пов'язати цей атрибут зdomain(фактичною таблицею, такою як ANILookup). Під час виклику дії BRE Request потік встановлює значення цього атрибута (тобтоdomain= ANILookup), щоб вказати контекст (правила якого домену використовувати).У цьому
domainправила написані в синтаксисі Drools для оцінки умов та встановлення значення іншогоattribute, який часто називаютьlabel(наприклад,label= "Знайдено збіг"). Це представляє результат правила, який повертається як відповідь на потік. -
Як атрибути, контексти та мітки пов'язані з параметрами запиту?
BRE викликається потоком, зазвичай через виклик API (діяльність запиту BRE) до жорстко закодованої внутрішньої URL-адреси. Це REST API, який дозволяє шукати значення BRE, завантажені у форматі CSV. (key/value пари). Дані, необхідні для прийняття рішення BRE, передаються як частина цього запиту, подібно до того, як параметри запиту або тіло запиту функціонують у звичайному виклику REST API.
Input Data: Інформація з вхідного виклику (наприклад, ANI абонента, номер облікового запису та інші подібні дані) фіксується як змінні даних, пов’язаних із викликом (CAD), у процесі обробки викликів Webex Contact Center.BRE Configuration Data: Інші необхідні параметри, такі як контекст та атрибут, що вказує на домен (наприклад, domain = ANILookup), також встановлюються як змінні у вузлі BRE Request Flow.Request Variables: На кроці запиту BRE в Потоці змінні САПР та налаштовані змінні вибираються як змінні в конфігурації запиту BRE. Потім ці змінні надсилаються до виконавчого бекенду BRE.Function: По суті, «Змінні запиту» діють як «параметри запиту» або вхідне корисне навантаження для BRE. BRE використовує ці вхідні значення для оцінки умов, визначених у його правилах.
Налаштування пошуку даних клієнтів на основі ANI за допомогою механізму бізнес-правил
У цьому зразку робочого процесу використовується Business Rules Engine (BRE) для пошуку даних клієнтів за допомогою автоматичної ідентифікації номера абонента (ANI), обробки повернутих даних у процесі контакт-центру Webex та відображення вибраної інформації на робочому столі агента. Кроки описані нижче:
Підготуйте дані для пошуку
Створіть CSV-файл, що містить унікальний ключ пошуку та пов'язані з ним дані. Для цього робочого процесу ANI абонента використовується як ключ пошуку. Зберігайте одне або кілька полів клієнта у стовпці значень. Розділіть кілька полів вертикальною рискою (|).
15551234567,VIP Customer|John Smith|Premium Queue|Toronto 15559876543,Standard Customer|Jane Smith|General Queue|Vancouver У цьому прикладі стовпець 1 містить ANI, а стовпець 2 містить тип клієнта, ім'я клієнта, чергу та місцезнаходження.
BRE призначена для пошуку, орієнтованого на читання, а не як транзакційна база даних для часто оновлюваних окремих записів.
Створення типу пошуку BRE та завантаження даних
Відкрийте інструмент синхронізації даних Webex Contact Center BRE та виберіть свого клієнта. Якщо потрібний тип пошуку недоступний, попросіть операційну команду створити його. Використовуйте описову назву, наприклад ANILookup. Запишіть згенеровану назву контексту, оскільки конфігурація та потік BRE повинні використовувати однакове значення з урахуванням регістру.
Щоб додати тестовий запис:
- Відкрити Додати дані.
- Виберіть орендаря та
ANILookup. - Введіть ANI та пов’язане з ним значення.
- Надішліть запис.
Щоб завантажити повний набір даних, відкрийте Завантажити BRE, виберіть орендаря та тип пошуку, а потім завантажте файл CSV. Відкрийте Список даних BRE та переконайтеся, що записи відображаються. Переконайтеся, що формат ANI у CSV-файлі відповідає формату, надісланому потоком.
Запуск бізнес-правил
Увійдіть на портал адміністрування контакт-центру Webex, відкрийте Бізнес-правилата запустіть панель інструментів BRE:
Створіть атрибут контексту:
- Перейти до
- Додайте атрибут із такими значеннями:
- Ім’я:
context - Тип даних: Текст
- Ім’я:
- Збережіть атрибут результату. Атрибут
contextвизначає завантажений набір даних пошуку, до якого запитує правило. - Додайте текстовий атрибут, який представляє повернуті дані. Дайте атрибуту змістовне ім'я, навіть якщо повернене значення містить кілька полів, розділених вертикальними рисками. Збережіть атрибут. У цьому прикладі як зразок використовується
customerType. - Відкрийте Контексти та додайте контекст. Введіть згенеровану назву контексту синхронізації даних, наприклад
ANILookup, пов’яжіть її з атрибутомcontextта збережіть. Назва контексту враховує регістр і має точно відповідати згенерованому контексту синхронізації даних.
Створити правило ANI-found та правило ANI-not-found
Відкрийте контекст і виберіть Додати редактор правил. Назвіть правило ANIFound, активуйте його та призначте йому вищий пріоритет, наприклад 100. Додайте наступне правило та збережіть його:
when c: Contact() eval(c.getGlobalValuesManager().getAsString( c.getTenantId(), c.getAttribute("context") + "." + c.getAttribute("ani") ) != null) then c.putAttribute( "customerType", c.getGlobalValuesManager().getAsString( c.getTenantId(), c.getAttribute("context") + "." + c.getAttribute("ani") ) ); end Правило поєднує контекст та ANI для формування ключа пошуку. Коли відповідне значення існує, результат присвоюється атрибуту відповіді customerType.
Додайте ще одне активне правило з назвою ANINotFound. Призначте йому нижчий, унікальний пріоритет, наприклад 99. Налаштуйте правило так, щоб воно встановлювало значення customerType на Not Found, коли відповідного запису не існує, і збережіть його. Не призначайте однаковий пріоритет обом правилам.
Створення потоку контакт-центру
Відкрийте Flow Designer та створіть або відкрийте тестовий потік. Додайте дію BRE Request у точці, де потік має отримати інформацію про абонента, та підключіть дію до відповідного шляху потоку.
Нормалізувати ANI
Якщо завантажені ключі не містять префікса коду країни +1, створіть вираз попередньої обробки, який видаляє його з ANI:
ANI.replace("+1", "") Використовуйте нормалізоване значення як ключ пошуку. Застосовуйте це перетворення лише тоді, коли збережені значення не містять +1; Значення запиту та завантажені ключі повинні використовувати однаковий формат.
Налаштування запиту BRE
Налаштуйте дію з такими значеннями:
- Контекст:
ANILookup - Атрибут запиту:
ani - Значення запиту: Нормалізований ANI
- Тайм-аут: 5 секунд
- Повторні спроби: 3
- Атрибут відповіді:
customerType
Зіставте відповідь зі змінною потоку рядків. Контекст вибирає набір даних, тоді як ani надає окремий ключ запису.
Обробка багатопольової відповіді
Якщо BRE повертає VIP Customer|John Smith|Premium Queue|Toronto, розділіть рядок за допомогою роздільника у вигляді вертикальної риски (\|). Отримані елементи містять тип клієнта, ім'я клієнта, чергу та місцезнаходження. Призначте необхідні елементи окремим змінним потоку. У демонстрації витягується останній елемент, Toronto.
Налаштування спливаючого вікна
Додайте або налаштуйте дію спливаючого вікна на робочому столі агента. Зіставте витягнуту інформацію про клієнта з потрібним полем спливаючого вікна, підключіть потік до черги або шляху маршрутизації агента, а потім збережіть і опублікуйте потік.
Перевірте демонстрацію
Здійснити виклик з ANI, який існує в завантаженому наборі даних. Переконайтеся, що потік нормалізує ANI, запит BRE виконується успішно, а витягнута інформація відображається на робочому столі агента. Повторіть тест з ANI, якого немає в наборі даних, і переконайтеся, що шлях «не знайдено» повертає налаштоване резервне значення.