• Главная
•  
• Решения
•  
• Каталог

Что такое служба обмена данными и зачем она нужна?  

• Проблемы, которые приходится решать при обмене данными
• Решение проблем - СОД
• Чем мы лучше?

Проблемы, которые приходится решать при обмене данными

Каждый торговый представитель или любой другой полевой (мобильный) сотрудник работает на маршруте со своим набором данных – со своей базой данных (БД). Учётная система (УС), стоящая в офисе, работает с данными всех полевых сотрудников. Почему бы им как-нибудь не обмениваться данными непосредственно друг с другом? Например, КПК устанавливает связь с компьютером в офисе (предположим, по GPRS каналу), после чего кладёт предназначенные для передачи данные (файл) в определённую папку на этом компьютере. УС кладёт свой файл, предназначенный для передачи на КПК, в ту же папку, и КПК забирает этот файл. Что мешает сделать это без всякой Службы обмена данными (СОДа)?

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

Давайте разберёмся подробнее. Для того чтобы КПК мог передать куда-нибудь данные, предположим, по GPRS каналу, необходимо сначала обеспечить, чтобы КПК мог работать хотя бы одним из протоколов передачи данных.

1. SMTP – для общения с почтовым сервером;
   
   В этом случае, КПК просто сможет формировать и отправлять на определённый адрес почтовые сообщения. Либо оператор, либо шедулер в определённое время прикажут специальной утилите разобрать письма, понять, от кого они пришли, и сделать специальные записи в УС. Я предлагаю дальше для простоты этот очень хлопотный способ не рассматривать. Потому что он, хотя и рабочий, обладает таким количеством недостатков, что смело может быть сравнён с проктологическим методом удаления гланд.

2. HTTP – для того, чтобы выкладывать данные на WEB;

3. FTP - чтобы выкладывать данные на FTP-сервер

Рассмотрим два последних. Данные нужно не просто передать. Для них нужно создать соответствующие FTP-папки или WEB-страницы. Эти папки нужно администрировать (удалять старых и заводить новых клиентов, стирать либо архивировать старые данные, делать бэкапы).
А когда данные с КПК торговых уже получены и безошибочно разложены по правильным папкам и WEB-страницам, УС может обработать их по команде оператора.
Но люди совершают ошибки, выходят покурить или в туалет, в конце концов. И даже, если они на месте, то время их реакции будет исчисляться минутами.
Если же мы настроим шедулер, который будет инициировать обработку полученной информации, например, каждую минуту, то и здесь необходимо отличать и обрабатывать лишь вновь поступившую информацию и игнорировать обработанную ранее. И не пытаться обработать файлы, которые в момент начала обработки переданы не до конца.
Самым разумным было бы заставить программу следить за тем, что передача и сортировка данных осуществлена правильно, так, чтобы она сама сообщала УС о завершении операции с тем, чтобы инициировать обработку полученной информации. Такой процесс называется нотификацией.
А ещё хотелось бы вести подробный ЛОГ операций, чтобы в случае чего можно было бы разобраться в причинах возможных инцидентов и неприятностей.

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

Решение проблем - СОД

В таком случае для осуществления всех этих функций естественно написать отдельное ПО, которое должно обеспечить передачу данных по всем известным каналам связи – через IR, GSM, GPRS, WiFi, WiMax, Bluetooth, CDMA и т.д. Сегодня такие программы используют любые известные системы автоматизации мобильной торговли, и, по крайней мере, большинство из способов передачи информации они покрывают…

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

Мы коротко расскажем об архитектуре и функциях нашей "ST-Службы обмена данными" 2.2 (ST-Сод). Только о самом важном.
Мы решили уделить этому ПО самое пристальное внимание потому, что:
• Во-первых, мы полагаем, что удалённый обмен данными - важнейшая функция системы, критическая для наших клиентов.
• А во-вторых, сам процесс обмена связи в силу объективных причин может быть крайне неустойчивым и сопровождаться обрывами и сбоями, с которыми нужно как-то управляться.

Чем мы лучше?

Я хотел бы подчеркнуть только принципиальные отличия нашей Службы обмена данными от других аналогичных продуктов:

1.  Важнейшее отличие – это действительно служба! Программисты меня поймут… Наша программа написана как сервис, а не как приложение, и обладает всеми специфическими функциями службы. Написание и отладка службы требует в разы большего объёма работы по сравнению с приложением. Но и надёжность, устойчивость к сбоям, остановкам, отключению электричества и т.д., а также открывающиеся новые возможности оказываются качественно иными. Это как сравнивать два автомобиля – «Волгу» и BMW. По основным характеристикам они вроде одинаковы (четыре колеса, мотор, тормоза, коробка передач и т.д.), но, качественно, это – разные машины :-). Те, кто называют свои приложения сервером, лукавят. Это – как называть вентилятор климат контролем на том основании, что он «тоже воздействует на климат в автомобиле».
2. Наша СОД 2.2. ведёт подробный лог (журнал событий). Так что можно, в случае чего, разобраться в причинах возможных инцидентов и неприятностей. 
3.  СОД 2.2. может стоять не только рядом с УС, но и в любом месте и взаимодействовать через Интернет и с УС и с КПК. То есть, ему не обязательно находиться в том же офисе, что и учётная система.
4. Управление СОД 2.2. выведено на консоль администратора СОД, которая также может находиться как в локальной сети вместе с СОД, так и в сети Интернет. Это означает, что администратор может управлять СОД 2.2. удаленно.
5. СОД 2.2. организует нотификацию учётной системы Клиента с тем, чтобы заставить её обработать полученную информацию – при этом предусмотрено три возможных способа нотификации. Это майкрософтовская очередь сообщений (в последней версии их можно одновременно организовать сколько угодно) — по этой процедуре нотифицируется 1С и другие сходные системы. Это вызов SQL запросов для работы с SQL серверами. И это отсылка E-mail сообщений. Последнее также позволяет настроить отсылку E-mail сообщений по любому событию на любой адрес (например, уведомлять любого абонента об окончании выгрузки данных или об их успешной обработки и т.д. – много чего).
6. Разграничение прав операторов – эта функция востребована, когда нужно кому-то дать доступ к консоли (например, для создания или удаления новых учетных записей агентов), но не стоит давать полных административных прав, которыми должен обладать только администратор СОД. В частности, этот механизм реализован в централизованном решении, когда менеджеры могут заводить и удалять пользователей в своих городах, обращаясь к единственной СОД, стоящему в центральном офисе.
7.  В поставке присутствует клиентское приложение, которое позволяет организовать обмен между любыми учетными системами. С помощью него можно, например, организовать обмен данными между БД, стоящими в магазинах компании, и центральным офисом. Или, к примеру, между двумя различными учётными системами.
8. GPS "ST-Служба обмена данными" может принимать, обрабатывать и визуализировать данные от различных источника сигналов, например от КПК, коммуникаторов или от GPS-контроля и трекеров. При этом нет необходимости в использовании любых сторонних сервисов (часто производители GPS - контроллеров и трекеров позволяют работать с получаемыми от них данными только при использовании на платной основе их сервисов, расположенныех в Интернете).
9. Чуть не забыл!... СОД обменивается с мобильной торговлей по написанному нами специализированному протоколу, который, с одной стороны, обеспечивает высокую скорость передачи, а с другой - защиту от взлома (поскольку, этот протокол не является общепринятым, нет и «ломалок» на него). Следует заметить, что протоколы, обычно используемые HTTP и FTP, не шифруются, что может сделать вашу информацию в Интернете доступной злоумышленникам.
10. При обрыве связи, обмен информацией продолжается с места обрыва (докачка). Это особенно важно при передаче больших объёмов (удалённое обновлении ПО, передаче данных, накопленных за длительный промежуток времени - день, неделю) и плохих каналах. На просторах России и СНГ такое ещё встречается довольно часто. В любом случае, надёжность лишней не бывает.
11.  И ещё! При возникновении ошибок и конфликтов (от которых никто не застрахован), ПО собирает данные о функционировании системы, об условиях в которых произошла ошибка, формирует письмо в нашу службу поддержки и, с Вашего разрешения, отправляет его нам. Это позволит нам более оперативно и с меньшими потерями времени вашего персонала решать возможные проблемы.
    

Наша Служба обмена данными не только реализует важный уникальный функционал (то есть функционал, которого нет больше ни у кого), но и обладает экстраординарными надёжностью и быстродействием.

Кроме всего прочего, мы заботимся о комфорте нашего Клиента. Надёжность - важнейший фактор комфорта!

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