Далее видно, каким образом производится выборка по многим компаниям с построением такого рода, можно сказать, консолидированного отчета. Важно отметить, что поддерживается фильтрация при помощи контейнеров. Ниже определяется контейнер компании, указывается, какого рода компании к нему относятся.
Дальше можно производить выборку по многим компаниям с учетом содержимого этого контейнера.
Кроме того, существует ряд изменений в структуре запросов, которые также нацелены на использование множества компаний, т. е. видно, что в структуре запросов можно явно указывать, допустимо ли использовать учет по многим компаниям или нет в данном случае. На рис. 18.3 представлен вариант отчета или просмотра данных по различным компаниям. Видно, что в отчете представлены как различные компании (dm2, dmo), так и различные сотрудники этих компаний. При этом отчет агрегируется и представляется для просмотра пользователю в едином интерфейсе DataGre-at, который является частью Windows Forms, одним из стандартных классов, в котором производится выборка данных из гетерогенных источников в том числе.
Еще одним важным направлением развития Microsoft Dynamics является пакетная обработка заданий. Здесь, наверно, уместно вспомнить, что пакетная обработка заданий использовалась еще очень давно, когда применялись широко мейнфреймовые архитектуры, машины типа IBM 360, EC 1030, возможно, и несколько раньше. Здесь эти технологии поднимаются на новый уровень, используются серверы, которые обслуживают пакеты заданий. При этом они строятся на основе объектных серверов, которые называются Application Object Server. Существует возможность группового запуска задач на одном сервере, балансировки загрузки между разными серверами. Для каждого пакета задач формируются специализированные извещения по завершении, т. е. достаточно гибко осуществляется управление заданиями в пакетном режиме.
Рис. 18.3. Вариант отчета или просмотра данных по различным компаниям
Далее перечислено, что собственно добавлено в отношении пакетной обработки в Dynamics:
• создание и описание задач. Задачи, если говорить о корпорации, часто могут быть взаимозависимыми и взаимосвязанными. В ряде случаев между задачами, если рассмотреть, например, сетевой график их выполнения, возникают достаточно сложные зависимости;
• возможность запуска задач как в последовательном, так и параллельном режиме;
• анализ зависимости между задачами и принятие решения, каким образом имеет смысл эти задачи реализовывать;
• распараллеливание потоков выполняемых задач по серверам (Application Object Server);
• оптимизация потоков задач в зависимости от загрузки серверов, в том числе сервер может автоматически выполнять несколько потоков в зависимости от пропускной способности и своей загрузки;
• в случае падения системы возможность автоматического повтора задачи;
• построение дерева зависимостей (создается X++-разработчиком), что дает возможность определить взаимодействие различных задач, пакетов задач в системе.
Еще одним важным направлением развития является архитектурное расширение Application Object Server до 64-бит. Здесь поддерживаются серверные компоненты в архитектуре 32 и 64 бита. Также 32– и 64-разрядная архитектура поддерживается для коннекторов на основе. NET для подключения сторонних приложений, для интеграции приложений. При этом возможна как балансировка нагрузки, так и поддержка распределенных систем на основе нескольких кластеров.
Еще один важный вопрос, который нужно рассмотреть для продолжения разговора о новых чертах Microsoft Dynamics, – это обновление данных. На самом деле применительно к корпоративным системам это достаточно сложная проблема обновления данных, приложений, потому что, естественно, это огромное количество взаимодействующих модулей, достаточно сложные взаимосвязи между ними и серьезные осложнения, если система собирается неправильно, т. е. какая-то версия модуля не вполне соответствует своему программному окружению. Для того чтобы облегчить обновление данных, существуют возможности, связанные с построением списков обновления, или Upgrade checklist. Процедура построения такого списка представлена на рис. 18.4.
Видно, что включаются возможности выполнения обновления по нескольким направлениям: обновление данных, обновление кода с учетом различных сценариев синхронизации. Существует возможность определения предварительных условий на обновление и заключительных условий, которые гарантируют успешное обновление. При этом используется новая пакетная модель разработки. Поддерживаются конфигурационные ключи как для сценариев обновления различных, так и для всех модулей, которые входят в состав программных комплексов. При этом для сценариев можно определить условия, которые необходимы для их запуска, т. е. планировать запуск сценариев.
Что касается коррекции списка обновления, то он может учитывать различные условия, в том числе, например, связанные с текущим часовым поясом. Как уже говорилось, возможна приостановка и повтор заданий, а также возможность создания специализированных заданий, которые нацелены на обработку ошибок, возникающих при обновлении консолидации данных.
Рис. 18.4..Список обновления, или Upgrade checklist
Еще один важный этап обновления системы, кроме обновления данных, – это обновление кода. Здесь тоже существует целый ряд этапов, которые последовательно реализуются при выполнении действий по обновлению. Формируется проект обновления, который поддерживает в ряде случаев автоматическое обнаружение и разрешение конфликтов. Отчасти о конфликтах говорилось в главе, которая была посвящена архитектурам данных, в частности проблемам, связанным с управлением данными при многопользовательской работе, при работе в больших распределенных системах. Кроме того, используется значительное количество визуальных индикаторов, в том числе характеризующих продолжительность процесса обновления, которые существенно упрощают для администраторов процесс управления обновлениями. Реализовано специальное средство, которое осуществляет послойное сравнение данных, и здесь учитывается возможность переименования, смены имени узлов системы. Кроме того, можно прогнозировать и динамически корректировать ожидаемые результаты от обновления кода.
На рис. 18.5 и 18.6 показано, каким образом происходит обновление кода.
На верхнем рисунке, там, где написано Detect upgrade conflicts (обнаружить конфликты обновления), осуществляется поиск по слоям (см. рис. 18.5). Проект обнаружения работает со слоями и осуществляет поиск проекта или ряда проектов, которые как раз и управляют обновлениями. При этом результирующий код будет соответствовать соглашению Trustworthy Computing, т. е. пройдет необходимые тесты Microsoft на внутреннюю безопасность.
