Развертывание Microsoft Dynamics CRM 4.0

Тем, кто привык думать о CRM лишь как о средстве управления сбытом и маркетингом, стоит подумать снова. Microsoft Dynamics Customer Relationship Management (CRM) – это платформа для разработки приложений, управляющих и отслеживающих информацию и процессы, относящиеся к физическим объектам. Эти объекты могут быть клиентами, но они также могут быть практически любой сущностью (и связанными с ней действиями), которой необходимо управлять.

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

С самого начала этой статьи я хотел бы пояснить, что, говоря о решении Microsoft Dynamics CRM, я имею в виду всю сумму модификаций, расширений, пользовательского кода, изменений схемы и так далее. Решение – это не что-то одно, это все изменения, взятые вместе.

По сути своей решение Microsoft Dynamics CRM является стандартным, управляемым данными приложением ASP.NET 2.0 и Microsoft .NET Framework 3.5. Трехуровневая система включает в себя следующие ниже крупные компоненты.

Уровень данных : база данных SQL Server 2005 или SQL Server 2008. Использование SQL Server 2008 требует установки исправления, как описано в статье базы знаний «Поддержка работы Microsoft Dynamics CRM 4.0 вместе с Microsoft SQL Server 2008».

Промежуточный уровень Microsoft Internet Information Services (IIS) 6.0 или более новый веб-интерфейс; SQL Server Reporting Services (SRS) 2005 или SRS 2008; ASP.NET 3.5; пользовательские службы Windows.

Клиентский уровень Клиент Microsoft Internet Explorer 6.0 или более новый; ASP.NET 2.0 и последующие версии; клиент Microsoft Office Outlook 2003 или Office 2007 (с необязательным автономных доступом); прочее, включает в себя потребителей SDK и мобильных клиентов от сторонних производителей.

Microsoft Dynamics CRM также полагается на ряд внешних систем, включая Microsoft Exchange Server 2003 и более поздние версии, а также Active Directory.

Жизненный цикл разработки решения

Решение Microsoft Dynamics CRM проходит через тот же цикл, что и любой проект разработки пользовательского приложения, который может быть подобен процессу, показанному на рис. 1.

Увеличить

Рис. 1. Цикл разработки приложения

Весь этот процесс будет поддерживаться несколькими средами, вместе составляющими системы разработки, тестирования и производства. В мире любого многогранного корпоративного приложения это, само собой, может оказаться на удивление сложным. Если, для примера, необходимо создать зеркальное отображение сред, результат может оказаться подобным показанному на рис. 2.

Увеличить

Рис. 2. Зеркальное отображение средств разработочных, тестовых и производственных сред

Это три домена, три контроллера доменов, три сервера электронной почты, три веб-сервера и три сервера базы данных – и эта модель предполагает, что SRS и CRM находятся на одном блоке, не принимая также в расчет задачи вроде балансировки нагрузок. Теперь давайте представим себе добавление избыточности и нескольких внешних служб, таких как Microsoft Office SharePoint Services (MOSS), и вполне может получиться схема, подобная показанной на рис. 3.

Рис. 3 Возрастающая сложность

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

В отношении разработки набора средств для поддержки жизненного цикла проекта CRM существует несколько направлений мысли и, в зависимости от важности тех или иных принципов, можно выбрать одно или другое. На одном конце спектра разработчики выдвигают вперед полную изоляцию, используя точное копирование. Они верят, что единственным способом проверки, будет ли что-то работать, вне производственной среды, является создание тестовой среды идентичной производственной на 100%. Каждый сервер, каждый фрагмент и каждый параметр должны быть идентичны и полностью изолированы от разработки и производства, чтобы тестеры и ИТ-специалисты поверили, что что-то будет работать в производственной среде.

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

Можно надеяться, что читатели находятся где-то между этими экстремальными случаями и будут открыты мысли о том, что, когда речь идет о решении на основе Microsoft Dynamics CRM, возможно создать гибрид, где сбалансированы сложность, затраты, изоляция и управляемость.

Элементы решения CRM

Компоненты решения Microsoft Dynamics CRM можно разделить на четыре крупных пакета и решение может включать в себя один из них, два, три или все четыре.

Модификации Сюда входят изменения форм, таблиц, схем и метаданных; роли безопасности; рабочие процессы; параметры системы и шаблоны. Модификации Microsoft Dynamics CRM предоставляются как один или несколько (обычно один или два) заархивированных файла XML. Они импортируются в развертывание CRM через Outlook или область «Параметры|Специальная настройка» веб-клиента, после чего «публикуются», чтобы сделать их активными. Все это можно автоматизировать, используя код, написанный для SDK Microsoft Dynamics CRM.

Расширения Сюда входят отчеты и такой пользовательский код, как надстройки, которые необходимо разворачивать отдельно от модификаций. Регистрационная информация надстройки сохраняется как файл XML им может быть развернута либо через командную строку, либо через приложение Windows Form, предоставленное корпорацией Майкрософт. Их также можно автоматизировать через код, написанный для SDK Microsoft Dynamics CRM.

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

Данные Любая информация, которую необходимо импортировать в среду для функционирования этой среды. Сюда могут входить доменные данные (такие как список кодов продуктов) или пользователи. Данные, необходимые решению, могут быть развернуты в экземпляр Microsoft Dynamics CRM с помощью кода сценария или функции пакетного импорта CRM, либо с помощью какой-либо формы внешнего процесса, использующего BizTalk, либо другое средство ETL (extract, transform, load – извлечения, преобразования и загрузки). Некоторые данные, такие как данные о пользователях, необходимо создавать вручную или через вызовы SDK Microsoft Dynamics CRM.

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

Как насчет обслуживания одним экземпляром приложения нескольких развертываний?

Давайте теперь посмотрим, на что должна быть похожа среда, в которую их предстоит развернуть. Вы могли читать о том, что выпуск Microsoft Dynamics CRM 4.0 Enterprise Edition поддерживает функцию, именуемую обслуживанием одним экземпляром приложения нескольких развертываний, которая позволяет нескольким экземплярам Microsoft Dynamics CRM работать внутри одного развертывания. Это значит, что несколько совершенно различных организаций, с собственными отчетами, рабочими процессами, модификациями и схемами, могут работать на одном и том же наборе оборудования, используя те же физические серверы и те же экземпляры баз данных и веб-узлов IIS.

На первый взгляд это может показаться панацеей, дающей ответ на все загадки управляемости, изоляции и издержек. Такое решение можно визуализировать, как показано на рис. 4.

Рис. 4. Решение, целиком построенное на обслуживании одним экземпляром приложения нескольких развертываний

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

Эта модель работает идеально в тех отдельных организациях, которые являются частью другой команды или решения отдела. В конце концов, обслуживание одним экземпляром приложения нескольких развертываний и было разработано для этого. Хотя и верно, что каждая организация (или развертывание) получает собственную базу данных, они используют общее структурное подразделение и службы Active Directory, а также службы платформы и клиентское приложение. Это значит, что одна и та же асинхронная веб-служба и веб-сайт IIS будут использоваться несколькими организациями. Серверы клиентского доступа могут «размещать» эти различные организации через поставщика URL-адресов, определяющего, основываясь на URL, какие организации размещать.

Возьмем, например, эти URL: crmserver/ContosoDevOrg/loader.aspx и crmserver/ContosoTestOrg/loader.aspx. Сервер CRM заглядывает в корневой каталог, чтобы определить имя организации, которую следует обслужить. Если имени корневой организации не найдено, как в случае crmserver/loader.aspx, сервер использует по умолчанию первую организацию, созданную в развертывании, или ту, к которой у вызывающего пользователя имеется доступ.

Поскольку для обеих организаций используется тот же веб-сайт, то, если в решении есть пользовательский код, то он тоже будет использоваться совместно обеими организациями, например crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx и crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx.

Обе они указывают на один и тот же физический файл на диске, такой как C:\inetpub\wwwroot\isv\mycustomdialog.aspx. Поскольку вероятно, что версия пользовательского расширения в производственной, тестовой и разработочной средах будет различаться, это может создать серьезную проблему. Предположим, например, что в настоящий момент разрабатывается сборка 11 приложения, тогда как сборка 9 находится на стадии тестирования, производимого пользователями. При попытке использовать обслуживание одним экземпляром приложения нескольких развертываний для решения проблем со средой, изоляция этих двух сборок будет сопряжена со сложностями. В подобных ситуациях может показаться заманчивым решение, показанное на рис. 5.

Рис. 5. Попытка использовать различные серверы IIS для разделения кода пользовательских решений

В этой модели (если больше не используется адрес балансировки сетевой нагрузки) пользователи могут щелкнуть URL наподобие приведенного ниже:

Разработка 192.168.1.100/ContosoDevOrg/loader.aspx

Тестирование 192.168.1.105/ContosoTestOrg/loader.aspx

Производственная среда 192.168.1.110/Contoso/loader.aspx

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

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

Это обусловлено тем, что все асинхронные службы в развертывании работают циклическим образом, и в силу этого асинхронная служба сервера развертывания может обработать ответ рабочего процесса, системной задачи или асинхронной надстройки на запрос от тестового сервера, тем самым немедленно нарушая требование изоляции. Кроме того, если пользовательский код, выполняемый этим асинхронным процессом, полагается на файлы, которые необходимо развернуть на подключаемом к серверу диске (такие как файл конфигурации или файл в глобальном кэше сборок – Global Assembly Cache/GAC), то возникнут конфликты версий.

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

Так для чего же предназначено обслуживание одним экземпляром приложения нескольких развертываний и когда оно является хорошим решением для сред жизненного цикла продукта? Обслуживание одним экземпляром приложения нескольких развертываний было первоначально разработано для решения проблем с оборудованием, связанных с размещением нескольких отличающихся развертываний в производственной среде, и оно решает их очень хорошо. Ранее, в Microsoft Dynamics CRM 3.0, каждому развертыванию приходилось выделять свой экземпляр SQL Server или SQL Server, а также сервер клиентского доступа.

Дето обстояло по многим причинам, включая то обстоятельство, что относящиеся к развертыванию параметры тогда хранились в реестре и на диске. Теперь все эти конфигурации переместились на базу данных, так что единственный сервер приложений может обслуживать несколько организаций. Обслуживание одним экземпляром приложения нескольких развертываний полезно для размещаемых версий CRM, включая Microsoft Dynamics CRM Online.

Соображения по разработке

Теперь, когда читатели знают о некоторых потенциальных проблемах, давайте подумаем о некоторых моментах, которые следует учитывать при разработке развертывания. Ответ, само собой, заключается в том, что все зависит от ситуации. Определенно возможно запустить полную среду CRM (включая контроллер домена, SQL server и веб-сервер) на одном компьютере, как можно увидеть в демонстрации Microsoft Dynamics CRM 4.0 Virtual Machine (см. боковую панель «Материалы по CRM» для URL). Виртуальный образ единственного компьютера очень часто используется для среды разработки. Но для тестирования важно проверять ключевые задачи производственной среды, и по этой причине я рекомендую, чтобы среда тестирования отражала производственную среду в плане структуры, но не емкости. Среда может выглядеть подобно показанной на рис. 6.

Увеличить

Рис. 6 Структура тестовой среды должна отражать структуру производственной

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

Обеспечение настраиваемости параметров Не предполагайте, например, что сервер ответит локальному узлу или определенному порту.

Учет нескольких серверов Не предполагайте, что все заработает без установки прокси-пользователей или доверия для делегации.

Учет балансировки нагрузки Следует быть очень осторожным в отношении состояния сеансы и кэширования. Отметьте, что Microsoft Dynamics CRM разработан, чтобы совершенно не сохранять состояния, и хорошо работает с циклическим балансировщиком нагрузки.

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

Материалы по CRM

• Руководство по применению Microsoft Dynamics CRM 4.0
  
• Microsoft Dynamics CRM 4.0 как платформа разработки бизнес-приложений
  
• Блог группы Microsoft Dynamics CRM
  
• Виртуальный компьютер Microsoft Dynamics CRM 4.0
  
• Оптимизация и обслуживание Microsoft Dynamics CRM 4.0
  

Ключевые мысли

Изоляция важна При разработке решения помните о том, какой подход (как проиллюстрировано на рис. 4, 5 и 6) наиболее подходит к ситуации, и учитывайте, где может работать создаваемый код. Также стоит отметить, когда не стоит волноваться о таких проблемах, в силу типа используемых решением расширений.

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

Обновляйте среду для каждой сборки В качестве общего правила хорошей идей является создание резервных копий либо виртуальных сред, либо просто баз данных Microsoft Dynamics CRM (Data и Config), которые затем могут быть восстановлены для возвращения сервера в обычное состояние. После этого каждый раз выполняется полное чистое развертывание в свежую среду; в том числе пользовательский код, модификации, надстройки и данные доменов.

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

В заключение можно сказать, что Microsoft Dynamics CRM – это масштабируемая система корпоративного уровня, которая, когда правильно настроена и развернута, может обслуживать мелкие группы, решения для всего предприятия и все варианты между ними. Определение того, какая среда жизненного цикла продукта подходит в конкретном случае, будет зависеть от ряда факторов.

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

Если решение требует дополнительной изоляции, ресурсов конкретного сервера или доступа (возможно, внешняя служба допускается только через VLAN от одного конкретного сервера к другому), я рекомендую последовать модели, показанной на рис. 6. Я также рекомендую избежать подхода, иллюстрируемого рис. 5, поскольку это, в лучшем случае, наскоро слепленный гибрид.

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