Как работает этот Apex класс?

Вот в этом видео объясняется, как вызывать Apex класс в Integration Procedure of OmniStudio.

https://www.youtube.com/watch?v=n9xUQYE1Yz4

и вроде все просто: нужно реализовать один интерфейсный метод, которые будет вызываться в Integration Procedure и возвращает он просто Булеан. Но в этом то и проблема, если возвращается только булеан, то как Integration Procedure получает результат работы самого класса: саму информацию.

У меня только один вариант: в этот метод аргументом присовывается Map<String, Object> output, куда и нужно загружать инфу. Но эта Мапа никуда не возвращается! Но так как она reference type, то к ней все еще есть доступ "из вне", из вызывающего метод кода. И таким образом эта инфа и вытягивается. И если моя логика верна, то получается, что для того, чтобы что-то получить из такого интерфейсного метода, вовсе не обязательно, чтобы он это явно возвращал.

Я никогда об этом не думал

Den Brown

Вот в этом видео объясняется, как вызывать Apex класс в Integration Procedure of OmniStudio.

https://www.youtube.com/watch?v=n9xUQYE1Yz4

и вроде все просто: нужно реализовать один интерфейсный метод, которые будет вызываться в Integration Procedure и возвращает он просто Булеан. Но в этом то и проблема, если возвращается только булеан, то как Integration Procedure получает результат работы самого класса: саму информацию.

У меня только один вариант: в этот метод аргументом присовывается Map<String, Object> output, куда и нужно загружать инфу. Но эта Мапа никуда не возвращается! Но так как она reference type, то к ней все еще есть доступ "из вне", из вызывающего метод кода. И таким образом эта инфа и вытягивается. И если моя логика верна, то получается, что для того, чтобы что-то получить из такого интерфейсного метода, вовсе не обязательно, чтобы он это явно возвращал.

Я никогда об этом не думал

Den Brown

У меня только один вариант: в этот метод аргументом присовывается Map<String, Object> output, куда и нужно загружать инфу

Так и работает

wilder

[quote="Den Brown"]У меня только один вариант: в этот метод аргументом присовывается Map<String, Object> output, куда и нужно загружать инфу[/quote]

Так и работает

Den Brown

У меня только один вариант: в этот метод аргументом присовывается Map<String, Object> output, куда и нужно загружать инфу. Но эта Мапа никуда не возвращается! Но так как она reference type, то к ней все еще есть доступ "из вне", из вызывающего метод кода.

Ну так все правильно. Модифицируется передаваемый в функцию параметр (output мапа) и после работы метода output будет содержать нужные значения. Ни разу не пользовался таким способом? Так же работает обычный триггер. Когда ты модифицируешь записи внутри Trigger.new. Ты же его никуда не возвращаешь. Он просто меняет твое состояние. Правильно отметил в метод ты передеаешь не сам объект а ссылку на него. Так что до метода, внутри метода и после него это тот же самый объект.
Я не любитель бест практис феншуя, поэтому часто использую методы static void которые на вход принимают объект и что-то с ним делают. Конкретно так с объектом output как в видео не работал, но идея мне нравится!

Dmitry Shnyrev

[quote="Den Brown"]У меня только один вариант: в этот метод аргументом присовывается Map<String, Object> output, куда и нужно загружать инфу. Но эта Мапа никуда не возвращается! Но так как она reference type, то к ней все еще есть доступ "из вне", из вызывающего метод кода.[/quote]
Ну так все правильно. Модифицируется передаваемый в функцию параметр (output мапа) и после работы метода output будет содержать нужные значения. Ни разу не пользовался таким способом? Так же работает обычный триггер. Когда ты модифицируешь записи внутри Trigger.new. Ты же его никуда не возвращаешь. Он просто меняет твое состояние. Правильно отметил в метод ты передеаешь не сам объект а ссылку на него. Так что до метода, внутри метода и после него это тот же самый объект. 
Я не любитель бест практис феншуя, поэтому часто использую методы static void которые на вход принимают объект и что-то с ним делают. Конкретно так с объектом output как в видео не работал, но идея мне нравится!

Dmitry Shnyrev

Конкретно так с объектом output как в видео не работал, но идея мне нравится!

так работают большинство dispatchers, которые я видел и писал. И один глобальный try catch

wilder

[quote="Dmitry Shnyrev"]Конкретно так с объектом output как в видео не работал, но идея мне нравится![/quote]

так работают большинство dispatchers,  которые я видел и писал. И один глобальный try catch

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

Den Brown

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

интересно как ты раньше работал без этого

это чистый пример side effect и в сэйлсфорсе без этого трудно
https://en.wikipedia.org/wiki/Side_effect_(computer_science)

Андрей

интересно как ты раньше работал без этого

это чистый пример side effect и в сэйлсфорсе без этого трудно
[url=https://en.wikipedia.org/wiki/Side_effect_(computer_science)]https://en.wikipedia.org/wiki/Side_effect_(computer_science)
[/url]

Андрей

это чистый пример side effect

сталкивался с этим в JS, когда там это приводилось в качестве примера неявного и очень нежелательного изменения объекта, для решения чего нужно было "коллапснуть" оригинальный объект в новый объект.

то есть это был как бы плохой сценарий. а здесь этот "side effect" лихо используется как вполне себе мейнстримный подход.

не использовал его раньше, т.к. что есть АПЕКС код в обычном орге? это просто какой то скрипт на пару-тройку сотню строк, в котором редко бывают такие навороченные ситуации.

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

Den Brown

[quote="Андрей"]это чистый пример side effect[/quote]

сталкивался с этим в JS, когда там это приводилось в качестве примера неявного и очень нежелательного изменения объекта, для решения чего нужно было "коллапснуть" оригинальный объект в новый объект.

то есть это был как бы плохой сценарий. а здесь этот "side effect" лихо используется как вполне себе мейнстримный подход.

не использовал его раньше, т.к. что есть АПЕКС код в обычном орге? это просто какой то скрипт на пару-тройку сотню строк, в котором редко бывают такие навороченные ситуации.

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