Dynamics AX Blog - Dynamics AX 2012 - Seite 8

Unlängst hatte ich erstmalig die Anforderung, im Mobile Device Portal (MDP) eine einfache Feldvalidierung einzubauen. Nachdem ich mich etwas mit den WHSWorkExecute-Klassen auseinander gesetzt habe, habe ich die Klassenmethode WHSRFControlData.processData()  als gut geeignet für solcherart Prüfungen gefunden.

Eine solche Prüfung könnte wie folgt aussehen:

case #Qty:
    qty = WHSWorkExecuteDisplay::str2numDisplay(data);
    if (qty <= 0)
    {
        errorMessage = "@WAX1172";
        hasError = true;
        break;
    }

    //--> Start
    if (pass.exists(#ProdId) &&
        pass.lookupStr(#ProdId) != "" &&
        mode == WHSWorkExecuteMode::ReportAsFinished)
    {
        my_ProdTable = ProdTable::find(pass.lookup(#ProdId));

        if (qty + my_ProdTable.reportedFinishedGood() +
            my_ProdTable.reportedFinishedError() > my_ProdTable.QtyStUp)
        {               
            errorMessage = "@SYS16097";
            hasError = true;
            break;
        }
    }           
    //<-- End

Um in einem Query nach einer Finanzdimension sortieren zu können, ist die Methode SysQuery::addOrderByDimensionAttribute() zu verwenden.

Das folgende Beispiel soll dies veranschaulichen. In diesem Job werden alle Debitoren ausgegeben und dabei nach der Dimension CostCenter sortiert.

static void sortByDimension(Args _args)
{
    Query query;
    QueryRun queryRun;
    QueryBuildDataSource qbds;
    CustTable custTable;
    DimensionComponent dimensionComponent;
    DimensionValue dimensionValue;

    #define.CostCenterDimensionName("CostCenter");

    query = new Query();
    qbds = query.addDataSource(tableNum(CustTable));

    SysQuery::addOrderByDimensionAttribute(query,
                                           qbds.name(),
                                           fieldId2name(tableNum(CustTable),
                                                        fieldNum(CustTable, DefaultDimension)),
                                           DimensionComponent::DimensionAttribute,
                                           SortOrder::Ascending,
                                           #CostCenterDimensionName);

    queryRun = new QueryRun(query);
    while(queryRun.next())
    {
        custTable = queryRun.get(tableNum(CustTable));

        // Get dimension value
        dimensionValue =
        (select firstonly DisplayValue from defaultDimensionView
         where defaultDimensionView.Name == #CostCenterDimensionName
            && defaultDimensionView.DefaultDimension == custTable.DefaultDimension).DisplayValue;

        info(strFmt("%1 %2", custTable.AccountNum, dimensionValue));
    }
}

Daß man in Forms eingebundene Display-Methoden cachen sollte, ist bekannt. Dafür wird schon seit jeher ein entsprechender Aufruf in der init()-Methode einer Form-Datasource eingebunden:

public void init()
{
    super();
    this.cacheAddMethod(tableMethodStr(DirPartyPostalAddressView,locationRoles));
}

Daß man in Dynamics AX 2012 sich diesen Aufruf sparen kann, wenn man in der Display-Methode selbst ein entsprechendes Attribut setzt, war mir selbst neu:

Um für eine Funktion, die über das SysOperaton-Framework abgebildet wurde, die Berechtigungen über eine Code Permission abzubilden, sind folgende Schritte notwendig:

1. Klassen erstellen
2. MenuItem erstellen (für Controller)
3. Code Permission erstellen
4. In dieser CP im Knoten Server-Methods die auszuführende Methode aus der Serviceklasse einfügen
5. In den Tables-Knoten alle Tabellen die benötigt werden einfügen und entsprechend berechtigen
6. CodePermssion beim MenuItem in der Eigenschaft LinkedPermissionObject eintragen und als LinkedPermissionType den Wert CodePermission auswählen
7. Das MenuItem wie üblich in ein Privilige oder eine Aufgabe einfügen

Abbildung: Darstellung von Schritt 4

Nachzulesen auf MSDN.

Vor kurzem musste ich bei einem Modul eruieren, ob Labels in einer bestimmten Sprache (im Beispiel de_at) vorhanden sind, oder nicht. Gut dafür geeignet scheint mir folgendes SQL-Statement.

SELECT *
FROM [AX2012R3_TEST_model].[dbo].[ModelElementLabel] as existing
where existing.Module = 'myModule'
and existing.Language = 'en_us'
and not exists
( select *
from [AX2012R3_TEST_model].[dbo].[ModelElementLabel] as missing
where missing.labelid = existing.LabelId
and missing.Module = existing.Module
and missing.Language = 'de_at')

Um in einem Formular auf das Ändern des Bearbeitungsmodus zu reagieren, kann man die task()-Methode des Formulares wie folgt überschreiben:

public int task(int _taskId)
{
    int ret;
    #Task
    ret = super(_taskId);
    
    switch(_taskId)
    {
        case #taskEditRecord:    
            …doSomething… 
            break;
    }
    return ret;
}

Wer den aktuellen Bearbeitungsmodus auslesen möchte, kann dies über die folgende Methode tun:

element.inViewMode()

Manchmal muss man im XML-Header einer Methode Sonderzeichen verwenden, um den Code gut dokumentieren zu können. Damit dieser Header trotzdem wohlgeformt ist und nicht als Best-Practice-Abweichung gekennzeichnet wird, kann man einen CDATA-Abschnitt einsetzen.

/// <version>
///  1.0
/// </version>
/// <summary>
/// <![CDATA[ Replaces following special characters: &, % ]]>
/// </summary>
private void someMethod()
{
    //...do something...
}

Ohne diesen CDATA-Abschnitt würde AX folgende BP-Abweichung ausgeben:

Die XML-Dokumentation ist nicht wohlgeformt.