Im Beispiel werden mehrere Dimensionen mit Werten befüllt. Bitte beachtet, daß die angeführten Dimensionen möglicherweise in Euren AX-Installationen nicht vorhanden sind.

Im Beispiel werden die Dimensionen namens CustomerGroup, Debitor und NonExistingDimension als zu prüfen angegeben. Bitte beachtet, daß nicht alle Dimensionen in jeder AX-Instanz vorhanden sind. Vor allem letztere dient lediglich zur Demonstration, wie sich der Code verhält, wenn eine Dimensionen ausgelesen werden soll, die es gar nicht gibt.

Als Ergebnis des obigen Jobs wird ein Infolog ausgegeben.

Der interessante Teil des Jobs ist die Methode addDimensionAttributeRange der Klasse SysQuery, da diese sich um das Verknüpfen der benötigten Datenquellen kümmert.

Die Klasse SysQuery stellt übrigens zahlreiche weitere ähnliche Funktionen zur Verfügung, um mit Dimensionswerten zu arbeiten.

Ein Must-Read zu dem Thema ist freilich: http://blogs.msdn.com/b/mfp/archive/2011/07/11/the-solution-to-the-element-id-problem.aspx

Auf Basis dieses Turorials habe ich in Dynamics AX 2012 eine Anforderung wie folgt gelöst:

In der Klasse wmsArrivalStart - das ist jene Klasse, die aus der Wareneingangsübersicht aus aufgerufen werden kann und Wareneingangsjournale erstellt - eine neue Methode MyDialog eingebaut, die ein Formular namens MyWMSArravialStart als Dialog aufruft. Diesem Formular wird eine temporäre Tabelle wmsArrivalDetailTmp übergeben und in einem Grid dargestellt.

Das Formular baut auf Basis dieser Tabelle wmsArrivalDetailTmp eine weitere temporäre Tabelle namens TmpWMSArrivalStartReturn auf und retourniert diese an die Klasse WMSArrivalStart.

Die Methode MyDialog wird von der run-Methode der Klasse WMSArrivalStart aus aufgerufen und öffnet das Formular MyWMSArrivalStart. Dabei wird diesem Formular über eine entsprechende Parameter-Methode  die Tabelle wmsArrivalDetailTmp übergeben. Auf Basis dieser Tabelle wird im Formular eine temporäre Tabelle TmpWMSArrivalStart aufgebaut und in einem Grid angezeigt. Hat der Benutzer in diesem Grid seine Eingaben gemacht,  wird diese temporäre Tabelle über die Methode getTmpWMSArrivalStart an die Klasse retourniert.

Aufruf der Methode aus der run-Methode der Klasse wmsStartArrival

In der run-Methode des Formulares wird die Methode fillTables aufgerufen, welche die von der Klasse übergebenen Daten verarbeitet (über die Methode parmWmsArrivalDetailTmp)

Die Methode parmWmsArrivalDetailTmp dient zum Übergeben der Datensätze der Tabelle WmsArrivalDetailTmp

Die Methode fillTables baut auf Basis der Tabelle WmsArrivalDetailTmp eine weitere Tabelle auf. Diese Tabelle dient gleichzeitig als DataSource des Formulares und wird in einem Grid dargestellt.

Klickt der Benutzer auf den OK-Button des Formulares wird über die Methode getTmpWMSArrivalStart der Inhalt der Tabelle TmpWMSArrivalStart an die Klasse retourniert.

Abschliessend noch ein paar Anmerkungen zum Formular selbst:

• Die Form muss eine Gruppe namens dialogStartGrp enthalten
• Die Form benötigt auch die entsprechenden Buttons (dafür am besten die gesamte Gruppe BottomButtonGrp des Formulares tutorial_RunbaseForm übernehmen

Das Beispiel funktioniert prinzipiell in AX 2009 genauso wie in AX 2012.

Prinzipiell unterscheidet man dabei zwischen Event-Handler die vor (PRE) bzw. nach (POST) dem Originalcode ausgeführt werden sollen, wobei jede der beiden Varianten ihre eigenen Möglichkeiten bieten. Pre-Event-Handler können die Original-Parameter der auslösenden Methode verändern wogegen Post-Event-Handler den Rückgabewert der auslösenden Methode verändern können.

Die folgenden drei Beispiele sollen die Verwendung dieser Event-Handler verdeutlichen.

Beispiel 1: Es soll der Inhalt des Feldes Suchbegriff der Artikeldetails dahingehend geprüft werden, daß zumindest 5 Zeichen eingegeben wurden.

In früheren Versionen von Dynamics AX hätte man für eine solche Prüfung üblicherweise die validateWrite der Tabelle inventTable verändert - in AX 2012 erstellen wir statt dessen eine Klasse MyInventTableEventHandler mit einer Methode inventTableValidateWritePostEventHandler und verknüpfen die Methode mit der validateWrite.

Schritt 1: Erstellen der Klasse und Methode

Schritt 2: Verknüpfen der Methode mit der Tabelle

Per Drag & Drop ziehen wir die Methode inventTableValidateWritePostEventHandler auf die validateWrite der inventTable.

Nun müssen wir noch festlegen, wann dieses Event ausgeführt werden soll, in unserem Fall wählen wir die Variante Post.

Beispiel 2: Auch in diesem Beispiel soll der Inhalt des Feldes Suchbegriff der Artikeldetails geprüft werden, allerdings nicht erst beim Speichern des Datensatzes sondern gleich nach der Eingabe.

In früheren Versionen von Dynamics AX hätten wir hierfür die Methode validateField entspechend angepasst, in meinem Beispiel verwende ich die Methode validateField als Auslöser des Events.

Im Gegensatz zum Beispiel 1 verfügt die Methode validateField über zwei Paramter, die selbstverständlich auch durch Event-Handler genutzt werden können. Auch dieses Mal handelt es sich um einen Post-Event-Handler.

Schritt 1: Erstellen der Klasse und Methode

Schritt 2: Verknüpfen der Methode mit der Tabelle

Per Drag & Drop ziehen wir die Methode inventTableValidateFieldPostEventHandler auf die validateField der inventTable. Nun müssen wir noch festlegen, wann dieses Event ausgeführt werden soll, in unserem Fall wählen wir die Variante Post.

Hinweis: Alternativ zu _args.args().valueIndex() kann man die Parameter der Original-Methode auch wie folgt abfragen:

Beispiel 3: Bei Aktualisieren eines Datensatzes in den Artikeldetails soll das Feld Suchbegriff mit der Artikelnummer gefüllt werden, wenn das Feld Suchbegriff leer ist.

In Versionen vor Dynamics AX 2012 hätten wir gewohnterweise die update-Methode verändert, in dieser Version verwenden wir Sie als Auslöser des Events.

Schritt 1: Erstellen der Klasse und Methode

Schritt 2: Verknüpfen der Methode mit der Tabelle

Per Drag & Drop ziehen wir die Methode inventTableUpdatePreEventHandler auf die update der inventTable. Nun müssen wir noch festlegen, wann dieses Event ausgeführt werden soll, in unserem Fall wählen wir die Variante Pre.

Weitere Hinweise

Selbstverständlich kann eine Klasse mehrere Methoden enthalten die als Event-Handler benutzt werden, so könnten wir also alle drei oben beschriebenen Methoden in nur einer Klasse kombinieren.

Weiters ist es natürlich auch möglich, eine Event-Handler-Methode derart zu programmieren, als daß sie sowohl als Pre- als auch als Post-Event-Handler verwendet werden kann. Abgefragt werden kann dies - wie in den obigen Beispielen ansatzweise dargestellt über die Abfrage von getCalledWhen der XppPrePostArgs.
Auch können wir mehrere Event-Handler mit eine Methode verknüpfen, die Reihenfolge der Ausführung ist allerdings nicht steuerbar.

Dynamics AX 2009

Dynamics AX 2012

Hatte man in AX 2009 noch die Möglichkeit, die Relations auf einem Extended Datatyp (EDT) festzulegen, so muss dies nun direkt auf den Tabellen erfolgen. Ausserdem sind die Tabellen nun meist so aufgebaut, daß Relations über die sogenannten Surrogate Foreign Keys erfolgen.
 
Als Surrogate Foreign Key bezeichnet man ein einzelnes Feld, über das sich ein Datensatz eindeutig identifizieren lässt. In vielen Datenbanksystemen ist dies eine vom System generierte Nummer die in der jeweiligen Benutzeroberfläche oft gar nicht angezeigt wird, in AX wäre dies beispielsweise die RecId. Schon in früheren Versionen von Dynamics AX wurde dieses Feld dazu verwendet, Beziehungen zwischen Tabellen herzustellen, mit Dynamics AX 2012 sollen sämtliche Relations über die RecId abgebildet werden.

Neben den Surrogate Foreign Keys gibt es die Natural Foreign Keys, über  die  sich ein Datensatz ebenfalls eindeutig identifizieren lässt, allerdings in einer auch für den Benutzer lesbaren Form. Ausserdem kann ein Natural Foreign Key mehrere Felder beinhalten.
 
Da sowohl der SurrogateForeign  Key als auch der Natural Foreign Key einen Datensatz eindeutig identifizieren, können beide als Primary Key verwendet werden. Die neue Eigenschaft ReplacementKey von Tabellen steuert die Anzeige im AX-Client, unabhängig vom tatsächlichen Primary Key.

Um die Verwendung dieser Keys zu verdeutlichen, möchte ich in Dynamics AX 2012 beispielsweise zwei Tabellen erstellen, in welchen Autohersteller und deren Modelle gespeichert werden sollen.

Die erste Tabelle DmoCarManufacturer enthält nur zwei Felder:

• ManufacturerID (Abgeleitet von einem eigens erstellten EDT vom Typ String mit dem Label Hersteller)
• Name (Abgeleitet vom EDT Name)

Wenn man sich die Eigenschaften der Tabelle nach der Erstellung ansieht, erkennt man daß AX die Eigenschaft CreateRecIdIndex auf YES gesetzt und als Primary Key und Clustered Index den Wert SurrogateKey eingetragen hat.

Nun erstellt man einen neuen eindeutigen Index über das Feld ManufacturerId und legt diesen über die gleichnamige Eigenschaft als AlternateKey fest.
Danach ist dieser Key auf Tabellenebene als ReplacementKey einzustellen wodurch dieses Feld automatisch der FieldGroup AutoIdentification hinzugefügt wird.

Zusätzlich habe ich noch die Felder ManufacturerId und Name als TitleFields der Tabelle definiert, dies hat aber für die Relaton selbst keine Auswirkung, lediglich das spätere Lookup-Formular wird dadurch benutzerfreundlicher.

Der nächste Schritt ist die Erstellung der zweiten Tabelle DmoCarModel.

Um nun eine Beziehung zur Tabelle DmoCarManufacturer zu erstellen wählt man im Kontextmenü des Knoten Relations Neue Relation und trägt als Tabelle die DmoCarManufacturer ein. Nun kann man über das Kontextmenü dieser neuen Relation Neu > ForeignKey > PrimaryKey-basiert auswählen. Dadurch erstellt AX ein neues Feld mit dem Namen DmoCarManufacturer, abgeleitet vom EDT RefRecId.

Das zweite Feld ModelId lege ich manuell an und soll später die Modellbezeichnung eines Autos beinhalten.

Um nun die Auswirkung dieser Einstellungen darzustellen, erstelle ich auf Basis der Formular-Vorlage Simple List ein Formular für die Tabelle DmoCarModel und ziehe per Drag & Drop das Feld DmoCarManufacturer in ein Grid des Designs. Dadurch wird innerhalb des Grids eine sogenannte ReferenceGroup erstellt. Auch das zweite Feld der Tabelle ModelId ziehe ich per Drag & Drop ins Grid.

Öffne ich nun dieses Formular und erstelle ich einen neuen Datensatz, sieht man daß im Lookup des Feldes DmoCarManufacturer nicht die RecId - welche ja in der Datenbank gespeichert wird - angezeigt wird, sondern die sprechenden Felder Hersteller und Name.

Öffnet man hingegen die Tabelle DmoCarModel über den TableBrowser, wird der Lookup das Feldes DmoCarManufacturer insoferne etwas anders dargestellt, als daß man hier auch die RecId sieht.

Informationen dazu sind natürlich in der MSDN (http://msdn.microsoft.com/en-us/library/aa556809.aspx) zu finden. 

Diese Klasse hat gegenüber der Klasse SysTableLookup, die es schon in Dynamics AX 2009 gegeben hat, sowohl einige Vorteile aber auch ein paar Nachteile:

Vorteile

• Aufruf aus der init-Methode eines Formulares aus möglich (d.h. es muss die lookup-Methode des jeweiligen Feldes nicht überschrieben werden)
• Mehrfachauswahl von Werten ist möglich

Nachteile

• Es können keine (Display-)Methoden in den Lookup eingebunden werden
• Man muss den Lookup verwenden um einen Wert auszuwählen, eine "freie" Eingabe ist nicht möglich

Hier ein einfaches Anwendungsbeispiel:

Es soll bei dem FormStringControl namens LookupStingEdit eine Lookup-Möglichkeit auf die Debitorengruppen geschaffen werden. Es sollen aber nur bestimmte Gruppen angezeigt werden (realisiert über einen QueryBuildRange auf einen Query) und es soll der Name der Debitorengruppe retourniert werden (realisiert über den 5 Parameter der Methode SysLookupMultiSelectCtrl::constructWithQuery).

Diese neue Klasse kann man auch für Dialog-Felder verwenden, beispielsweise innerhalb eines Jobs:

Führt man den Job aus, öffnet sich der Dialog wie folgt:

Auch innerhalb einer von RunBasebatch abgeleiteten Klasse kann der Dialog um einen Lookup erweitert werden. Dafür müssen die Methoden dialog und dialogPostRun angepasst werden. Im Beispiel wird ein Lookup auf die Debitoren ermöglicht, wobei auch Informationen aus der jeweiligen Debitorengruppe angezeigt werden:

Hinweis: Wenn innerhalb des Lookups mehrere Tabellen verjoint werden, können nur Werte aus der "Haupttabelle" des Queries retourniert werden. Wichtig ist weiters, daß nur jene Felder der Tabelle retourniert werden können, die auch im Lookup angezeigt werden.

Hier ein einfaches Beispiel unter Verwendung eines Queries, bei dem prinzipiell ein Lookup auf die Kundengruppen möglich sein soll, aber nur bestimmte angezeigt werden sollen. Diese Einschränkung kann über sysQuery::findOrCreateRange abgebildet werden.

Das Beispiel funktioniert übrigens sowohl in Dynamics AX 2009 als auch AX 2012.

Im nächsten Beispiel sollen nur Kundengruppen angezeigt werden, wo es auch Kunden/Debitoren dazu gibt, dies wurde über einen ExistsJoin mit der Tabelle CustTable realisiert.

Weiteres werden die im Lookup angezeigten Spalten die Labels über die Methode setLabel geändert und es wird nicht - wie es standardmässig der Fall ist - die erste Spalte als zu retournierender Wert angegeben sondern die Spalte mit dem Namen der Kundengruppe (dafür wird der zweite, boolsche Parameter der Methode addLookupfield verwendet):

Auch dieses Beispiel funktioniert sowohl in Dynamics AX 2009 als auch AX 2012.

Zusätzlich zu den oben beschriebenen Möglichkeiten können auch Display-Methoden von Tabellen eingebunden werden. Wichtig dabei ist lediglich, daß sämtliche Felder, die von der anzuzeigenden Display-Methode benötigt werden, auch im Lookup angezeigt werden. Im Beispiel wird die Methode bankAccountNum eingebunden, diese benötigt die Werte aus den Feldern accountNum und bankAccount der Tabelle custTable:

Im folgenden Beispiel gehe ich noch einen Schritt weiter und befülle zuerst eine temporäre Tabelle, aus der anschließend die Daten angezeigt werden. Ganz konkret werden sämtliche Kundengruppen inkl. einer Anzahl der zugewiesenen Kunden.

Notiz:Als temporäre Tabelle habe ich im Beispiel die TmpJobSelect verwendet, schöner wäre natürlich eine eigene Tabelle. Auch bin ich mir darüber im klaren, daß das kontruierte Beispiel auch ohne temporäre Tabelle lösbar gewesen wäre.

Auch dieses Beispiel funktioniert sowohl in Dynamics AX 2009 als auch AX 2012.

Über einen Blog-Eintrag bin ich aber auf einen wertvollen Tip gestossen: Wenn man die [SHIFT]-Taste hält, während man über die rechte Maustaste das Kontext-Menü einer Applikation aufruft, steht die Option Als anderer Benutzer ausführen wieder zur Verfügung.

Szenario: Es soll ein Bericht erstellt werden, bei welchem der Umsatz pro Verkaufsgruppe ausgewertet werden kann.

Schritt 1: Erstellen eines Queries in Dynamics AX

Ich gehe davon aus, daß der geneigte Leser schon einmal einen Query erstellt hat, deshalb werde ich darauf nur sehr oberflächlich eingehen. Basis-Tabellen meines Queries sind die Tabellen CustInvoiceTrans CustInvoiceJour CommissionSalesGroup Die Tabelle CustInvoiceTrans wird per InnerJoin mit der CustInvoiceJour über die im Screenshot gezeigten Felder verknüpft, die Tabelle CommissionSalesGroup wird per OuterJoin über das Feld SalesGroup verknüpft.

Seit AX 2012 muss die Eigenschaft Dynamic der Fields-Gruppe aller beteiligten Tabellen entsprechend gesetzt werden, im einfachsten Fall wird diese auf Yes gesetzt, um im Visual Studio später alle Felder der Tabellen verwenden zu können.

Schritt 2: Erstellen eines Projektes im Visual Studio

Über File > New > Project das Template Microsoft Dynamics AX auswählen, Report Model auswählen und einen Namen und Speicherort angeben.

Schritt 3: Erzeugen eines DataSets

Innerhalb dieses Reports ist nun ein neues DataSet zu erstellen. Diesem geben wir den Namen CustInvoiceDataSet und tragen als Query den zuvor in Dynamics AX erstellten ein. Letzteres erfolgt über einen Dialog wo auch jene Felder oder Methoden gewählt werden können, die im Bericht ausgegeben werden sollen. In unserem Fall sind dies: Aus der Tabelle CustInvoiceTrans die Felder InvocieId InvocieDate ItemId SalesGroup LineAmountMST und die Methode itemName() Aus der Tabelle CommissionSalesGroup benötige ich das Feld Name Gleichzeitig habe ich das DataSet über die Properties auf CustInvoiceDataSet umbenannt.

Die Eigenschaften des DataSet stellen sich nach Abschluß des Dialoges wie folgt dar:

Schritt 4: Erzeugen eines Designs

Nun kann das DataSet per Drag & Drop in den Knoten Designs gezogen werden. Dadurch wird ein neues Design namens AutoDesign1 erstellt.

Nun gilt es einige Eigenschaften dieses Designs anzupassen. Dazu zählen das Seitenformat, Bezeichnungen (Title) des Berichtes aber auch das Layout (LayoutTemplate), im Beispiel habe ich als Seitenformat die Einstellungen für DIN-A4 eingetragen.

Der automatisch generierten Tabelle CustInvoiceDataSetTable weisen wir ebenfalls über die Eigenschaft StyleTemplate ein Layout zu. Im Beispiel habe ich das Layout so gewählt, daß die einzelnen Zeilen später abwechselnd grau oder weiß unterlegt werden.

Schritt 5:Gruppierung einrichten

Nun gilt es, die geforderte Gruppierung nach der Verkaufsgruppe (Feld SalesGroup) abzubilden. Hierzu muss im Knoten Groupings der CustInvoiceDataSetTable benannten Tabelle ein neuer Knoten erstellt werden. Diesen nennen wir SalesGroupGrouping und vergeben im einen sprechenden Label, z.B. Verkaufsgruppe. In diesem Knoten können wir nun einen Unterknoten erstellen, in dessen Expression wir das Feld SalesGroup eintragen. Dieser Knoten bekommt nun noch den Namen SalesGroup. Danach erstellen wir jeweils einen neuen Knoten im Header und Footer-Bereich. Auch diese bekommen einen möglichst selbstsprechenden Namen (SalesGroupHeader bzw. SalesGroupFooter). Im SalesGroupHeader erzeugen wir zwei Unterknoten. Beim Ersten tragen wir in der Eigenschaft Expression das Feld SalesGroup ein, beim Zweiten das Feld Name.

Im SalesGroupFooter erzeugen wie nun in Summe sieben Unterknoten. Nur beim siebenten tragen wir über die Eigenschaft Expression einen Wert ein, die anderen taufen wir Dummy1 bis Dummy6.

Damit diese Summe je Verkaufsgruppe korrekt formatiert wird, passen wir die Eigenschaften entsprechend an:

Hintergrund der Dummy-Felder ist, daß Visual-Studio die Spalten im Footer automatisch unter den Spalten im Data-Bereich versucht auszurichten. Würden wir diese Dummy-Felder nicht erstellen, würde die Summe unterhalb der ersten Spalte  angedruckt.

In früheren Versionen von Dynamics AX hätten wir einfach die Eigenschaft ModelFieldName für solcherart Positionierung herangezogen, eine solche Eigenschaft scheint es aber in Visual Studio nicht zu geben.

Schritt 6: Reihenfolge der Spalten und Detail-Eigenschaften anpassen

Damit die Daten in einer bestimmten Reihenfolge sortiert angedruckt werden, erstellen wir im Sorting-Knoten entsprechende Unterknoten und tragen über deren Eigenschaft SortBy das jeweilige Feld ein. Wir sortieren nach Verkaufsgruppe, Rechnungsnummer und Rechnungsdatum.

Abschließend prüfen bzw. ändern wir die Reihenfolge der anzudruckenden Felder im Data-Bereich und passen über die jeweiligen Eigenschaften Spaltenbreiten und ggf. die Bezeichnungen an. So wähle ich zum Beispiel für die Spalte LineAmountMST als Bezeichnung Betrag statt dem vom Visual Studio vorgeschlagenen Label.

Schritt 7: Spalte Betrag einfärben

Damit Gutschriften bzw. Rechnungen mit negativen Werten rot dargestellt werden, ändern wir die Eigenschaft Style > Font > Color über eine entsprechende Expression:

Diese Änderung bewirkt, daß im Bericht negative Beträge später wie folgt dargestellt werden:

Schritt 8: MenuItem in Dynamics AX erzeugen

Abschließend erstellen wir in Dynamics AX ein neues MenuItem, verknüpfen dieses mit einem Menü um den Bericht aus Dynamics AX heraus starten zu können. AX erzeugt - wie schon in früheren Versionen - automatisch einen Dialog, wo man die anzuzeigenden Daten filtern kann.

Schritt 9: Aufrufen des Berichtes aus Dynamics AX heraus - Fertig

You are not recognized user of Dynamics AX. Please contact your system administrator

Die Ursache dafür ist, daß in der Tabelle UserInfo - das ist jene Tabelle wo die AD-Benutzer verwaltet werden - natürlich noch die Benutzer der Ursprungsdomäne hinterlegt sind. Im einfachsten Fall ändert man in dieser Tabelle den Eintrag für den Administrator, indem man die Felder NetworkDomain, NetworkAlias und SID entsprechend ändert. NetworkDomain und NetworkAlias sind selbsterklärend, woher bekommt man aber die SID?

Eine einfache Internet-Recherche nach "GET SID" liefert einige Möglichkeiten, weniger bekannt ist aber, daß auch Dynamics AX 2009 selbst eine Methode zur Verfügung stellt, um die SID für einen Benutzer auszulesen.

Jetzt braucht man also nur noch ein anderes, bereits lauffähiges AX, wo man sich anmelden und den Job absetzen kann ;-)

Einfacher geht’s mit folgendem Codebeispiel, welches in der init-Methode der DataSource eingebunden wurde und - im konkreten Fall in der Tabelle SalesLine - nur bei einem einzigen Feld die Bearbeitung erlaubt.

Im Gegensatz zu einem früher veröffentlichten Beitrag mit dem gleichen Thema werden bei diesem Codebeispiel auch Array-Felder korrekt berücksichtigt.

Getestet in Dynamics AX 2009

Im Beispiel wird ermittelt, wieviele Benutzer- bzw. Unternehmensvorlagen es für die Tabelle InventTable gibt und ob der aktuelle Benutzer sich den Vorlagendialog anzeigen lässt, wenn er/sie einen neuen Artikel anlegt.

Dafür wird ein Dialog verwendet, wo man lediglich den Namen und den Typ des zu suchenden Elementes angeben muss. Außerdem kann man noch einstellen, ob auch die privaten Projektknoten durchsucht werden sollen.

Wer eine etwas komfortablere Möglichkeit vorzieht, der kann sich bei Firma Loncar Technologies Inc. ein entsprechendes XPO herunterladen und ins AX einspielen. AUf Basis dieses XPOs ist auch obiger Job entstanden.

https://www.loncartechnologies.com/download.php

Diese Bedingung dient dazu, berechnete Werte einer GROUP BY-Clause in der WHERE-Clause berücksichtigen zu können. Dieses Feature habe ich in der Vergangenheit vor allem dazu gerne verwendet, wenn es darum ging über eine SQL-Abfrage doppelte (bzw. vielfache) Datensätze in einer Tabelle zu finden. In den bisherigen Versionen von Dynamics AX war dieses Unterfangen über X++ nur etwas umständlich abzubilden.

Microsoft hat dies scheinbar eingesehen, und stellt nun bei der Verwendung von Queries die Methode addHavingFilter zur Verfügung.

Im folgenden Beispiel möchte ich mir z.B. alle Kundengruppen ausgeben lassen, die bei mehr als nur einem Kunden hinterlegt sind.

Das Ergebnis der oben stehenden Abfrage ohne addHavingFilter würde wie folgt aussehen:

Mit addHavingFilter ändert sich das Ergebnis/Infolog:

Natürlich kann man dieses neue Feature auch bei einem im AOT definierten Query einsetzen. Dazu gibt es einen neuen, entsprechend benannten Knoten: