У цій статті
Вступ
dropdown icon
Впровадження механізму бізнес-правил
    dropdown icon
    Перш ніж почати
      Налаштування екземпляра BRE DataSync
    Доступ до програми BRE
    Створення набору правил
    dropdown icon
    Запит на BRE
      Загальні налаштування
      Параметри запиту
      Налаштування розбору
      Налаштування розшифрування
      Вихідні змінні
    Створення потоку з активністю запиту BRE
    Поширені запитання
    dropdown icon
    Налаштування пошуку даних клієнтів на основі ANI за допомогою механізму бізнес-правил
      Підготуйте дані для пошуку
Посібник користувача модуля бізнес-правил Webex Contact Center
list-menuУ цій статті
list-menuНадіслати відгук?

Механізм бізнес-правил (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 DataySync для оновлення репозиторію BRE. Синхронізація даних BRE > CRUD (неправильно визначений текст) > Репозиторій BRE.
Утиліта BRE DataSync

Адміністратор клієнта повинен створити екземпляр 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/

https://bre.prodjp1.ciscoccservice.com/bre/

https://bre.prodsg1.ciscoccservice.com/bre/

2

Виберіть Список даних BRE, щоб переглянути всю інформацію, пов’язану з організацією-орендарем.

3

Щоб додати дані у вигляді пар ключ-значення до репозиторію BRE: Виберіть Додати дані BRE

  1. Виберіть назву організації зі спадного списку TenantName.

  2. Виберіть Тип пошуку BRE з випадаючого списку.

    Див. наступні обмеження розміру для додавання типу пошуку BRE:

    • Максимальна кількість символів для типу пошуку BRE: VARCHAR(200)
    • Максимальна кількість символів для поля значення: VARCHAR(500)
    • Максимальна кількість типів пошуку на організацію: 100
    • Максимальна кількість рядків для кожного типу пошуку: 100 тис. рядків
    • Максимальний розмір файлу для завантаження: 10 МБ

    Щоб додати нові типи пошуку, зверніться до менеджера з питань успіху клієнтів Cisco або контактної особи з питань забезпечення рішень.

  3. Натисніть Додати дані, щоб ввести Ключ та Значення.

  4. (Необов’язково) Натисніть Видалити, щоб видалити існуючий ключ та значення.

  5. Клацніть Надіслати.

4

Щоб завантажити CSV-файл до репозиторію BRE: Виберіть Завантажити дані BRE CSV.

  1. Виберіть назву організації зі спадного списку TenantName.

  2. Виберіть Тип пошуку BRE з випадаючого списку.

  3. Виберіть Завантажити, щоб переглянути та завантажити файл CSV.

  4. Клацніть Надіслати.

    Зразок CSV-файлу для завантаження даних BRE CSV. Заголовки стовпців – «ANI», «Розширення» та «Дія».
    Зразок CSV-файлу з даними
    Дії «Видалити», «Оновити» та «Додати» не враховують регістр. Ви також можете використовувати синтаксис 725160001,,Delete для видалення даних.

Доступ до програми BRE

Ви можете отримати доступ до програми Business Rules Engine з порталу адміністрування Webex Contact Center.

  1. Увійдіть на портал адміністрування контакт-центру Webex.
  2. Натисніть Бізнес-правила, щоб відкрити панель інструментів Business Rules Engine.

    BRE використовує службу ідентифікації та взаємодію єдиного входу. Якщо ви вже ввійшли за допомогою Common Identity, ви можете отримати доступ до утиліти BRE для вашої організації, не входячи повторно.

Система відкриває програму Business Rules Engine (BRE) у новій вкладці браузера. З’явиться сторінка «Інформаційна панель» із графічним представленням кількості правил та виконань.Панель керування BRE

Створення набору правил

Діаграма утиліти Business Rule Engine, що викликається потоком у Webex Contact Center. Керування потоком у Webex Contact Center Flow Designer > Запит на пошук > Cisco BRE > Читати > Репозиторій BRE.

Відкрийте портал BRE та налаштуйте атрибут, мітку, контекст і правила, як описано нижче.

1

Щоб створити атрибут для зв’язку з вашою організацією:

  1. Виберіть Атрибути та натисніть Додати на сторінці «Атрибути».

  2. Введіть context у поле Ім'я.

  3. Виберіть Тип даних як Text з розкривного списку.

    Тип даних у утиліті BRE має бути Text.

  4. Клацніть Зберегти.

2

Мітка додає сенсу вашим даним. Щоб створити мітку:

  1. Виберіть Мітки та натисніть Додати на сторінці «Мітки».

  2. Введіть назву для мітки в поле Назва .

  3. Клацніть Зберегти.

3

Натисніть Контексти, щоб перейти на сторінку Контексти. Натисніть +Add Контекст.

  1. Введіть Ім'я, яке є Згенерованим контекстом у списку даних BRE.

  2. Введіть необов'язковий опис.

  3. Якщо створено більше одного атрибута, виберіть атрибут, який потрібно пов’язати з цим контекстом, зі спадного списку Атрибут .

  4. Клацніть Зберегти.

4

Щоб створити правила, перейдіть на сторінку Контексти. Натисніть +Add Редактор правил та налаштуйте такі деталі:

  • Ім'я: Введіть назву правила.
  • Опис: Необов'язковий опис правила.
  • Активний: Установіть прапорець, щоб указати, що правило активне.
  • Мітка: Виберіть потрібну мітку зі спадного списку.
  • Пріоритет: Перетягніть повзунок, щоб призначити пріоритет правилу. Система запускає правила на основі призначеного пріоритету, від найвищого (100) до найнижчого. Рекомендується починати призначати пріоритети зі 100 у порядку спадання.
  • Редактор правил (інструмент для введення коду, як показано на скріншотах нижче): Введіть код для правила.

Створіть два правила: один, якщо система знаходить збіг, і інший, коли система не знаходить збігу.

Наведений нижче приклад коду повертає значення атрибута з іменем routeInfo. Це трапляється, якщо номер, з якого набрав абонент (ANI), збігається з ANI у списку орендарів, завантажених до бази даних BRE. Скопіюйте та вставте наступне правило в редактор правил:
when
c: Contact()
eval(c.getGlobalValuesManager().getAsString( c.getTenantId(),
c.getAttribute("context")+"."+
c.getAttribute("ani")) != null)
then
c.putAttribute("routeInfo",
c.getGlobalValuesManager().getAsString(c.getTenantId(),
c.getAttribute("context")+"." + c.getAttribute("ani")));
end
Сторінка контекстів BRE з прикладом коду, що повертає значення для ANIFound для атрибута routeinfo.

Наведений нижче приклад коду повертає значення NotFound для атрибута routeInfo. Це трапляється, якщо номер, з якого набрав абонент (ANI), не відповідає ANI у списку орендарів, завантажених до бази даних BRE. Скопіюйте та вставте наступне правило в редактор правил:

when
c: Contact()
eval(c.getGlobalValuesManager().getAsString( c.getTenantId(),
c.getAttribute("context")+"." + c.getAttribute("ani")) == null)
then
c.putAttribute("routeInfo", "NotFound ");
end

Сторінка контекстів BRE з прикладом коду, що повертає значення ANINotFound для атрибута routeinfo.
5

Клацніть Зберегти.

Запит на BRE

Використовуйте дію запиту BRE, щоб отримати дані з механізму бізнес-правил (BRE) вашої організації для використання в потоці. Дія запиту BRE використовує стандартні протоколи HTTP для отримання даних з BRE.

У наступних розділах можна налаштувати дію запиту BRE:

Загальні налаштування

Параметр

Опис

Мітка активності

Введіть назву для активності.

Опис діяльності

(Необов’язково) Введіть опис дії.

Параметри запиту

Як частину запиту BRE, ви можете передавати параметри, надані у виклику API, до BRE. У стовпцях «Ключ-значення» можна ввести ключ для запиту та пов’язане з ним значення, яке потрібно надіслати разом із запитом. Ви також можете використовувати синтаксис подвійних фігурних дужок для передачі значень змінних.

Діяльність BRE має один попередньо визначений параметр запиту: context. Цей параметр запиту передається у виклику API до BRE.

TenantID автоматично вводиться як параметр і не потребує налаштування.

Таблиця 1. Параметри запиту

Параметр

Опис

Контекст

Містить причину запиту. Цей обов'язковий параметр не можна редагувати або видаляти.

Цей параметр повинен містити те саме значення, що й значення, вказане в атрибуті context у BRE. Для отримання додаткової інформації див. розділ Створення набору правил у посібнику користувача механізму бізнес-правил Cisco Webex Contact Center.

ANI

Містить номер телефону, з якого було здійснено дзвінок. Це параметр за замовчуванням, який можна редагувати або видаляти залежно від конфігурації правил у BRE.

Приклад значення для ANI: {{NewContact.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.

Поширені запитання

  1. Яке призначення attribute?

    Attributes є фундаментальними для зв'язування вхідних запитів пошуку BRE з певними наборами правил, визначеними в BRE, та для зберігання результатів оцінки правил.

  2. Як ви створюєте attributes?

    Створити attributes у розділі Налаштування > Атрибути в утиліті BRE. Наприклад, ви можете створити атрибут з назвою context.

  3. Яке призначення context?

    Context визначає конкретний сценарій або тип пошуку, який застосовує BRE. Коли потік викликає дію запиту BRE, він повинен повідомити BRE, який набір правил оцінювати. Атрибут, який часто називають Context, встановлюється на ім'я конкретного домену.

  4. Що таке domain?

    Таблиця domain у BRE містить відповідні дані. Доменне ім'я спрямовує BRE до правильних даних та відповідного набору правил.

  5. Що таке label?

    Після того, як BRE оцінить свої правила, воно має повідомити результат назад до системи, що викликає (наприклад, потік контакт-центру Webex, що містить дію запиту BRE). Правила налаштовано для встановлення значення призначеного атрибута мітки на основі їхніх умов.

  6. Який зв'язок між атрибутом, контекстом та міткою?

    Ви можете створити Attribute, наприклад, з назвою context. Ви можете пов'язати цей атрибут з domain (фактичною таблицею, такою як ANILookup). Під час виклику дії BRE Request потік встановлює значення цього атрибута (тобто domain = ANILookup), щоб вказати контекст (правила якого домену використовувати).

    У цьому domainправила написані в синтаксисі Drools для оцінки умов та встановлення значення іншого attribute, який часто називають label (наприклад, label = "Знайдено збіг"). Це представляє результат правила, який повертається як відповідь на потік.

  7. Як атрибути, контексти та мітки пов'язані з параметрами запиту?

    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 повинні використовувати однакове значення з урахуванням регістру.

Щоб додати тестовий запис:

  1. Відкрити Додати дані.
  2. Виберіть орендаря та ANILookup.
  3. Введіть ANI та пов’язане з ним значення.
  4. Надішліть запис.

Щоб завантажити повний набір даних, відкрийте Завантажити BRE, виберіть орендаря та тип пошуку, а потім завантажте файл CSV. Відкрийте Список даних BRE та переконайтеся, що записи відображаються. Переконайтеся, що формат ANI у CSV-файлі відповідає формату, надісланому потоком.

Запуск бізнес-правил

Увійдіть на портал адміністрування контакт-центру Webex, відкрийте Бізнес-правилата запустіть панель інструментів BRE:

Створіть атрибут контексту:

  1. Перейти до Головна > Атрибути > .
  2. Додайте атрибут із такими значеннями:
    • Ім’я: context
    • Тип даних: Текст
  3. Збережіть атрибут результату. Атрибут context визначає завантажений набір даних пошуку, до якого запитує правило.
  4. Додайте текстовий атрибут, який представляє повернуті дані. Дайте атрибуту змістовне ім'я, навіть якщо повернене значення містить кілька полів, розділених вертикальними рисками. Збережіть атрибут. У цьому прикладі як зразок використовується customerType.
  5. Відкрийте Контексти та додайте контекст. Введіть згенеровану назву контексту синхронізації даних, наприклад 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, якого немає в наборі даних, і переконайтеся, що шлях «не знайдено» повертає налаштоване резервне значення.

Чи була ця стаття корисною?
Чи була ця стаття корисною?