Обзор Salesforce CRM. Часть 1

Автор статьи: Иван Левицкий, Salesforce разработчик, DataArt

В этой статье речь пойдет об американской компании Salesforce и ее главном продукте — одноименной CRM-системе. Посмотрим, что скрыто у нее под капотом, оценим систему с технической точки зрения и попробуем разобраться, кому будет интересно с ней поработать. Изначально я этого не планировал, но текст получился таким длинным, что пришлось разбить его на две части. В первой поговорим об истории успеха Salesforce, готовых решениях, бэкенде и языке Apex, созданном специально для работы с CRM.

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

Штаб-квартира Salesforce в Сан-Франциско находится в самом высоком небоскребе Западного побережья с говорящим названием Salesforce Tower. Это вполне характерная деталь: компания любит внимание, на нем во многом держится ее бизнес. Бывший менеджер по продажам, поднявшийся до вице-президента в Oracle, Марк Бениофф основал Salesforce в 1999 году — на старте вложился ряд инвесторов, включая Geneva Venture Partners. Уже в 2000-м они заставили говорить о себе, нахально разместив рекламный баннер с надписью "The End of Software" напротив места проведения конференции Siebel, прямого конкурента и на тот момент лидера рынка CRM.

С тех пор прошло более 20 лет, Siebel занимает не более 8 % рынка CRM-решений. Более того, его еще в 2006 году поглотил Oracle, но и это слияние не помогло участникам сделки составить серьезную конкуренцию Salesforce. Компания бывшего сотрудника Oracle уже восемь лет сохраняет позицию единоличного лидера рынка, занимая большую долю, чем тот же Oracle, SAP, Microsoft и Adobe вместе взятые.

Слоган c того рекламного баннера задал направление всей маркетинговой стратегии Salesforce. В несколько измененном виде они используют его даже в качестве номера контактного телефона: 1-800-NO-SOFTWARE.

В 2004 году компания стала публичной и начала торговать акциями на Нью-Йоркской бирже с тикером CRM. На момент написания статьи общая ее капитализация немного превысила $ 201,4 миллиарда, акция Salesforce стоила $ 218,72 (для примера, одна акция Apple Inc. в этот момент стоила $ 123, Microsoft — $ 242,35, Facebook Inc. — $ 298,66), а доход компании в 2020 году составил $ 4,875 — 4,885 миллиардов.

С 2006 года Salesforce поглотил более десятка компаний, среди которых Heroku (PaaS-решения), Quip (онлайн текстовый процессор), MuleSoft (промежуточное программное обеспечение), Tableau (BI-решения, ориентированные на визуальный анализ) и Slack (корпоративный мессенджер).

Двенадцать лет подряд Salesforce входит в список 100 лучших работодателей по версии журнала Fortune.

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

Важным фактором успеха стали личные качества, навыки и способности, в том числе маркетинговые, главы компании — Марка Бениоффа. Он всегда относился к репутации с повышенным вниманием, а каждый новый крупный клиент только добавлял Salesforce веса.

Здесь я собрал термины, которые часто встречаются в статье, но могут не быть понятны из контекста.

• SF, SFDC — сокращения для названия Salesforce.

• Salesforce organization/org (реже Salesforce instance) — экземпляр, открытый для конкретного клиента Salesforce. Может относится к одной из разновидностей: Production, Sandbox, Developer, Scratch. В обиходе часто называется «оргой».

• Production org — орга или инстанс, с которым непосредственно работают конечные пользователи.

• Sandbox org — песочница для экспериментов, привязанная к какой-либо Production org.

• Developer org — орга, в основном предназначенная для создания пакетов для AppExchange. Еще чаще ее используют для экспериментов или работы с бесплатной обучающей SF-платформой Trailhead. Новые клиенты обычно начинают именно с Developer org, затем после настроек и миграции конвертируют ее в Production.

• Scratch org — особый тип орги с ограниченным циклом существования (до 30 дней), предназначенный для выполнения отдельных задач или создания Proof of Concept. Очень популярен при работе в больших командах, где нет возможности создавать отдельную песочницу для каждого разработчика. Часто используется для CI/CD.

• Salesforce Cloud — готовое решение для какой-либо отрасли от Salesforce.

• Package — кастомное решение, чаще разработанное сторонней компанией для расширения функционала или интеграции с внешними системами. В большинстве случаев распространяется через магазин приложений, реже по ссылке, некоторые работают по подписке.

• ISV — Independent Software Vendor — независимый поставщик ПО. Как правило, так называют тех, кто разрабатывает пакеты для AppExchange.

• AppExchange — официальный магазин приложений для Salesforce, в нем предлагают бесплатные и платные пакеты.

• Application (App)— в контексте Salesforce этот термин многозначен. Чаще всего App-кой называют набор сгруппированных вкладок, реже App — это автономная Aura-аппликация, наконец совсем редко App употребляют в значении Package.

• SaaS —Software as a Service — модель, внутри которой программное обеспечение поставляется не установочным пакетом или исполняемым файлом, а в основном в виде Веб-приложения, под капотом которого скрыто облачное решение.

• PaaS —Platform as a Service — модель предоставления услуг, которая позволяет быстро разворачивать и масштабировать сайты или сервисы, не слишком беспокоясь о настройке. Компания, предоставляющая PaaS-услуги, берет на себя ответственность за сам процесс развертывания.

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

Ниже приведен обзор самых популярных решений Salesforce.

Sales Cloud (Встроенный, SaaS). Говоря о Salesforce, в первую очередь имеют в виду именно Sales Cloud — ядро всей CRM. Он имеет встроенные объекты (Lead, Contact, Account, Opportunity, Order, Quote и др.) для работы с клиентами и готовую бизнес-логику (Lead Conversion, Lead Assignment, Forecasting и т. д.). Позволяет строить пайплайн, обладает богатым инструментарием для отчетности. Sales Console UI позволяет работать с несколькими записями одновременно.

Service Cloud (Встроенный, частично доступный по умолчанию, SaaS). Наиболее прибыльный среди всех SF Clouds. Позволяет обрабатывать жалобы клиентов. Имеет ряд встроенных объектов (Case, Knowledge Article и др.) и встроенную бизнес-логику (Case Assignment, Case Escalating, Web-to-Case, Email-to-Case). Для Service Cloud разработан специальный вид Salesforce UI — Service Console. Он позволяет удобно работать с несколькими записями, не переключаясь между вкладками.

Experience Cloud (ранее Community Cloud) — встроенный, но недоступный по умолчанию, PaaS. Мало чем отличается от сайтов-конструкторов, многие компании, особенно среднего масштаба, используют его функционал для расширения взаимодействия с клиентами, партнерами или сотрудниками. Тесно интегрирован с самым Salesforce, позволяет легко настроить автоматическую выгрузку контента с CMS. Множество встроенных компонентов повторяет функционал Salesforce. Позволяет настроить все: от страницы входа до адреса портала.

Marketing Cloud (частично встроен, но большая часть функционала вынесена в отдельный пакет, SaaS). B2C маркетинговое решение, в прошлом продукт самостоятельной компании Exact Target. Предоставляет типичный для маркетингового инструмента функционал: массовая рассылка электронных писем, их отслеживание, создание лендингов, проведение кампаний и т. д.

Pardot (Отдельные сайт и пакет, SaaS). B2B маркетинговое решение, в прошлом продукт сторонней компании. Позволяет создавать формы и лендинги, отслеживать посещения, проводить оценку потенциальных клиентов и маркетинговые кампании, снимать статистику в реальном времени.

CPQ (Configuration Price Quotes) — отдельный пакет, SaaS. Содержит богатый инструментарий для гибкой настройки ценообразования и продаж (в том числе подписок), продвинутого управления процессом согласования решений. Может быть дополнен плагинами для расширения функционала.

Существует и множество других решений для конкретных областей применения. Government Cloud предназначен для государственных организаций, Healthcare Cloud объединяет в единую сеть пациентов и поставщиков медицинских услуг. Vaccine Cloud, построенный на основе Experience Cloud и интегрированный с Government Cloud, позволяет быстро найти клинику для вакцинации, а правительству и медицинским учреждениям упростить процесс. Для благотворительных организаций разработан Non Profit Cloud, он же Nonprofit Success Pack или NPSP, предоставляющий десять бесплатных лицензий. Кроме того, есть, например, Education Cloud, Industries Cloud, Financial Service Cloud, Commerce или B2C Commerce Cloud, которое активно интегрируется с CMS, Analytics Cloud, интегрируемое с Tableau, Integration Cloud, интегрируемое с интернет-шиной Mulesoft.

• Force.com sites — PaaS-сервис, предназначенный для упрощения разработки и развертывания облачных приложений и веб-сайтов.
• Chatter — корпоративный мессенджер, продукт сторонней компании, поглощенной Salesforce. Позволяет быстро создавать чат-ботов, но, возможно, в компании его считают устаревшим. С этим может быть связано приобретение Slack.
  
• Omni channel — центр, объединяющий разные каналы общения с клиентами.
  

• Einstein™ AI — искусственный интеллект от Salesforce, в основном отвечающий за анализ данных на вашей Salesforce-орге. Очень ограничен в плане программного взаимодействия, оно почти полностью сводится к настройке и администрированию.

• Встроенные интеграции с продуктами Google (Gmail, Calendar, Contacts, Drive), Microsoft (Outlook) и Amazon: в частности, с AWS, где есть возможность настроить private connect в обход HTTP/HTTPS-трафика.

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

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

Для начала надо напомнить, что Salesforce CRM — полностью облачное решение. Значит, на локальной машине ничего компилировать не придется. Вернее, можно самостоятельно компилировать классы, но Salesforce справляется с задачей автоматически, необходимость делать это вручную возникает редко. Собственно, это желательно только в случае изменения зависимостей. Salesforce под капотом работает с кэшированными скомпилированными классами.

Систему, построенную на облачных технологиях, даже устанавливать на локальный сервер не нужно. Salesforce берет на себя всю ответственность за настройку и поддержку серверов, а архитектура его CRM многошаровая и распределенная: основные серверы находятся в CША, Англии, Германии, Франции и Японии, а те, что работают на AWS-инфраструктуре — в США, Канаде, Индии и Австралии. Базы данных одного клиента хранятся на одном сервере, более того, есть информация, что эти данные хранятся в одной базе с данными других клиентов. Но по понятным причинам компания неохотно распространяется о том, как организовано хранение информации, и вообще старается хранить в тайне максимально много технических подробностей.

В Salesforce имеется Mobile SDK для создания кастомных Android- и iOS-приложений для инстансов клиентов. Кроме того, есть и официальные аппликации.

Система содержит ряд встроенных объектов, с полным списком которых можно ознакомиться здесь. Можно создавать и свои — кастомные — например, в версии Unlimited Edition можно создать 2000 штук, а еще 1000 установить как часть пакетов. В Salesforce объект, который можно сохранить в базе данных, называют SObject, его аналог в реляционной базе данных — таблица. В основном объекты в Salesforce создаются через UI-интерфейс или Metadata API, также SObject может быть создан автоматически на основе данных, импортированных из электронных таблиц.

Для хранения глобальных переменных в Salesforce используют инструмент Сustom Settings или более новый Custom Metadata Types, который широко применяется в разработке пакетов. Преимущество Custom Settings в возможности создавать уникальные иерархические записи, например, для различных профайлов пользователей. В свою очередь для Custom Metadata Type можно создавать связи между собой. На самом деле, между этими инструментами есть и другие различия.

Для создания языковых версий можно использовать инструмент Translation Workbench. При разработке кастомных компонентов рекомендуется выносить все надписи в Custom Labels, которые поддерживают мультиязычность. Также есть поддержка разных валют с привязкой к курсу на конкретную дату.

В Salesforce аналогом колонок таблицы БД служат поля. Для кастомных полей выделяют следующие типы:

• Auto Number — автоматически нумерует запись, позволяет создать шаблон.

• Checkbox — может принимать значения true/false.

• Currency — тип валюты, представленный в ISO-стандарте.

• Date — дата хранится в GMT, но отображается в соответствии с временной зоной пользователя, который просматривает поле.

• Date/Time — аналогично предыдущему, но позволяет также сохранять и время.

• Email — предназначен для хранения электронных адресов.

• External Lookup Relationship — специальный тип связи, который используется для интеграции с внешними системами.

• Formula — значения для поля-формулы не сохраняются в базе данных, а исчисляются непосредственно в момент доступа к нему. Для поля выделяют типы: Checkbox, Currency, Date, Date/Time, Number, Percent, Text, Time.

• Geolocation — позволяет сохранять координаты: широту и долгота.

• Hierarchical Relationship — специальный тип связи, доступный для объекта User.

• Indirect Lookup Direction — специальный тип связи между внешними объектами.

• Lookup Relationship — слабый тип связи.

• Master-Detail Relationship — сильный тип связи, когда child (detail) наследует от parent (master) владельца настройки общего доступа. При удалении master записи автоматически удаляется и detail.

• Number — числовой тип позволяет хранить до 18 цифр (например, 18 цифр целого числа или 16 цифр целой части плюс 2 цифры дробной части).

• Percent — для хранения процентов, по-разному отражается на UI, в формулах и Apex-коде.

• Phone — поля для телефонных номеров, по сути текстовые.

• Picklist — название dropdown в Salesforce. Хотя база данных здесь считается нормализованной, она включает этот тип поля, который противоречит требованиям к нормализованным БД.

• Picklist (Multi-select) — еще один тип, которого не должно быть в нормализованной базе данных. Сохраняет значения для multi select combobox, в базе данных выбранные значения сохраняются в виде текстового поля и разделяются с помощью точки с запятой.

• Roll-Up Summary — специальный тип поля, доступный только на master объектах, проводит вычисления с помощью функций агрегации (COUNT, SUM, MAX, MIN). Значение детерминированных функций сохраняются в базе данных, остальные пересчитываются при изменении связанных detail записей.

• Text — текстовое поле, которое позволяет хранить до 255 символов.

• Text (Encrypted) — текстовое поле, которое кодируется с помощью 128-битного AES-ключа, ограниченное 175 символами.

• Text Area — поле, ограниченное 131 072 символами, которое сохраняет символы табуляции.

• Text Area (Rich) — позволяет сохранять текст объемом до 131 072 символов, отформатированный с помощью HTML, поддерживает ограниченный набор тегов.

• Time — самый новый тип поля, предназначенный для хранения времени.

• URL — предназначен для хранения гиперссылок.

Скоро должен появиться новый тип поля Address.

Email-, Number- и Text-поля можно использовать как External ID, что особенно удобно при миграции или интеграции.

Для реализации связи многие-ко-многим создаются Junction Objects, которые имеют два Master-Detail Relationship поля. Собственно, два — максимум для этого типа поля на одном объекте.

Для полей в Salesforce есть встроенная поддержка политики приватности, в том числе в соответствии с GDPR. Для текстовых закодированных полей предусмотрен Classic Encryption (AES-шифрование блоками по 128 бит). Также есть платный Salesforce Shield, который не ограничивается текстовыми полями и использует AES-шифрование блоками по 256 бит.

Также имеется встроенная система доступов на уровне объектов, полей, записей. Записями можно делиться автоматически, например, с помощью sharing rules и Apex managed sharing, или вручную.

Если у вас накопились миллиарды записей, можно использовать специальный инструмент — Salesforce Big Objects.

Подробнее о типах полей можно прочитать по этой ссылке, о типах связей между объектами — здесь.

Говоря о бэкенде, чаще всего уделяют внимание Apex-классам и триггерам. Реже — какому-то функционалу на Heroku или интеграции с помощью платформ MuleSoft и DellBoomi. Еще реже под этим термином подразумевают кастомные ETL-решения.

Недавно Salesforce объявил о запуске Salesforce Functions, однако эта услуга пока находится на стадии бета-тестирования. По идее, это FaaS-инструмент (Functions-as-a-Service), который позволяет писать бэкенд-решения не только на Apex, но и на других языках программирования, и бесшовно интегрировать их с вашим Salesforce-инстансом.

Apex — проприетарный Java-подобный объектно-ориентированный язык программирования, разработанный специально для работы с Salesforce CRM. Язык не чувствителен к регистру, однако придерживаться регистров при написании кода на Apex все же считается хорошей практикой.

Вот пример Hello World написанного на Apex:

В основе Salesforce — transaction based- и event-based-архитектура, но здесь поддерживается и возможность запуска кода по требованию или в соответствии с зафиксированным ранее планом. Все это отражается на специфике самого языка программирования. Например, static переменные будут храниться только в контексте одной транзакции (скажем, при создании записи и всех вызванных ей синхронных и некоторых асинхронных действий).

Язык содержит следующие типы данных:

• Примитивные: Blob, Boolean, Date, Datetime, Decimal, Double, Id, Integer, Long, Object, String, Time.

• SObject — стандартные и кастомные объекты, которые хранятся в базе данных.

• Коллекции: List, Set, Map.

• Типизированный список значений (enum).

• Пользовательские Apex-классы.

• Определенные системой Apex-классы.

• Null.

Все типы данных наследуются от Object, все стандартные и кастомные объекты — от SObject.

Да, Salesforce имеет только три типа коллекций. Массивы (Arrays) и списки (List) — здесь фактически одно и то же. Но никто не запрещает вам создавать собственные имплементации других коллекций, в том числе и для этого предусмотрен интерфейс Iterator. По опыту скажу, чаще всего приходится имплементировать multi map.

В отношении объектно-ориентированности в Salesforce также есть специфика: вы можете создавать классы, абстрактные классы и интерфейсы. Для примера, в интерфейсе нельзя задавать сигнатуры свойств (property), но это не единственное ограничение.

Здесь есть возможность определять конструктор класса, инициализатор класса, но, например, нет возможности определить деструкторы.

Для работы с базой данных имеются DML (Data Manipulation Language), SOQL (Salesforce Object Query Language) и SOSL (Salesforce Object Search Language). Для манипуляций с записями не надо устанавливать соединение с базой данных или создавать DTO-классы. Это, пожалуй, самое большое преимущество при работе с базой данных Salesforce.

DML — язык манипуляции данными. Поддерживает следующие операции: insert, update, upsert, delete, undelete, merge. DML работает с одной записью или списком SObject-записей, созданных пользователем программно или полученных с помощью SOQL.

SOQL — SQL-подобный язык запросов. Основное отличие в отсутствии поддержки Join, зато многие другие возможности идентичны, хотя и со своими ограничениями. Например, так будет выглядеть SOQL-запрос, который вытягивает данные об аккаунтах — объектах, отвечающих за компании — и связанные с ними контакты:

Здесь контакты связаны с компанией с помощью lookup поля AccountId, а название связи в конкретном случае — Contacts.

SOQL может возвращать:

• Одну запись (если есть LIMIT 1 или в WHERE указывается конкретное Id).

• Пустой список SObjects, Custom Setting или Custom Metadata Types (когда заданным критериям не соответствует ни одна запись).

• Список SObjects, Custom Setting или Custom Metadata Types.

• Агрегированные результаты или просто число (например, для функции агрегации COUNT).

Для оптимизации запросов есть возможность индексировать поля, а некоторые типы полей индексируются автоматически.

SOSL — язык запросов, предназначенный исключительно для поиска. Используется значительно реже SOQL, особенно полезен при написании глобального поиска. Пример SOSL-запроса:

На основе хорошо документированного кода можно автоматически сгенерировать документацию с помощью ApexDoc. Для статического анализа кода существует много сервисов и плагинов, самый популярный из них — PMD.

Governor Limits

Поскольку Apex работает в среде многошаровой архитектуры, выполнение Apex-кода строго ограничивается, чтобы исключить монополизацию им совместных ресурсов. Ограничение накладывается почти на все в контексте одной транзакции: количество поисковых запросов с помощью SOQL; количество SOSL-запросов, которые они возвращают; количество DML-операций; Heap size; CPU Time и т. д. Для асинхронного Apex эти ограничения не столь строги.

Подробнее о Governor Limits можно прочитать здесь.

Вписаться в ограничения помогут Apex Design Best Practices.

Асинхронный Apex

Имеются следующие типы асинхронного Apex:

• Future — используется для относительно коротких callouts (до 60 секунд).

• Continuation — используется для длительных callouts[13] [14] , доступен и для VisualForce, и с недавних пор для Aura и LWC.

• Batch — позволяет асинхронно обрабатывать большие объемы данных, помогает обойти Governor Limits.

• Queueable — как и Batch, применяется для обработки большого объема данных. Главное преимущество перед Batch — возможность вызвать другой Queueable, т. е. сформировать цепочку.

• Schedualble — позволяет запускать код в определенное время и с определенным интервалом.

Событийно-ориентированная архитектура

Для построения Event-based архитектуры применяют Platform Events (publish-subscribe модель для взаимодействия с внешними приложениями, также используется для вынесения ресурсоемкого функционала), Change Data Capture Events (используется для обработки изменений записей), обычные и асинхронные триггеры.

Безопасность и контроль доступа

В профайле пользователя можно предоставить или забрать доступ к Apex-классу.

Аналогично многим C-подобным языкам программирования, Apex имеет следующие модификаторы доступа: private, protected, public. Помимо них, в Apex есть еще один — global, который чаще всего используют при разработке сторонних пакетов, реже — для имплементации некоторых стандартных интерфейсов.

Когда вы объявляете класс, можете также указать ключевые слова: with sharing (все sharing rules, CRUD, FLS будут соблюдены), without sharing (код будет иметь доступ ко всем записям и полный доступ к CRUD и FLS), inherited (означает, что sharing mode класса будет зависеть от sharing mode класса, который его вызвал).

Пример объявления класса:

Веб и Email-сервисы

С помощью Apex можно разработать полноценные SOAP-, REST-based Web- и Email-сервисы. Например, для параметров и возвращаемых значений Apex REST поддерживает следующие типы данных.

* Примитивы Apex (исключая Object и Blob).

* sObjects.

* Списки или map примитивов Apex или sObjects (поддерживаются только map со строковыми ключами).

* Определяемые пользователем типы, которые содержат переменные — члены перечисленных выше типов.

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

Юнит-тесты

Код на Production-орге нельзя редактировать напрямую, поэтому принцип «раз-раз, и в продакшен» здесь не сработает. Код пишется и тестируется, например, в Sandbox, а на Production он только деплоится. Причем код должен быть покрыт юнит-тестами не менее чем на 75% и не валиться при развертывании, по крайней мере локальном. Для деплоймента Sandbox => Sandbox таких требований нет.

Отладка

Для отладки Apex-кода существуют Debug Logs с различными уровнями логирования. Можно создать Traced Flags для: 1) автоматизированного процесса; 2) Platform Integration; 3) конкретного пользователя; 4) Apex-класса; 5) Apex-триггера. В коде для лучшей отладки можно ставить breakpoints.

Apex-триггеры

Есть возможность создавать before- и after-триггеры для следующих DML-операций: insert, update, delete, undelete (восстановление записи, ранее удаленной в корзину). Для операции undelete можно определить только after триггер. В зависимости от операции доступны следующие контекстные переменные: Trigger.new (List с измененными значениями), Trigger.old (List со значениями до изменения), Trigger.newMap (Map — то же, что Trigger.new, только в виде Map), Trigger.oldMap (Map — то же, что Trigger.old, только в виде Map) и другие. Upsert DML операция — это микс Insert и Update, merge — микс Update и Delete.

Как правило, весь код из триггеров выносят в отдельные handler-классы, а код, который можно переиспользовать, в service-классы. Хотя подходов и trigger-фреймворков очень много.

Для разгрузки триггеров используют асинхронные триггеры, которые выполняются после завершения транзакции. Чтобы задеплоить Apex-триггер на Production, нужно хотя бы одну строку его кода покрыть юнит-тестом.

Каждый Salesforce-разработчик должен помнить об Order of execution. Поскольку при DML-операции запускается не только триггер, но и множество другого декларативного функционала, в отдельных случаях это может вызвать рекурсию и как результат — выход за Governor Limits. Подробнее о порядке выполнения можно прочитать здесь.

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

Даже относительно высокая цена продуктов Salesforce не отпугивает клиентов, в основном средний и крупный бизнес. При этом существуют решения и для совсем небольших компаний. Впрочем, и ограничений здесь хватает, и я точно не стану убеждать вас, что Salesforce обязательно будет вам интересен. Подробнее о том, кому, скорее всего, стоит присмотреться к CRM и прочей Salesforce-инфраструктуре, поговорим во второй части статьи. Также речь в ней пойдет о фронтенде и развертывании в Salesforce, встроенных средствах декларативного программирования, процесс и средах разработки. В заключении обещаю поделиться списком литературы для разработчиков и администраторов, полезными ссылками и расширениями для Сhrome.

Продолжение следует.