Кастомизация апекса на стороне клиента (ч.2)

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

3. Два флоу - не один флоу (ц)

Внесем некоторые изменения: для того, чтобы добиться большей гибкости общей реализации и для того, чтобы пример стал несколько более приближенным к реальной ситуации. Для начала, изменим наш первый флоу таким образом, чтобы он “пропускал” в коллекцию возвращаемых значений только те записи Case, у которых поле Subject начинается со слова Test:

flowRef-2

А также создадим еще один дополнительный флоу, но во втором случае пусть все записи фильтруются по наличию первого слова Check:

flowRef-2-1

Имя первого флоу - FilterFlow, имя нового флоу (проверяющего слово Сheck) - OneMoreFilterFlow:

flowRef-2-2

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

4. Кастуем - Custom metadata type

Создадим custom metadata type для того, чтобы вынести все наши настройки уровня апекс кода на уровень настроек Setup.

Для этого был создан custom metadata type FlowProcess с соответствующими кастомными полями,

flowRef-2-4

где:

  • Flow API name - имя API нашего флоу, т.е. имя в том виде, в котором оно будет использоваться в апексе
  • InputListName - имя API входящей переменной (то, как переменная коллекции названа в флоу)
  • OutputListName - имя API возвращаемого значения (то, как переменная возвращаемой коллекции названа в флоу)

И, конечно, мы добавляем соответствующие записи, описывающие каждый из наших флоу в созданном нами custom metadata type:

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

flowRef-2-6

Попробуем использовать созданное решение с каждым из созданных ранее флоу. В класс будем передавать алиас (MasterLabel), закрепленный в нашем описании флоу в соответствующей записи custom metadata type, а не имя самого флоу. Подобный подход может в будущем позволить нам (в реальной практической ситуации) использовать один и тот же флоу, но с разными настройками, столько, сколько это будет нам необходимо. Собственно, анонимус код тестового запуска и вывод в дебаг-лог для первого флоу:

flowRef-2-7

flowRef-2-8

И для второго:

flowRef-2-9

flowRef-2-99

В итоге:

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

Естественно, полученное решение не является конечным и идеальным, а скорее рамочным и базовым. В дальнейшем, неплохо бы было развить систему Exceptions на уровне класса, а также добавить еще несколько custom metadata type, для хранения настроек “системы расширений” в целом. Также как и менеджер-класс, который бы осуществлял подстановку соответствующих флоу в соответствующие расширяемые модули и классы, и много чего другого, вплоть до логирования (и эффекта конфетти!).

Независимо от того, будете ли вы использовать подобный подход в своих проектах или нет, никогда не забывайте о клиенте.
Have fun!

1 Like