Dynamics AX Blog - Dynamics AX 2009 - Seite 8

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.

In einem früheren Beitrag habe ich ja schon demonstriert, wie man einen Report in Dynamics AX per Code aufruft, und diesem dabei einen Query übergibt. Der folgende Code erweitert diesen Aufruf um die Druckeinstellungen (printJobSettings), sodaß es nun möglich ist, einen Report vollautomatisch mit vorgegebenen Filterkriterien und definierten Druckeinstellungen aus X++ heraus aufzurufen.

Um bei einem Bericht/Report, der direkt über ein MenuItem (d.h. nicht über eine von RunBaseReport abgeleitete Klasse) aufgerufen wird, die Möglichkeit zu unterbinden, diesen im Stapel auszuführen, muss nur die Methode canGoBatch des Reports überschrieben werden.

Diese Methode scheint allerdings nicht in den überschreibbaren Methoden auf, also muss man einfach eine solche wie folgt anlegen:

Wird der Report über eine Klasse aufgerufen, dann muss in dieser die gleichnamige Methode entsprechend überschrieben werden.

Getestet in Dynamics AX 2009

Manchmal braucht man einfach nur den Label eines Extended Datatypes (EDT), um diesen zum Beispiel als Bestandteil einer Info-/Fehlermeldung ausgeben zu können: