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

Асинхронная обработка при превышении лимитов

Взялся упорядочить все триггеры одного объекта в один. Плюс, сообщения о подползающих лимитах за одну транзакцию.
Че я начал делать для операций, которые не очень критичны для синхронной обработки.

public static void method1(List<Opportunity> oppsToUpdate) {
if (oppsToUpdate == null || oppsToUpdate.size() == 0) return;

if (
Limits.getDMLStatements() > Limits.getLimitDMLStatements()/2
||
Limits.getQueries() > Limits.getLimitQueries()/2
) {
method1Async(new Map<Id, Opportunity>(oppsToUpdate).keySet());
} else {
method1Sync(oppsToUpdate);
}
}

public static void method1Sync(List<Opportunity> oppsToUpdate) {
// ...
}

@future
public static void method1Async(Set<Id> oppIdsToUpdate) {
List<Opportunity> oppsToUpdate = [
SELECT Id
FROM Opportunity
WHERE Id IN :oppIdsToUpdate
];
method1Sync(oppsToUpdate);
}

Понятное дело, лучше такого избегать, грамотно планируя триггеры. Но бывают моменты, когда есть еще какой-то код, логику которого надо разобрать, и на это пока нет времени. А такое решение помошает избежать проблем с лимитами и скоростью обработки работы с данными.
Такие "обертки" я делаю для логики, которая достаточно проста, но использует пару SOQL запросов, от которых я ну ни как не могу избавиться и куда-нить еще их приткнуть (например, сделать один SOQL, но птм в цикле вытащить данные для 2 массивов).

Взялся упорядочить все триггеры одного объекта в один. Плюс, сообщения о подползающих лимитах за одну транзакцию.
Че я начал делать для операций, которые не очень критичны для синхронной обработки.

[code]
  public static void method1(List<Opportunity> oppsToUpdate) {
    if (oppsToUpdate == null || oppsToUpdate.size() == 0) return;
    
    if (
      Limits.getDMLStatements() > Limits.getLimitDMLStatements()/2
      ||
      Limits.getQueries() > Limits.getLimitQueries()/2
    ) {
      method1Async(new Map<Id, Opportunity>(oppsToUpdate).keySet());
    } else {
      method1Sync(oppsToUpdate);
    }
  }
  
  public static void method1Sync(List<Opportunity> oppsToUpdate) {
    // ...
  }
  
  @future
  public static void method1Async(Set<Id> oppIdsToUpdate) {
    List<Opportunity> oppsToUpdate = [
      SELECT Id
      FROM Opportunity
      WHERE Id IN :oppIdsToUpdate
    ];
    method1Sync(oppsToUpdate);
  }
[/code]

Понятное дело, лучше такого избегать, грамотно планируя триггеры. Но бывают моменты, когда есть еще какой-то код, логику которого надо разобрать, и на это пока нет времени. А такое решение помошает избежать проблем с лимитами и скоростью обработки работы с данными.
Такие "обертки" я делаю для логики, которая достаточно проста, но использует пару SOQL запросов, от которых я ну ни как не могу избавиться и куда-нить еще их приткнуть (например, сделать один SOQL, но птм в цикле вытащить данные для 2 массивов).

Норм, почему нет?
Можно еще посмотреть в сторону https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm

Типа как future для продвинутых пограммистов )

Норм, почему нет? 
Можно еще посмотреть в сторону https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm

Типа как future для продвинутых пограммистов )