Разработка программного комплекса автоматизации процесса получения и передачи сообщений между центром обработки звонков и клиентами

• Введение
• 1. Специальный раздел «Программный комплекс автоматизации телефонных соединений»
• 1.1 Обзор существующих программных продуктов
• 1.2 Выбор среды разработки
• 1.3 Разработка графического интерфейса пользователя
• 1.4 Разработка алгоритма программы
• 1.5 Разработка алгоритма AES
• 1.6 Разработка текста программы
• 2. Технологический раздел «Разработка технологической инструкции для пользователя программы, контроля и аттестации программ»
• 2.1 Интеграция в режиме «Конфигуратор»
• 2.2 Интеграция в режиме «Предприятие»
• 2.3 Инструкция пользователю
• 3. Организационно-экономический раздел «Расчет затрат при автоматизации телефонных соединений с использованием сетевого графика»
• 3.1 Построение сетевого графика
• 3.2 Анализ и оптимизация сетевого графика

3.3 Расчет экономических затрат

3.4 Экономическая целесообразность разработки

4. Производственная и экологическая безопасность «Производственная и экологическая безопасность при работе с программным комплексом»

• 4.1 Аппаратура на рабочем месте
• 4.2 Анализ производственных опасностей и вредностей на рабочем месте
• 4.3 Составление перечня факторов обитаемости
• 4.4 Расчет защиты от статического электричества
• 4.5 Экологическая безопасность
• 4.6 Пожарная безопасность
• Заключение
• Список использованных источников

Введение

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

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

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

Раздел 1. «СПЕЦИАЛЬНЫЙ» Программный комплекс автоматизации телефонных соединений

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

В качестве сервера телефонии используется AsteriskIP-PBX. В качестве системы ведения учета — 1С: Предприятие. Данные программные продукты выбраны путем глубокого анализа существующих продуктов. Существует множество решений телефонии и систем учета. Самыми известными серверами телефонии являются Cisco, Avaya, Asterisk и Infinity. Рассмотрим их подробнее.

Cisco предоставляет комплексное решение, включающее вычисление, сеть, сеть хранения данных, безопасность и сервисы L4−7. Кроме того, они предоставляют большое количество опций и много возможностей масштабирования центров обработки данных. Cisco предоставляет FEX (Fabric Extenders) для Gigabit Ethernet, унифицированные порты. С помощью DCB (Data Center Bridging) позволяет основанной на Ethernet сети транспортировать трафик LAN/SAN.Однако настройка потребует значительных материальных затрат от компании. Так же, даже имея на руках инструкцию, далеко не каждый системный администратор сможет разобраться в начинке. Для администрирования этой системы необходимо приобрести лицензию, а так же оплатить обучение своего специалиста, либо вызвать для наладки специалиста из Cisco, что тоже далеко не дешево. Добавление новых пользователей, расширение количества IP-телефонов и т. д. стоит вложений. А для того, чтобы установить дополнительные модули интерфейсов VOIP, FANSO или другие платы, компании потребуются дополнительные лицензии. Cisco производит собственное оборудование, так что если компании не хватает бюджета для полностью укомплектованного АТС с соответствующей маркировкой, возможности поставить себе ПО так же отпадает. Cisco адекватно работают с любой АТС, но вот с АТС Cisco — работают далеко не все IP-телефоны. Cisco предлагает полный комплект виртуализированных продуктов: Cisco Nexus 1000V Series Switches, Virtualized Security Gateway (VSG), virtual network access module (vNAM) и Virtual Wide Area Application Services (vWAAS). Но расширяемость ПО Cisco серьезно ограничена, когда дело доходит до интеграции единых поставщиков связи.

Avaya похожа на Cisco в плане предоставляемых услуг. Это такая же готовая АТС с оборудованием собственного производства. Надежность здесь, как правило, исходит из стоимости. Настроить её может обученный специалист, если разберется в такой же замысловатой инструкции. Call-центр Avaya применяет технологии распознавания человеческого голоса, что при исходящем обзвоне увеличивает количество соединений с человеком, а не с IVR, факсом или голосовой почтой. Avaya работает с системой Communication Manager, которая в свою очередь вышла из MutiVantage. Из-за чего, по моему мнению, имеется много ненужных по сути функций, настроек и т. д. Например, то же качество документации изрядно страдает.

Infinity выигрывает удобством и простотой: у неё большой функционал по статистики, по сбору информации из IVR. В отличие от других платформ с преимущественно древовидным IVR-меню, Infinity постарались и сделали его графическим. Оно хорошо визуализировано, а это не только приятно глазу, но и удобно. Огромным минусом является то, что Infinity работает на Windows, в то время как остальные предпочитает более надежный Linux. Для Asterisk тоже есть подобные интерфейсы, но они идут в виде отдельных модулей, в том числе и OpenSource.

Asterisk более всего выделяется из этой группы одним существенным показателем: на ПО Asterisk не нужны дополнительные лицензии, как при подключение дополнительных SIP-номеров, так и при интеграции с подключаемыми модулями[1]. Тем более, найти соответствующие темы в форумах по настройке Asterisk может любой системный администратор. Инструкции в разы понятнее и удобнее. А значит, не надо тратить лишние деньги на обучение или вызов технической поддержки.

У системы автоматизации 1С: Предприятие так же существует довольно много конкурентов:

— ИНФИН;

— Парус;

— Галактика;

— БЭСТ;

— ИнфоБухгалтер;

— Турбо Бухгалтер (он же ТБ Корпорация);

— Компас;

— КомТех;

— Инотек;

— ИнфоСофт (продукт Флагма);

— Омега;

— Контур;

— SAP;

— Oracle.

Самой распространенной системой управления предприятием в крупном бизнесе является SAP. Доля данного программного продукта составляет 49,6% от всего рынка интегрированных систем управления предприятием. За ним идет Oracle с 14,9% и 1С: Предприятие с 14,4%. Однако, в среднем и малом бизнесе картина кардинально меняется. Лидером в этом секторе является 1С: Предприятие, имеющееся практически у каждой компании.

Исходя из полученных данных и специфики работы компании было решено разработать систему автоматизации телефонных соединений на базе 1С и Asterisk. На данный момент уже имелось несколько разработок от сторонних компаний. Среди них самыми известными являются:

— 1С-Рарус:СофтФон;

— Панель телефонии Asterisk 1С от MyAsterisk;

— 1С: Телефония от Simplit.

Рассмотрим каждый продукт подробнее.

Программный продукт «1С-Рарус: СофтФон, Проф, ред. 1» выпускается компанией «1С-Рарус». Решение обеспечивает интеграцию телефонной системы с CRM-модулем типовых конфигураций «1С:Предприятие 8.0». Тесная интеграция телефонной системы с CRM-системой обеспечивает быстрый доступ к информации о клиенте и способствует внедрению CRM-технологий (CRM — Customer Relations Management). Программа помогает в работе диспетчерского отдела, справочной службы, отдела продаж и маркетинга.

Панель телефонии Asterisk 1С от MyAsterisk обеспечивает связь между 1С: Предприятие и IP АТС на базе телефонии Asterisk 1.6 и выше. Реализованы следующие возможности:

— прием звонков в 1С;

— звонки из 1С телефонии;

— встроенный софтфон;

— удержание вызовов;

— перевод вызовов;

— отображение информации о звонящем;

— автоматическое открытие карточки;

— привязка клиентов по номеру телефона на определенного менеджера;

— прослушивание записей разговоров из 1С Asterisk;

— отправка факсов из 1С через Fax Asterisk;

— прием СМС в 1С.

1С:Телефония от Simplit представляет из себя дополнительную DLL-библиотеку для 1С, с помощью которой организован сетевой обмен данными с сервером IP-телефонии на базе Asterisk. Функции аналогичны панели телефонии Asterisk 1С от MyAsterisk.

Если рассматривать данные программные продукты более детально, то оказывается, что ни один из них не подходит под все требования. 1С-Рарус:СофтФон не может работать с Asterisk. Панель телефонии Asterisk 1С от MyAsterisk не поддерживает современный управляемый режим запуска 1С и, соответственно, не будет работать в браузере и в тонком клиенте. Управляемые формы — новая концепция интерфейса программ 1С, позволяющая, кроме всего прочего, работать через браузер. В ближайшее время все программы 1С: Предприятие перейдут на управляемые формы. Так же у нее отсутствует шифрование данных, что делает небезопасной работу через интернет. 1С: Телефония от Simplit подходит практически всем, однако большая часть логики перенесена в 1С, что не эффективно. К тому же компания Simplit находится в Киеве и в основном ориентирована на Украину. Таким образом, техническая поддержка и сопровождение их продукта в России будет значительно затруднено.

Проанализировав недостатки существующих систем интеграции телефонии, было решено разработать собственный продукт, лишенный этих недостатков. При разработке учитывалась возможность работы в разных конфигурациях 1С: Предприятия и разных режимах запуска. Выбор языка разработки C# позволит, при необходимости, быстро разработать компоненту соединения с сервером для других операционных систем и даже для мобильных устройств (смартфонов). Поддерживаются все новые версии сервера телефонии, начиная с 1.4 и все 103 команды управления сервером, что позволяет адаптировать решение под любые требования клиента. Так же реализовано шифрование соединения с сервером телефонии.

1.2 Выбор среды разработки Интегрированная среда разработки, ИСР (англ. IDE, Integrated development environment или integrated debugging environment) — система программных средств, используемая программистами для разработки программного обеспечения (ПО).

Среда разработки включает в себя:

— текстовый редактор;

— компилятор и/или интерпретатор;

— средства автоматизации сборки;

— отладчик.

ИСР иногда содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов — для использования при объектно-ориентированной разработке ПО. Хотя и существуют ИСР, используемые для нескольких языков программирования — такие, как Eclipse, NetBeans, Embarcadero RAD Studio, Qt Creator или Microsoft Visual Studio, но обычно в ИСР используется один определённый язык программирования — как, например, Visual Basic, Delphi, Dev-C++.

Частный случай ИСР — среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы.

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

IDE обычно представляет из себя единственную программу, в которой проводилась вся разработка. Она обычно содержит много функций для создания, изменения, компилирования, развертывания и отладки программного обеспечения. Цель среды разработки заключается в том, чтобы абстрагировать конфигурацию, необходимую, чтобы объединить утилиты командной строки в одном модуле, который позволит уменьшить время, чтобы изучить язык, и повысить производительность разработчика. Также считается, что трудная интеграция задач разработки может далее повысить производительность. Например, IDE позволяет проанализировать код и тем самым обеспечить мгновенную обратную связь и уведомить о синтаксических ошибках. В то время как большинство современных IDE является графическим, они использовались еще до того, как появились системы управления окнами (которые реализованы в Microsoft Windows или X11 для *nix-систем). Они были основаны на тексте, используя функциональные клавиши или горячие клавиши, чтобы выполнить различные задачи (например, Turbo Pascal). Использование IDE для разработки программного обеспечения является прямой противоположностью способа, в котором используются несвязанные инструменты, такие как vi (текстовый редактор), GCC (компилятор), и т. п.

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

Таблица 1.1 — Сравнение сред разработки C#

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

Лицензия LGPL позволяет линковать с данной библиотекой или программой программы под любой лицензией, несовместимой с GNU GPL, при условии, что такая программа не является производной от объекта, распространяемого под (L)GPL, кроме как путём линкования. Главное различие между GPL и LGPL в том, что последняя позволяет и такое линкование с данным объектом других, которое создаёт производную от данного работу, если лицензия слинкованных объектов позволяет «модификации для внутреннего использования потребителем и обратную разработку для отладки таких модификаций». Т. е. LGPL, в отличие от GPL позволяет связывание библиотеки с любой программой, не обязательно свободной.

Закрытое (проприетарное) программное обеспечение (англ. proprietary software) — программное обеспечение, являющееся частной собственностью авторов или правообладателей и не удовлетворяющее критериям свободного ПО (наличия открытого программного кода недостаточно). Правообладатель проприетарного ПО сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах. Обычно проприетарным называют любое несвободное ПО, включая полусвободное.

Geany — свободная среда разработки программного обеспечения, написанная с использованием библиотеки GTK2. Доступна для следующих операционных систем: BSD, Linux, Mac OS X, Solaris и Windows. Geany распространяется согласно GNU General Public License. Geany не включает в свой состав компилятор. Вместо этого используется GNU Compiler Collection (или любой другой компилятор) для создания исполняемого кода.

Microsoft Visual Studio — линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight. Visual Studio включает в себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего рефакторинга кода. Встроенный отладчик может работать как отладчик уровня исходного кода, так и как отладчик машинного уровня. Остальные встраиваемые инструменты включают в себя редактор форм для упрощения создания графического интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы данных. Visual Studio позволяет создавать и подключать сторонние дополнения (плагины) для расширения функциональности практически на каждом уровне, включая добавление поддержки систем контроля версий исходного кода (как например, Subversion и Visual SourceSafe), добавление новых наборов инструментов (например, для редактирования и визуального проектирования кода на предметно-ориентированных языках программирования или инструментов для прочих аспектов цикла разработки программного обеспечения (например, клиент Team Explorer для работы с Team Foundation Server).

MonoDevelop — свободная среда разработки, предназначенная для создания приложений C#, Java, Boo, Nemerle, Visual Basic .NET, Vala, CIL, C и C++. Также планируется поддержка Oxygene со стороны Embarcadero Technologies. Изначально это был порт SharpDevelop на Mono/GTK+, но с того времени проект далеко ушёл от своего начального состояния. MonoDevelop является частью проекта Mono.

SharpDevelop — свободная среда разработки для C#, Visual Basic .NET, Boo, IronPython, IronRuby, F#, C++. Обычно используется теми, кто не хочет пользоваться Visual Studio .NET. Существует также форк на Mono/Gtk+ — MonoDevelop. SharpDevelop 2.0 предоставляет интегрированный отладчик, который использует собственные библиотеки и взаимодействует с исполняющей средой .NET через COM Interop. Хотя SharpDevelop 2.0 (как и VS2005) использует файлы проекта в формате MSBuild, он по-прежнему может использовать компиляторы от .NET Framework 1.0 и 1.1, а также от Mono.

Для разработки необходимо активно использовать все средства языка программирования. Однако среда MonoDevelop использует собственный компилятор, который не полностью поддерживает язык С# в силу того, что является свободной мультиплатформенной разработкой, независимой от создателей языка. Хотя она и обеспечивает мультиплатформенность, но невозможно предсказать поведение языка в новых версиях. А одной из ключевых составляющих проекта является его отказоустойчивость и стабильность и в то же время мультиплатформенность не требуется (пользователей 1С на Linux исчезающе мало). Поэтому эта среда не подходит для разработки данного проекта.

SharpDevelop и Geany не имеют собственных компиляторов. Поэтому для разработки с использованием этих сред все равно придется использовать проприетарное ПО, что делает их использование оправданным лишь в некоторых случаях. Например на низкопроизводительных компьютерах или при сильно ограниченном бюджете проекта. Несмотря на то, что что они могут запускаться и работать в ОС Linux, данные среды разработки в силу отсутствия собственных компиляторов не смогут создать мультиплатформенное приложение, и разработка все равно ограничится операционными системами Windows.

Microsoft Visual Studio также не лишена недостатков. Основными из них являются тяжеловесность, требующая довольно большой вычислительной мощности компьютера; платность; отсутствие мультиплатформенности. Несмотря на эти недостатки, Visual Studio остается предпочитаемой средой разработки большинства C# программистов. Причиной этому является полная поддержка языка, расширенные средства разработки, энергично развивающаяся документация и сама среда. Данную среду разработки будем использовать в проекте.

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

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

— простота — возможность интуитивного понимания пользователем элементов интерфейса;

— использование стандартных элементов 1С — обеспечение единого интерфейса 1С и панели телефонии как в обычном, так и в управляемом приложении;

— масштабируемость — возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, количества линий и иных требований заказчика;

— адаптивность к действиям пользователя — приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства), кроме того, программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации;

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

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

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

— сокращению длительности операций звонка выбранному контрагенту;

— уменьшению времени поиска информации о контрагенте;

— повышению общей продуктивности пользователя, заключающейся в объёме обработанных звонков за определённый период времени;

— увеличению длительности устойчивой работы пользователя и др.

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

— прозрачной для пользователя навигации и целевой ориентации в программе;

— ясности и чёткости понимания пользователем текстов и значения икон;

— быстроты обучения при работе с программой, для чего необходимо использовать преимущественно стандартные элементы взаимодействия, их традиционное или общепринятое их расположение;

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

Разработка интерфейса ведется в конфигураторе 1С. Существуют два типа форм — обычные и управляемые. В режиме управляемого приложения интерфейс не «рисуется», а «описывается». Разработчик определяет только общую схему командного интерфейса и общую схему форм. Это описание платформа использует при построении интерфейса для конкретного пользователя с учетом различных факторов: прав пользователя, особенностей конкретного внедрения, настроек, сделанных самим пользователем. Разрабатываемое приложение должно одинаково работать на обоих типах форм.

Главное окно приложения должно состоять из нескольких функциональных частей. Должно быть главное окно приложения и закладка с настройками подключения. В главном окне необходимо реализовать возможность набрать введенный номер и отклонить звонок. При этом кнопка для принятия звонка не нужна, так как телефон сам оповестит об этом сервер при ответе на звонок. Таким образом, необходимо поле ввода номера телефона с кнопкой очистки и кнопки «Набрать» и «Отбой». Однако на устройствах с сенсорными экранами неудобно будет для набора номера каждый раз вызывать клавиатуру, поэтому необходим блок кнопок набора номера. Разместим их под полем с номером телефона. Теперь необходимо отображать информацию о собеседнике. Для этого подойдут поля с его номером и именем. Так же необходимо сделать поддержку двух линий. Поэтому добавим еще 2 поля с номером и именем собеседника по второй линии. При отсутствии звонков эти поля нам не требуются, поэтому сделаем их по умолчанию неактивными. При разговоре по первой линии может так случиться, что не будет возможности ответить на входящий вызов по второй. Поэтому для второй линии необходимо сделать быстрый перевод на другого сотрудника. Для этого добавим кнопку «Перевести» для второй линии. При нажатии на кнопку будет появляться выпадающий список с именами остальных сотрудников. При выборе определенного сотрудника будет произведен быстрый (без консультации) перевод звонка. Однако при разговоре может потребоваться перевод на другого сотрудника текущего звонка. Для этого добавим кнопку «Перевести» и для первой линии. Причем, если текущий пользователь на звонок еще не ответил, логичным будет перевести звонок без консультации, то есть без предварительного разговора с другим сотрудником. И напротив, при отвеченном вызове и необходимости перевода правильнее при переводе звонка сначала поговорить с сотрудником о контрагенте, целях звонка, и только потом переводить. Поэтому кнопки «Перевести» для обоих линий будут выполнять немного разные переводы в зависимости от того, был ли входящий вызов отвечен. При отвеченном вызове произойдет перевод с консультацией, при не отвеченном — перевод без консультации. Так же при одновременных звонках на обе линии необходимо давать возможность отклонять любую линию. Поэтому требуется как минимум еще одна кнопка «Отбой». Однако для избежания перекосов интерфейса и возможных затруднений со стороны пользователя необходимо добавить кнопку «Отбой» и для второй линии. Таким образом получится три кнопки «Отбой» на форме — по одной для каждой линии и одна общая рядом с кнопкой «Набрать» и полем ввода номера телефона. Логично предположить, что общая кнопка должна завершать последний вызов. То есть при одной активной линии она будет завершать текущий звонок, а при двух активных линиях — звонок по второй. Так же необходима кнопка поиска номеров по контрагенту. Расположим ее рядом с полем ввода номера. На этом основная функциональность главного окна реализована. Можно позвонить любому контрагенту, набрав его номер на клавиатуре или на экранных кнопках или же найдя его в списке, окончить телефонное соединение, перевести вызов на другого сотрудника, поддерживать 2 телефонных соединения одновременно.

Однако необходимо дополнительно реализовать возможности по просмотру истории звонков, отправке смс и факса. Кнопку «История звонков» лучше разместить в основной части формы, недалеко от кнопок «Набрать» и «Отбой». При нажатии на эту кнопку должно выводиться окно с историей звонков на определенную дату.

Не остались рассмотренными две возможности: посылка факса и смс. СМС обычно отправляют вне активного голосового соединения. Поэтому разместим кнопку «СМС» в основной части формы, рядом с кнопкой «История звонков». При нажатии на кнопку отображается окно с полем ввода текста смс и двумя кнопками: «Послать» и «Отмена». Номер для отправки берется из поля номер телефона главной формы. Факс же часто бывает необходимо отправить во время разговора, прямо на тот номер, с которым установлено соединение. Поэтому разместим две кнопки «Факс» для первого и второго каналов. При нажатии открывается стандартный диалог выбора файла и пользователем выбирается документ, который и отправляется по факсу. На этом функции основной закладки главного окна закончились. Главное окно панели телефонии в управляемом режиме показано на рисунке 1.1.

Рисунок 1.1 — Главное окно панели телефонии Теперь необходимо рассмотреть закладку «Настройки». На этой вкладке необходимо собрать все параметры, передаваемые во внешнюю компоненту для подключения и работоспособности панели. Для начала необходимо определиться с адресом сервера телефонии. Для этого добавим два поля ввода: «Адрес астериска» и «Порт AMI (5038)». 5038 — стандартный порт интерфейса AMI. Далее необходимо авторизоваться на сервере. Для этого добавим еще два поля: «Имя пользователя» и «Пароль». Следом необходимо поле для указания контекста звонков. Это служебное поле Астериска для правильной адресации. Также необходимо предусмотреть флажок «Открывать карточку» для открытия карточки контрагента при входящем звонке от него и флажок «Отладочные сообщения» для вывода отладочных сообщений при возникновении проблем панелью. В режиме отладочных сообщений будут отображаться в панели служебных сообщений практически все сообщения от внешней компоненты и частично от Астериска. По полученной информации можно быстро локализовать и исправить проблему. Следующим полем будет поле флажка «Не учитывать код города». При установленном флажке код города будет автоматически выбрасываться из номера. Код города указывается чуть ниже в одноименном поле ввода. Это необходимо, если провайдер телефонии требует строго определенный формат номера телефона. Так же, флажок «Не учитывать код города» необходим, если в информационной базе 1С: Предприятия возможны ситуации, когда код города не заполнен или заполнен неверно. Далее необходимо предусмотреть кнопку «Сохранить», нажатие на которую сохранит изменения в настройках. Для принятия новых настроек необходимо переподключаться к серверу Asterisk, поэтому добавим кнопку «Переподключиться к серверу» для завершения текущего соединения с сервером и установления нового. Так же при проблемах с соединением необходимо предусмотреть проверку доступности сервера. Для этого добавим кнопку «Пинг соединения с сервером», нажатие на которую посылает специальный пакет серверу. В случае доступности сервера, установленного соединения и успешной авторизации сервер вернет пакет «Pong». В окне служебных сообщений появится строка «Был получен ответ сервера Ping: Pong», а это значит, что сервер телефонии Asterisk доступен и работает. Данная вкладка будет практически одинаково выглядеть как в управляемом режиме запуска 1С: Предприятия, так и в обычном. Настройки панели телефонии в управляемом режиме показаны на рисунке 1.2.

Рисунок 1.2 — Закладка «Настройки»

Нажатие на копку «История звонков» открывает новое окно. В окне истории звонков должно быть поле выбора даты, на которую получаем историю звонков. При изменении даты необходимо сразу же получать историю без дополнительных действий со стороны пользователя. При открытии формы дату следует устанавливать равной текущей дате. Так же в этом окне необходимо отображать табличную часть, в которой описаны сами звонки. В каждой строке — один звонок. Для каждого звонка должны быть указаны:

— дата и время начала звонка;

— тип (входящий или исходящий);

— номера телефонов и имена обеих сторон;

— длительность звонка;

— отвечен или нет;

— дата и время окончания звонка.

Для каждого номера, если он занесен в базу 1С, необходимо дать пользователю возможность вызвать карточку того контрагента или клиента, для которого назначен номер в текущей строке истории звонков. Для этого разместим на форме кнопку «Инфо». Так же необходимо предоставить возможность позвонить по любому из телефонов в истории (разумеется, кроме телефонов текущего пользователя). Для этого разместим в шапке формы, рядом с полем выбора даты, кнопку «Позвонить». При нажатии на нее происходит вызов номера, указанного в текущей строчке истории. АТС Asterisk по умолчанию записывает все разговоры, поэтому можно разместить на форме кнопку «Прослушать». При нажатии на эту кнопку формируется команда Астериску для прослушивания разговора в текущей строке. Астериск, в свою очередь, совершает звонок на телефон пользователя и начинает воспроизводить ранее записанный телефонный вызов при поднятии трубки. На этом функциональность данного окна можно считать исчерпанной. Окно истории звонков в управляемом режиме показано на рисунке 1.3.

Рисунок 1.3 — История звонков Полученный интерфейс использует только стандартные элементы 1С и построен в едином стиле со всеми конфигурациями. Он интуитивно понятен, не требует глубокого изучения пользователем, удобен и не выбивается из общего стиля интерфейсов 1С.

1.4 Разработка алгоритма программы Для организации обширной и универсальной системы автоматизации звонков следует предусмотреть такой же универсальный алгоритм работы, который не зависел бы от внешних факторов, а определялся только самой системой и её внутренними параметрами.

Поскольку для построения компонентов системы, а также для построения внедряемых в компоненты элементов выбрана технология Microsoft .Net Framework, то следует воспользоваться всеми её преимуществами.

.NET Framework — программная платформа, выпущенная компанией Microsoft в 2002 году. Основой платформы является исполняющая среда Common Language Runtime (CLR), способная выполнять как обычные программы, так и серверные веб-приложения. NET Framework поддерживает создание программ, написанных на разных языках программирования.

Основной идеей при разработке .NET Framework являлось обеспечение свободы разработчика за счёт предоставления ему возможности создавать приложения различных типов, способные выполняться на различных типах устройств и в различных средах. Вторым принципом стало ориентирование на системы, работающие под управлением семейства операционных систем Microsoft Windows. Для обеспечения максимальной переносимости компоненты будем использовать только управляемый код C#.

Управляемый код (англ. managed code) — термин, введённый Microsoft для обозначения кода программы, исполняемой под «управлением» виртуальной машины .NET — Common Language Runtime. При этом обычный машинный код называется неуправляемым кодом. Программа для .NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для .NET понятный человеку низкоуровневый язык Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). Затем компилятор производит перевод CIL-кода в объектный байт-код (в терминах .NET получается сборка, англ. assembly), а уже байт-код либо исполняется виртуальной машиной CLR, либо транслируется утилитой NGen. exe в исполняемый код для конкретного целевого процессора. Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR, встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы.

Для начала рассмотрим основные аспекты протокола AMI. AMI — мощный и удобный программный интерфейс (API) Asterisk для управления системой из внешних программ. Благодаря AMI внешние программы могут осуществлять соединения с Астериском посредством TCP протокола, инициировать выполнение команд, считывать результат их выполнения, а так же получать уведомления о происходящих событиях в реальном времени.

Между сервером Астериск и клиентской программой для установления связи используется простой построчный протокол. Пакет, передаваемый от клиента в Астериск сервер и назад, определяется следующими ключевыми характеристиками:

— Action, пакеты отправляемые клиентом, соединенным с AMI. После обработки сервером такого пакета будет осуществлено некоторое действие. Существуют относительно гибкие ограничения на действия, осуществляемые клиентом. Один пакет — одно действие. В пакете Action должно содержаться имя операции, которую необходимо выполнить, а также все необходимые параметры;

— Response, определяет ответ, отсылаемый Астериском клиенту по факту выполнения действия;

— Event, данные, относящиеся к событию, которое сгенерировано внутри ядра Астериска или модуля расширения.

Как правило, клиент отсылает пакеты Action в Астериск (они так же называются командами). Астериск, в свою очередь, выполняет запрос и возвращает результат (часто результат — успешность действия с кратким описанием в случае неудачи), получаемое в пакете Response. Нет гарантии касательно порядка прихода результатов (пакетов Response), поэтому в клиентском запросе обычно включают параметр [ActionID] в каждый пакет Action, при этом соответствующий пакет Response будет содержать такое же значение в поле [ActionID]. Таким образом, клиент может обрабатывать Action и Response пакеты, в любом желаемом порядке, не ожидая пакетов Response, чтобы произвести следующее действие.

Передача данных в AMI похожа на обычный Telnet. Для управления сервером используются пакеты Action, а возвращает он Response или Event. Пакет представляет собой комбинацию строк, разделенных символами перевода строк (CRLF). Окончанием пакета служат два подряд идущих символа перевода строки. Общий формат пакетов управления сервером показан в распечатке 1.1.

Распечатка 1.1

Action:

:

:

…

Параметр «action type» указывает название действия. Далее идут пары «ключ: значение», определяющие необходимые переменные. Аналогичный вид у пакетов Response и Event.

Самым простым решением будет написание процедур, которые будут вызываться из 1С и которые будут посылать серверу сформированный пакет. Таким образом можно значительно уменьшить количество параметров у процедур, так так некоторые пары «ключ: значение» являются константами и их можно задать один раз для всех пакетов.

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

Для начала необходимо реализовать функцию, получающую строку от сервера. Есть два способа получать данные: посимвольно и построчно. При посимвольном способе в цикле из пришедших данных за раз можно получить только один символ. В ходе тестирования данный метод показал неудовлетворительные результаты: для получения одного символа необходимо пройти полный цикл получения символа от сервера телефонии Asterisk, что приводит к повышенной нагрузке на процессор при большом объеме передаваемых данных. В процессе тестирования наблюдалась полная загрузка процессора уже при восьми активно работающих телефонных аппаратах. При большем количестве использование панели телефонии Asterisk было невозможно. Поэтому в данном программном продукте был выбран второй способ, в котором используется построчное чтение данных от сервера. При построчном чтении данные с сетевой карты сначала помещаются в буфер, а при вызове функции чтения данные из буфера передаются в программу одной строкой, в виде типа String. Для начала необходимо определить какое максимальное количество байт мы можем принять за раз. Для этого используется свойство ServicePoint. ReceiveBufferSize, которое возвращает размер приемного буфера для сокета. Размер буфера будет равен количеству символов в строке, которую мы получим при чтении из него. При этом можно оптимизировать период цикла чтения из буфера, добившись максимальной производительности. Однако, при построчном чтении из буфера часто возникает ситуация, когда количество данных будет больше, чем размер буфера. В таком случае последний пакет от Asterisk может быть не полным, и последующий его разбор может привести к ошибкам. Для исключения этой возможности необходимо при каждом чтении из потока проверять получен ли последний пакет целиком. Проще всего это сделать, найдя последний символ перевода строки и последний двойной символ перевода строки. Если двойной символ будет стоять раньше на 2 символа («rn»), чем простой перевод строки, значит, пакет получен полностью и можно принимать следующие данные. Если же положения символов не совпадают (что в большинстве случаев и происходит), тогда последний пакет получен не целиком, необходимо сохранить его начало и добавить при следующем чтении из потока. Для этого ищется последний двойной символ перевода строки, и в отдельную переменную заносятся все данные, идущие после данного символа. В текущей строке данные, стоящие после символа двойного перевода строки, удаляются. Схема алгоритма подпрограммы получения строки от сервера телефонии показана на рисунке 1.4.

Рисунок 1.4- Схема алгоритма подпрограммы получения строки от Asterisk

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

— входящий вызов;

— окончание соединения с абонентом;

— исходящий вызов для получения названий каналов;

— история звонков;

— пакеты «Response».

Канал — соединение каждого абонента. Он необходим для избегания путаницы когда, например, один абонент принимает одновременно два звонка. Новый канал создается для каждого соединения абонента. Поэтому при разговоре двух абонентов каналов будет два — по одному для каждого абонента.

Остановимся на каждом из видов подробнее. Входящий и исходящий вызовы можно объединить, так как в данном случае будут меняться местами только номера каналов. Для начала необходимо определить пакет. Он будет начинаться со строки «Event: Dial». Пример текста пакета, посылаемого сервером телефонии при звонке с номера 36 на 34, приведен в распечатке 1.2.

Распечатка 1.2

Event: Dial

Privilege: call, all

SubEvent: Begin

Channel: SIP/36−54d

Destination: SIP/34−54e

CallerIDNum: 36

CallerIDName: Sergey Shimkov

UniqueID: 1 322 047 772.2227

DestUniqueID: 1 322 047 772.2228

Dialstring: 34

ПараметрыChannelиDestinationуказывают на каналы, которые создались при звонке. Они потребуются для того, чтобы была возможность перевести звонок. При переводе звонка необходимо использовать именно каналы, а не номера телефонов. Ссылки на каналы отображаются как [протокол, на котором происходит звонок]/[номер абонента]-[случайные символы]. Таким образом, определяется следующая схема действий:

— найти пакет в потоке, определить его начало и конец;

— попытаться найти строку в пакете: «Destination: «+ SIP/[наш номер]. Если найдена, значит это входящий звонок и тогда Destination — наш канал, Channel — канал звонящего;

— попытаться найти строку в пакете: «Channel: «+ SIP/[наш номер]. Если найдена, значит это исходящий звонок и тогда Destinationканал звонящего, Channel — наш канал;

— проверить, занята ли первая линия. Если свободна, тогда сохранить значения каналов как звонка по первой линии, иначе по второй;

— вызвать внешнее событие в 1С, оповестить о входящем звонке и сообщить номер.

Далее рассмотрим ситуацию прекращения звонка. Текст пакетаот Asterisk с сообщением об окончании телефонного соединения показан в распечатке 1.3.

Распечатка 1.3

Event: Hangup

Privilege: call, all

Channel: SIP/34−54e

Uniqueid: 1 322 047 772.2228

CallerIDNum: 34

CallerIDName:

Cause: 16

Cause-txt: Normal Clearing

Пакет с сообщением об окончании телефонного соединения начинается со строки «Event: Hangup». Соответственно будем искать пакет с таким началом. Параметр Channel указывает на канал, с которого повесили трубку. Алгоритм будет следующим:

— найти пакет, начинающийся со строки «Event: Hangup» в потоке, определить его начало и конец;

— попытаться найти строку в пакете: «Channel: «+ [наш канал]. Проверить во всеми запомненными каналами (максимум четыре). Если найдена, значит очистить;

— вызвать внешнее событие в 1С, оповестить о входящем звонке и сообщить номер.

Необходимо добавить, что звонок может быть инициализирован не только нашей компонентой, но и обычным телефонным аппаратом. А значит нельзя опираться на «ActionID».Схема алгоритма проверки начала вызова показана на рисунке 1.5.

Рисунок 1.5- Схема алгоритма подпрограммы проверки начала вызова

Запрос истории звонков так же происходит через пакеты Action, а сама история звонков возвращается Event пакетами. Период истории звонков в стандартной реализации можно установить равным только одному дню. Для получения истории звонков мало только послать Action пакет. Необходимо еще установить переменные канала «date» и «chan». Они так же устанавливаются через Action пакеты. В первой необходимо передать число, за которое нужна история, а во второй — основу канала («SIP/[наш номер]»). Переменные устанавливаются для канала, содержащегося в пакете с заголовком «Event: NewCallerid». После этого необходимо дождаться пакета, начинающегося с «Event: UserEvent» и содержащего наши переменные, которые были нами отправлены ранее. В нем будет история звонков. В одном пакете может быть отражено до 10 звонков. Если количество звонков за день больше, тогда будут высланы дополнительные пакеты. Для каждого звонка указаны номера, с которого и на который совершен звонок, наименование звонящего, время звонка, длительность, отвечен или нет, а так же имя файла на сервере с записью звонка.

Общий алгоритм будет такой:

— посылается Action пакет с запросом истории звонков;

— ожидается Event пакет «Event: NewCallerid». При получении сравнивается номер (CallerIDNum) с номером, переданным в Action пакете, и если они совпадают, тогда запоминается канал и для него устанавливаются переменные канала;

— ожидается Event пакет «Event: UserEvent». У него сравниваются канал и дата с запомненными, если совпадают, то начинается построчный разбор истории звонков;

— каждая строка содержит один звонок, все данные разбираются и упаковываются в более понятный вид;

— вызывается внешнее событие в 1С, передается строка с данными о звонке;

— разбирается следующая строка или, если пакет закончился, начинается ожидание следующего пакета.

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