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

Некоторые продукты предъявляют специальные требования к сети, и эти требования необходимо сопоставить с возможностями и пропускной способностью работающих у вас сетей. Обязательно проверьте все параметры, учитывая при этом, что больщинство продавцов пользуются для демонстраций и эталонных тестов высокопроизводительными мащинами. Например, в демонстрациях для среды клиент-сервер клиенты обычно имеют минимум 32 Мбайт памяти и взаимодействуют с серверами по сети Ethernet. Если вы можете позволить себе такую конфигурацию на промыщденном уровне - прекрасно. Однако не удивляйтесь, если реальная производительность клиентов на базе 486 процессора с 8 Мбайт оперативной памяти при работе в глобальной сети будет на несколько порядков ниже, чем у системы, демонстрация которой убедила президента ващей фирмы утвердить заказ.

Взаимодействие с другими приложениями

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

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

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

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

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

5. Могут использоваться интерфейсные модули, которые подключаются к обоим приложениям и служат средством связи. Приблизительно так работает разработанный фирмой Microsoft механизм динамического обмена данными (Dynamic Data Exchange, DDE).

6. Приложение может содержать объект, принадлежащий другому приложению, что реализуется с помощью такой технологии, как Object Linlcing and Embedding (OLE) или ActiveX.

Давайте рассмотрим, как некоторые из этих механизмов работают на практике. Допустим, вы приобретаете пакет Sales Ledger (Регистр продаж) или Accounts Payable (Кредиторы). Вполне вероятно, что в базе данных в таком пакете будет таблица покупателей (Customer). Однако вряд ли эта таблица будет похожа на таблицу покупателей, которая у вас уже есть (мы имеем в виду столбцы или общую структуру). Конечно, лучще обойтись без сопровождения двух таблиц покупателей и связанных с этим проблем, поэтому вы рещаете реплицировать данные из одной таблицы в другую. Сначала вам придется назначить одну из них (надеемся, исходную таблицу) главной, в которую будут вноситься все изменения, а затем обеспечить перенос всех изменений в подчиненную таблицу. Теоретически это просто, но на практике существуют некоторые сложности.

Первая проблема, с которой приходиться столкнуться, связана с тем, насколько хорошо производитель пакета описал структуру своей базы данных. Конечно, можно воспользоваться средствами SQL*PIus и выполнить операцию DESCRIBE над этими таблицами, но в результате будут получены только имена столбцов и типы их данных. Эти имена могут быть совершенно неинформативными, поэтому назначение столбцов придется угадьгеать (например, что такое в таблице покупателей NOT CUST PARENT FLAG или еще хуже: что такое С012 в Т047?). Следующая проблема состоит в том, как заполнить в подчиненной таблице обязательные столбцы, отсутствующие в главной таблице? Возможно, для представления значения еще не известно придется использовать какое-то специальное значение (очевидно, не нулевое).

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

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

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

В Oracle Designer/2000 есть набор API, реализованных как набор пакетов PL/SQL. Они позволяют выполнять функции, которые не обязательно реализованы в Repository Object Navigator или иных инструментальных средствах и которые в предыдущих версиях нужно было выполнять путем непосредственного обновления репозгггария.

Примечание

Мы считаем, что в не столь далеком будущем разработка приложений превратится в искусство связывания воедино множества разных объектов, поставляемых разными фирмами и несколько похожих на такие элементы управления, как VBX и OCX (которые уже предлагаются), но в более глобальных масштабах. Программирование, каким мы знаем его сейчас, канет в небытие, и появгггся новое поколение интеграторов . Именно эту нишу Oracle надеется заполнить при помощи архитектуры сетевых вычислений (Network Computing Architecture), где упомянутые выше объекты реализованы в виде картриджей.

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

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

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