17 AprMeine TOP 3: So bringe ich meine Salesforce-Umgebung zum Stillstand – und wie man es wieder behebt

Immer wieder bin ich in der Vergangenheit über die gleichen Klassiker gestolpert mit denen ein Admin zielsicher die Salesforce-Umgebung seiner Firma zum Stillstand bringen kann. Anlass dieses Blog-Artikels war eine spannende Unterhaltung auf dem Salesforce-User-Treffen in München vergangenen Montag.
Ihr fragt Euch, wie man mal eben seine Salesforce-Umgebung zum Stillstand bekommt, wo das doch so stabil läuft?
Hier kommen meine TOP 3

TOP 1 – Validierungsregeln
Eine wunderbare Sache, denn sie stellen sicher, dass Datensätze oder Felder bestimmte Kriterien erfüllen müssen bevor sie gespeichert werden. Ein Anwendungsfall ist beispielsweise der, dass ein Rabatt nie größer als 100% sein darf, oder eine Mailadresse immer ein @ Zeichen und einen Punkt enthalten muss.
Validierungsregeln werden immer ausgeführt – auch wenn ein Feld gar nicht im Layout ist. Und genau so produziert man Probleme: Bei jeglichen Speichern gibt es eine Fehlermeldung, aber der Anwender hat keine Chance die Daten richtig einzugeben.
Wenn möglich in einer 1:1 Kopie der Produktionsumgebung (eine sog. Full Sandbox) einmal alle (!) Datensätze über die API speichern, eh man die Validierungsregel in der Produktion aktiviert. Und die Regeln nicht in der Produktion bauen, sondern in einer Testumgebung und dann in die Produktion überspielen (siehe auch TOP 3)

TOP 2 – Pflichtfelder im Layout
Auch sehr beliebt ist es Pflichtfelder zu definieren, die ab sofort von jedem immer ausgefüllt werden müssen.
Oft wird dabei vergessen, dass es dabei zu 2 Problemen kommen kann: Bei Änderungen an bestehenden Datensätzen und bei Routinen, die im Hintergrund laufen (z.B. bei nächtlichen Batch-Läufen).
Vergesst bitte die bestehenden Datensätze nicht. Am besten findet Ihr das über einen Bericht oder ein Dashboard heraus wie gut die Pflichtfelder in der Vergangenheit gefüllt wurden. In der Praxis müssen die Daten im Systen oft erst bereinigt bzw. befüllt werden, eh man bestehende Felder zum Pflichtfeld ernennt.
Auch hier ist es mehr als hilfreich wenn man in der Full Sandbox alle Datensätze einmal speichert. Wenn keine Full Sandbox vorhanden ist, kann man das auch in der Produktion machen… KANN!
… Dann sollte dann nämlich wissen, ob das eventuell Workflows aktiviert, oder die Felder “zuletzt gespeichert durch / am” an irgendeiner Stelle benötigt werden. Im Zweifelsfall lieber etwas mehr Zeit in Berichte und Dashboards investieren anstatt sich in Teufels Küche zu begeben.

3. Keine ausreichende Testabdeckung
Um das zu verstehen, muss ich etwas ausholen – und das kann Euch auch nur dann passieren, wenn Ihr Apex-Code geschrieben habt. Punkt 1 und 2 sind aber sehr oft der Hintergrund für Probleme, die meistens erst etwas später auftauchen.
Generell empfehle ich immer in ein laufendes System nur dann einzugreifen, wenn es wirklich nicht anders geht.
Nur weil man in 30 Sekunden ein Feld in einem Live-System ohne Downtime anlegen kann sollte man es nicht unter allen Umständen auch tun. Und zwar aus folgenden Gründen:
Salesforce ist ein so beliebtes System, weil alle Nutzer auf der Welt immer auf dem gleichen Release arbeiten und die Entwickler sich auf 3 Major Releases im Jahr stürzen können, ohne alte Releases am Leben halten zu müssen.
Damit muss aber auch zwingend sichergestellt sein, dass man jederzeit ein stabiles System hat. Das wird durch eine vorgegebene Testabdeckung von 75% vorgegeben. In der Praxis heisst das, dass die Entwickler, die Code in Apex schreiben, für ihren Code Testklassen schreiben müssen bis die eine Abdeckung von mind. 75% erreichen. 100% wird man selten erreichen können, in der Praxis zeigt sich, dass 75% eine sehr gute Vorgabe ist.
Ein Problem kann dann auftauchen, wenn man in einer Produktion z.B. Validierungen erstellt, Pflichtfelder definiert oder auch einfach Felder aus dem Layout entfernt, die in Testklassen genutzt werden. Das kann nämlich dazu führen, dass die Testabdeckung dann nicht mehr erreicht wird.
Wann merkt man das? Das Gute: Nicht im Betrieb, die Testklassen haben auf den Betrieb keine Auswirkungen. Aber Ihr werdet es beim nächsten Einspielen von Änderungen aus der Testumgebung in die Produktion schmerzlich zu spüren bekommen. Es wird nämlich nicht möglich sein.
Erstellt möglichst alles in einer Testumgebung und schickt es per Änderungsset in die Produktion und folgt dem Deployment-Konzept. So stellt Ihr sicher, dass Ihr jederzeit eine stabile Produktion habt, wenn ihr werdet vor dem Deployment feststellen, ob Ihr Eure Testklassen anpassen müsst oder eventuell neue schreiben dürft für die veränderten Vorgaben.
Man kann übrigens in jeder Salesforce-Umgebung im Menü unter Setup -> Develop -> Apex Test Execution -> Select Tests -> alles anklicken -> Run die Testabdeckung überprüfen.
Apex-Code und Visualforce sind eine wunderbare Sache. Wenn das zum Einsatz kommt, sollte man sich nur auch über die Auswirkungen vorab etwas informieren.

Kann man also eine Salesforce-Umgebung zum Stillstand bringen? Ja, kann man. Das gute ist, man kann alle Fehler wieder recht schnell beheben und man wird die Fehler sicher auch nicht erneut begehen.
Dennoch sollte man mit Validierungen und Pflichtfeldern etwas vorsichtiger umgehen, als vielleicht zunächst gedacht.