Dynamics AX Blog - Microsoft Dynamics AX (Axapta) - Seite 36

Wenn man in Dynamics AX (4.0 bzw. 2009) einmal in die Verlegenheit kommen sollte, prüfen zu müssen, ob es Tabellen mit doppelten RecIDs gibt, kann folgendes SQL-Script dabei behilflich sein:

Die Feldgruppe AutoReport einer Tabelle und deren Verwendung beim Drucken von Daten aus einem Formular heraus sollte wohl jedem Dynamics AX-Entwickler bekannt sein. Auf Basis dieser Standard-Funktionalität habe ich versucht, selbst einen Report per X++ auf Basis eines Query zu erstellen.

Das Ergebnis des obigen Codes ist ein sehr einfacher Report:

Um in einem Objekt auf das aufrufende Objekte zuzugreifen, habe ich anhand von einigen Zeilen Code ja schon demonstriert (siehe hier und hier). Dabei hatte ich aber immer ausser Acht gelassen, daß das aufrufende Objekt ja auch eine Klasse sein kann.

Nun also hier ein entsprechendes Beispiel:

if (element.args() && 
    element.args().caller() && 
    classidget(element.args().caller()) == classnum(nameOfClass )) 
{
    nameOfClass = element.args().caller();
    someValue = nameOfClass.someMethod();
}

Vor einiger Zeit habe ich schon einmal einen Eintrag über das runBaseBatch-Framework geschrieben, damals ging's hauptsächlich um die Aufrufreihenfolge der einzelnen Methoden und wofür einige von diesen Methoden verwendet werden können bzw. verwendet werden sollten.

Nun habe ich mir basierend auf diesem Eintrag und vor allem aufgrund von Erfahrungswerten eine eigene Klasse namens tutorial_ClassWithQueryRun geschrieben, die einige oft benötigte Anforderungen vereinigt.

Diese Klasse vereint folgende Fähigkeiten:

• Stapelfähigkeit
• Arbeiten mit einem Query
• Arbeiten mit den Nutzungsdaten
• Schreiben einer Datei via textIo
• Arbeiten mit Fortschrittsanzeigen (progress)

Der nachstehende Code zeigt wie man einen Query mit Gruppierung, Sortierung und verschiedenen Filtern aufbaut und diesen mit Hilfe eines QueryRun abarbeitet.

static void tutorialQueryGroupBy(Args _args)
{
    Query                query;
    queryBuildDataSource queryBuildDataSource;
    queryBuildRange      queryBuildRangeInvoiceDate;
    queryrun             queryrun;
    Salesline            Salesline;
    ;

    query = new query();

    queryBuildDataSource = query.addDataSource(tableNum(Salesline));

    // Add group by-clause
    queryBuildDataSource.addGroupByField(fieldNum(Salesline, custAccount));
    queryBuildDataSource.addGroupByField(fieldNum(Salesline, currencyCode));

    // Add fields to select-clause
    queryBuildDataSource.addSelectionField(fieldNum(Salesline, custAccount),        SelectionField::Database);
    queryBuildDataSource.addSelectionField(fieldNum(Salesline, currencyCode),       SelectionField::Database);
    queryBuildDataSource.addSelectionField(fieldNum(Salesline, lineAmount),         SelectionField::Sum);
    queryBuildDataSource.addSelectionField(fieldNum(Salesline, createdDateTime),    SelectionField::Min);

    // Add sort by-clause
    queryBuildDataSource.addSortField(fieldNum(Salesline, custAccount), SortOrder::Ascending);

    // Add where-clause
    sysQuery::findOrCreateRange(queryBuildDataSource, fieldNum(Salesline, DeliveryCountryRegionId)).value("AT, US");                                            
    sysQuery::findOrCreateRange(queryBuildDataSource, fieldNum(Salesline, createdDateTime)).value(SysQueryRangeUtil::lessThanDate(-365));                       
    sysQuery::findOrCreateRange(queryBuildDataSource, fieldNum(Salesline, salesStatus)).value(strFmt("%1, %2", SalesStatus::Invoiced, SalesStatus::Delivered));

    // Represents Select
    // SELECT FIRSTFAST CustAccount, CurrencyCode, SUM(LineAmount), MIN(createdDateTime)
    // FROM SalesLine
    // GROUP BY SalesLine.CustAccount, SalesLine.CurrencyCode
    // ORDER BY SalesLine.CustAccount ASC
    // WHERE ((DeliveryCountryRegionId = N'AT' OR DeliveryCountryRegionId = N'US'))
    //   AND ((createdDateTime<'2009-07-06T22:00:00'))
    //   AND ((SalesStatus = 3 OR SalesStatus = 2))


    queryrun = new SysQueryRun(query);
    while(queryRun.next())
    {
        Salesline = queryRun.get(tableNum(SalesLine));

        info(strFmt("%1: %2 %3 (%4)", salesLine.CustAccount, 
                                      salesLine.LineAmount, 
                                      salesLine.CurrencyCode, 
                                      salesLine.createdDateTime));
    }
}

Vor kurzem stand ich vor der Herausforderung, in einem Formular alle x Sekunden etwas tun zu müssen (Beispielsweise sollen alle 2 Sekunden der Inhalt einer angezeigten Datenquelle/Tabelle aktualisiert werden).

Lösen kann man so etwas mit Hilfe der Methode setTimeOut, die z.B. auch von der clientseitigen Stapelverarbeitung unter Grundeinstellungen > Periodisch > Stapel > Bearbeitung verwendet wird.

Dazu muss z.B. im Formular eine Methode angelegt werden, die sich selbst über die setTimeOut-Methode nach einer definierten Zeitspanne (in tausendstel-Sekunden anzugeben) aufruft:

void runEvery2Seconds()
{
    // Set a Time Out with the idle flag set to false
    this.setTimeOut(funcname(), 2000, false);

    // ...do something...
    dataSourceName_ds.executeQuery();
}

Im Zuge eines Upgrades einer Applikation auf Dynamics AX 2009 ist mir ein Stückchen Code über den Weg gelaufen, dessen Code-Upgrade auf den ersten Blick recht einfach sein sollte, sich aber bei genauerer Betrachtung als doch gar nicht so einfach herausgestellt hat.

Und zwar gehts um ein einfaches SELECT-Statement, z.B. wie das folgende:

date myDate = str2date('07.05.2010', 123);

select count(recid)
from salesline
where salesline.createdDate == myDate;

Obiges Statement soll mir einfach eine Zahl der Auftragszeilen liefern, die an einem bestimmten Tag erstellt wurden.

In Dynamics AX 2009 wurde ja das Feld createdDate durch createdDateTime und einen vollständigen neuen Datentyp, der nun auch die Zeit mitspeichert, ersetzt.