Inf_comp_sys

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

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

14.3.2 Шлюз записи данных

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

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

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

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

111

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

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

14.3.3 Активная запись

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

вобъект домена. В этом случае все знают, как считывать данные из базы данных и как их записывать в нее.

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

втаблице базы данных: каждое поле объекта должно соответствовать одному столбцу таблицы. Значения полей следует оставлять такими же, какими они были получены в результате выполнения SQL-команд; никакого преобразования на этом этапе делать не нужно. Активная запись может применяться к таблицам или представлениям (хотя в последнем случае реализовать обновления будет значительно сложнее). Использование представлений особенно удобно при составлении отчетов.

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

Недостатком использования активной записи является тесная зависимость структуры ее объектов от структуры базы данных. В этом случае изменить структуру базы данных или активной записи довольно сложно, а ведь по мере развития проекта подобная необходимость возникает очень и очень часто.

14.3.4 Преобразователь данных

Преобразователь данных – это промежуточный объект, который осуществляет передачу данных между объектом предметной логики и базой

112

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

113

Глава 15. Предпосылки интеграции

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

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

Materials Requirements Planning (MRP-систем), MRPII, Enterprise Resource Planning (ERP-систем), Customer Synchronized Resource Planning (CSRP-систем) и Customer Relations Management (CRM-систем).

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

Рассмотрим основные коммерческие продукты корпоративного уровня. MRP системы решают задачи планирования потребностей в материалах с

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

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

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

114

В то же время, MRPII системы не контролируют конструкторские разработки, составление сметы, кадры, сбыт и распределение продукции, обслуживание, т.е. подразделения не объединены в одну систему.

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

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

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

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

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

Основное отличие CRM систем от всех остальных информационных систем предприятия состоит в следующем. Прочие системы (ERP, документооборот) минимизируют расходы и/или «наводят порядок», а значит, работают на экономичность и экономию (снижение цены покупки), тогда как CRM системы призваны наращивать эффективность бизнеса: отбором правильных клиентов и корректным выстраиванием отношений с первого раза.

115

Более современной концепцией управления ресурсами предприятия является CSRP (customer synchronized resource planning, планирование ресурсов,

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

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

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

Несмотря на довольно широкую функциональность, перечисленные выше системы не являются полностью интегрированными системами управления: на многих предприятиях существуют подразделения, деятельность которых хотя и связана с производственным процессом, однако не укладывается в существующую идеологию этих систем. Для автоматизации работы таких подразделений используются свои системы. Речь идет, например, о системах автоматизированного проектирования (САПР), системах конструкторской и технологической подготовки производства (PDM-системы - Product Data Management), а так же о ряде приложений, разработанных внутренними силами компании. Поэтому реально на предприятии всегда используется ряд коммерческих продуктов описанных классов совместно с подобными подсистемами.

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

116

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

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

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

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

117

Глава 16. Подходы и методы интеграции приложений

16.1Стили интеграции приложений

Существует несколько общеизвестных стилей интеграции корпоративных приложений:

Передача файла

Общая база данных

Удаленный вызов процедур

Обмен сообщениями

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

16.1.1 Передача файла

Данный стиль подразумевает обмен файла между различными приложениями. Этот способ является универсальным, в том плане, что любая операционная система и язык программирования имеют встроенные средства для обработки файлов. Поэтому он является одним из самых простых способов интеграции корпоративных приложений (Диаграмма 1).

Диаграмма 1

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

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

118

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

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

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

16.1.2 Общая база данных

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

Общая база данных

Диаграмма 2

119