Регистрация  |  Вход

Можно ли делать асинхронный вызов из асинхронного контекста?

если я правильно это помню, нельзя делать новый асинхронный вызов из асинхронного метода (за исключение специально для этого предназначенного Queueable асинхронного класса).

поправьте меня, если я ошибаюсь

а как насчет такой ситуации:
(1) ВФ страница запускает асинхронный процесс (цепочку Queueable вызовов), в конце каждого происходит апсерт записей;
(2) ДМЛ операция записей провоцирует тригер на объекте;
(3) Тот, в свою очередь, отстреливает бизнес-логику в асинхронный процесс.

Нельзя сказать, что это какая-то необычная ситуация (кроме того, сам тригер может и должен сработать при обычном апдейте записи через стандартный интерфейс).

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

Ну так вот, получится ли сделать новый асинхронный вызов из текущего асинхронного контекста?

разумеется, в тригере можно делать проверку, вроде такой:

public static Boolean isAsync() { 
return System.isBatch() || System.isQueueable() || System.isScheduled() || System.isFuture();
}

и запускать то синхронный, то асинхронный метод,

но все же вопрос, нужно ли об этом вообще париться

если я правильно это помню, нельзя делать новый асинхронный вызов из асинхронного метода (за исключение специально для этого предназначенного Queueable асинхронного класса).

поправьте меня, если я ошибаюсь

а как насчет такой ситуации:
(1) ВФ страница запускает асинхронный процесс (цепочку Queueable вызовов), в конце каждого происходит апсерт записей;
(2) ДМЛ операция записей провоцирует  тригер на объекте;
(3) Тот, в свою очередь, отстреливает бизнес-логику в асинхронный процесс.

Нельзя сказать, что это какая-то необычная ситуация (кроме того, сам тригер может и должен сработать при обычном апдейте записи через стандартный интерфейс).

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

Ну так вот, получится  ли сделать новый асинхронный вызов из текущего асинхронного контекста?

разумеется, в тригере можно делать проверку, вроде такой:
[code]public static Boolean isAsync() { 
     return System.isBatch() || System.isQueueable() || System.isScheduled() || System.isFuture();
}[/code]

и запускать то синхронный, то асинхронный метод,

но все же вопрос, нужно ли об этом вообще париться

Ой как плохо злоупотреблять триггерами!!! Ну зачем пихать в триггер вызов асинхронных методов? Сами же себе ставите палки в колеса. Триггер может стартануть откуда угодно. А потом половина программистов плюются потому что у них не работает простая логика из-за корявых триггеров, а те кто программирую триггеры потом городят огороды чтобы ити триггеры закостылить чтобы они работали в любых контекстах. Что мешает вызвать асинхронный метод не в триггере, а после триггера (после DML операции)? В триггере оставить примитивную логику, а сложные тяжелые расчеты запускать отдельно при необходимости.

Я бы вообще за TDD (Trigger-driven development) по рукам бил бы!!! Слава богу в других языках и платформах триггеры вообще не используют или используют крайне редко.

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

PS. Наболело - просто тема как раз в последние два дня актуальная - пришла задача сделать импорт данных. Данные нельзя импортировать потому что бля 2 триггера и 1 flow и 1 validation rule не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам!

Ой как плохо злоупотреблять триггерами!!! Ну зачем пихать в триггер вызов асинхронных методов? Сами же себе ставите палки в колеса. Триггер может стартануть откуда угодно. А потом половина программистов плюются потому что у них не работает простая логика из-за корявых триггеров, а те кто программирую триггеры потом городят огороды чтобы ити триггеры закостылить чтобы они работали в любых контекстах. Что мешает вызвать асинхронный метод не в триггере, а после триггера (после DML операции)? В триггере оставить примитивную логику, а сложные тяжелые расчеты запускать отдельно при необходимости.

Я бы вообще за TDD (Trigger-driven development) по рукам бил бы!!! Слава богу в других языках и платформах триггеры вообще не используют или используют крайне редко.

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

PS. Наболело - просто тема как раз в последние два дня актуальная - пришла задача сделать импорт данных. Данные нельзя импортировать потому что бля 2 триггера и 1 flow и 1 validation rule не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам!

Dmitry Shnyrev
PS. Наболело - просто тема как раз в последние два дня актуальная - пришла задача сделать импорт данных. Данные нельзя импортировать потому что бля 2 триггера и 1 flow и 1 validation rule не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам!

Запилить отключение триггеров, фловов и валидейшенов для отпределенного пользователя :)

[quote="Dmitry Shnyrev"]PS. Наболело - просто тема как раз в последние два дня актуальная - пришла задача сделать импорт данных. Данные нельзя импортировать потому что бля 2 триггера и 1 flow и 1 validation rule не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам![/quote]
Запилить отключение триггеров, фловов и валидейшенов для отпределенного пользователя :)

Конечно это решение, только "нельзя трогать клиентский код"
Еще идеи?

Конечно это решение, только "нельзя трогать клиентский код" :D 
Еще идеи?

Я парюсь.
Ибо логики много, и не вся она нужна сразу после создания/редактировании записи.
Все что нужно отобразить пользователю сейчас - синхронно. Все, что на другие записи - асинхронно.
Ну да, запарка с интеграционными тестами (надо делать проверку после Test.stopTest()). Ну что ж поделаешь, все в синхронное либо не лезет, либо очень долго.

Можно ли делать асинхронный вызов из асинхронного контекста?

https://salesforce.stackexchange.com/questions/204896/calling-async-from-async-process

Нет правила "нельзя вызвать асинзрон из асинхрон", но есть правила "нельзя вызывать асинхронный метод (@future) из асинхронного метода".
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_invoking_future_methods.htm

Я парюсь.
Ибо логики много, и не вся она нужна сразу после создания/редактировании записи.
Все что нужно отобразить пользователю сейчас - синхронно. Все, что на другие записи - асинхронно.
Ну да, запарка с интеграционными тестами (надо делать проверку после Test.stopTest()). Ну что ж поделаешь, все в синхронное либо не лезет, либо очень долго.  
  
[quote]Можно ли делать асинхронный вызов из асинхронного контекста?[/quote]
https://salesforce.stackexchange.com/questions/204896/calling-async-from-async-process  

Нет правила "нельзя вызвать асинзрон из асинхрон", но есть правила "нельзя вызывать асинхронный метод (@future) из асинхронного метода".
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_invoking_future_methods.htm

Dmitry Shnyrev
PS. Наболело - просто тема как раз в последние два дня актуальная - пришла задача сделать импорт данных. Данные нельзя импортировать потому что бля 2 триггера и 1 flow и 1 validation rule не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам!

Ну извините, что данные в систему должны проходить отбор. Не бизнес должен подстраиваться под программера, а прогарммер делать то, что нужно бизнесу.
Ищи записи, не проходящие проверки, и пиши клиенту вопрос - "что с ними делать?". Все достаточно просто. Код здесь ни при чем ;-)

[quote="Dmitry Shnyrev"]PS. Наболело - просто тема как раз в последние два дня актуальная - пришла задача сделать импорт данных. Данные нельзя импортировать потому что бля 2 триггера и 1 flow и 1 validation rule не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам![/quote]
Ну извините, что данные в систему должны проходить отбор. Не бизнес должен подстраиваться под программера, а прогарммер делать то, что нужно бизнесу.
Ищи записи, не проходящие проверки, и пиши клиенту вопрос - "что с ними делать?". Все достаточно просто. Код здесь ни при чем ;-)

Andrii Muzychuk
https://salesforce.stackexchange.com/questions/204896/calling-async-from-async-process
Нет правила "нельзя вызвать асинзрон из асинхрон", но есть правила "нельзя вызывать асинхронный метод (@future) из асинхронного метода".

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

[quote="Andrii Muzychuk"]https://salesforce.stackexchange.com/questions/204896/calling-async-from-async-process
Нет правила "нельзя вызвать асинзрон из асинхрон", но есть правила "нельзя вызывать асинхронный метод (@future) из асинхронного метода". [/quote]

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