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

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

Как показывает опыт, создание единой среды, охватывающей все бизнес-процессы предприятия, является сложной и трудоемкой задачей [2]. В современном мире как небольшие, так и крупные компании стремятся использовать ERP-системы. Однако даже такие крупные программные комплексы, как SAP, Oracle, IFS, IBM Cognos и другие, вынуждены модифицировать отдельные модули для обеспечения соответствия изменяющимся задачам. Распределение бизнес-процессов между несколькими приложениями дает компаниям возможность выбора наилучшего, гибкого пакета программ для бухгалтерского и финансового учета, оптимального приложения для управления поставками и складского учета, для решения производственных задач, ремонтов оборудования, а также для управления кадрами и расчета заработной платы. Однако не всегда предлагаемый разработчиками стандартный функционал удовлетворяет всем бизнес-требованиям. Разработчикам ПО приходится адаптировать соответствующие модули, дорабатывать и расширять функционал, что влечет за собой еще большие финансовые затраты предприятия-заказчика.

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

Для решения задачи интеграции данных IT-под­разделения создают частные интеграционные решения (стандартные программные интерфейсы). Преимуществом такого подхода является возмож- ность использования внутренних инструментов настройки интеграций этих ИС, а также относительно невысокая стоимость создания такого решения.

Бизнес-процессы горнодобывающего предприятия, реализуемые в ИС

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

Особенностью горнодобывающей промышленности является сложность взаимодействия предприятий, участвующих в процессе добычи, их географическое расположение, различие в методах отработки залежей в зависимости от особенностей физико-механических свойств поверхности и пород, что обусловливает уникальность IT-инфра­структуры на каждом горнодобывающем предприятии [2].

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

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

В блоке «Планирование горных работ» применяются горно-геологические ИС, позволяющие моделировать и планировать горные работы. Задачи блока «Управление производством и ТОиР» – управление производственными процессами, управление техническим обслуживанием и ремонтами, обеспечение промышленной безопасности. Блок «Управление финансами и бухучет» включает в себя управление бухгалтерским учетом, казначейство, учет и управление основными сред- ствами, учет затрат и доходов, калькуляцию себестоимости, финансовый контроль. Модуль «Управление поставками» эффективно решает задачу по организации закупочной деятельности служб материально-технического снабжения. Бизнес-процессы, связанные с кадровым учетом, учетом рабочего времени и расчетом заработной платы, решаются в блоке «Управление персоналом». Блок «Управление сбытом» включает ИС, решающую задачи реализации готовой продукции.

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

Потоки данных

Data flows

Горнодобывающее производство имеет следующие особенности [3]:

-     бизнес-процессы представляют собой сложный комплекс разнотипных технологий;

-     технологические процессы распределены в пространстве, что связано с географической удаленностью производств друг от друга;

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

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

Эти особенности обусловливают соответствующие ограничения на интегрируемые ИС

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

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

К основным недостаткам этого метода можно отнести несвоевременный обмен данными между приложениями и возникновение проблемы диссонанса при разборе интеграционного сообщения. Например, если разделителем полей в файле является символ «,» либо другие служебные символы и при вводе данных в систему-источник пользователь введет указанный символ в поле ввода, то при формировании интеграционного файла принимаемая система не сможет правильно обработать данный файл вследствие увеличения количества полей за счет применения указанного символа. Этот метод интеграции реализован между ИС бухгалтерского и финансового учета ERA Financials и системой управления материально-техническим снабжением IFS Procurement, между IFS Procurement и системой собственной разработки «Электронные торги», а также между IFS Procurement и системой складского учета WMS в компании «Корпорация Казахмыс». К преимуществам данной архитектуры можно отнести возможность легко добавлять дополнительные програм- мные комплексы на все уровни системы, а также отсутствие привлечения дополнительных средств или пакетов для интеграции.

Следующая концепция – взаимодействие систем по принципу точка–точка [4]. Точечная интеграция рекомендуется к реализации в единичных случаях между двумя системами с жестко определенными и не предполагаемыми к изменению в будущем требованиями к бизнес-процессам и передаваемым данным и чаще всего реализуется в небольших компаниях с упрощенными бизнес-процессами. Достоинствами этого метода являются возможность быстрой реализации интеграции с минимальными трудозатратами ресурсов и надежность взаимосвязей между компонентами. К недостаткам можно отнести сложную масштабируемость, сильную зависимость от интегрируемых систем и вследствие этого недостаточную гибкость. Следует отметить, что чаще всего подобные частные решения требуют дополнительной поддержки со стороны местной службы ИТ.

Концепция интеграции общей БД отличается от метода передачи данных посредством файлов тем, что обеспечивает единое пространство для хранения в ней информации [5, 6]. Недостатки данного метода:

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

-     большое количество подключений к общей БД снижает производительность систем и накладывает специализированные ограничения на архитектуру БД из-за возникновения блокировки данных;

-     если серверы приложений находятся отдаленно друг от друга и далеко от сервера БД, могут возникать «гонки» изменения данных;

-     сложность преобразования базовой структуры БД.

Технологии web-сервисов являются развитием концепции общей БД, в которой большинство потоков данных проходят через внешнюю среду (например через Интернет), что определяет дополнительные требования к надежности и скорости передачи данных.

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

Учитывая большой поток данных и подсистем, участвующих в построении единой ИС в горнодобывающей промышленности, изменения во времени функционала решаемых задач и, конечно же, стоимость внедрения и владения подобными системами, сложность и требования к надежности, предлагается рассмотреть относительно новую технологию построения интеграции данных на основе сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA), развитие которой в последние годы идет особенно быстрыми темпами.

Цель данной архитектуры – отвечать требованиям слабосвязанных ИС, осуществлять взаимодействие модулей ПО друг с другом [7]. В SOA программная обработка реализована в виде сервисов, которые представлены как автономные модули, обеспечивающие стандартную бизнес-функциональность и не зависят от текущего состояния или контекста других сервисов. Сервисы описаны на определенном стандартном языке. Имеют опубликованные интерфейсы и общаются друг с другом путем выполнения запросов с целью поддержки общих бизнес-задач. Наиболее популярные из доступных сегодня служб – это сервисы, использующие стандарты веб-служб, например, Simple Object Access Protocol (SOAP) для описания формата принимаемых и отправляемых сообщений, язык описания сервисов Web Services Description Language (WSDL) и стандарт Universal Description, Discovery and Integration (UDDI). UDDI используется для создания каталогов доступных сервисов. SOA реализует набор служб, которые могут осуществлять связь друг с другом, используя интерфейс для пе- редачи сообщений от одного сервиса к другому или координируя деятельность между одним и более сервисами.

Построение единой архитектуры интеграции данных

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

Исходя из вышеуказанных описаний, а также опираясь на лучшие мировые практики внедрения ПО, интеграцию ИС в компаниях горнодобывающей промышленности предлагается организовать посредством промежуточного ПО (корпоративной интеграционной шины Enterprise Service Bus, ESB) с применением сервис-ориентированной архитектуры SOA. Данный подход целесообразен для крупных компаний (групп компаний) с большим количеством различных интегрируемых систем и сложными бизнес-процессами [8].

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

На рисунке 2 представлена архитектура интегрируемых ИС.

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

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

В данной концепции интеграции необходимо реализовать две схемы подписки:

-     подписка на уведомления о бизнес-событиях;

-     подписка на запросы от конкретных систем.

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

Во втором случае системы-поставщики данных подписываются на запросы в очередь запросов, отрабатывают запросы и публикуют ответы в очередь ответов. Данная схема является достаточно гибкой с точки зрения подключения/изменения поставщиков данных на запросы, так как нет необходимости конечной системе вести информацию о точках доступа к конкретной системе [9, 10]. Все взаимодействие будет построено только на основе очередей сообщений.

На рисунке 3 схематично отображен процесс передачи данных между системой-источником и системой-потребителем.

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

Использование подобного подхода порождает ряд особенностей:

-     усложнение архитектуры и введение дополнительных элементов, которые, в свою очередь, требуют материальных и людских ресурсов, особенно остро это проявляется при условии объединения большого количества систем;

-     зачастую невозможность прямого подключения адаптеров к определенным системам, которые изначально не разрабатывались с учетом данного подхода [10].

Выводы

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

Работа выполнена при поддержке Российского научного фонда, проект № 17-11-01353.

Литература

1.     Клебанов А.Ф. Информационные системы горного производства и основные направления развития автоматизации открытых горных работ // Горная промышленность. 2015. № 2. С. 93–95.

2.     Хоп Г., Вульф Б. Шаблоны интеграции корпоративных приложений; [пер. с англ.]. М.: Вильямс, 2007. 672 с.

3.     Temkin I.O., Kulyanitsa A.L., Kubrin S.S. Application of intellectual system for robotic coal plough machine. Proc. Miner's week-2015 reports of the XXIII Intern. sc. sympos., 2015. pp. 274–280.

4.     Добровольский А. Интеграция приложений: методы, взаимодействия, топология, интрументы // Открытые системы. СУБД. 2006. № 9. С. 20–36.

5.     Калиниченко Л.А. Методы и средства интеграции неоднородных баз данных. М.: Физматлит, 1983. 424 с.

6.     Papazoglou M.P., van den Heuvel W.-J. Service oriented architectures: approaches, technologies and research. The VLDB Jour., 2007, no. 3, pp. 389–415.

7.     Nachiyappan S., Justus S. Big data validation needs and challenges. Intern. Jour. of Pharmacy and Technology, 2016, vol. 8, iss. 4, pp. 21998–22008.

8.     Li Y. Design and implementation of the management information system for Chain business corporation. Proc. 8th Intern. Conf. on Measuring Technology and Mechatronics Automation (ICMTMA 2016), 2016, pp. 195–198.

9.     Li J., Wang L., Yan L. Cloud Service based intelligent power monitoring and early-warning system, 2012 IEEE Innovative Smart Grid Technologies – Asia, 2012, Article no. 6303140. pp. 1944–1947.

10.  Christudas B.A. Service oriented Java business integration. Packt Publ.: 2008.

References

1. Klebanov A.F. Information systems of mining production and main directions of development of open mining operations automation. Gornaya promyshlennost [Mining Industry]. 2015, no. 2 (120), pp. 93–95 (in Russ.).
2. Hohpe G., Woolf B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional Publ., 2003, 736 p. (Russ. ed.: Moscow, Vilyams Publ., 2007, 672 p.).
3. Temkin I.O., Kulyanitsa A.L., Kubrin S.S. Application of intellectual systems for robotic plough machine control under complex mine-geological conditions. Reports 23rd Int. Sci. Symp. “Miner's Week-2015”. 2015, pp. 274–280.
4. Dobrovolsky A. Integration of applications: methods, interactions, topology, tools. Otkrytye sistemy. SUBD [Open Systems. DBMS]. 2006, no. 9 (in Russ.).
5. Kalinichenko L.A. Metody i sredstva integratsii neodnorodnykh baz dannykh [Methods and Tools for Integrating Heterogeneous Databases]. Moscow, Nauka Publ., 1983, 424 p.
6. Papazoglou M.P., van den Heuvel W.-J. Service oriented architectures: approaches, technologies and research issues. The VLDB Jour. 2007, no. 3, pp. 389–415.
7. Nachiyappan S., Justus S. Big data validation needs and challenges. Int. Jour. of Pharmacy and Technology. 2016, vol. 8, iss. 4, pp. 21998–22008.
8. Li Y. Design and implementation of the management information system for Chain business corporation. Proc. 8th Int. Conf. on Measuring Technology and Mechatronics Automation, ICMTMA. 2016, pp. 195–198.
9. Li J., Wang L. Email Author, Yan L. Cloud Service based intelligent power monitoring and early-warning system. 2012 IEEE Innovative Smart Grid Technologies – Asia. 2012, no. 6303140.
10. Christudas B.A. Service Oriented Java Business Integration. Packt Publ., 2008.