если я правильно это помню, нельзя делать новый асинхронный вызов из асинхронного метода (за исключение специально для этого предназначенного 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 не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам!
Запилить отключение триггеров, фловов и валидейшенов для отпределенного пользователя :)
[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
Ну извините, что данные в систему должны проходить отбор. Не бизнес должен подстраиваться под программера, а прогарммер делать то, что нужно бизнесу.
Ищи записи, не проходящие проверки, и пиши клиенту вопрос - "что с ними делать?". Все достаточно просто. Код здесь ни при чем ;-)
[quote="Dmitry Shnyrev"]PS. Наболело - просто тема как раз в последние два дня актуальная - пришла задача сделать импорт данных. Данные нельзя импортировать потому что бля 2 триггера и 1 flow и 1 validation rule не дают. Править проверки нельзя, но импортировать надо. Вот и ебись как хочешь! Низкий поклон тем программистам![/quote] Ну извините, что данные в систему должны проходить отбор. Не бизнес должен подстраиваться под программера, а прогарммер делать то, что нужно бизнесу. Ищи записи, не проходящие проверки, и пиши клиенту вопрос - "что с ними делать?". Все достаточно просто. Код здесь ни при чем ;-)
вот это нормальный ответ, я так и полагал, иначе было бы невозможно использовать асинхронные вызовы вообще, так как в большом приложении далеко не всегда понятно, куда этот вызов приведет цепочку последующих событий и нет ли там другого асинхронного вызова
[quote="Andrii Muzychuk"]https://salesforce.stackexchange.com/questions/204896/calling-async-from-async-process Нет правила "нельзя вызвать асинзрон из асинхрон", но есть правила "нельзя вызывать асинхронный метод (@future) из асинхронного метода". [/quote] вот это нормальный ответ, я так и полагал, иначе было бы невозможно использовать асинхронные вызовы вообще, так как в большом приложении далеко не всегда понятно, куда этот вызов приведет цепочку последующих событий и нет ли там другого асинхронного вызова