Переопределяющая переменная среды SSIS

Question

Я установил конфигурацию пакета, в которой указан тип конфигурации (файл конфигурации непрямого XML). Где переменная среды указывает на файл C:\SSIS\MasterConfig\MasterConfig.dtsConfig.

Это прекрасно работает и позволяет легко перейти от теста к UAT к продукции.

Проблема в нашей среде разработки, где каждый разработчик имеет собственную БД. Я пытаюсь настроить Agent Job для каждого разработчика, где Job Agent переопределит главный файл конфигурации. Командная строка агент работа ":

/FILE "C: \ SSIS \ Packages \ Developer1 \ LoadPackage.dtsx"/ CONFIGFILE "C: \ SSIS \ Packages \ Developer1 \ Developer1_Config.dtsConfig"/ X86 /чекпойнтинг OFF/ОТЧЕТНОСТЬ E

Использование 2008 R2

Я ожидал, что/CONFIGFILE "C: \ SSIS \ Packages \ Developer1 \ Developer1_Config.dtsConfig". будет использоваться вместо из C: \ SSIS \ MasterConfig \ MasterConfig.dtsConfig.

Используется только файл Master Config. Есть идеи?

Answer 1

Проблема, с которой вы столкнулись, подпадает под Defining a Configuration Approach for Integration Services Packages. В основном применяется конфигурация командной строки, но затем перезаписывается значением времени разработки.

Я не уверен, каким будет ваше решение. Полуполюсная ситуация здесь, кроме случаев, когда нам приходилось иметь дело с многоинтенсивными ящиками (dev и test совместно использовали физический хост). Чтобы обойти это, мы пропустили бит переменной среды и решили, что значение времени разработки всегда будет указывать на dev. Test, UAT и PROD будут запускать пакеты только через SQL Agent, поэтому наши задания явно определяют строку подключения для ресурса конфигурации. Ваш сценарий обратный, хотя значения времени разработки отлично повсюду, но dev.

Answer 2

Вот что мы делаем.

Все переменные называются одинаковыми независимо от того, указывает ли оно на Production, QA или Dev (или даже на локальный). Мы меняем значения переменных, указывающие на файлы конфигурации.

Мы создаем файлы конфигурации, которые имеют всю соответствующую информацию о соединении для каждого окна. Таким образом, для каждой базы данных у нас будет как минимум 3 отдельных файла конфигурации. Мы называем их DB_Prod.config, DB_QA.config, DB_Dev.config, а затем DB_Joe_local.config (если вы хотите иметь тот, который указывает на ваш локальный db.

Затем мы создаем файлы .bat, которые устанавливают наши переменные в я имею 3 разных, один для QA, один для dev и один для моей локальной среды.

переменные среды называются такими же, как DB1_adonet, DB1_ole, AS400 и т. д. Без указания QA, prod и т. д.

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

Заключительное примечание. У нас есть все конфигурационные файлы, проверенные в TFS. Делает для легкого распространения файлов.