Тим, хто звик думати про 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. Трирівнева система включає в себе наступні нижче великі компоненти.
Життєвий цикл розробки рішення
Рішення Microsoft Dynamics CRM проходить через той же цикл, що і будь-який проект розробки користувальницького додатка, який може бути подібний до процесу, показаному на рис. 1.
Мал. 1. Цикл розробки програми
Весь цей процес буде підтримуватися кількома середовищами, разом складовими системи розробки, тестування та виробництва. У світі будь-якого багатогранного корпоративного додатка це, само собою, може виявитися напрочуд складним. Якщо, для прикладу, необхідно створити дзеркальне відображення середовищ, результат може виявитися подібним показаному на рис. 2.
Мал. 2. Дзеркальне відображення коштів розроблювальні, тестових і виробничих середовищ
Це три домену, три контролера доменів, три сервера електронної пошти, три веб-сервера і три сервера бази даних - і ця модель передбачає, що SRS і CRM знаходяться на одному блоці, не беручи також до уваги завдання на зразок балансування навантажень. Тепер давайте уявимо собі додавання надмірності і декількох зовнішніх служб, таких як Microsoft Office SharePoint Services (MOSS), і цілком може вийти схема, подібна показаної на рис. 3.
Мал. 3 Зростаюча складність
В точки зору витрат і складності можна подумати про компроміси між потребою в ізоляції середовища і потребою знизити витрати і підвищити керованість. Організації, в силу цього, звернулися до різноманітних методик, такі як віртуалізація і вбудовані функції обслуговування одним екземпляром програми декількох розгортання Microsoft Dynamics CRM для вирішення цих завдань.
За контрастом, інші вважають, що подібна ізоляція зовсім не має значення. Якби вони могли, то займалися б розробкою і тестуванням прямо у виробничому середовищі. Вони схильні бачити надмірність як розтрату часу і грошей і переконані, що видавати результати було б простіше, якби можна було просто залізти в систему і змусити все працювати.
Можна сподіватися, що читачі перебувають десь між цими екстремальними випадками і будуть відкриті думки про те, що, коли мова йде про рішення на основі Microsoft Dynamics CRM, можливо створити гібрид, де збалансовані складність, витрати, ізоляція і керованість.
Елементи рішення CRM
Компоненти рішення Microsoft Dynamics CRM можна розділити на чотири великих пакета і рішення може включати в себе один з них, два, три або всі чотири.
Модифікації Сюди входять зміни форм, таблиць, схем і метаданих; ролі безпеки; робочі процеси; параметри системи і шаблони. Модифікації Microsoft Dynamics CRM надаються як один або кілька (зазвичай один або два) заархівіруваних файлу XML. Вони імпортуються в розгортання CRM через Outlook або область «Параметри | Спеціальна настройка» веб-клієнта, після чого «публікуються», щоб зробити їх активними. Все це можна автоматизувати, використовуючи код, написаний для SDK Microsoft Dynamics CRM.
Призначений для користувача код Все, що розроблено як частину рішення, - він може складатися з зовнішніх веб-служб, призначених для користувача компонентів веб-додатків і так далі. Правила та практики щодо розгортання призначеного для користувача коду не повинні відрізнятися від таких для будь-якого іншого користувача веб-додатки.
Дані Будь-яка інформація, яку необхідно імпортувати в середу для функціонування цього середовища. Сюди можуть входити доменні дані (такі як список кодів продуктів) або користувачі. Дані, необхідні рішення, можуть бути розгорнуті в екземпляр Microsoft Dynamics CRM за допомогою коду сценарію або функції пакетного імпорту CRM, або за допомогою будь-якої форми зовнішнього процесу, що використовує BizTalk, або інший засіб ETL (extract, transform, load - вилучення, перетворення і завантаження). Деякі дані, такі як дані про користувачів, необхідно створювати вручну або через виклики SDK Microsoft Dynamics CRM.
Я вважаю за краще думати про розгортання рішень CRM як якби вони були розгортання розробки власних додатків. Це означає, що в ході розгортання і тестування кожна нова збірка рішення встановлюється з чистою базової системи, а процес настільки повторюємо і працює за сценаріями, наскільки можливо.
Як щодо обслуговування одним екземпляром програми декількох розгортання?
На перший погляд це може здатися панацеєю, що дає відповідь на всі загадки керованості, ізоляції та витрат. Таке рішення можна візуалізувати, як показано на рис. 4.
Мал. 4. Рішення, цілком побудоване на обслуговуванні одним екземпляром програми декількох розгортання
Це здається логічним, оскільки кожна організація отримує власну фізичну базу даних на загальному SQL Server або примірнику (який включає в себе користувачів, модифікації, робочі процеси, ролі і параметри) і власну папку служб звітів SQL.
Візьмемо, наприклад, ці URL: crmserver / ContosoDevOrg / loader.aspx і crmserver / ContosoTestOrg / loader.aspx. Сервер CRM заглядає в кореневій каталог, щоб визначити ім'я організації, яку слід обслужити. Якщо імені кореневої організації не знайдено, як у випадку crmserver / loader.aspx, сервер використовує за замовчуванням першу організацію, створену в розгортанні, або ту, до якої у викликає користувача є доступ.
Оскільки для обох організацій використовується той же веб-сайт, то, якщо в рішенні є призначений для користувача код, то він теж буде використовуватися спільно обома організаціями, наприклад crmserver / ContosoDevOrg / ISV / mycustomdialog.aspx і crmserver / ContosoTestOrg / ISV / mycustomdialog.aspx.
Обидві вони вказують на один і той же фізичний файл на диску, такий як C: # 92; inetpub # 92; wwwroot # 92; isv # 92; mycustomdialog.aspx. Оскільки ймовірно, що версія користувальницького розширення у виробничій, тестової і разработочной середовищах буде відрізнятися, це може створити серйозну проблему. Припустимо, наприклад, що в даний момент розробляється збірка 11 додатка, тоді як збірка 9 знаходиться на стадії тестування, виробленого користувачами. При спробі використовувати обслуговування одним екземпляром програми декількох розгортання для вирішення проблем із середовищем, ізоляція цих двох збірок буде пов'язана зі складнощами. У подібних ситуаціях може здатися привабливим рішення, показане на рис. 5.
Мал. 5. Спроба використовувати різні сервери IIS для поділу коду користувальницьких рішень
Виробниче середовище 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
Ключові думки
Ізоляція важлива При розробці рішення пам'ятайте про те, який підхід (як проілюстровано на рис. 4, 5 і 6) найбільш підходить до ситуації, і враховуйте, де може працювати створюваний код. Також варто відзначити, коли не варто хвилюватися про такі проблеми, в силу типу використовуваних рішенням розширень.
Віртуалізація Віртуалізація допомагає знизити складність створення середовища, що відбиває ключові сценарії тестування виробничого середовища. Наведу трохи рад з приводу підготовки. Помістіть CRM і SQL Server на різні сервери. Це допомагає перевіряти відносини довіри для делегування і пов'язаних проблем. Навантаження на серверах CRM повинна бути збалансована, що допомагає визначити проблеми кешування, сеансів і межсерверной роботи. Нарешті, помістіть контролер домену і електронну пошту на окремі сервери; це допомагає визначати проблеми з підключенням.
Оновлюйте середу для кожної збірки За загальним правилом хорошого ідей є створення резервних копій або віртуальних середовищ, або просто баз даних Microsoft Dynamics CRM (Data і Config), які потім можуть бути відновлені для повернення сервера в звичайний стан. Після цього кожен раз виконується повне чисте розгортання в свіжу середу; в тому числі для користувача код, модифікації, надбудови і дані доменів.
Тестування продуктивності / надмірності можна виконувати окремо За винятком випадків дуже великих організацій, отказоустойчивостью і тестуванням продуктивності зазвичай можна займатися через ізольовані симуляції, а не через розширення реальної системи. Це означає, що немає необхідності створювати тестову середу, що дозволяє тестування таких сценаріїв. В якості альтернативи можна покластися на тестування їх або в виробничих, або в окремих одноразових середовищах.
На закінчення можна сказати, що Microsoft Dynamics CRM - це масштабована система корпоративного рівня, яка, коли має бути встановлена і розгорнута, може обслуговувати дрібні групи, рішення для всього підприємства і всі варіанти між ними. Визначення того, яке середовище життєвого циклу продукту підходить в конкретному випадку, буде залежати від ряду факторів.
Говорячи загалом, обслуговування одним екземпляром програми декількох розгортання не є ідеальним способом вирішення завдань розробки життєвого циклу продукту в складних рішеннях, і його бажано використовувати лише в разі повного розуміння. Прості рішення, які вимагають лише базових налаштувань або користуються адекватно написаними і ізольованим призначеними для користувача рішень, які не покладаються на ресурси диска або доступ до конкретного сервера, повинні спрацьовувати нормально, слідуючи моделі, описаній на рис. 4.
Якщо рішення вимагає додаткової ізоляції, ресурсів конкретного сервера або доступу (можливо, зовнішня служба допускається тільки через VLAN від одного конкретного сервера до іншого), я рекомендую наслідувати моделі, показаної на рис. 6. Я також рекомендую уникнути підходу, иллюстрируемого рис. 5. оскільки це, в кращому випадку, нашвидку зліплений гібрид.
В кінцевому підсумку, Microsoft Dynamics CRM може бути розгорнуто в тисячах конфігурацій, і те, яка саме з них підходить до ситуації, залежить від потреб рішення. З найкращим розумінням обслуговування одним екземпляром програми декількох розгортання, односерверних середовищ розгортання, віртуальних тестових середовищ і того, які тестовані сценарії актуальні, розробник повинен мати можливість розробити розгортання життєвого циклу продукту, яке як функціонально, так і економічно.