Wenn Sie diese Fehlermeldung schon einmal gesehen haben, nachdem Sie Ihr Modell in Mendix, dann ist dieser Beitrag für dich.

Es gibt viele Gründe für eine Fehlermeldung und mehrere Varianten. In diesem Beitrag erkläre ich Ihnen, wie Sie die Ursache dieser Fehler finden, einige der häufigsten Fehler beheben und das Fehlerpotenzial während der Entwicklung minimieren.

Im gesamten Beitrag werde ich auch Beispiele verwenden. Die für diese Beispiele verwendete App hat drei Entitäten: Order, OrderLine und SaleOffer. In unserer App können wir OrderLines zur Bestellung hinzufügen und ein SaleOffer an die Bestellung anhängen.

Die Grundursache finden

Wenn Sie eine Fehlermeldung erhalten, müssen Sie zunächst herausfinden, wo der Fehler aufgetreten ist.

Wenn Ihre App lokal ausgeführt wird:

Sie können einfach den Business Modeler öffnen und die Konsole anzeigen. In der Konsole finden Sie eine rote Zeile mit einem roten „X“ am Anfang. Diese Zeile liefert uns die Informationen, die wir benötigen.

Doppelklicken Sie auf die rote Linie, um weitere Details zur Fehlermeldung und zum Stapelüberwachungsprotokoll zu erhalten.

Dieser Stacktrace enthält drei wichtige Informationen:

1. Der Microflow-Name und der Ort des Microflow-Fehlers: In diesem Beispiel liegt der Fehler innerhalb von „IVK_DeleteOrderLine“ im exklusiven Split (Gateway) mit der Überschrift „Nummer > 0?“
2. Der aufgetretene Fehler: In diesem Beispiel bezieht sich der Fehler auf java.lang.NullPointerException.
3. Der genaue Ausdruck, der fehlschlugIn diesem Fall bezieht sich der Fehler auf ein Stück innerhalb des exklusiven Splits, das die Nullzeiger-Ausnahme verursacht hat.

Wenn Ihre App in der Cloud oder über die Servicekonsole ausgeführt wird

In diesem Szenario müssen Sie auf die Protokolldateien zugreifen und nach einer Zeile suchen, die mit „ERROR“ beginnt und einen Zeitstempel hat, der mit dem Zeitpunkt Ihres Fehlers übereinstimmt. Alle erforderlichen Details werden der Reihe nach im Protokoll angezeigt.

Nachdem wir nun wissen, wie wir die Fehlerstelle finden, sehen wir uns zwei häufige Fehler und einige Muster an, die dabei helfen, sie zu vermeiden.

Nullzeigerfehler

Der Nullzeigerfehler tritt auf, wenn bei einem Abruf kein Objekt zurückgegeben wird oder wenn ein Attribut eines Objekts leer ist. In meinem ersten Beispiel ist der Microflow fehlgeschlagen, weil wir eine OrderLine gelöscht, aber überprüft haben, dass die Zahl größer als Null war.

Wir sehen die exklusive Aufteilung, die das Problem verursacht (aus Punkt (1) zuvor), und da wir nun die möglichen Ursachen unserer Ausnahme kennen, können wir mit der Behebung des Problems beginnen.

Beheben von Nullzeigerfehlern – Option 1:

Fügen Sie eine Prüfung hinzu, um festzustellen, ob das Number-Attribut leer ist oder ob das OrderLine-Objekt leer ist.

Diese Prüfungen sind nicht immer notwendig – wenn es unmöglich ist, dass das Objekt leer ist, besteht kein Grund, zu prüfen, ob es leer ist. Beachten Sie, dass „true“ immer horizontal führt – dies ist eine bewährte Vorgehensweise.

Diese Prüfungen können auch in einem exklusiven Split durchgeführt werden:

$Bestellzeile != leer
und
$Bestellzeile/Nummer != leer
und
$Bestellzeile/Nummer>0

Funktionell sind diese gleich, aber die separaten Aufteilungen können den Microflow leichter lesbar und verständlich machen. Beachten Sie, dass die Reihenfolge hier wichtig ist; Sie müssen zuerst die Leerprüfungen durchführen, sonst führt die Auswertung von $OrderLine/Number>0 immer noch zu einem Nullzeigerfehler.

Beheben von Nullzeigerfehlern – Option 2:

Wenn der Abruf einer Entität leer ist, versuchen Sie, ein „GetCreate“-Muster zu implementieren. Dieses Muster wird mithilfe einer Microflow-Aktion anstelle einer Abrufaktion implementiert. Dieses Beispiel zeigt, was passiert, wenn wir das SaleOffer der Bestellung aktualisieren möchten, der Bestellung aber noch kein SaleOffer zugeordnet ist.

Verwenden Sie in diesem Fall das Muster GetCreate. Anstatt einfach das SaleOffer abzurufen, rufen Sie einen Microflow auf, der garantiert ein SaleOffer zurückgibt. Der folgende Microflow zeigt, wie dieses Muster funktioniert.

Der erste Schritt im Get Create-Muster ist der Versuch, das SaleOffer abzurufen. Nachdem wir dies versucht haben, prüfen wir, ob es erfolgreich war. Wenn ein SaleOffer gefunden wird, geben wir einfach dieses SaleOffer zurück. Wenn der Abruf fehlgeschlagen ist, erstellen wir ein neues SaleOffer und verknüpfen es mit der Bestellung. Auf diese Weise ist der Abruf beim nächsten Aufruf dieses Microflows erfolgreich. Schließlich geben wir das NewSaleOffer zurück.

Dieses Muster sollte nur implementiert werden, wenn es sicher ist, eine neue Instanz des Objekts zu erstellen. Je nach Situation ist dies möglicherweise nicht immer angemessen. In diesem Fall müssen Sie einfach die Leerprüfung durchführen und entsprechend fortfahren.

Sicherheitsfehler

Sicherheit ist eine wichtige Komponente in jedem Domänenmodell, Microflow und jeder Seite. Beim Testen mit aktivierter Sicherheit erhalten Sie jedoch möglicherweise Fehlermeldungen mit dem Satz „Aus Sicherheitsgründen fehlgeschlagen“. Einer der häufigsten Sicherheitsfehler betrifft den Entitätszugriff.

Entitätszugriff anwenden ist eine Einstellung in den Eigenschaften des Microflows. Der schnellste Weg, um festzustellen, ob Entitätszugriff angewendet wird, besteht darin, die Hintergrundfarbe eines Microflows zu überprüfen. Der Microflow weist eine leichte Tönung auf, wenn Entitätszugriff angewendet wird.

Im obigen Beispiel wird auf den rechts gezeigten Microflow Entitätszugriff angewendet. Wenn Entitätszugriff angewendet wird, hat die für die Entität festgelegte Sicherheit Vorrang vor dem Microflow-Zugriff.

Gehen wir für dieses Beispiel davon aus, dass wir zwei Benutzerrollen, „Benutzer“ und „Administrator“, und zwei Modulrollen, „Benutzer“ und „Administrator“, haben, wobei der „Benutzer“ der Modulrolle „Benutzer“ zugeordnet ist und eine ähnliche Konstruktion für „Administrator“ gilt.

Bei der Untersuchung eines Sicherheitsfehlers folgen wir denselben Schritten wie zuvor: Wir gehen zur Konsole und suchen nach den rot hervorgehobenen Informationen, die uns zu der Aktion führen, die den Fehler verursacht hat. So finden wir beispielsweise heraus, dass unser Fehler hier auftritt:

Wir sehen, dass auf diesen Microflow Entitätszugriff angewendet wurde (anhand der Tönung des Hintergrunds). Daher wissen wir, dass wir die Sicherheit der Entität und des Microflows überprüfen müssen. Auf den Microflow können Benutzer mit der Benutzerrolle „Administrator“ und den folgenden Sicherheitseinstellungen für die Entität „SaleOffer“ zugreifen:

Von hier aus wird das Problem identifiziert – der „Administrator“ versucht, die SaleOffer-Entität im Microflow zu erstellen, verfügt jedoch nicht über die entsprechenden Berechtigungen. Es gibt zwei Möglichkeiten, dieses Problem zu lösen. Beachten Sie jedoch, dass die richtige Lösung vom jeweiligen Anwendungsfall abhängt:

1. Fügen Sie der Modulrolle „Administrator“ die Berechtigung zum Erstellen des SaleOffer hinzu
2. Machen Sie den Microflow für „Administratoren“ unzugänglich.

Dies sind nur einige Beispiele für mögliche Laufzeitfehler. Gibt es noch weitere, die Ihnen häufig begegnen? Gibt es einen, der schwierig oder verwirrend ist?