Декларативное программирование в Salesforce — сила «кликов, а не кода»

В этой статье мы объясним, как вы можете программировать, не зная языка программирования, с помощью Salesforce «Clicks Not Code» в их инструменте Lightning Flow Builder.

На дворе 1998 год, вы сидите в своей кабинке, и ваш коллега говорит, что ему поручили разработать автоматизированную систему, которая сканирует оперативные данные и разумно обрабатывает их. Он говорит вам, что собирается сделать все это, не написав ни строчки кода. Вы бы назвали его сумасшедшим и потребовали бы его отставки. Перепрыгните на 10 лет вперед, в 2008 год, и вы, вероятно, подойдете к этому так же.

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

Благодаря быстрому развитию таких инструментов, как RPA и AI, эти типы подходов становятся все более распространенными, однако Salesforce уже довольно давно является бастионом в авангарде того, что они называют декларативным программированием.

Их тег «Clicks Not Code» был тем, что я полностью протестировал недавно, и он оказался успешным и надежным подходом к разработке.

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

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

Поймите влияние

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

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

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

  • Какие системные ограничения нам необходимо соблюдать?
  • Каков порядок исполнения?
  • С каким объемом данных я буду работать?
  • Будет ли это влиять на другие процессы?

Построить путь развития

Хотя создание чего-то в конструкторе процессов довольно просто, это потому, что конструктор процессов не может достичь той же сложности, что и Flow. Flow может использовать сложные переменные, создавать списки и карты и циклически перебирать наборы, чтобы определить, какому дереву решений следовать. Все эти действия являются терминами, с которыми разработчик знаком.

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

Оставайтесь организованными

Оставаться организованным крайне необходимо. Точно так же, как разработчик комментирует примечания и детали, чтобы объяснить, что делают вещи, обязательно добавляйте описания к своим элементам Flow. Когда у вас в потоке 100 или более элементов, может быть сложно уследить за всем или вернуться к чему-то через 3 недели и вспомнить, для чего оно было использовано.

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

За и против

Хотя Flow и другие методы «Clicks Not Code» могут охватывать многие области, которые разработчики обычно охватывают в Salesforce, существуют некоторые ограничения. Но есть и некоторые преимущества. Каждый сценарий должен быть оценен для определения наилучшего подхода. Продолжайте расширять эту тему в следующем блоге, где мы углубимся в оценку того, когда следует использовать декларативное и традиционное программирование в Salesforce.

Хотите узнать больше о модернизации систем?

Ознакомьтесь с дополнительной информацией и опытом на smartbridge.com/modernization/insights-impact/

Продолжайте читать: Извлеченные уроки Salesforce: сообщества самообслуживания и интеграция NetSuite

Первоначально опубликовано на https://smartbridge.com 27 августа 2019 г.