AX7 – Wo sind meine DeleteActions hin?

Nach der Migration auf das neue Microsoft Dynamics AX (AX7) wird man früher oder später bestimmt darauf stoßen, dass der Code Upgrade Service bestehende DeleteActions von Tabellen entfernt hat. Wieso macht der das und wo sind die hin?

Keine Sorge, die mit den DeleteActions abgebildete Logik ist nicht verschluckt, sondern nur sinnvoll umgezogen worden.

Zustand unter AX 2012

Schon unter AX 2012 war es so, dass der Zusammenhang zwischen Relation und DeleteAction zwar jedermann schnell klar, aber nicht optimal war, wenn man es aus Sicht einer Erweiterung des AX-Standards betrachtet. Als Beispiel möchte die Tabelle LanguageTable anführen. Viele werden schon mal eine eigene Table angelegt haben, die die verschiedenen verfügbaren Sprachen referenziert, wir nennen sie beispielhaft MyObjectTableTranslation. Diese erhält eine Relation auf die LanguageTable, modelliert als übliche Fremdschlüsselbeziehung. Die Krux ist jetzt, dass man natürlich eine verwendete Sprache in der Regel so einstellen möchte, dass diese nicht entfernt werden kann, sobald eine Objekt-Übersetzung in dieser vorhanden ist. Dazu ist man genötigt, eine Anpassung der Tabelle LanguageTable vorzunehmen und diese um eine DeleteAction (mit Wert Restricted) zu ergänzen.

AX7 löst das Problem

Dieser Missstand wurde mit der neuen AX-Version nun behoben, und zwar, das sei nebenbei erwähnt, gezwungenermaßen. Es gibt noch die Möglichkeit, DeleteActions zu definieren (mutmaßlich aus Abwärtskompatibilitätsüberlegungen), der aktuelle Weg sieht jedoch vor, das bisher darüber abgebildete Verhalten über ein Property an der jeweiligen Relation zu definieren. Das Property heißt
OnDelete
Es nimmt exakt die gleichen Werte an wie die DeleteActions zuvor, also

  • None
  • Cascade
  • Restricted
  • CascadeRestricted
AX7 DeleteActions OnDelete Property

Das Beispiel LanguageTable ist aus meiner Sicht besonders gut zur Erklärung geeignet, weil die Tabelle ohnehin schon sehr stiefmütterlich behandelt wurde, was die Definition von DeleteActions angeht (ich glaube, sie hatte quasi nie welche – OK, man malt in dem Datentopf auch nicht wirklich rum). Der Grund könnte sein, dass man die riesige Menge an DeleteActions gescheut hat. Und wie erwähnt, gibt es auch einen unumgänglichen Grund für die ohnehin sinnvolle Umkehrung des Prinzips. Und zwar die Grenzen der Packages. Die LanguageTable gehört nämlich zur Application Platform und wäre entsprechend gar nicht in der Lage, eine DeleteAction auf unser Beispiel MyObjectTableTranslation zu definieren. Auch im Standard referenzieren unzählige Tabellen die Sprachen, wie etwa EcoResProductTranslation, und die meisten davon befinden sich unterhalb von Platform und zum Beispiel in der Application Suite.
Sollte dir das mit den Packages und deren Grenzen noch nicht ganz geheuer sein, darfst du gespannt sein, ich werde mich in einem der nächsten Posts bemühen, das mit einem oder mehreren Beispielen zu veranschaulichen. Abgesehen davon gibt es auch im Wiki eine kurze Übersicht dazu, im Artikel Understanding the model split.

Schreibe einen Kommentar