Обеспечение деятельности ОАО «Ростовэнерго» с применением корпоративной информационной системы

Поэтому на первом этапе  было принято решение о переходе на архитектуру клиент-сервер, с использованием наиболее совместимой с FoxPro СУБД – MS SQL Server 2000 и реализации части бизнес логики в виде хранимых процедур. Данный процесс по времени занял примерно около одного года.

На втором этапе  согласно распоряжению дирекции ОАО «Ростовэнерго» была реализована возможность ведения единой базы нормативно справочной информации (НСИ) и реестра контрагентов. Первая задача была решена средствами СУБД MS SQL Serever 2000 с помощью механизма репликации. В силу того, что НСИ является относительно статичной структурой, то есть изменения и дополнения данных выполняются не часто, было принято решение делать репликацию снимка НСИ с сервера аппарата управления, которая выполняется раз в сутки в нерабочее время и передавать его подписчикам – SQL серверам филиалов. Для решения второй задачи, был задействован совершенной другой механизм, в силу того, что филиалам при заключении договоров необходимо оперативно заводить нового контрагента, в случае если он отсутствует в едином реестре, причем с данным контрагентом, договора могут заключать разные филиалы. То есть необходимо чтобы при вводе нового контрагента он автоматически попадал в единый реестр. Для этих целей стали использовать каркас (framework) менеджера транзакций Mule, реализовав с его помощью корпоративную шину для обмена информацией (enterprise service bus - ESB), следующим образом. При вводе нового контрагента, перед тем как выполнить внесение в единый реестр, выполняется его поиск на центральном сервере аппарата управления по ИНН и КПП, и если в другом филиале данный контрагент в этот день уже был заведен, то выдается его идентификатор, в противном случае он добавляется в реестр, а вечером реестр вместе с НСИ реплицируется на все филиалы. Реализация, отладка и внедрение второго этапа по времени заняли примерно около полугода.

Параллельно первому  и второму этапам выполнялось  проектирование и реализация многослойной архитектуры распределенной корпоративной  системы. В качестве инструментальных средств выбрана Java – технология и решения базирующиеся на ней. Так как во–первых, де-факто Java – технологии – промышленный стандарт в области больших корпоративных распределенных систем, во – вторых сам язык Java и сопутствующие средства, такие как, например среда разработки NetBeans, Eclipse, средство ORM – отображения Hibernate, всевозможные менеджеры отчетов и пр. являются свободно распространяемыми. В третьих, в силу открытости данной технологии, она легко интегрируется с любой СУБД. В – четвертых, Java является аппаратно- и платформено- независимой, то есть система реализованная с помощью Java – технологии может работать на компьютерах не только с архитектурой x86 и не только на операционной системе Windows.

Рассмотрены варианты смены платформы СУБД на более «дружественную» по отношению к Java. Был реализован ряд тестов для сравнительной оценки производительности при работе с СУБД, на основании которых в качестве альтернативы предполагается использование MySQL v.5, PostgreSQL 8.2, также отработана технология межплатформенного переноса данных.

На рисунке 1 представлена «Архитектура системы». Рассмотрим более подробнее каждый из уровней. Уровень базы данных отвечает за реализацию физического хранения. Во время первого и второго этапов выполнялся постоянный мониторинг работы SQL- сервера в результате которого были выявлены «узкие» места в его работе, снижавшие его производительность. Во-первых, была выполнена нормализация всех отношений и их приведение к третьей нормальной форме. Во-вторых, для снижения нагрузки на СУБД, было принято решение реализовать хранение небольших по объему, около сто записей, справочников в формате XML на Web-сервере, а при загрузке приложения выполнять анализ данного файла и заносить его содержимое в стековые структуры. Такой подход позволяет добиться повышения производительности системы, как на стороне сервера, так и на стороне клиента. В-третьих, решили отказаться от хранимых процедур на стороне СУБД и вынести их на уровень сервера приложений, так как при значительном увеличении количества пользователей (100 и более) пытающихся их одновременно выполнять существенно снижает производительность. Кроме того, специфика синтаксиса языка T-SQL MS SQL Sever не позволяет переносить хранимые процедуры на другие серверные платформы без их глобальной переработки.

Уровень сервера приложения, представляет из себя, множество слоев (рисунок 1), которые при необходимости для повышения производительности могут быть разнесены между несколькими серверами. Взаимодействие между уровнем баз данных и уровнем сервера приложений реализуется ORM системой – Hibernate. Это обстоятельство является одной из важных частей позволяющей довольно просто переходить от одной платформы СУБД к другой, без изменений в других слоях. Слой бизнес – логики в свою очередь условно можно разделить на несколько частей. Первая часть отвечает за работу с СУБД. Основная цель, которую пытались достичь при реализации данной части – снижение нагрузки на СУБД. Для чего все методы реализующие запросы к СУБД старались делать универсальными, то есть не зависящими от реализации конкретного бизнес объекта, используя компонент библиотеки Hibernte – Criterion, а далее работать с полученными коллекциями, используя механизмы Java - RTTI и Reflection реализуя методы, позволяющие выбирать бизнес объекты из коллекции по различным критериям. Кроме того, при работе с большим количеством бизнес объектов (десятки и сотни тысяч) использовали отсоединенные коллекции (DetachetCriterion). Описанное выше, является второй важной частью делающей приложение независимым от платформы СУБД. Следующая составная слоя бизнес логики – специфичные методы, реализованные для конкретной задачи.

Рисунок 1 – Архитектура системы

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

Слой отчетов, это фактически набор шаблонов для  их построения. Отчеты строятся с использованием библиотеки JasperReport, а при реализации Web-клиента с помощью xslt преобразования, для чего реализован подслой с xslt – шаблонами.

Последний слой – Web-компонент реализован для построения web интерфейса.

На уровне клиента  реализовано два типа интерфейсов  – Web-клиент и полнофункциональный Swing – клиент. Так как ни одно web-приложения не обладает такими возможностями, которые  предоставляет для пользователя библиотека Swing. Поэтому было принято решение для реализации относительно простых возможностей использовать Web-интерфейс, а взаимодействие посредством Swing – клиента, реализовать, используя технологию Java Web-start.

Кроме того, была разработана технология единой идентификации  пользователей корпоративной системы на территории всей Ростовской области на базе быстрого и удобного механизма - LDAP сервера. На сервере, данные о пользователях разбиты в зависимости от их принадлежности к филиалу в иерархические структуры, которые повторяют организационные структуры ОАО «Ростовэнерго». Сам объект «пользователь», хранящийся на сервере содержит массу дополнительной информации, которая в том числе может использоваться для конфигурирования программ, например атрибут филиала – IP адрес сервера СУБД. Более того извлекая информацию с LDAP сервера и используя для доступа Web – интерфейс, можно формировать справочную систему, например телефонный справочник предприятия, не затрачивая дополнительных усилий.

Таким образом, был выполнен реинженеринг существующей системы и разработана архитектура и каркас (framework) приложения. Однако мы себе отчетливо представляли, что процесс перехода на новую архитектуру будет довольно сложным и долгим, так как одна из самых больших проблем связана с переносом данных в новые структуры, а малейшие изменения в существующих структурах данных могла привести к катастрофическим последствиям. Так же для коллективной разработки, использовался Subversion server(SVN). Это обеспечивает качественную связь всех разработчиков системы. В качестве клиента SVN был выбран продукт TortiseSVN.

  
Рисунок 2 – Схема взаимодействия

1. юристов филиалов при добавлении и редактировании данных;
2. юристов филиалов при просмотре данных;
3. юристы управления при добавлении, редактировании и просмотре данных

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

Для первой задачи были проанализированы все возможные  варианты ее решения. Самым правильным решением в данном случае является переход на сервер приложений и использование менеджера транзакций, например JOTM. Однако в силу целого ряда субъективных и объективных причин быстрый переход на такую архитектуру не представлялся возможным. Поэтому было принято решение использовать для двухфазной транзакции средства библиотеки Hibernate. Так же следует учитывать то, что взаимодействие клиентов аппарата управления и клиентов на филиалах с СУБД существенно отличаются. На рисунке 2 представлена Схема взаимодействия. Юристы аппарата управления работают только с центральным сервером, выполняя операции редактирования добавления и выборки при этом, «видя» весь реестр договоров. Юристы на филиалах при редактировании и добавлении в начале вносят их на центральный сервер, после чего происходит внесение данных на сервере филиала, а при просмотре происходит взаимодействие только с локальным сервером. Реализация данной схемы на всех уровнях архитектуры приложения выглядит следующим образом:

1. Уровень клиента. Приложение работает по технологии Web-start и имеет Swing- интерфейс.
2. Уровень сервера приложений. На основании полученного с LDAP сервера IP – адреса происходит настройка подключения к СУБД. В случае если указан IP – адрес филиала, то выполняется настройка Hibernate на создание двух фабрик сессий (SessioFactory), одна из которых создается с центральным сервером другая с локальным. При этом бизнес объект имеет два варианта мэппиинга, основное отличие которых заключается в способе получения идентификатора, на сервере значение – native, а на филиале – assign. В случае если IP – адрес центрального сервера, то соответственно создается одна фабрика сессий. Исходя из этого, работают методы сохранения и обновления бизнес объектов. При работе юристов филиала вначале изменения вносятся на центральный сервер, а затем на локальный, в случае их успешного занесения на оба сервера происходит принятие транзакций (commit) на обоих серверах, в случае возникновения каких либо проблем на одном из серверов происходит общий откат (rollback) транзакции. Следует заметить, что за время эксплуатации данной технологии в течение четырех месяцев, каких либо значимых сбоев или потери информации не было. Следующим шагом стал переход на технологию с использованием менеджера транзакции JOTM. В силу того, что отсутствует возможность установки и эксплуатации сервера приложений на каждом филиале, было принято решение использовать один сервер приложений Tomcat, на котором формировать источники данных для каждого филиала.
3. Уровень базы данных. Уровень базы данных на филиале и в аппарате управления отличается только способом задания уникальности идентификатора бизнес объекта. В аппарате управления установлено автоматическое увеличение на 1.

Таким образом, переход к полноценной единой корпоративной системе в РЭ – это процесс, который может растянуться на годы. Несмотря на его трудоемкость, уже сейчас очевидны его преимущества, особенно с использованием технологий от Sun Microsystems. Которые обеспечивают, оперативный доступ к любому сегменту информации на территории Ростовской области, являются свободно распространяемыми, в отличие, например от подобных технологий на базе SAP R/3.

 

ЗАКЛЮЧЕНИЕ

 

 

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

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

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

СПИСОК  ЛИТЕРАТУРЫ

 

 

1. Вершинин О.В. Компьютер для менеджера. - М.: Высшая школа, 1990.
2. Вычислительные машины, системы и сети / Под ред. А.П. Пятибратова. - М.: Финансы и статистика, 1991.
3. Герасименко В.А. Защита информации в автоматизированных системах обработки данных. - В 2-х кн. - М.: Энергоатом-издат, 1994.
4. Гершторин Л.Г. Что такое АРМ бухгалтера. - М.: Финансы и статистика, 1988.
5. Гольц Г. Рабочие станции и информационные сети/ Пер. с англ. В.П. Нестерова; Под ред. П.В. Нестерова. - М.: Машиностроение, 1990.
6. Доил У. Табличный процессор Суперкалк. для персонального компьютера/ Пер. с англ. - М.: Финансы и статистика, 1987.
7. Жигарев А.Н., Макарова Н.В., Путинцева М.А. Основы компьютерной грамоты. -Л.: Машиностроение, 1987.
8. Локальные вычислительные сети/Под ред. С.В. Назарова. -В 3-х кн. - М.: Финансы и статистика, 1994 - 1995.
9. Нортон П. Программно-аппаратная организация IBM PC: Пер с англ. - М.: Радио и связь, 1991.
10. Персональный компьютер для всех/ Под ред. А.Я. Савельева. - В 4-х кн. - М.: Высшая школа, 1991.
11. Свириденко С.С. Современные информационные технологии. - М.: Радио и связь, 1989.
12. Фигурнов В.Э. IBM PC для пользователя. - М.: Финансы и статистика, 1994.
13. флинт Д. Локальные системы ЭВМ. Архитектура, принципы построения, реализация.: Пер. с англ. - М.: Финансы и статистика, 1986.
14. Якубайтис Э.А. Информатика - Электроника - Сети. - М.: Финансы и статистика, 1984.