Платформа Salesforce Customer 360 предоставляет мощную многопользовательскую архитектуру на основе метаданных каждому отдельному экземпляру клиента Salesforce (также известному как ‘организация’). Этот документ «Основы архитектуры» предоставляет обзор областей, в которых базовая архитектура Salesforce Platform создает ключевые рекомендации для архитектур решений, созданных на платформе.

При создании архитектур Salesforce Platform необходимо учитывать три важных области:

• Транзакции
• Метаданные в сравнении с данными
• API платформы

На Salesforce Platform транзакцию можно выполнить посредством выполнения кода и/или операции базы данных. Основополагающая компетенция для создания архитектуры в Salesforce - понимание того, как платформа определяет и управляет транзакциями для клиентов. Чтобы сохранить ресурсы для всех клиентов, Salesforce устанавливает ограничения для каждого клиента, рассчитанные на каждую транзакцию и организацию.

На транзакционном уровне Salesforce устанавливает пределы управления и выполнения, чтобы отдельные экземпляры выполнения кода и транзакций базы данных не монополизировали общедоступные вычислительные ресурсы. На уровне организации Salesforce устанавливает ограничения на основе версии и типа функции. Общеорганизационные ограничения также включают скользящий расчет использования API во всех транзакциях в организации, на которые распространяются ограничения API.

Рассмотрим более подробно две ключевые части транзакций на Salesforce Platform: контекст выполнения и манипуляции с базами данных.

Salesforce вычисляет ограничения транзакций на основе концепции контекста выполнения. Важно понимать, что для приложений Salesforce это не только выполнение настраиваемого кода в одной организации Salesforce. Контекст выполнения основан на механизме среды выполнения платформы и всем кодом, доступным механизму среды выполнения для определенного клиента. Это значит, что настраиваемый код, определенный в организации клиента, код из пакетов, установленных в этой организации, а также код, содержащийся в службах Salesforce Platform, могут мгновенно выполнить транзакцию. Платформа различает разные типы кода Apex и вычисляет контролирующие ограничения на основе этих различий.

Подробнее об ограничениях транзакций Apex см. в руководстве разработчика Apex.

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

Платформа открывает переменные контекста для состояния операций базы данных в виде переменных контекста триггера. Важно понимать, что эти переменные контекста триггера описывают состояния среды выполнения для всех транзакций базы данных в организации Salesforce — вне зависимости от того, были ли определены настраиваемые триггеры Apex в этой организации. Они доступны декларативным инструментам, например, Salesforce Flow.

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

Ключевой антипаттерн, которого следует избегать в архитектуре Salesforce, — это попытка сократить или заменить встроенный порядок выполнения платформы.

Для более подробного изучения логики этих встроенных алгоритмов целостности данных см. «Внутренние и внешние стороны»: Транзакции в блоге Salesforce Engineering.

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

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

Таблица ниже предлагает быстрое сравнение производительности данных по сравнению с метаданными, относящимися к ключевым частям жизненного цикла приложения:

Иногда это различие достаточно очевидно. Например, отдельные записи в организации Salesforce являются данными. Разные объекты в организации являются метаданными.

Различия могут быть более сложными, когда речь идет о функциях конфигурации организации. Ключевым примером являются настраиваемые параметры и типы настраиваемых метаданных. Обе эти функции позволяют настраивать информацию в организации, чтобы она была легко доступна во время выполнения, а также управлять ею аналогично записям базы данных. Обе функции предназначены для создания слабо связанных высокогибких схем оформления в коде и автоматизации. Однако, настраиваемые параметры хранятся в организации как данные, а типы настраиваемых метаданных — как метаданные.

Чтобы определить, является ли что- то метаданными, просмотрите их отображение в отчете о покрытии метаданными. Этот отчет также расскажет вам о ключевых алгоритмах разработки и развертывания для определенного типа метаданных.

Существует много API Salesforce Platform. Salesforce Platform API поддерживают разные форматы данных и протоколы, разные типы операций и сроки. Некоторые API позволяют взаимодействовать с данными в организации Salesforce, в то время как другие поддерживают взаимодействия с метаданными в данной организации. Некоторые API создаются специально для обработки больших объемов транзакций, а другие нет. Salesforce обновляет номер версии для всех API Salesforce Platform в каждом выпуске.

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

Многообразие разных API Salesforce Platform, а также скорость версий Salesforce API значительно усложняют жизненный цикл любых приложений, использующих Salesforce API. Вам нужно спланировать регулярные оценки ссылок на API Salesforce Platform в приложениях и расставить приоритеты запланированных циклов обслуживания API, чтобы поддерживать предсказуемую и правильную работу приложений.