В первой части мы создали протопип нашего класса, использующего флоу в качестве расширения функциональности апекс кода.
3. Два флоу - не один флоу (ц)
Внесем некоторые изменения: для того, чтобы добиться большей гибкости общей реализации и для того, чтобы пример стал несколько более приближенным к реальной ситуации. Для начала, изменим наш первый флоу таким образом, чтобы он “пропускал” в коллекцию возвращаемых значений только те записи Case, у которых поле Subject начинается со слова Test:
А также создадим еще один дополнительный флоу, но во втором случае пусть все записи фильтруются по наличию первого слова Check:
Имя первого флоу - FilterFlow, имя нового флоу (проверяющего слово Сheck) - OneMoreFilterFlow:
Желательно подготовить набор тестовых данных, такой, чтобы в нем каждый флоу нашел для себя что-нибудь полезное.
4. Кастуем - Custom metadata type
Создадим custom metadata type для того, чтобы вынести все наши настройки уровня апекс кода на уровень настроек Setup.
Для этого был создан custom metadata type FlowProcess с соответствующими кастомными полями,
где:
- Flow API name - имя API нашего флоу, т.е. имя в том виде, в котором оно будет использоваться в апексе
- InputListName - имя API входящей переменной (то, как переменная коллекции названа в флоу)
- OutputListName - имя API возвращаемого значения (то, как переменная возвращаемой коллекции названа в флоу)
И, конечно, мы добавляем соответствующие записи, описывающие каждый из наших флоу в созданном нами custom metadata type:
Поскольку теперь почти все готово - можем непосредственно перейти к коду. Вот как может изменится наш класс, если мы учтем все привнесенные через Setup изменения:
Попробуем использовать созданное решение с каждым из созданных ранее флоу. В класс будем передавать алиас (MasterLabel), закрепленный в нашем описании флоу в соответствующей записи custom metadata type, а не имя самого флоу. Подобный подход может в будущем позволить нам (в реальной практической ситуации) использовать один и тот же флоу, но с разными настройками, столько, сколько это будет нам необходимо. Собственно, анонимус код тестового запуска и вывод в дебаг-лог для первого флоу:
И для второго:
В итоге:
мы вынесли всю настройку поведения части функциональности апекс кода в автоматизированные нативные для SF инструменты и предоставили возможность админу на стороне клиента изменять используемое расширение кликами, - без какой-либо необходимости что-то менять в самом коде.
Естественно, полученное решение не является конечным и идеальным, а скорее рамочным и базовым. В дальнейшем, неплохо бы было развить систему Exceptions на уровне класса, а также добавить еще несколько custom metadata type, для хранения настроек “системы расширений” в целом. Также как и менеджер-класс, который бы осуществлял подстановку соответствующих флоу в соответствующие расширяемые модули и классы, и много чего другого, вплоть до логирования (и эффекта конфетти!).
Независимо от того, будете ли вы использовать подобный подход в своих проектах или нет, никогда не забывайте о клиенте.
Have fun!