Иерархии и двусторонние данные

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 5 из 6 главы Мастер-данные и идентичность, глава 6 курса Data Architect. Каждый модуль самостоятелен. Назад: Карта — это не решение · Далее: Контрольная точка 1: Steve Trucking

Вопрос, на который отвечает этот модуль: как управлять данными, которые ведет больше одной системы?

Простая архитектура: клиентом владеет ERP, Salesforce получает копию, готово. Реальные предприятия не настолько аккуратны. ERP владеет юридическим клиентом, а Salesforce — отношениями в продажах; одно подразделение живет в SAP, купленное — в другой ERP; потенциальные клиенты существуют только в Salesforce. Потом кто-то хочет, чтобы пользователи Salesforce обновляли поле, которым управляет ERP, и стрелки начинают указывать в обе стороны. Как я говорю, когда это преподаю: «Самое сложное — это двунаправленные потоки». Не потому, что отправлять данные в обе стороны технически сложно, а потому, что, как только обе системы участвуют в изменениях, нужно быть предельно точным в вопросе полномочий.

Двусторонние данные не означают двух мастеров

ERP владеет адресом для счетов, который копируется в Salesforce. Торговый представитель узнает от клиента, что адрес изменился, и бизнес хочет, чтобы представитель обновил его, не выходя из Salesforce. Разумно. Теперь данные текут ERP → Salesforce и Salesforce → ERP. Становится ли теперь Salesforce совладельцем адреса для счетов? Нет. Направление интеграции не определяет полномочия. Представитель не меняет копию в Salesforce. С точки зрения архитектуры он просит изменить авторитетное значение. Вы не меняете поле ERP; вы просите его изменить. Salesforce — это интерфейс; мастером по-прежнему остается ERP.

Это меняет дизайн. Если бы полем владел Salesforce — сохранили, и готово. Если им владеет ERP, «сохранить» означает: Salesforce отправляет предлагаемый адрес, ERP проверяет и принимает его, обновляет свою мастер-запись и отправляет авторитетное значение обратно. Только тогда управляемое значение изменилось: запрос → проверка → принятие → публикация, а не «обновим обе системы и будем надеяться, что они останутся синхронными».

Click to enlarge

Двунаправленная интеграция не создает двунаправленных полномочий.

Когда мастер говорит «нет»

ERP отклоняет изменение: клиент неактивен, адрес нарушает правило ERP, пользователю нельзя менять юридические адреса, ERP недоступна или кто-то другой тем временем изменил клиента. Если Salesforce уже показал новый адрес, у нас теперь две истины, а модуль 1 уже сказал нам, какая побеждает: истина ERP. Поэтому архитектуре нужно состояние «запрошено, но еще не принято»: отдельное предлагаемое значение, флаг «ожидающее изменение» или ожидание подтверждения, прежде чем показывать значение. Механизм зависит от сценария. Правило — нет: никогда не позволяйте отклоненному запросу превратиться в конкурирующую истину.

Циклы и конфликты

Вот классика. ERP обновляет Salesforce; интеграция Salesforce видит изменение и отправляет его в ERP; ERP видит обновление и отправляет его обратно. Вы построили очень дорогой цикл. Хороший двусторонний дизайн знает, где началось изменение, принял ли его мастер и является ли это новым бизнес-изменением или лишь эхом уже обработанного: идентификаторы источника, метки времени, метаданные интеграции, идемпотентная обработка. Глава об интеграции разбирает это подробно. Принцип мастер-данных прост: знайте, порождаете ли вы изменение или отражаете его.

Затем конфликты. Один вы уже встречали в главе 5: торговый представитель запрашивает Steve’s Plumbing LLC, а в это время кто-то в ERP вводит Steve’s Plumbing L.L.C. (Защитите управляемую запись). Вот еще один. Salesforce предлагает Main Street, 125; почти в тот же момент пользователь ERP меняет его на 130. Что побеждает? Универсального технического ответа нет. Может быть, ERP всегда побеждает, потому что владеет полем; может быть, запрос из Salesforce уходит в очередь на проверку; может быть, побеждает более позднее принятое изменение; может быть, ERP отклоняет любое обновление, исходное значение которого изменилось. Это параллелизм, но под ним лежит решение о полномочиях, и никакой шаблон интеграции не спасет, если никто не решил, кто может вносить авторитетное изменение.

И одно поле — это простой случай. Адрес — это улица, город, почтовый индекс. Salesforce отправляет новую улицу, а ERP только что изменила город. Пропустите ли вы улицу отдельно? Или будете считать адрес одной транзакцией, чтобы все поля проходили вместе или не проходило ни одно, и отклоните все изменение целиком? Решите, какие поля путешествуют группой, до первого конфликта, а не после.

Каждый раз, когда я вижу двустороннюю интеграцию, я спрашиваю: что происходит, когда обе стороны меняют одни и те же данные? Если ответ — «вряд ли такое случится», мы еще не закончили. Что побеждает: отклоняем, ставим в очередь, сравниваем версии, отправляем на проверку? Должно ли поле вообще редактироваться в обоих местах? Иногда лучший двусторонний дизайн убирает одно направление для конкретного атрибута: Salesforce может запрашивать; только ERP публикует принятое значение. Данные по-прежнему движутся в обе стороны, но мастером поля является только одна система. В этой разнице — все.

Иерархии — тоже мастер-данные

Связи тоже могут быть мастер-данными. Глобальная материнская компания с регионами в Северной Америке и Европе, у каждого из которых есть дочерние компании по странам: сама иерархия несет смысл. Кто родитель? Какая дочерняя компания находится под каким юридическим лицом? Какие организации сводятся к глобальному клиенту? От этого зависят отчетность, территории, ценообразование, договоры, кредитный риск, обслуживание, доступ к данным и аналитика. Иерархия может значить столько же, сколько записи в ней, и ей нужно такое же управление. (Экзамен называет управление иерархиями; об этом легко забыть.)

В Salesforce иерархии организаций строятся с помощью поля Parent Account (родительская организация). Представление иерархии в Lightning показывает до 2 000 организаций, и только те, которые пользователь может видеть; персональные учетные записи в иерархии не поддерживаются; а Account Site различает площадки компании (Considerations for Using Account Hierarchy (opens in a new tab)). Но поле Parent Account не отвечает на архитектурный вопрос: кто владеет иерархией?

Знать к экзамену. Знайте основы иерархии организаций: она строится с помощью Parent Account; представление в Lightning показывает до 2 000 организаций, только те, которые пользователь может видеть; персональные учетные записи не поддерживаются; а Account Site различает площадки компании.

Одна иерархия, несколько мастеров

По моему опыту, у иерархий несколько мастеров. Североамериканские юрлица приходят из SAP, европейские — из другой ERP, новые потенциальные клиенты создаются в Salesforce, а купленная дочерняя компания еще не мигрировала. Кто владеет иерархией? Зависит от ветви. Каждая ERP управляет своей ветвью; Salesforce управляет связями потенциальных клиентов до их конверсии. Это законная архитектура — при условии, что все знают, где проходят границы. Решайте по ветвям.

Click to enlarge

Полномочия над иерархией можно назначать ветвь за ветвью.

Так что не позволяйте полю Parent Account скрывать полномочия. Пользователь меняет родителя дочерней компании в Salesforce. Технически — пустяк. А с точки зрения архитектуры — не изменил ли он только что юридическую структуру компании? Если эту ветвь ведет ERP, вероятно, нет, поэтому Salesforce должен это заблокировать или превратить в запрос на изменение. А может быть, Salesforce законно ведет коммерческую иерархию, а ERP — юридическую. Тогда, возможно, это вообще не должна быть одна и та же связь.

У компании может быть несколько законных иерархий: юридическая, биллинговая, продажная, сервисная, географическая. Глобальная материнская компания подписывает договор, регионы получают обслуживание самостоятельно, биллинг идет через общее финансовое юрлицо, продажи управляются по регионам. Какая иерархия настоящая? Все; они отвечают на разные вопросы. Ошибка — считать, что она должна быть одна. Должны быть четкие полномочия для каждого вида связи: принцип атрибутов из модуля 1, примененный к связям.

И не каждая связь «родитель — потомок» — это мастер-данные. Группировка сегодняшних доставок в один маршрут — это связь, но транзакционная, операционное событие. Иерархия клиента описывает долговременные деловые отношения. В модели обе выглядят как «родитель — потомок»; жизненный цикл у них разный. Спросите, что означает связь и как долго этот смысл сохраняется.

Один клиент, две ERP

Когда я это преподаю, я спрашиваю аудиторию: кто работал с клиентом, у которого один Salesforce и больше одной ERP? Руки поднимаются каждый раз. Спросите почему — и окажется, что ERP разделены по регионам (одна для Северной Америки, другая для Европы), по функциям (сантехническая компания покупает электротехническую, и каждая сохраняет свою ERP) или просто исторически: бизнес купили, и никто еще не провел миграцию.

Возьмем клиента — Steve’s Plumbing. Он работает в Северной Америке, поэтому в североамериканской ERP есть его запись клиента. Потом он открывает офис в Мюнхене, и европейская ERP создает собственную запись клиента со своим номером. Одна компания, две записи, два ID. Как представить это в одном org Salesforce? Я видел три способа.

Иерархия организаций. Steve’s Plumbing — родитель, а Steve’s Plumbing North America и Steve’s Plumbing Europe — дочерние организации, каждая из которых соответствует записи в одной ERP. Подвох: дочерние записи — это уже не совсем Steve’s Plumbing. Это Steve’s Plumbing, ведущий бизнес в регионе, а иерархия, как мы только что видели, несет смысл.

Равноправные организации. Две организации рядом, у каждой поле, которое говорит, к какой ERP она относится: код компании, регион. Ничего не скрыто. Цена проявляется в отчетности: чтобы увидеть Steve’s Plumbing по всему миру, нужно что-то, что говорит, что эти две организации — одна компания.

Одна организация с дочерней записью для каждой ERP. Один Steve’s Plumbing и дочерний объект с записью для каждой ERP, в которой хранится ID клиента в этой ERP. Две ERP или десять. Продавцы видят одного клиента и оформляют один заказ; за кулисами потоки решают, в какую ERP уходит каждая позиция: электромонтаж — в электротехническую ERP, сантехника — в сантехническую. Но теперь нужно решить, какая ERP главная для общих значений, таких как название и адрес, и что происходит, когда клиент есть в одной ERP и нет в другой.

Click to enlarge

Один клиент, две ERP: три способа представить это в Salesforce.

Спросите, как они синхронизируют свои ERP

Так какой выбрать? Сначала: сколько структуры ERP должны видеть продавцы? Если они всегда знали, что Северная Америка и Европа — отдельные бизнесы, потому что входят то в одну ERP, то в другую, не прячьте это от них. Перенесите эту структуру в Salesforce в виде равноправных организаций. Если бизнес хочет, чтобы перед продажами был один Steve’s Plumbing, ваш вариант — одна организация с дочерней записью для каждой ERP.

Затем вопрос, который действительно все решает, и решается он не в Salesforce. Я спрашиваю клиента: как вы синхронизируете эти две записи между своими ERP? Не то, что локально для каждой ERP, например баланс; это транзакционные данные. Я имею в виду мастер-данные: юридическое название, адреса. Если у них есть команда, которая поддерживает синхронизацию двух ERP, мы можем свести их в одну организацию. Если они не могут синхронизировать их в собственных ERP, как они могут ожидать, что мы будем синхронизировать их в Salesforce? Тогда — равноправные организации или иерархия.

Вспомните, что такое ERP. Это огромные системы, внедрение которых занимает годы, и у них собственный способ управления мастер-данными. Salesforce не будет ими командовать. Мы не управляем ERP. Мы управляем тем, как представляем их в Salesforce.

MDM посередине

Некоторые клиенты решили эту задачу еще до нашего прихода. Крупная компания, много лет на рынке, несколько ERP: они столкнулись с этой проблемой задолго до Salesforce и поставили посередине отдельный MDM-продукт как посредника между ERP. Это сосуществование или централизованное MDM из модуля 2. Теперь Salesforce не подключается к каждой ERP. Он смотрит в одно место — MDM-хаб — и получает единое представление клиента. Только не рассчитывайте встречать такое часто. Это крупные внедрения сами по себе; за все годы работы я сталкивался с этим всего два-три раза. И даже с хабом вам может понадобиться тот самый дочерний объект, чтобы каждый заказ знал, в какую ERP он уходит.

Click to enlarge

MDM посередине: Salesforce смотрит в одно место.

Steve Trucking: чья иерархия?

У розничного партнера своя структура: материнская корпорация, региональные подразделения, распределительные центры, магазины. Владеет ли Steve Trucking этой иерархией? Нет; партнер — источник полномочий для своей собственной организации. Но Steve Trucking может понадобиться собственное коммерческое представление тех же площадок — для договоров, управления клиентами, обслуживания и отчетности, — возможно, дочерняя организация для каждого DC под партнером. Две законные иерархии, два источника полномочий. Назовите их и не делайте вид, что одно дерево представляет все связи.

Сделайте границы видимыми

Когда полномочия разделены, я хочу, чтобы граница была видна: в именах полей, метаданных записей, идентификаторах исходных систем, разрешениях, поведении интеграций, документации. Чего я не хочу — так это чтобы разработчик читал пять интеграций, чтобы обнаружить: «эти значения Parent Account приходят из SAP, кроме потенциальных клиентов, кроме Европы». Это не сопровождаемая модель полномочий. Если у иерархии несколько мастеров, задокументируйте это разделение. Если полномочия меняются при конверсии, задокументируйте это изменение. Если Salesforce может запросить изменение, но не внести его, сделайте это очевидным в интерфейсе.

В Salesforce это начинается с одного поля. Нужно поле, которое ясно говорит, что это мастер-данные: ключ ERP или флаг «это мастер-данные». Управляйте редактируемостью полей через это поле, а не через тип записи; с Dynamic Forms вам больше не нужен тип записи, чтобы показывать поля ERP только для чтения (глава 5, Тип записи для каждого потока). Можно разрешить создавать записи вне мастера, но следите за правками.

За пределами экзамена: что меняет ИИ. Клиент говорит агенту: «Измените наш адрес для счетов на Main Street, 125». Поле прямо здесь, в Salesforce. Должен ли агент его обновить? Нет, если им владеет ERP. Агенту нужны полномочия на запись, а не только доступ к полю: его действие должно воплощать утвержденный путь — отправить запрос на изменение и сказать: «Я отправил изменение на обработку», а не ложно сообщить: «Я обновил ваш адрес для счетов».

Что здесь решает архитектор

• Меняет ли правка в Salesforce авторитетные данные или запрашивает изменение у системы, которая ими владеет.
• Как двусторонние потоки отличают исходные изменения от эха и обрабатывают отклонения, конфликты, задержки и сбои.
• Кто владеет каждой иерархией — при необходимости ветвь за ветвью.
• Для одного клиента, который хранится в нескольких ERP: иерархия, равноправные организации или одна организация с дочерней записью для каждой ERP — в зависимости от того, насколько хорошо клиент синхронизирует свои ERP.
• Являются ли конкурирующие иерархии на самом деле разными законными связями: юридической, биллинговой, продажной, сервисной.
• Как границы полномочий и утвержденные пути записи становятся видимыми для пользователей, интеграций, разработчиков и агентов.

Разделенные полномочия — не проблема. Проблема — неясные полномочия. Несколько ERP могут вести разные ветви, Salesforce может быть мастером одних атрибутов и запрашивать изменения других, а несколько иерархий могут описывать одно предприятие. Все это работает — при условии, что для каждого важного атрибута и связи вы можете сказать, кто им владеет, кто может его менять, где вносится авторитетное изменение и что происходит, когда системы расходятся. Если не можете, еще одна двусторонняя стрелка на диаграмме этого не исправит.

Дополнительно

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (на английском, проверено 2026-10-14).