ALL_OR_NONE_OPERATION_ROLLED_BACK in Salesforce-Deployments beheben

Ein einziger fehlerhafter Datensatz in einem mit allOrNone=true übermittelten Batch machte alle Datensätze dieses Batches rückgängig, auch die gültigen.

Tritt auf bei: Massen-DML-Operationen, Datenladevorgängen und Apex-Testsetup

Was das bedeutet

ALL_OR_NONE_OPERATION_ROLLED_BACK bedeutet, dass eine DML-Operation mit allOrNone auf true übermittelt wurde und mindestens ein Datensatz im Batch die Validierung nicht bestand, sodass Salesforce den gesamten Batch rückgängig machte, statt die einzeln gültigen Datensätze zu übernehmen. Das ist das erwartete Verhalten von allOrNone, kein Fehler, kann bei großen Batches aber teuer werden.

Es tritt überall auf, wo Massen-DML läuft: ein Database.insert(records, true)-Aufruf in Apex, ein Bulk-API-Job mit aktivierter allOrNone-Option, oder eine Data-Loader-Sitzung mit deaktiviertem "Insert null values" und deaktiviertem Teilerfolg. Eine einzige fehlerhafte Zeile irgendwo im Batch reißt die gesamte Transaktion mit sich.

Diagnose

Häufige Ursachen

Ein Datensatz in einem großen Batch besteht die Validierung nicht
Ein falscher Auswahllistenwert, ein fehlendes Pflichtfeld oder eine fehlgeschlagene Validierungsregel bei einem einzigen Datensatz macht den gesamten allOrNone-Batch ungültig.
Gemischte Datensatztypen wurden nicht vorab validiert
Ein Batch mischt Datensätze aus unterschiedlichen Quellen oder Formen, ohne jeden zuvor gegen die Validierungsregeln des Objekts zu prüfen.
Batches wurden nicht in Blöcke aufgeteilt
Der Datenschritt eines großen Deployments übermittelt einen einzigen sehr großen Batch, statt ihn in kleinere, fehlerisolierte Blöcke aufzuteilen.

Die Lösung

  1. Datensätze clientseitig vor der Übermittlung validieren
    Prüfen Sie offensichtliche Fehlerbedingungen, Pflichtfelder, Auswahllistenwerte, gegen die Regeln des Objekts, bevor Sie den Batch senden.
  2. allOrNone=false während Migrationsläufen setzen
    Führen Sie Migrationen mit allOrNone=false aus, damit einzelne Fehlschläge den Rest des Batches nicht blockieren, und überprüfen und korrigieren Sie anschließend die fehlgeschlagenen Datensätze.
  3. Große Batches in kleinere Gruppen aufteilen
    Teilen Sie eine große Datenoperation in kleinere Batches auf, sodass ein einzelner fehlerhafter Datensatz nur einen kleinen Teil der Gesamtladung betrifft.
    List<SObject> chunk = new List<SObject>();
    for (Integer i = 0; i < records.size(); i++) {
        chunk.add(records[i]);
        if (chunk.size() == 200 || i == records.size() - 1) {
            Database.insert(chunk, false);
            chunk.clear();
        }
    }
In der Praxis

Wie Serpent das verhindert

Die Datenoperationen von Serpent werden im Rahmen der Pipeline in Blöcke aufgeteilt und validiert, sodass ein einzelner fehlerhafter Datensatz in einer Migration früh an einem kleinen Batch auffällt, statt einen großen Batch tief in einem Deployment zurückzurollen. Siehe die Bibliothek der Salesforce-Deploymentfehler.

Release-Dashboard mit Konfliktwarnungen in Serpent

Prävention

Standardmäßig allOrNone=false für Massenladevorgänge verwenden
Behandeln Sie allOrNone=true als Ausnahme für Fälle, in denen Teilerfolg wirklich inakzeptabel ist, nicht als Standard für jeden Batch-Job.
Vor der Übermittlung vorab validieren
Lassen Sie eingehende Datensätze eine leichte Schemaprüfung durchlaufen, Pflichtfelder, Auswahllistenwerte, bevor sie überhaupt den DML-Aufruf erreichen.
Migrationen von Anfang an mit fester Blockgröße gestalten
Bauen Sie Datenladevorgänge so, dass sie von Beginn an in Blöcken fester Größe, 200 bis 2.000 Datensätze, übermittelt werden, statt die Aufteilung erst nach einem Fehlschlag nachzurüsten.
Häufige Fragen

ALL_OR_NONE_OPERATION_ROLLED_BACK, erklärt

Ist allOrNone immer die falsche Einstellung?
Nein. Es ist die richtige Wahl, wenn Teilerfolg inakzeptabel ist, etwa bei einer Reihe von Finanzdatensätzen, die gemeinsam gebucht werden müssen; es ist nur teuer, wenn es auf große, locker validierte Batches angewendet wird.
Macht allOrNone=true auch Nebeneffekte von Apex-Triggern rückgängig?
Ja. Salesforce macht die gesamte Transaktion rückgängig, einschließlich jeder DML, die ein Trigger auf anderen Objekten ausgeführt hat, nicht nur die direkt übermittelten Datensätze.
Wie finde ich heraus, welcher konkrete Datensatz in einem großen Batch fehlgeschlagen ist?
Das SaveResult-Array (oder das Bulk-API-Jobergebnis) enthält einen Eintrag pro übermitteltem Datensatz, jeweils mit eigenem Erfolgs-Flag und Fehlerliste; durchlaufen Sie es, um den Fehlschlag zu isolieren.

Kostenlos starten. Keine Kreditkarte, keine Installation, keine Verpflichtung.

In unter 15 Minuten eingerichtet. Keine DevOps-Einstellung nötig.

Neugierig auf schnelleres Shipping, bevor Sie einsteigen? Sprechen wir

Unverbindlich.