Из-за проблем, которые мы обнаружили при восстановлении сайтов / семейств сайтов с помощью stsadm (наши задачи, созданные из рабочих процессов, не были восстановлены), мы выбрали другой путь для резервного копирования / восстановления. Мы планируем основную настройку нашего сайта SP и хотим сделать резервную копию, чтобы мы могли откатиться в случае сбоя установки. В нашей среде тестирования системы (не производственной) мы сделали резервную копию 12 кустов, виртуальных каталогов, которые IIS указывает на SharePoint, и баз данных SharePoint в SQL (с использованием SQL-сервера для резервного копирования БД).
У нас есть настраиваемые обработчики событий и рабочие процессы, созданные с помощью Visual Studio, и мы развертываем библиотеки DLL в GAC как версию 2 (подписанную и управляемую версиями в Visual Studio). Поэтому при развертывании GAC будет содержать 2 версии рабочих процессов - версию 1 и версию 2. Во время развертывания мы используем функции SP stsadm для установки / активации WF. Мы также переходим к каждой библиотеке и добавляем новые WF версии 2. Это автоматически устанавливает для WF версии 1 значение «Не разрешать» новые экземпляры (это то, что мы хотим), а для версии 2 - как активные - пока идеально.
Когда мы завершили установку, мы предполагаем сбой и пытаемся выполнить восстановление на тех же машинах (SharePoint на одном сервере, SQL на другом). Мы начинаем с удаления WF версии 2 из GAC, сброса IIS (чтобы очистить кеш этих dll WF версии 2), восстановления папок с 12 кустами и виртуальных каталогов, а затем восстановления базы данных SQL. Это все так же руководство, как вы его читаете - здесь нет stsadm. Похоже, что все работает после нашего восстановления, похоже, что восстановление было успешным - все модификации, которые мы внесли в имена столбцов, изменения данных и т. Д. Во время установки, возвращаются в исходное состояние до установки. За одним исключением. Когда мы запускаем рабочий процесс, он всегда дает сбой, и журналы в 12-улье указывают, что WF все еще пытается использовать версию 2 dll (ошибка System.IO file not found). Мы думаем, что мы сделали резервную копию и восстановили все движущиеся части Sharepoint, но нам здесь чего-то не хватает, есть ли у кого-нибудь идеи, почему на библиотеки DLL версии 2 все еще ссылаются, хотя мы восстановили все папки и базы данных SharePoint?
Спасибо, Кевин
Кевин,
Если я правильно понимаю ваш порядок операций, у меня есть один большой вопрос: восстанавливаете ли вы базы данных контента, но оставляете ли базу данных конфигурации фермы (и другие базы данных, такие как базы данных SSP) нетронутыми во время восстановления? Если ответ «да», то я подозреваю, что SharePoint подходит, потому что ваша база данных конфигурации по-прежнему поддерживает ссылку на v2 вашего рабочего процесса. Вот что, я подозреваю, могло произойти.
Когда вы устанавливаете компонент в свою ферму SharePoint, SPFarm.FeatureDefinitions Коллекция (которая поддерживается в базе данных конфигурации фермы) обновляется, чтобы отразить то, что вы добавили. Это включает в себя всю стандартную информацию, которую вы ожидаете, что ваш компонент будет содержать: имя, область действия, идентификатор, версию и т. Д. Он также поддерживает информацию о сборке FeatureReceiver и Корневая директория ценность, среди прочего. В Корневая директория указывает на папку в 12-улье, где находится манифест Feature для Feature.
Когда вы добавляете компонент рабочего процесса v2 в ферму и активируете его, база данных конфигурации обновляется. Даже если вы восстановите версию рабочего процесса до версии 2 для своей базы данных контента, ферма по-прежнему будет искать версию 2 вашего рабочего процесса из-за связи функций, которая поддерживается на уровне базы данных конфигурации. Если папка функций v2 все еще существует в 12-улье и ее манифест указывает на сборку v2 в GAC, легко увидеть, где могут возникнуть проблемы.
В то же время, если ваша функция рабочего процесса использует FeatureReceiver, эта информация также сохраняется (в базе данных конфигурации) в РесиверСборка собственность FeatureDefinitions коллекция после установки компонента.
Если я ошибаюсь и вы фактически восстанавливаете всю свою ферму на месте (включая базу данных конфигурации), то то, что я написал, неприменимо. В таком случае я бы тоже немного почесал голову. :-)
Надеюсь, это поможет!
Не могли бы вы попытаться удалить привязки рабочего процесса из списков после завершения установки, поэтому сначала удалите все ассоциации рабочих процессов из списка, затем удалите библиотеки DLL V2 из GAC, затем повторно разверните библиотеки DLL, а затем повторно сопоставьте рабочие процессы, чтобы убедиться, что все оставшиеся ссылки на рабочие процессы исчезли (как из базы данных содержимого, так и из базы данных конфигурации) и заставили sharepoint повторно привязать / перенастроить связи рабочих процессов.
P.S. ОЧЕНЬ странно, что задачи, связанные с рабочим процессом, не восстанавливаются, они не более чем содержимое и должны быть в базе данных содержимого, я думаю, что задачи рабочего процесса привязаны к рабочему процессу, который не восстанавливается правильно (поскольку ассоциации рабочих процессов хранятся как в db содержимого и db конфигурации ...). Когда происходит восстановление, рабочие процессы в основном повторно инициализируются, получают новый GUID и т. Д. Для sharepoint это может показаться новым рабочим процессом, поэтому задачи, относящиеся к старому рабочему процессу, больше не могут быть связаны).
Я предлагаю вам глубже погрузиться в суть проблемы, а не создавать индивидуальное решение.
посмотри на этот сайт и Эта статья для получения дополнительной информации о проблемах восстановления / упаковки, связанных с рабочим процессом, и о том, как рабочий процесс на самом деле сохраняется / создается.
Я никогда им не пользовался (даже парень с Sharepoint), но это может сработать для вас. Наткнулся на CodePlex ...