Программные продукты и системы

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

Исторически для автоматизации работы сотрудников использовались два кардинально противоположных подхода [1]: полный offline-ре­жим, когда обмен выполнялся не чаще одного или двух раз в день (как правило, такой обмен требует наличия стабильного выделенного канала, так как объем передаваемых данных довольно значителен – сотни МГб); полный online – в этом режиме все данные получаются непосредственно с сервера в момент запроса. Оба эти подхода, характерные для крупных CRM/ERP-систем, имеют ряд ключевых (концептуальных) проблем. В первом случае это катастрофически низкая оперативность данных, во втором – непомерно высокие требования к стабильности канала передачи данных.

Существует несколько систем, которые изначально создавались под задачу сбора данных с помощью мобильных терминалов в условиях нестабильной работы канала передачи данных [2, 3]. Данные системы используют модифицированный offline-режим, в котором обмен данными можно проводить достаточно часто, так как размер передаваемых данных ограничен. К сожалению, при проектировании этих систем были допущены серьезные просчеты, которые привели к избыточности функций (дублирование бизнес-процессов корпоративной информационной системы (КИС), например ведение остатков) либо к жесткой привязке к программным платформам (например 1С). Результат многолетней эксплуатации показал, что несколько имеющихся систем (в том числе и лидер данной отрасли CDC Optimum) либо требуют постоянного контроля за их работой, либо сложно масштабируются в случае использования в крупных проектах (автоматизация крупных производителей).

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

Таким образом, для решения поставленной задачи необходимо:

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

–      спроектировать и выполнить программную реализацию комплекса;

–      провести промышленную эксплуатацию разработанной системы.

Решение поставленной задачи возможно при соблюдении следующих условий:

–      будет уменьшено количество элементов системы, разрабатываемых с нуля, соответственно, необходимо максимально использовать стандартные протоколы передачи данных и стандартные механизмы хранения данных;

–      в любой момент времени будет доступен срез актуальных данных таким образом, чтобы недоступность КИС не препятствовала получению данных со стороны мобильных клиентов;

–      все данные должны быть подготовлены индивидуально для каждого удаленного пользователя системы и предоставлены ему таким образом, чтобы у пользователя по определению не было возможности получить доступ к чужим данным;

–      сбор данных будет возможен даже в том случае, если наблюдаются проблемы с каналом их передачи.

Анализ различных существующих систем показал, что обмен данными должен осуществляться в пакетном режиме [1, 2]. Каждый пакет – это специально оформленный текстовый файл. Обмен пакетами производится через FTP-серверы, которые изначально проектировались для этих целей (обмен файлами). Хранение пользователей и их параметров должно осуществляться в LDAP-каталоге таким образом, чтобы все элементы системы имели к нему доступ. Обмен уведомлениями должен происходить через SMTP/POP3-серверы.

Таким образом, программный комплекс можно разделить на три составные части (рис. 1): мобильный клиент OMOBUS, отвечающий за организацию эффективного и надежного сбора данных; сервер OMOBUS, организующий потоки данных; интеграционный слой, связывающий сервер OMOBUS и КИС.

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

Сервер OMOBUS (omobusd) реализован на языке C/C++. В качестве целевой платформы для его работы используется операционная система openSUSE (с возможностью переноса на другие Linux-системы – код на C/C++ собирается непосредственно, требуется лишь переработка скриптов инициализации демонов). Сервер разделен на четыре составные части.

·       Центральный процесс, реализующий конвейер выполнения операций (omobusd). При этом для повышения эффективности работы конвейер спроектирован так, чтобы подключение к источнику данных было минимальным по времени.

·       Набор подключаемых модулей, скрывающих детали доступа к источнику данных (stor_*). В настоящий момент реализованы процедуры доступа к следующим источникам данных: PostgreSQL (stor_pgsql), Firebird (stor_fb – для доступа используется C++ библиотека IBPP), Microsoft SQL Server (stor_sybdb – доступ к серверу БД осуществляется с помощью протокола TDS, свободная реализация которого предоставляется в рамках проекта freetds).

·       Набор подключаемых модулей, реализующих логику работы (далее – ядро) в зависимости от поставленных задач (kern_*).

·       Текстовые конфигурационные файлы в формате xml, осуществляющие тонкую настройку системы.

Конвейер операций представляет собой последовательное выполнение следующего набора действий.

1.     Перевод процесса в режим демона, при котором процесс полностью отключен от всех управляющих терминалов, стандартный поток ввода stdin блокирует закрытия или перенаправления на устройство /dev/null. Стандартные потоки вывода перенаправляются в журнальные файлы. В результате всех перечисленных действий процесс становится полностью автономным, а его остановка возможна только путем отправки специального сигнала SIG_USR1 или SIG_KILL.

2.     Разбор конфигурационных параметров, включающих все необходимые для работы системы данные.

3.     Загрузка модуля доступа к данным и ядра.

4.     Переключение на заданный режим работы. Существуют следующие режимы:

·       simple – предписанный набор операций выполняется один раз, после этого работа процесса прекращается (данный режим используется только для отладки);

·       cycle – режим циклического выполнения операций через строго заданный интервал времени (данный режим используется для организации периодического выполнения без строгой привязки к моменту выполнения; для реализации необходимого функционала используется внутрипроцес- сный POSIX-семафор);

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

5.     Инициализация ядра. После выполнения данной операции ядро переходит в состояние «готово к использованию».

6.     Подключение к источнику данных, определенному в настройках с помощью модуля доступа к данным.

7.     Начало новой транзакции. Если источник данных не поддерживает транзакционную целостность данных, эта операция игнорируется на уровне модуля подключения к данным.

8.     Выполнение операций ядра в рамках подключения. В этом режиме ядро может выполнять любые предписанные операции с источником данных.

9.     Завершение транзакции.

10. Выполнение операции ядра вне транзакции.

11. Отключение от источника данных.

Приведенная последовательность действий является обобщенной, порядок и количество выполнений тех или иных шагов могут варьироваться в зависимости от режима работы сервера. На рисунке 2 приводится детальная схема работы режима event.

К моменту реальной эксплуатации были следующие ядра.

Kern_sync – ядро генерации пакетов данных (в CSV-подоб­ном формате), необходимых и достаточных для работы мобильных клиентов в полностью автономном режиме. Данные генерируются индивидуально для каждого пользователя. Такой подход позволяет исключить их избыточность за счет того, что мобильным клиентам предоставляются только те данные, которые им необходимы. Для повышения производительности процедура непосредственной генерации пакетов может выполняться параллельно несколькими потоками. Созданный набор пакетов публикуется на ftp-сервере.

При проектировании и реализации интерфейса пользователя была применена концепция предписанного бизнес-про­цесса, заключающаяся в том, что пользователю предписывается строго один предопределенный путь для достижения поставленной цели. Такой подход позволяет полностью устранить возможность произвола со стороны сотрудников, которые работают с устройством. Данная концепция дополняется возможностью мониторинга всех параметров выполнения как системы в целом, так и omobus-mobile. Возможен контроль следующих параметров: электропитание, подключение к ПК, включение и выключение устройства, выполнение бизнес-операций в пользовательском интерфейсе omobus-mobile, перемещения (по данным GPS).

Интерфейс пользователя omobus-mobile строится по модульному принципу. Порядок и количество используемых модулей зависит от целей, для которых используется система. На рисунке 3 приводится пример нескольких экранов omobus-mobi­le, который был использован для автоматизации производителя молочной продукции, осуществляющего прямые поставки в розничные торговые точки.

Интеграционный слой отвечает за гибкое подключение OMOBUS к КИС. Основным требованием к данной части системы является возможность гибкого изменения всех параметров интеграции. Возможны следующие варианты интеграции.

·       Прямое подключение к СУБД КИС. Взаимодействие с КИС выполняется с помощью скриптов, написанных на языке SQL. В данном случае обеспечивается максимально быстрый обмен данными, однако не всегда такой вариант возможен как по техническим, так и по организационным (политическим) причинам.

·       Прямое подключение к КИС с использованием ее API. Данный вариант является аналогом предыдущего, за исключением того, что обмен идет через стандартный интерфейс КИС.

·       Обмен данными с помощью текстовых файлов в CSV-подобном формате. Обмен файлами ведется через общий ftp-ресурс. В данном случае OMOBUS производит накопление собранных данных в специальном хранилище. Впоследствии собранные данные выгружаются с предписанной периодичностью.

В целом все перечисленные варианты имеют свои плюсы и минусы и могут применяться в зависимости от решаемой задачи.

Система OMOBUS используется в промышленной эксплуатации с 2006 г. За это время разработанная архитектура показала свою высокую эффективность. В отличие от других она не требует постоянного контроля за работой со стороны персонала компании, в которой данная система используется. Внедрение системы OMOBUS позволяет значительно увеличить объем продаж (например, у производителя молочной продукции объем продаж увеличился на 35 %), а также сократить операционные издержки сотрудников (например за счет экономии ГСМ).

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

Литература

1.     Siebel Mobile Solutions. URL: http://www.oracle.com/us/ products/applications/siebel/contact-center-service/038243.htm (дата обращения: 03.05.2012).

2.     ОПТИМУМ АСУМТ. URL: http://www.cdc.ru/soluti­ons/optimum-asumt/ (дата обращения: 03.05.2012).

3.     Комплекс «ST–Мобильная Торговля. Чикаго». URL: http://www.sys4tec.com/ (дата обращения: 03.05.2012).

References

1.  Siebel Mobile Solutions,  Available at:  http://www.oracle. com/us/products/applications/siebel/contact-center-service/038243. htm (accessed 03 May 2012).

2.  Automated Control System OPTIMUM,  Available at: http://www.cdc.ru/solutions/optimum-asumt/  (accessed  03  May 2012).

3.  Complex «ST Mobile  Trade. Chicago»,  Available at: http://www.sys4tec.com/ (accessed 03 May 2012).