Дедовские методы

В одном недавнем проекте мы встраивали в SugarCRM возможность распознавать паспортные данные при сканировании (наш заказчик – туристическая фирма, и заводить паспортные данные в систему требуется постоянно).

Для пользователей SugarCRM это работать должно было так:

  • Менеджер кладет паспорт в сканер (сканер находится на его рабочем столе)
  • Заходит на карточку клиента в CRM и кликает на кнопку «Сканировать»
  • Карточка клиента волшебным образом заполняется данными из паспорта

А вот как это должно было работать с точки зрения компьютерного мира:

  • CRM отправляет запрос в какой-то сервис сканирования, который запущен локально у менеджера (т.к. сканеры, в отличие от принтеров, управляться удаленно не очень-то могут)
  • В локальной сети есть сервер, на котором запущена программа, умеющая распознавать сканы документов. Программа распознавания запущена только на одном сервере (сделано в целях экономии, так как для каждого сервера распознавания надо покупать лицензию).
  • Получив команду от CRM сканер должен был отсканировать и передать изображение в программу распознавания, которая в свою очередь должна была распознать скан и полученные данные отправить в CRM. В CRM эти данные должны были сохраниться на карточке клиента.
  • Сервис распознавания – это Windows-приложение, компьютер менеджера – также Windows, CRM работает под Linux.

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

  • Сервис CRM (умеющий отправлять запросы в сервис сканера и умеющий принимать запросы на обновление клиента от сервис распознавания )
  • Сервис сканера (умеющий по команде от CRM сканировать и полученное изображение передавать в сервис распознавания)
  • Сервис распознавания (умеющий получать скан документа и передавать распознанные данные в сервис CRM)

В целом, не самая безоблачная архитектура… К тому же сервисы сканеровния надо запускать на каждом рабочем компьютере менеджера, и это не добавляет надежности всему этому зоопарку.

Но это нам – поколению всесущего интернета – казалось, что надо разрабатывать 3 сервиса, бегущих онлайн: раз компоненты разбросаны на 3-х разных машинах. Что еще может прийти в голову? А вот наши более опытные коллеги, которые начинали работать во времена аналоговых модемов, предложили нам куда более простую, надежную и изящную схему.

Вот эта схема:

  • Вместо сервиса сканер пишется desktop приложение, которое про другие компьютеры вообще ничего не знает. Это приложение при установке регистрирует свой протокол в реестре Windows. Мы этот протокол назвали scanto (работает по аналогии с протоколом mailto, с которым ежедневно каждый сталкивается при клике на электронный адрес). Единственное, что умеет делать это приложении, это при вызове scanto://shared_folder /file.jpg запускать сканер и сохранять полученное изображение по пути shared_folder/file.jpg
  • Сервис распознавания упростили до следующего: это windows сервис, который при появлении в предопределенной папке файла начинает его сразу распознавать. Распознав, шлет http запрос в CRM
  • В SugarCRM вообще ничего не пришлось дорабатывать – лишь на страницу клиента добавить ссылку scanto://shared_folder/id.jpg (где id – это id клиента, на странице которого располагается ссылка, а shared_folder – общедоступная папка в локальной сети). А сервис распознавания для обновления карточки клиента вызывает стандартный метод soap веб сервиса set_entry, который уже есть изначально в SugarCRM.

В итоге все это работает так:

  • Менеджер на странице клиента с id=id_c тыкает на новую ссылку: scanto://shared_folder/id_с.jpg
  • Scanto:// вызывает локальную программу сканирования на компьютере менеджера
  • Программа сканирования просто сохраняет отсканированное изображение в обещдоступной в локальной сети папке
  • Сервис распознавания, увидев файл id_c.jpg, распознает документ и отправляет запрос в CRM, передавая одним из параметров id_c, взятый... из имени файла.
  • CRM, используя свой стандартный веб-сервис, обновляет карточку клиента по этому id_c

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


© 2013 Ведисофт
Москва: +7 (499) 703-04-23
Екатеринбург: +7 (343) 236-60-96
Почта: info_at_vedisoft_dot_info