Создание независимых пакетов SQL Server 2005 Integration Services

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

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

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

Зависимость от расположения

Проблемы с переносимостью пакета возникают, когда ресурсы в ссылках (такие как папки и файлы) обозначены так, что имеют смысл для конкретной системы. Проблема заключается в том, что, когда пользователь развертывает пакет на другом компьютере, жестко привязанные ссылки к ресурсам не могут быть правильными. Например, на одной системе, имеется папка на диске D, где размещаются прибывающие плоские файлы, которые должны быть обработаны. Затем пакет переносится на другую систему, и система может не иметь диска D, тогда разработчику нужно использовать другое определение, например диск Z. Иногда существуют простые решения такого рода проблем. Для этой проблемы можно, например, для создания нового имени диска использовать системную команду "subst". Но такой тип решения может быть запутанным и сложным в управлении в долгосрочной перспективе.

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

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

Настройка пакетов

Настройка пакетов - это способ изменения свойств объектов в пакете в процессе загрузки; сюда входит несколько способов, включая SQL, XML, Registry, Environment Variable и Parent Package. Можно запустить мастер Configuration Wizard для генерации конфигураций в Package Designer, щелкнув правой кнопкой в Control-Flow Designer и выбрав пункт меню Package Configurations. Более подробную информацию можно найти в документации Books Online (BOL).

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

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

Системно-резидентная конфигурация: этап первый

Этот метод описания системы состоит в создании конфигурации, которая отражает среду системы. Я называю такую конфигурацию резидентом системы, потому что она не перемещается с пакетом. При построении пакетов добавляется ссылка к системно-резидентной конфигурации на компьютере, где происходит разработка. Также добавляются некоторые стандартные переменные, которые содержат значения параметров настройки, определенных для конкретной системы. Например, если есть переменная User::TempDir, которая содержит каталог, где должны храниться временные файлы на этой системе, можно иметь другую переменную с именем User::SQLServer, содержащую имя сервера. Другая переменная с именем User::Root Drive может указывать на корневой диск, где разработчик собирается хранить свои пакеты.

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

Частные выражения: этап второй

Частные выражения - это метод автоматического вычисления значений свойства с помощью выражения. Выражение может включать одну или более переменных, так что можно использовать значения переменных для того, чтобы влиять на результат выражения и тем самым - на значение свойства. Например, чтобы сформировать строку темы в почтовом сообщении во время выполнения пакета, можно создать частное выражение и связать его со свойством «Тема» в задаче Send Mail подобно следующей:

"The package :" + "@PackageName" + " completed
successfully on " + (DT_WSTR, 20)GETDATE()

Когда Send Mail task отправит электронное сообщение, строка темы будет выглядеть так:

The package :MyTestPackage completed successfully on July 13, 2005 05:17:32.

Эта методика представляет интерес, когда используется частное выражение вместе с конфигурационными переменными. Например, задача Dataflow имеет свойство BufferTempStoragePath. Это свойство сообщает задаче Dataflow, где поместить очередь буфера данных, когда память будет исчерпана. Лучше всего задать местонахождение на выделенном высокопроизводительном диске. Компьютеры разработчика вряд ли будут иметь отдельный диск для этой цели, так что временный путь, вероятно, укажет на диск C. Однако на промышленной системе такой диск может быть и хотелось бы разместить папку там. Системно-резидентная конфигурация сформирует переменные User::TempDir и User::RootDrive. Можно использовать следующее выражение для свойства BufferTempStoragePath, чтобы автоматически указать задаче Dataflow, как правильно разместить очередь буфера. Следующее выражение

@User::RootDrive + "" @User::TempDir +
"" + "BufferTempStorage"

может устанавливать значение на одной системе в C:TempBuffer-TempStorage, но когда пакет перемещен на другую систему с отличной конфигурацией, выражение может получить значение K: PackageTempStorageBufferTempStorage. Использование частного выражения, таким образом, завершает конфигурацию пакета. Это второй и последний этап конфигурации.

Сценарий

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

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

Как это сделать

Прежде всего, на вкладке Advanced окна свойств My Computer нужно нажать на Environment Variables и создать переменную среды с именем RESIDENTCONFIGURATION, содержащую полное уточненное имя вашей резидентной конфигурации. Определение местоположения XML-конфигурации в переменной среды напоминает установку конфигураций. Жесткая привязка к местонахождению файла конфигурации приводит к тем же последствиям, что и жесткая привязка к месту хранения файлов с данными или серверам. Использование переменной среды для указания на резидентную конфигурацию, однако, позволяет даже резидентному расположению конфигурации изменяться от системы к системе. Использование переменной среды в ссылке на местоположение файла конфигурации, таким образом, называется неявной настройкой.

Чтобы проверить, правильно ли установлена переменная среды, используйте команду set. Командная строка гарантировано укажет полное имя установленного конфигурационного файла. Это должно выглядеть примерно так:

C:>set res
RESIDENTCONFIGURATION=Z:ISCONFIGURATIONS RESIDENT.dtsconfig

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

Затем щелкните правой кнопкой мыши на Control Flow в проектировщике и выберите Package Configurations из контекстного меню. Возникнет диалоговое окно Package Configurations Organizer, которое можно видеть на Рисунке 1. Выберите Enable package configurations из списка и щелкните Add, чтобы запустить мастер Package Configuration Wizard, как показано на Рисунке 2. Я предполагаю, что читатель уже создавал конфигурационный XML-файл, который устанавливает переменные и что XML-конфигурация расположена там, где описано в переменной окружения RESIDENTCONFIGURATION.

На Рисунке 2 видно, что я выбрал конфигурационный тип файла XML. Я также выбрал переменную Environment Variable, которая сообщает пакету, что при загрузке конфигураций пакет должен найти переменную окружения, извлечь местоположение XML-конфигурации и настроить себя, используя обнаруженную XML-конфигурацию. Таким образом, удовлетворяется требование, чтобы пакет менялся только один раз. Если бы расположение файла конфигурации было непосредственно установлено в пакете и если бы расположение файла конфигурации когда-либо изменилось по каким-то причинам, тогда для отражения нового расположения потребовалось бы редактировать пакет и переподписывать его. В нашем же случае расположение конфигурации пакета может изменяться, но пакет будет изолирован от такой привязки. Это еще один способ сохранять пакет в изоляции.

В резидентной конфигурации пакета у меня имеется одна конфигурация. Она настраивает переменную "User::FlatFileDropDir" моего пакета на папку для размещения файлов, которая называется Z:FFDROP. Это первый шаг конфигурации. Затем, у меня есть менеджер для подключения нескольких плоских файлов, который указывает, что файлы должны быть обработаны в задаче Data Flow. Чтобы избежать одноступенчатой настройки, я буду использовать частное выражение, чтобы узнать расположение из настроенной переменной. Частное выражение похоже на следующее:

@User::FlatFileDropDir + "" + "*.txt"

Это выражение будет искать файлы по маске *.txt и в каталоге Z:FFDROP. Теперь, когда этот пакет будет перемещен на систему с резидентной конфигурацией, он успешно найдет размещенные там плоские файлы.

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

Другие вопросы зависимости от расположения

.

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

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

Приложение на каждый день

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

7 секретов конфигурации пакетов

Что нужно знать о настройке пакетов

  • Оптимально использовать один файл конфигурации (резидентная конфигурация) на сервер.
  • Можно использовать более одной конфигурации в пакете.
  • Можно использовать одну конфигурацию в более чем одном пакете (подобно работе резидентной конфигурации).
  • Каждая конфигурация пакета применяется в порядке, показанном в Package Configurations Organizer, исключая Parent Package Configurations, которые применяются во время выполнения.
  • Если при запуске конфигурация не выполняется, выдается только предупреждение. Конфигурация не должна вызывать ошибку, приводящую к сбою в загрузке пакета.
  • Можно явно устанавливать расположение конфигурации в пакете или делать это в переменной среды.
  • Конфигурации применяются на этапе загрузки, а не во время выполнения. Тогда изменение конфигурации в проектировщике и дальнейшее выполнение пакета без перезагрузки не будет изменять конфигурацию самого пакета. Требуется перезагрузка пакета.

Что необходимо знать о частных выражениях

  • Приложение оценивает и применяет частные выражения только на определенных этапах:
    • При загрузке
    • При сохранении
    • Когда приложение запрашивает подтверждение в задачах
    • Когда приложение запрашивает выполнение в задачах
    • Когда компонент запрашивает AcquireConnection в менеджерах подключения
    • Когда компонент запрашивает GetEnumerator на foreach нумераторе
  • Доступны почти для всех задач, в доступных на запись свойствах нумераторов, провайдеров журналов и менеджера подключений.
  • Доступны в ограниченном числе свойств компонентов потока данных.
  • Не могут быт использованы для модификации переменных.
  • Поддерживаются автоматически во всех доступных для записи свойствах пользовательских компонентов за исключением пользовательских компонентов задачи Data Flow.