SAP Processes and Forms. Применение нескольких backend сервисов в одном FPM процессе
Давно мы не погружались в словесные перипетии о славном инструменте SAP Processes and Forms, заметочки о котором я имею обыкновение периодически тут публиковать. Было уже и про потоки операций, и про создание FPM процесса с нуля, и про создание backend сервисов тоже. В этой заметке я буду распространяться о том, как возможно применение нескольких backend сервисов в одном FPM процессе, и возможно ли оно вообще.
Для начала
Если эта заметка, по каким-то причинам, попалась вам под руку в качестве самой первой, по функциональности Processes and Forms, то я настоятельно рекомендую изучить справочное руководство от вендора
Затем, при необходимости, можно ознакомиться с циклом заметок по этой же функциональности, приготовленных с любовью вашим покорным слугой
См. заметки по функциональности SAP Processes and Forms
О чем эта заметка?
Как уже упомянуто выше, далее я хочу разглагольствовать на предмет использования двух backend сервисов в одном FPM процессе. Основное применение такого подхода может быть востребовано в случае, когда процесс один, а условий его проверок несколько. Под условиями я понимаю правила проверки полей, а также правил обработки/отображения этих полей в процессе. Актуальность принимает данный сценарий, когда один и тот же процесс используется работниками из разных стран. Скажем, по значению параметра molga вам нужно выполнить вызов разных backend сервисов, abap код которых любезно разнесен по разным реализующим классам вашим программистом.
Задача
Для одного процесса реализовать вызов двух разных backend сервисов.
Исходные данные
У меня есть FPM процесс с двумя текстовыми полями
См. заметку SAP Processes and Forms based on FPM Forms
А также два backend сервиса
См. заметку Создание собственного backend-сервиса для процесса Processes and Forms
Добавление backend сервиса в процесс
Добавьте новый backend сервис для своего процесса через транзакцию HRASR_DT
Создание правила выбора backend сервиса
Находясь в транзакции HRASR_DT, перейдите на узел "Rules"
Use
You use this function to create rules that you can use to control whether a back-end service is called or whether a specific operation of this service is called.Features
Rules are based on form fields and return “true” or “false” as a result at runtime, depending on the input values. The back-end service or operation is called only if the result of the rule is "true" at runtime.
Создайте новое правило для процесса, в случае выполнения которого (то есть результат его должен быть равен логическому true) произойдет вызов дополнительного backend сервиса.
Для демонстрации в заметке, я воспользуюсь простым условием: если значение поля TEST_FIELD2 моего FPM процесса принимает значение UK, должен быть вызван нужный мне сервис.
Присвоение нового правила соответствующему backend сервису
Присвойте вновь созданное правило для сервиса, который должен будет вызван по определенному вами условию. Транзакция все та же: HRASR_DT
Тестирование
Итак, в моем процессе используется два поля (TEST_FIELD1 и _TEST_FIELD2). _Как описано выше, в процессе наличествует два backend сервиса. В обоих сервисах задействован метод DO_OPERATIONS их реализующего класса, с помощью которого выполняется проверка заполнения полей процесса. В одном из них (пусть это будет первый сервис) осуществляется проверка на заполнение обоих полей
В другом (пусть это будет второй сервис), выполняется проверка значения, введенное пользователем в поле TEST_FIELD2
Тестирование. Кейс 1
Проверяю, что выполняется вызов первого сервиса (на заполненность всех полей процесса)
Тестирование. Кейс 2
Проверяю, что для условия TEST_FIELD2 = UK будет вызван второй backend сервис процесса
Вызов двух разных реализующих классов одного процесса в зависимости от разных условий выполнен корректно.
Обнимаю. Ваш, ignatov.