Огляд Salesforce CRM. Термінологія, готові рішення та функціонал. Частина 1
У цій статті поговоримо про американську компанію Salesforce та її головний продукт — однойменну CRM-систему. Подивимось, що приховано під капотом, оцінимо її з технічного боку та спробуємо розібратись, кому буде цікаво з нею працювати.
Матеріал для зручності розбито на дві частини. У першій йтиметься про історію успіху Salesforce, готові рішення, бекенд і мову програмування Apex, створену спеціально для роботи з CRM.
Я познайомився з Salesforce чотири роки тому та здебільшого встиг непогано вивчити її. Треба сказати, що я не схильний ідеалізувати систему: тут є свої обмеження, з якими краще розібратися до занурення в тему. Сподіваюсь, стаття допоможе в цьому, а ще зорієнтує, чи варто йти далі. До речі, у другій частині буде дещо і для тих, хто вже давно працює з Salesforce.
Ілюстрація Марії Рибак
Що таке Salesforce
Штаб-квартира Salesforce у Сан-Франциско розташована в найвищому хмарочосі Західного узбережжя з промовистою назвою Salesforce Tower. Це цілком характерна деталь: компанія любить увагу, багато в чому на ній тримається бізнес. Колишній менеджер з продажу, що піднявся до віцепрезидента в Oracle, Марк Беніофф заснував Salesforce 1999 року. Тоді в неї вклалася низка інвесторів, зокрема Geneva Venture Partners. Уже у
Відтоді минуло понад 20 років, Siebel займає не більше як 8% ринку CRM-рішень. До того ж її ще 2006 року поглинула компанія Oracle, але й це злиття не допомогло учасникам угоди скласти серйозну конкуренцію Salesforce. Компанія колишнього співробітника Oracle вже вісім років зберігає позицію одноосібного лідера ринку, займаючи більшу частку, ніж та сама Oracle, SAP, Microsoft і Adobe разом узяті.
Слоган з того рекламного банера задав напрям усій маркетинговій стратегії 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-аплікація, зовсім рідко вживають у значенні Package.
SaaS — Software as a Service — модель, всередині якої програмне забезпечення поставляється не інсталяційним пакетом або виконуваним файлом, а здебільшого у вигляді вебзастосунку, під капотом якого приховано хмарне рішення.
PaaS — Platform as a Service — модель надання послуг, яка дає змогу швидко розгортати та масштабувати сайти або сервіси, не надто турбуючись про налаштування. Компанія, що надає PaaS-послуги, бере на себе відповідальність за сам процес розгортання.
Готові рішення Salesforce
Salesforce підготувала безліч рішень для різних індустрій, часто вони відокремлюються у самостійні продукти, до назви яких зазвичай входить слово Cloud. Деякі конкретні рішення існують просто як елементи функціоналу. Чимало Salesforce Clouds раніше були окремими продуктами, а створили їх компанії, які були поглинені й інтегровані з Salesforce. Частина з них поставляється як окремі пакети, що можна встановити на Salesforce org.
Дохід від найбільш прибуткових Salesforce Clouds (©). На 2021 рік аналітична платформа Statista прогнозує зростання доходу Salesforce на 25%
У таблиці нижче наведено огляд найпопулярніших рішень 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.
Інший Salesforce-функціонал
- 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 можна міняти бекенд, фронтенд і навіть модель бази даних. Є можливість для декларативного програмування, до того ж вбудованих інструментів багато. Звісно, нюанси та обмеження все ж існують, поговоримо про них піде далі.
Спершу треба нагадати, що 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 використовують інструмент Custom 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 цифр цілої частини плюс дві цифри дробової частини).
- 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
Крім того, є вбудована система доступів на рівні об’єктів, полів, записів. Записами можна ділитися автоматично, наприклад, за допомогою sharing rules і Apex managed sharing або вручну.
Якщо у вас накопичилися мільярди записів, то для Big Data є Salesforce Big Objects.
Докладніше про типи полів можна прочитати у статті Custom Field Types, про види зв’язків між об’єктами — у Different types of relationships in Salesforce.
Бекенд
Коли говорять про бекенд, найчастіше приділяють увагу Apex-класам і тригерам. Рідше — функціоналу на Heroku чи інтеграції за допомогою платформ MuleSoft і DellBoomi. Ще рідше під цим терміном мають на увазі кастомні ETL-рішення.
Нещодавно Salesforce оголосила про запуск Salesforce Functions, проте ця послуга поки на стадії beta-тестування. Це FaaS-інструмент (Functions-as-a-Service), який дає змогу писати бекенд-рішення за допомогою не лише Apex, а й інших мов програмування, та безшовно інтегрувати їх з вашим Salesforce-інстансом.
Apex
Apex — пропрієтарна, Java-подібна, об’єктно-орієнтована мова програмування, розроблена спеціально для роботи з Salesforce CRM. Мова не чутлива до регістру, проте дотримуватися регістрів під час написання коду через Apex все ж вважають хорошою практикою.
Ось приклад Hello World, написаного на Apex:
System.debug(‘Hello World!’);
В основі Salesforce — transaction based і event-based архітектура, але підтримується і можливість запуску коду на вимогу, відповідно до завчасно запланованого із користувацького інтерфейсу, або за допомогою CRON expression. Наприклад, 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-запит, який витягує дані про акаунти — об’єкти, що відповідають за компанію, — та пов’язані з ними контакти:
SELECT Id, Name, (SELECT Id, Name FROM Contacts) FROM Account
Тут контакти пов’язані з компанією за допомогою lookup поля AccountId, а назва зв’язку в конкретному випадку — Contacts.
SOQL може повертати:
- Один запис (якщо є LIMIT 1 або у WHERE вказується конкретне ID).
- Порожній список SObjects, Custom Setting чи Custom Metadata Types (коли заданим критеріям не відповідає жоден запис).
- Список SObjects, Custom Setting чи Custom Metadata Types.
- Агреговані результати чи просто число (наприклад, для функції агрегації COUNT).
Для оптимізації запитів є можливість індексувати поля, а деякі типи полів індексуються автоматично.
SOSL — мова запитів, призначена суто для пошуку. Використовується значно рідше за SOQL, особливо корисна під час написання глобального пошуку. Приклад SOSL-запиту:
FIND {"Joe Smith" OR "Joe Smythe”} IN Name Fields RETURNING lead(name, phone), contact(name, phone)
На основі добре документованого коду можна автоматично згенерувати документацію за допомогою ApexDoc. Для статичного аналізу коду є багато сервісів і плагінів, найпопулярніший з них — PMD.
Governor Limits
Оскільки Apex працює в середовищі багатошарової архітектури, виконання Apex-коду суворо обмежується, щоб унеможливити монополізацію ним спільних ресурсів. Обмеження накладається майже на все в контексті однієї транзакції: кількість пошукових запитів за допомогою SOQL; кількість SOSL-запитів, які вони повертають; кількість
Докладніше про Governor Limits можна прочитати тут.
Вписатися в обмеження допоможуть Apex Design Best Practices.
Асинхронний Apex
Є такі типи асинхронного Apex:
- Future — використовують для порівняно коротких callouts (до 60 секунд).
- Continuation — для тривалих callouts, доступний і для VisualForce, і віднедавна для Aura та LWC.
- Batch — дає змогу асинхронно обробляти великі обсяги даних, обійти Governor Limits.
- Queueable — як і Batch, застосовують для обробки великого обсягу даних. Головна перевага перед Batch — можливість викликати інший Queueable, тобто сформувати ланцюжок.
- Schedualble — дозволяє запускати код у певний час і з певним інтервалом.
Подійно-орієнтована архітектура
Для побудови Event-based архітектури застосовують Platform Events (publish-subscribe модель для взаємодії із зовнішніми застосунками, також використовують для винесення ресурсоємного функціонала), Change Data Capture Events (використовують для обробки змін записів), звичайні та асинхронні тригери.
Безпека і контроль доступу
У профайлі користувача можна надати або забрати доступ до Apex-класу. Як і багато
Коли ви оголошуєте клас, можете вказати ключові слова: with sharing (усіх sharing rules, CRUD, FLS буде дотримано), without sharing (код матиме доступ до всіх записів і цілковитий доступ до CRUD і FLS), inherited (означає, що sharing mode класу залежатиме від sharing mode класу, який його викликав).
Приклад оголошення класу:
public inherited class AccountService {}
Веб та Email-сервіси
За допомогою Apex можна розробити повноцінні SOAP, REST-based Web та Email-сервіси. Наприклад, для параметрів і значень, що повертаються, Apex REST підтримує такі види даних:
- Примітиви Apex (виключаючи Object і Blob).
- SObjects.
- Списки або map примітивів Apex чи SObjects (підтримуються тільки map із текстовими ключами).
- Типи, що визначаються користувачем та містять змінні — члени вищеперерахованих типів.
Ви можете використовувати Email-сервіси для обробки вмісту, заголовків і вкладень вхідної електронної пошти. Наприклад, створити службу електронної пошти, яка автоматично створює записи контактів на основі контактної інформації у повідомленнях.
Юніт-тести
Код на Production-орзі не можна редагувати безпосередньо, тому принцип «раз-раз і в продакшен» тут не спрацює. Код пишеться й тестується, наприклад, на Sandbox, а на Production він лише деплоїться. До того ж весь код на Production має бути покритим юніт-тестами не менше ніж на 75% та не валитися при розгортанні, принаймні локальні тести мають працювати без помилок. Для деплойменту Sandbox => Sandbox таких вимог немає.
Налагодження
Для налагодження Apex-коду існують Debug Logs з різними рівнями логування. Можна створити Traced Flags для: 1) автоматизованого процесу; 2) Platform Integration; 3) конкретного користувача; 4) Apex-класу; 5) Apex-тригера. У коді для кращого налагодження варто ставити breakpoints.
Apex-тригери
Є можливість створювати before та after тригери для наступних
Зазвичай весь код із тригерів виносять в окремі handler-класи, а код, який можна перевикористати, у service-класи. Хоча підходів і тригер-фреймворків дуже багато.
Для розвантаження тригерів використовують асинхронні тригери, які виконуються після завершення транзакції. Щоб задеплоїти Apex-тригер на Production, потрібно хоча б один рядок його коду покрити юніт-тестом.
Кожен Salesforce-розробник має пам’ятати про Order of execution. Оскільки під час
Замість висновку
Компанія, заснована незадовго до краху доткомів, не лише гідно пройшла це випробування, але, продемонструвавши новаторський підхід до CRM, закріпилася на позиції лідера. Salesforce давно перестала бути просто системою для управління відносинами з клієнтами: вона обросла рішеннями для багатьох галузей, розробленими всередині або сторонніми компаніями. Прямим конкурентам залишається тільки мріяти про те, щоб потіснити Salesforce, а авторитетні аналітики прогнозують подальше зростання компанії.
Навіть порівняно висока ціна продуктів Salesforce не відлякує клієнтів, здебільшого середній і великий бізнес. Водночас існують рішення і для зовсім невеликих компаній. Втім, обмеження тут теж є, і я точно не стану переконувати вас, що Salesforce обов’язково буде цікавою для вас. Докладніше про те, кому, найімовірніше, варто придивитися до CRM та іншої Salesforce-інфраструктури, поговоримо у другій частині статті. Також йтиметься про фронтенд і розгортання у Salesforce, вбудовані засоби декларативного програмування, процес і середовища розробки. У підсумку обіцяю поділитися списком літератури для розробників і адміністраторів, корисними посиланнями та розширеннями для Сhrome.
Продовження огляду — у наступній частині. Скоро на DOU :)
