ST – Сервер обмена данными

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

Я тут на одном уважаемом сайте прочёл, что сервер обмена данными – это промежуточная база данных между КПК и учётной системой клиента. Сразу оговорюсь, что авторы подобных высказываний не разобрались в данной теме, а, может быть, просто запутались в ней.

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

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

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

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

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

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

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

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

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

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

Мы коротко расскажем об архитектуре и функциях нашего СОД-2.0 (сервера обмена данными). Только о самом важном. 
Мы решили уделить этому ПО самое пристальное внимание потому, что: 

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

• А во-вторых, сам процесс связи в силу объективных причин может быть крайне неустойчивым и сопровождаться обрывами и сбоями, с которыми нужно как-то управляться… 
  
  

Чем мы лучше? 

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

1. Важнейшее отличие – это действительно сервер! Программисты поймут… То есть, наша программа написана как сервис, а не как приложение, и обладает всеми специфическими функциями сервера. Написание и отладка сервиса требует в разы большего объёма работы по сравнению с приложением. Но и надёжность, устойчивость к сбоям, остановкам, отключению электричества и т.д., а также открывающиеся новые возможности оказываются качественно иными. Это как сравнивать два автомобиля – «Волгу» и мою любимую Toyota Camry. По основным характеристикам они вроде одинаковы (четыре колеса, мотор, тормоза, коробка передач и т.д.), но, в сущности, это– разные машины :-). Те, кто называют свои приложения сервером, немного лукавят. Это – как называть вентилятор климат контролем на том основании, что он «тоже воздействует на климат в автомобиле».

2. Наш СОД 2.0. ведёт подробный лог (журнал событий). Так что можно, в случае чего, разобраться в причинах возможных инцидентов и неприятностей.

3. СОД 2.0. может стоять в любом месте и взаимодействовать через Интернет не только с КПК, но и учётной системой. То есть, ему не обязательно находиться в том же офисе, что и учётная система.

4. Управление СОД 2.0. выведено на консоль администратора СОД, которая также может находиться как в локальной сети вместе с СОД, так и в сети Интернет. Это означает, что администратор может управлять СОД 2.0. удаленно.

5. СОД 2.0. организует нотификацию учётной системы Клиента с тем, чтобы заставить её обработать полученную информацию – при этом предусмотрено три возможных способа нотификации. Это майкрософтовская очередь сообщений (в последней версии их можно одновременно организовать сколько угодно) - по этой процедуре нотифицируется 1С и другие сходные системы. Это вызов SQL запросов для работы с SQL серверами. И это отсылка E-mail сообщений. Последнее также позволяет настроить отсылку Email сообщений по любому событию на любой адрес (например, уведомлять любого абонента об окончании выгрузки данных или об их успешной обработки и т.д. – много чего).

6. Разграничение прав операторов – эта функция востребована, когда нужно кому-то дать доступ к консоли (например, для создания или удаления новых учетных записей агентов), но не стоит давать полных административных прав, которыми должен обладать только администратор СОД. В частности, этот механизм реализован в централизованном решении, когда менеджеры могут заводить и удалять пользователей в своих городах, обращаясь к единственному СОД, стоящему в центральном офисе.

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

8. GPS – СОД может принимать, обрабатывать и визуализировать данные от различных источника сигналов, например от КПК, коммуникаторов или от GPS-контроллеров и трекеров. При этом нет необходимости в использовании любых сторонних сервисов (часто производители GPS- контроллеров и трекеров позволяют работать с получаемыми от них данными только при использовании на платной основе их сервисы, расположенные в Интернете).

9. Чуть не забыл!... СОД обменивается с мобильной торговлей по специально написанному нами специализированному протоколу, который, с одной стороны, обеспечивает высокую скорость передачи, а с другой - защиту от взлома (поскольку, этот протокол не является общепринятым, данные надёжно зашифрованы). Следует заметить, что протоколы обычно используемые HTTP и FTP, не шифруются, что может сделать Вашу информацию в Интернете более доступной злоумышленникам.

10. При обрыве связи, обмен информацией продолжается с места обрыва (докачка). Это особенно важно при передаче больших объёмов (обновлении ПО, передаче данных, накопленных за длительный промежуток времени - день, неделю) и плохих каналах. На просторах России и СНГ такое ещё встречается довольно часто. В любом случае, надёжность лишней не бывает. 
    

11. И ещё! При возникновении ошибок и конфликтов (от которых никто не застрахован), ПО собирает данные о функционировании системы, об условиях в которых произошла ошибка, формирует письмо в нашу службу поддержки и, с Вашего разрешения, отправляет его нам. Это позволит нам более оперативно и с меньшими потерями времени Вашего персонала решать возможные проблемы. 
    
    

Обращаю Ваше внимание на то, что в большинстве случаев речь идёт не о замечательных новых функциях, а об отсутствии принципиальных ограничений и источников проблем, свойственных конкурирующим программам. А также о чрезвычайном комфорте и надёжности в реализации общепринятых функций. Кроме, конечно, пунктов 7, 8 и 9, которые являются именно новым функционалом.