Интеграция с телефонией

[ZooY]

Коллеги, подскажите у кого есть такой опыт...
Есть телефония с торчащими наружу веб-сервисами, которые позволяют ей рулить как хочешь.
Есть CRM 2013.
Нужно, чтобы при поступлении звонка "поднималась" карточка клиента.
Программно все довольно просто: регистрируешь в сервисе телефонии колбек-функцию, которая будет вызвана при поступлении звонка. В функцию передается номер звонящего, по нему можно найти данные в CRM. Работа с сервисами ведется через JavaScript.
Вопрос в том, где разместить этот код, чтобы он производил регистрацию при запуске CRM и оставался работающим в процессе работы CRM. Самое простое решение - открывать отдельное окно браузера в котором будет работать страничка с кодом интеграции. Но это какое то корявое решение. CRM во-фрейме тоже не запустишь. Какие еще могут быть варианты?

[-O_o-]

дам концепцию
поступает звонок- создается запись звонка в СРМ
оператор поднял трубку - даргается из базы запись звонка => открывается новое окно браузера => вставляется ссылка на запись звонка.

Как технически сделано не скажу, не вникал но чуток потрудились с этим.
ПыСы - астериск

[ZooY]

Да концепция то понятна, вся проблема упирается в пункт "даргается из базы запись звонка" - как, кем дергается - вот в чем вопрос.

[-O_o-]

гЫ) ну тут вам спец по телефонии нужен )
а вообще.... могу продать уже все готовое )))

[ZooY]

Спец по телефонии тут не нужен, потому что вопросов к телефонии нет - вопрос к месту размещения кода взаимодействия.

Есть описание вашего готового решения?

[Артем Enot Грунин]

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

[Артем Enot Грунин]

Альтернативно, если вы хотите чтобы решение было целиком в веб, тогда можно посадить код его запуска на правило видимости кнопки на риббоне. Далее, в глобальной переменной окна создается JS объект, который выполняет все необходимые функции. Однако, вам нужно будет как-то следить, чтобы инстансы объекта в соседних окнах не сработали одновременно. Например, можно попробовать следить за фокусом окна.

[spectr]

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

[Quodnon]

а если звонок не создавать, а открывать форму создания?
кстати в урл передать значения ActivityParty для полей звонка from и to вообще можно?
....бо как-то не хочется лупашить через рест создание всей цепочки активити...
АПДЕЙТ
вопрос снят и сорри за возможный оффтоп
http://msdn.microsoft.com/en-us/library/gg334375.aspx
..придется по старинке кастомными полями. =(

[magicandy]

Решил поднять тему, так как на данный момент занимаюсь данной задачей в контексте интеграции с Астериском.
Топикстартер в итоге решил задачу? Какой был выбран способ?
В моём решении входящие звонки мониторятся настольным агентом (wpf-приложение) с последующим поднятием карточки. А вот как бы вы реализовали звонки по клику на карточке? Сейчас как раз в процессе осмысления. Поделитесь опытом.

[ZooY]

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

По телефонии нет одного единого "правильного" и "абсолютно верного" подхода к интеграции. Все зависит от многих факторов: какой API у сервера телефонии, какой API у софт-фона (клиентского приложения), какая инфраструктура (версии ОС, браузера) и пр....
Кроме того, все очень сильно зависит от требований, предъявляемых к интеграции: кому-то нужно чтобы только карточка поднималась при входящем звонке, а кому-то полное управление с переводами и блэк-джеком.

Могу примерно описать, что я делал при серьезной такой интеграции (с Avaya)… У меня был web-сайт, который общался с сервером телефонии на предмет получения звонков и выполнения вызовов. С помощью SignalR сайт общался с CRM вызывая там JS-команды при поступлении звонка и изменении его статуса. Со-стороны CRM это был чистой воды «unsupport». В файл main.aspx добавил свой JS-файл, отвечающий за подключение к SignalR, а также за интерфейс. Опять же, неподдерживаемыми способами (прямой манипуляцией с DOM), на панель CRM были добавлены кнопки управления звонком. Таким образом, прямого взаимодействия с софт-фоном не было, хотя оператор использовал его для работы (фактически он использовался только чтобы выводить звонок на ПК, все управление звонком осуществлялось через CRM).
Интегрировались с сервером, а не с софт-фоном по той причине, что его API был крайне ограничен.

На стороне CRM неподдерживаемый вариант с внедрением в main.aspx можно было бы заменить на манипуляции с кнопками формы/представления и вставлять нужный код через обработчики кнопок (есть такой извращенный способ). Такой подход можно применить даже в Online-версии, но он показался гораздо сложнее в реализации и менее надежным.

Сейчас, оглядываясь на получившееся решение, жалею, что не продавил вариант с «собственным браузером», т.е. сделать на WPF приложение, вставить туда элемент управления WebBrowser и запускать CRM в нем, а вся телефония при этом была бы в этом WPF-приложении, включая какие-то кастомные окна. Кстати я проверял, CRM прекрасно работает в контроле WebBrowser и приложение имеет доступ к DOM если что. Распространять приложение в корп. сети можно с помощью ClickOnce.

[ZooY]

Перечитал написанное, понял что меня немного в сторону увело...
Собственно, по поводу вопроса про совершение звонков... У меня звонки совершались по нажатию кнопки на форме звонка. Т.е. позвонить без создания записи звонка нельзя - сначала создаете звонок, потом из него звоните.
С "позвонить" вообще не было особенных проблем, гораздо сложнее "ответить на звонок". При поступлении звонка создавалась запись "Звонок" и она открывалась. По номеру телефона искался клиент, если он был найден, то просто открывался звонок. Если не найден, то открывался звонок и сразу при его открытии открывалась форма поиска клиента.

[Артем Enot Грунин]

Когда читал, почему-то подумалось: а еще можно было форкнуть Firefox, или Хромиум и добавить функционал туда В любом случае, то что вы описали выглядит довольно круто!

[Артем Enot Грунин]

На случай если интересно, опишу свой подход к выбору архитектуры. В первую очередь, нужно соблюдать следующие принципы:

1. Не играть в создателя. Разного рода попытки исправить родовые травмы платформы, или придумать к ней "более лучший" API, или интерфейс практически всегда обречены на провал.
2. Не жалеть систему. Не нужно пытаться разгрузить систему за счет попыток написать свой движок процессов, вынести данные в сторонние базы, написать рядом другой CRM. Вы не сможете существенно ускорить решение, но сильно потеряете в стабильности и маштабируеммости
3. Не плодить сущности. Нужно максимально полно использовать те инструменты и решения, которые уже задействованы на проекте, даже если новое решение кажется лучше, или производительнее. Например, если на проекте уже есть SQL Server разумно использовать SSIS, SSRS, SSAS и прочие технологии "в комплекте". С хорошей долей вероятности, новые системы и технологии лишь создадут новые интеграционные точки и сведут на нет все плюсы
4. Не изобретать велосипед. Все придумано до нас. Создать что-то свое - это заманчивый порыв, но лучше не делать это за счет проекта

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

[Bondonello]

Цитата:

Сообщение от ZooY

Сейчас, оглядываясь на получившееся решение, жалею, что не продавил вариант с «собственным браузером», т.е. сделать на WPF приложение, вставить туда элемент управления WebBrowser и запускать CRM в нем, а вся телефония при этом была бы в этом WPF-приложении, включая какие-то кастомные окна. Кстати я проверял, CRM прекрасно работает в контроле WebBrowser и приложение имеет доступ к DOM если что. Распространять приложение в корп. сети можно с помощью ClickOnce.

Это уже есть, называется Unified Service Desk (USD)

[ZooY]

Почему я говорю про "обертку" для CRM... В описанную реализацию было вложено неимоверное количество труда. Реализовать тоже самое в "обертке" было бы 1) быстрее; 2) проще; 3) получившееся решение было бы проще в понимании и поддержке, было бы задействовано меньше технологий; 4) можно было бы реализовать больше функций (потому что не нужно бороться с платформой); 5) решение не было бы так привязано к конкретной версии CRM.

Третий пункт довольно важный, потому что в получившемся решении некоторые моменты просто сложно объяснить, например магию открытия лукапа поиска клиента при открытии карточки звонка. Так что к вашему списку правил я бы добавил первым пунктом "простота и понятность решения (разработка, развитие и сопровождение)"

[ZooY]

Цитата:

Сообщение от Bondonello

Это уже есть, называется Unified Service Desk (USD)

Мне кажется что USD относиться все таки к клиентскому обслуживанию, там помимо телефонии еще и обращения (проблемы), вские очереди запросов и тд. и т.п.
Я же говорю только за телефонию, которая годна и маркетинга, например.

[Артем Enot Грунин]

Цитата:

Сообщение от ZooY

Мне кажется что USD относиться все таки к клиентскому обслуживанию, там помимо телефонии еще и обращения (проблемы), вские очереди запросов и тд. и т.п.
Я же говорю только за телефонию, которая годна и маркетинга, например.

Да, согласен. Внесу в свой список Поддержка не оценит, если вы передадите им "корабль в бутылке", а заказчик попросит покрасить палубу