Кілька середовищ або клієнтів
Програми для взаємодії з клієнтами (Dynamics 365 Sales, Dynamics 365 Customer Service, Dynamics 365 Field Service, Dynamics 365 Marketing) забезпечують можливості розділення даних і доступу користувачів. Для більшості компаній додавання і використання декількох середовищ Power Platform забезпечує правильний баланс функціональності та легкості керування. Підприємства з окремими юридичними особами у складі, для яких може бути актуальним розділення каталогу і окреме ліцензування, можуть розглянути питання про використання кількох клієнтів. Усі користувачі певного клієнта можуть отримувати доступ до різних середовищ в межах цього клієнта. Щоб надати доступ користувачам з іншого клієнта, необхідно у клієнті запросити користувачів іншого клієнта як гостей.
Використання для декількох середовищ
Середовища схожі за концепцією на висотні бізнес-комплекси з поверхами, організованими відповідно до бізнес-функцій. Уявіть, що кожний поверх всередині будівлі це програма (продаж, послуга, маркетинг, постачальник управління, управління активами), а кожен блок поверху – середовище для певної цілі, наприклад, виробництва, навчання, тестування та розробки.
Декілька середовищ потрібно, якщо необхідно здійснити сегрегацію даних, плагінів, робочих циклів або ресурсів адміністратора, які не можуть бути легко ізольовані за допомогою організаційних одиниць.
Розгортання декількох середовищ
Типове розгортання включає лише одного клієнта. Клієнт може містити одне або декілька середовищ. Однак, середовищ завжди зв’язується з одним клієнтом.
У цьому прикладі використовуються два середовища для трьох команд: збут, маркетинг і послуги.
Sales і Marketing мають спільний доступ до середовища, що забезпечує їм обом легкий доступ до відомостей про потенційних клієнтів. Послуги мають власне середовище, тому запитами ти гарантіями можна керувати окремо від кампаній та інших відповідних заходів збуту.
Можна легко надавати доступ до одного або обох середовищ. Користувачі відділів збуту та маркетингу можуть обмежуватися своїм середовищем, в той час як користувачі відділу обслуговування із розширеним доступом можуть оновлювати записи по підвищення пріоритету підтримки, що відносяться до бізнес-партнерів, в обох середовищах.
Про одного клієнта із кількома середовищами:
Кожне середовище в межах клієнта отримує власну базу даних SQL.
Дані не є спільними для всіх середовищ.
Див. Обсяг сховища Microsoft Dataverse, щоб дізнатись, як сховище використовується вашими середовищами.
Середовища в межах одного клієнта за замовчуванням створюються у географічному розташуванні, де було здійснено реєстрацію відповідного облікового запису. Крім того, розробник середовища може створити середовище в іншій географічній області; користувачу відображатимуться доступні до вибору географічні розташування. За певних обставин користувачам може знадобитися побачити або вибрати всі географічні регіони, підтримувані Power Platform.
Споживання сховища обчислюється і відстежується для всіх середовищ, прикріплених до клієнта.
Для керуванням доступом до окремого середовища та правами на перегляд його вмісту можна настроїти окремі групи безпеки для середовищ.
Ліцензований користувач може потенційно отримати доступ до всіх середовищ, пов’язаних із клієнтом. Доступ контролюється участю у групі безпеки середовища.
Навіщо використовувати кілька середовищ?
Нижче наведено загальні випадки використання розгортання декількох середовищ. Згадайте ці приклади, коли вирішуватимете, який тип розгортання найкраще підходить вимогам вашої компанії.
Майстер Керування даними
У цьому сценарії «основний» набір даних забезпечує управління змінами через центральне джерело основних даних. Такий підхід вимагає, щоб центральні основні дані було синхронізовано для всіх середовищ, щоб кожне середовище мало доступ до останньої версії основної інформації. Запитані зміни до інформації можуть бути внесені безпосередньо в рамках основної системи. Крім того, користувачі можуть мати відкритий доступ до основної системи або фіксувати зміни у локальному середовищі, з такими змінами, що були послідовно прийняті в основному середовищі.
Вимога централізованого внесення змін може забезпечувати централізований контроль змін. Наприклад, перевірки щодо випадків шахрайства можуть здійснюватися для забезпечення того, що зміни вносяться лише центральною, а не місцевими робочими групами, які могли б мати переваги від змін, такі як змінення кредитних лімітів. Це забезпечило б другий рівень авторизації змін і перевірку, яка дозволяє уникнути можливості для однієї людини або групи людей, які працюють разом, співпрацювати для впливу на шахрайство. Передача запиту іншій, незалежній робочій групі може забезпечити захист від потенційних випадків шахрайства.
Безпека та конфіденційність
Відмінності в регіональному, наприклад Європейського Союзу (ЄС), або національному законодавстві може призвести до змін у вимогах до забезпечення безпеки даних або збереження конфіденційності даних для різних регіонів і країн в розгортанні. У деяких випадках законодавчі/нормативні обмеження роблять незаконним прийом даних за межами країни або регіону, проте розгляд цієї проблеми має особливе значення для конкретних галузей підприємств.
Наприклад, розглянемо обмеження сфери охорони здоров'я на обмін інформацією про пацієнта. Деякі правила ЄС вимагають, щоб будь-яка зібрана інформація щодо здоров'я людини, що проживає в ЄС, надається та розголошується лише в межах ЄС, хоча аналогічні дані, зібрані про людину у Сполучених Штатах (США) зберігається у межах США. Крім того, розглянемо обмеження щодо банківського сектору на спільний доступ до інформації про клієнтів. У Швейцарії, наприклад, є незаконним надання спільного доступу до інформації щодо клієнта за межами національних кордонів.
Масштабованість
Одне середовище дозволяє здійснювати масштабування і підтримувати розвиток бізнесу клієнта; проте, якщо використовуються складні архітектури або обробляються дуже великі обсяги даних, слід враховувати додаткові аспекти. Наприклад, за умов надзвичайно великих обсягів та/або широкого використання Планування послуг, масштабування SQL Server може вимагати складної і дорогої інфраструктури, нерентабельної або надто складної для керування.
Існує багато сценаріїв, в яких немає природного функціонального розподілу щодо вимог до можливостей. У таких випадках делегування навантаження шляхом створення масштабних сценаріїв на основі функціональних розподілів, може забезпечити більші обсяги за допомогою використання товарної інфраструктури.
Додавання середовища до передплати
Додаткові відомості про додавання середовища до клієнта див. в розділі Створення середовищ та керування ними.
Розгортання з підтримкою багатоклієнтської архітектури
Глобальний бізнес з регіональною моделлю чи моделлю країни, які відрізняються, можуть використовувати клієнтів як бізнес-партнерів за рахунок змін у підході, розмірі ринку або дотримання правових і нормативних обмежень.
Цей приклад стосується другого клієнта для Contoso Japan.
Облікові записи користувачів, посвідчення осіб, групи безпеки, передплати, ліцензії та сховище не можуть спільно використовуватися клієнтами. Усі клієнти можуть мати кілька середовищ, пов’язаних з кожним конкретним клієнтом. Дані не є спільними для всіх середовищ або клієнтів.
Про декількох клієнтів:
У сценарії з підтримкою багатоклієнтської архітектури ліцензований користувач, пов’язаний із клієнтом, може мати доступ лише до одного або декількох середовищ, зіставлених з таким клієнтом. Щоб отримати доступ до іншого клієнта, користувач повинен отримати запрошення як гість і, можливо, отримати окрему ліцензію.
Кожному клієнту потрібен адміністратор Microsoft Power Platform (або декілька) з унікальними обліковими даними для входу, а кожна афілійована особа клієнта керуватиме клієнтом окремо у консолі адміністратора.
Кілька середовищ у рамках клієнта відображуються в інтерфейсі, якщо адміністратор має доступ.
Не можна перепризначити ліцензії між реєстраціями клієнта. Зареєстровані афілійовані особи можуть використати скорочення ліцензії під однією реєстрацією і додати ліцензії до іншої реєстрації для спрощення цього процесу.
Локальне об'єднання Active Directory не може бути встановлене більше ніж з одним клієнтом, якщо у вас немає доменів верхнього рівня, які потрібно об'єднати з різними клієнтами (наприклад Contoso.com і Fabricam.com).
Використання декількох клієнтів
Функціональна локалізація
Цей сценарій зазвичай виникає в організаціях з перекриттям але з окремими функціональними потребами. Деякі загальні приклади:
Організації з різними підрозділами, кожен з яких має різний ринок або бізнес-модель.
Міжнародні підприємства з регіональною моделлю чи моделлю країни, які відрізняються за підходом, розміром ринку або дотриманням правових і нормативних обмежень.
У таких типах бізнес-середовища організації часто мають загальні набори функціональності, які підтримують певні регіони, країни або ділові районів зі ступенем локалізації щодо:
Записування відомостей. Наприклад, записування поштового індексу у США співвідноситься із записуванням поштового індексу в Сполученому Королівстві.
Форми, робочі цикли.
Фізичний розподіл
Для бізнес-рішень, які мають підтримувати користувачів, які фізично розподілені на великі відстані, особливо для глобальних розгортань, використання одного середовища може не підходити через ускладнення (наприклад WAN-затримку), пов'язані з інфраструктурою, за допомогою якої підключаються користувачі, що може суттєво вплинути на їхній досвід. Розповсюдження середовищ для надання користувачам більше локального доступу може зменшити або подолати проблеми, пов'язані з WAN, оскільки доступ відбувається через коротші підключення до мережі.
Додавання розгортання з підтримкою багатоклієнтської архітектури в рамках програми корпоративного ліцензування
Для розгортання з підтримкою багатоклієнтської архітектури потрібна спеціальна зміна для підтримки багатоклієнтської архітектури. Зміна для підтримки багатоклієнтської архітектури є фактичною зміною до корпоративної ліцензійної угоди, що використовується для придбання ліцензій. Зверніться до свого Microsoft торгового представника або торгового посередника, щоб отримати зміни.
Обмеження декількох клієнтів
Адміністратори, які хочуть розгортати і керувати кількома клієнтами, повинні знати:
Облікові записи користувачів, посвідчення осіб, групи безпеки, передплати, ліцензії та сховище не можуть спільно використовуватися клієнтами.
Один домен можна об'єднати з одним клієнтом.
Кожен клієнт повинен мати власний простір імен; простори імен UPN або SMTP не можуть бути спільними для декількох клієнтів.
Якщо використовується локальна організація Exchange, її не можна розділити між кількома клієнтами.
Об'єднаний глобальний список адрес буде доступним, тільки якщо керується в низхідному порядку від синхронізації.
Співпраця між клієнтами буде обмежена до функцій об’єднання Lync Federation і об’єднання Exchange.
Доступ SharePoint між клієнтами може не бути доступним. Хоча це може бути вирішено за допомогою доступу партнера, порушується досвід користувача та застосовуються аспекти ліцензування.
У локальній службі Active Directory не може бути повторюваних облікових записів у різних клієнтах або розділах.