Таблицы абонентов — различия между версиями

Версия 06:15, 4 марта 2014

Наверх

Модуль доступен администраторам БД и пользователям, имеющим соответствующее право. Для пользования модулем необходимо зарегистрироваться в call-центре системы.

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

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

Раздел дает возможность создавать и настраивать соответствующие таблицы.

Таблицы абонентов подчиняются политике прав доступа. Параметры доступа к ним определяются на соответствующей вкладке «Доступ». Доступные привилегии: чтение, изменение.

В приведенном двойном списке выделите слева интересующий проект. Справа отобразятся все существующие в нем таблицы абонентов. Выделив необходимую, Вы можете редактировать и удалить ее, а также можете создать новую таблицу в выбранном проекте.

По характеру создания и доступа к информации они делятся на «локальные» и «внешние».

Локальная таблица

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

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

Все столбцы по умолчанию имеют строковый тип (nvarchar) с авторазмерностью (до 2000). Пользователь может по своему усмотрению задать любой другой тип данных для столбца. При смене типа данных столбца осуществляется попытка автоматического преобразования данных к новому типу. Однако следует помнить, что при обнаружении некорректных данных, преобразование которых невозможно, весь столбец с данными очищается (удаляется, а вместо него создается новый).

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

Создание локальной таблицы может производиться на базе уже существующей таблицы в БД. В этом случае она будет подключена и автоматически сформируется информация о столбцах, доступная к редактированию (название, тип данных, назначение, описание).

ВНИМАНИЕ! Если изменить название таблицы БД во время редактирования локального списка, то физическая таблица в БД будет переименована в новое указанное имя, сохранив все данные. Однако, если имя занято (таблица с указанным новым именем уже существует в БД), то локальный список будет переподключен к существующей таблице, а прежняя таблица будет удалена..

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

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

Внешняя таблица

Пользователю предоставляется возможность подключить в качестве таблицы абонентов набор данных из собственной таблицы или запрос в БД, возвращающий произвольный набор данных. Одно другого не исключает. «Таблица» здесь не всегда понимается в буквальном смысле.

• Способ подключения. Позволяет выбрать, каким образом подключаться к базе данных с таблицей. Таблица абонентов может быть расположена в любой базе данных на любом сервере, в том числе в файлах Microsoft Excel. Выбрав требуемый механизм доступа (ADO, OLE, ODBC, Oracle), можно организовать прямое подключение к внешней базе, указав строку подключения и провайдер данных. По умолчанию подключение к собственной БД. При этом все требуемые данные будут браться и сохраняться в подключенной БД. Такой способ подключения является более оптимальной альтернативой линковке базы к серверу БД.

• Строка подключения. В случае, если выбран способ подключения, отличный от подключения к собственной БД, требуется указание строки подключения. Строка подключения не должна содержать указание названия провайдера данных (он указывается отдельно и в случае необходимости подставляется автоматически), так как указанная строка используется в качестве параметра команды T-SQL OPENROWSET в хранимых процедурах MS SQL Server. Например, для доступа к файлу Microsoft Excel, строка подключения должна выглядеть «Excel 8.0;Database=D:\monitor.xls;», а для доступа к MS SQL Server - «server=DOMAIN;database=databasename;uid=login;pwd=password;»

• Провайдер данных. OLE, ODBC и Oracle подключения требуют указания здесь провайдера данных. Это имя подставляется в качестве аргумента в команду OPENROWSET в хранимых процедурах MS SQL Server, а также дополняет указанную строку подключения для доступа непосредственно из службы сервера телефонии. Например Microsoft.Jet.OLEDB.4.0 или SQLOLEDB.

ВНИМАНИЕ! Подключение больших таблиц в задачах с «ручным выбором абонентов» и «распределением по операторам», а также работающих с таблицей абонентов через «кэш в БД» требует полного перекачивания данных таблицы с удаленного сервера БД на локальный сервер БД в хранимых процедурах всякий раз при синхронизации. Это может требовать дополнительного времени.

ВНИМАНИЕ! Подключение драйверов, не поддерживающих T-SQL лишает возможности использовать некоторые функции. Например, при подключении в качестве источника файлов Microsoft Excel становится недоступным распределение абонентов по операторам с указанием начальных символов имен из-за отсутствия поддержки команд Substring и Cast. А при отсутствии поддержки команды like и символа '%' становится невозможным поиск по номерам.

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

• Запрос в БД. Если указан запрос, то выборка данных по абонентам для исходящей задачи будет формироваться на его основе, также как и загрузка данных по абонентам в сценарии и диалоговые формы. Запрос может быть сколь угодно сложным с разумным ограничением на время исполнения. В качестве примера использования можно привести задачу формирования данных по абоненту из нескольких таблиц, где раздельно хранятся телефоны и прочая информация, а также, если в ходе реализации задачи необходимо производить работу не со всеми абонентами в таблице, а по какому то заранее известному условию, например, где долг более 1000 рублей. Если в дополнение к запросу не указана базовая таблица с идентификаторами абонентов, то сохранение вводимых данных невозможно. Следует отметить, что запрос с течением времени может возвращать разные данные. При работе с исходящей задачей в моменты синхронизации перечень абонентов будет корректироваться в соответствии с возвращаемой выборкой.

ВНИМАНИЕ! Введенный текст используется для формирования более сложного запроса на получение данных. Вы можете использовать запрос любой сложности с учетом того, что он позже будет заключен в еще один select * from ([Ваш запрос]). Не допускается использование операторов declare и set. Для более подробной информации изучите правила вложенных запросов по этой ссылке (ORDER-группа допускается только вместе с использованием TOP).

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

Работа с данными

Работа сервера логики не зависит от типа представления таблицы («внешняя» или «локальная»). Исключение составляют внешние таблицы баз данных, обслуживающимися другими серверами БД.

После выбора типа таблицы и указания способа получения данных производится переход на вкладку проверки и назначения типов столбцов.

Для локальной таблицы, как было отмечено выше, здесь доступно изменение таблицы. Выделите соответствующую запись, и щелкните в поле, которое хотите отредактировать. Появится курсор ввода текста, позволяющий изменять данные. Каждая строка представляет собой отдельного абонента, его идентификатор назначается автоматически и не виден пользователю. Чтобы создать новую запись вставьте курсор ввода в последнюю строку (пустую) и введите данные. При редактировании последнего столбца последней записи появится новая пустая строка. Пользователь может создавать/удалять столбцы, изменять данные в ячейках вручную, а также импортировать табличные данные из файлов Microsoft Excel и из буфера обмена, столбцы при этом автоматически создаются по необходимости. Из локальной таблицы возможен экспорт данных в файлы Excel. Соответствующая команда находится в контекстном меню.

ВНИМАНИЕ! Все создаваемые для локальной таблицы поля имеют строковый тип. Длина поля для хранения данных рассчитывается как максимальное значение длины среди всех сохраняемых данных в столбце, но не менее 50 символов. Это необходимо иметь в виду при формировании пустых локальных таблиц (для вставки данных) для использования с внешними задачами. Если прогнозируются объемные данные, то рекомендуется первой и единственной строчкой вставлять «бессмысленные» данные с целью формирования полей с соответствующим ограничением на длину.

Для внешней таблицы выполняется указанный запрос, или производится выборка из указанной таблицы при его отсутствии. Возвращаются первые 10 записей.

В обоих случаях (локальный и внешний тип таблиц) имеющимся в списке столбцам необходимо назначить типы. Среди обязательных типов:

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

• Поле номера телефона. В таблице может быть один или несколько столбцов типа «Номер». В каждой ячейке может лежать номер телефона или несколько номеров телефонов, разделенных запятыми, пробелами или прочими символами, отличными от +()-Ww и цифр. Полей номеров телефонов может быть неограниченное число. В случае, если соответствующие поля не заполнены данными, они игнорируются менеджером задач.

• Информационное поле. Значение полей с непустыми значениями подставляются в диалоговую форму оператора, а также в форму уведомления оператора о его резервировании на выполнение исходящей голосовой задачи в момент осуществления дозвона по номеру абонента (действует для типов задач «С резервированием оператора» и «С уведомлением оператора»). Информационных полей может быть неограниченное число. Все незаполненные данными значения игнорируются менеджером задач.

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

• Идентификатор оператора. В таблице может быть один столбец типа «Идентификатор оператора». Тип может быть проставлен только полю, имеющему тип данных uniqueidentifier. Применяется при синхронизации задач с закреплением абонента за оператором, автоматически перестраивая кэш и формируя привязки. Является альтернативой ручному способу перераспределения абонентов по операторам в настройках задачи.

• Прочие поля. Другие поля, а также перечисленные выше могут быть использованы для отображения данных в форме, для ввода данных из формы, для маршрутизации сценария, для озвучивания в IVR, а также для других необходимых действий. Доступ к ним осуществляется в сценариях посредством переменных типа «Поле таблицы» или непосредственными запросами на основании текущего идентификатора абонента.

Сохраненный список становится доступным для прикрепления к задачам внутри текущего проекта.

Любые поля таблицы абонентов доступны в сценариях всех типов, выполняемых по задачам, в которых таблица абонентов используется. Абсолютно любые поля доступны в сценариях для чтения с использованием переменных типа «Поле таблицы», имя которых совпадает с именем соответствующих полей. Однако аналогичным образом для записи доступны только поля, которые находятся в прикрепленной таблице в случае внешнего списка и все поля из локального списка. То есть, если в качестве источника для исходящей задачи используется внешняя таблица абонентов с типом «Запрос в БД», то запись не будет производиться в поля, не принадлежащие к прикрепленной таблице. И запись не будет производиться вообще, если прикрепленная таблица вовсе не указана.

ВНИМАНИЕ! При вставке в реальную таблицу БД в строковое поле с определенным ограничением на длину данных большей длины, вставка не осуществляется. Происходит генерация исключения с выводом информации в лог-журнал исключительных ситуаций. Если требуется избежать этого и вместо генерации исключения обрезать переходящие за рамки ограничения данные, в запросах необходимо явно приводить SQL-типы. Это можно сделать, например, так (здесь @a – внутренняя переменная):

Select cast ( @a as nvarchar ( 50 ) )

ВНИМАНИЕ! При вставке новых столбцов, а равно и при использовании внешних таблиц используйте в качестве имен латинские буквы и цифры. Несмотря на возможность использовать и другие символы, делать этого не рекомендуется во избежание ошибок, которые обычно длительно устраняются, и часто в этом случае не обходится без помощи технической поддержки. Чтобы представить оператору адекватные названия на родном языке, необходимо задать свойство «Описание» столбцам таблицы абонентов.

ВНИМАНИЕ! В задачах по умолчанию используется буфер синхронизации, позволяющий реализовывать различные варианты обхода таблицы абонентов (в задаче метод работы с таблицей «Загрузка в память и синхронизация»). Это подразумевает периодическую синхронизацию данных (загрузку из БД и сопоставление), что в случае большого количества абонентов в таблице требует от сервера существенных временных и ресурсных затрат. В среднем синхронизация с таблицей из 10 тыс. абонентов происходит 0.5 секунды, 100 тыс. абонентов - 3 секунды, 500 тыс. абонентов - 9 секунд. Значительно возрастает объем используемой памяти (кэш по таблице из 100 тыс. абонентов, где у каждого по одному номеру, требует ~40 МБ). Синхронизационный буфер (кэш в памяти) при формировании задач рекомендуется оставлять для таблиц с числом записей менее 100 тысяч. При настройке работы нескольких задач одновременно обращайте внимание на объем используемой памяти во избежание зависания системы. При необходимости использования значительно больших таблиц применяйте при настройке задач метод работы с таблицей «кэш внутри БД» или «сценарий поиска абонента».

ВНИМАНИЕ! При организации массовых исходящих кампаний с большим числом операторов рекомендуется выносить БД на отдельную рабочую станцию или сервер, организовать распределение БД по нескольким жестким дискам. В обязательном порядке необходимо проверить наличие индекса по полю идентификатора основной прикрепленной таблицы. В случае отсутствия его необходимо создать.