Dynamics AX Blog - Dynamics AX 2012 - Beiträge von 2015

Beispiel, wie man per Code eine nicht-primäre Adresse mit zwei Rollen für einen Eintrag im Globalen Adressbuch erstellen kann.

static void createPartyInvoiceAndHomeAddress(Args _args)
{
    DirPartyTable dirPartyTable = DirPartyTable::findByNum("???100000??");
    DirParty dirParty;
    DirPartyPostalAddressView dirPartyPostalAddressView;

    // Create instance of dirParty
    dirParty = DirParty::constructFromCommon(dirPartyTable, DirUtility::getCurrentDateTime(), dirPartyTable.partyType());

    // Create primary address
    dirPartyPostalAddressView.LocationName      = "Invoice & Home";
    dirPartyPostalAddressView.City              = "Vienna";
    dirPartyPostalAddressView.Street            = "Kärtnerring";
    dirPartyPostalAddressView.StreetNumber      = "22";
    dirPartyPostalAddressView.CountryRegionId   = "AUT";
    dirPartyPostalAddressView.IsPrimary         = NoYes::No;

    dirParty.createOrUpdatePostalAddress(dirPartyPostalAddressView, 
                                         [LogisticsLocationRole::findBytype(LogisticsLocationRoleType::Invoice).RecId,
                                          LogisticsLocationRole::findBytype(LogisticsLocationRoleType::Home).RecId]);
}

Wenn man eine Funktion die über das SysOperation-Framework abgebildet ist per Code aufrufen möchte, kann der folgende Job zeigen, wie man das machen kann.

static void runSysOperationThroughCode(Args _args)
{
    TutorialSysOperationServiceController controller;
    TutorialSysOperationDataContract dataContract;
    SysOperationStartResult sysOperationStartResult;
    
    controller = TutorialSysOperationServiceController::newFromArgs(new Args()); 

    dataContract = controller.getDataContractObject('_dataContract'); 

    controller.parmExecutionMode(SysOperationExecutionMode::Synchronous); 

    dataContract.parmFilenameSave(@"c:\temp\myFile.txt");
    dataContract.parmCustAccount('US-006');
       
    sysOperationStartResult =
    controller.startOperation();
}

Bei der Entwicklung bzw. Anpassung von Dataprovidern eines SSRS-Reports hatte ich in der Vergangenheit immer wieder das Thema, daß das Aufrufen/Testen des SSRS-Reports  oft mehr Zeit beansprucht, als die eigentliche Anpassung im Code.

Deshalb ist folgender Job entstanden, der mir lediglich den Inhalt der vom Dataprovider erstellten (temporären) Tabelle als einfaches Infolog ausgibt.

Das ist vor allem dann hilfreich, wenn man den Dataprovider (abgeleitet von SRSReportDataProviderBase) zur Fehleranalyse debuggen möchte, das aber aufgrund seiner Programmierung aber vielleicht nicht so ohne weiteres möglich ist. Im Beispiel handelt es sich um den Bericht "Arbeitsbeschreibung" aus dem Service-Modul.

static void testSSRSDatProvider(Args _args)
{
    SMAWorkNoteTmp      tempTable;
    SMAWorkNoteDP       dataProvider = new SMAWorkNoteDP();
    SMAWorkNoteContract contract = new SMAWorkNoteContract();
    Query               query = new Query(identifierStr(SMAWorkNote));

    try
    {
        SysQuery::findOrCreateRange(
            query.dataSourceTable(
                tableNum(SMAServiceOrderTable)),
                fieldNum(SMAServiceOrderTable, ServiceOrderId)).value("00018");

        contract.parmItemConsumption(true);
        contract.parmItemRequirement(true);
        contract.parmExpense(true);
        contract.parmFee(true);
        contract.parmAdditionalNotes(true);
        contract.parmLineText(true);

        if( !contract.validate())
        {
            throw error(error::missingParameter(contract));    
        }

        dataProvider.parmDataContract(contract);
        dataProvider.parmQuery(query);
        dataProvider.processReport();

        tempTable = dataProvider.getSMAWorkNoteTmp();

        while select tempTable
        {
            info(tempTable.otServiceOrderId);
        }
    }
    catch (Exception::Break)
    {
        info("Aborted");
    }
}

In diesem Blog-Beitrag habe ich schon einmal beschreiben, wie man in Dynamics AX das Label eines Dialogfeldes auslesen kann, das folgende Beispiel macht das gleiche in Dynamics AX 2012.

static void getDialogFieldLabel(Args _args) 
{ 
     Dialog dialog = new Dialog(); 
     DialogField df_Project; 
     DialogField df_AmountMST;
 
     str getLabel(DialogField _df) 
     { 
         formStringControl fsc; 
         
         fsc = _df.fieldControl(); 
         
         return fsc.labelText(); 
     } 
      
     df_project   = dialog.addField(extendedTypeStr(ProjId), "Mein Projekt"); 
     df_AmountMST = dialog.addField(extendedTypeStr(AmountMST)); 
     
     dialog.run();

     info(getLabel(df_project)); 
     info(getLabel(df_AmountMST)); 
}

Vor kurzem benötigte ich in einem View, dessen Datenquelle eine abgeleitete Tabelle (im Beispiel EcoResDistinctProductVariant) enthielt, die TableId dieser Tabelle als Feld. Also erstellte ich ein neues Feld, wählte die Tabelle aus und das Feld TableId aus dem DropDown.

Der View

Eigenschaften des Feldes TableId1

Leider brachte dies nicht das erwartete Ergebnis, wenn ich den View öffnete, wurde das Feld immer mit NULL ausgegeben.

Mit setPrefix() kann man in die Infolog-Meldungen ganz einfach Verschachtelungen erzeugen.
Was ich bisher noch nicht kannte ist, daß man solche Prefixes direkt in die Meldung integrieren kann, indem man die eigentliche Meldung um die gewünschte Überschrift und das Steuerungszeichen für einen Tabulator erweitert.

static void inlinePrefix(Args _args)
{
    setPrefix("Inhaltsverzeichnis");
    info("Kapitel 1\tSeite 1");
    info("Kapitel 1\tSeite 2");
    info("Kapitel 1\tSeite 3");
    info("Kapitel 2\tSeite 4");
    info("Kapitel 2\tSeite 5\tAbschnitt 1");
    info("Kapitel 2\tSeite 5\tAbschnitt 2");
    info("Kapitel 2\tSeite 6");    
}

Das Infolog des obigen Jobs sieht wie folgt aus:

Eine häufige Anforderung im Projekt-Alltag ist es, Journale verschiedenster Art per Code zu erstellen. Darüber habe ich auch schon den einen oder anderen Beitrag verfasst.

Vor kurzem hatte ich eine ähnliche Anforderung, allerdings sollte dabei das Journal nicht gleich gebucht werden, sondern es sollte nur sichergestellt sein, daß diese Journale nicht unabsichtlich von anderen Benutzern verändert werden.

Und genau für diese Anforderung ist der folgende Code gedacht:

JournalTableData::updateBlockServer(
    prodJournalTable, 
    JournalBlockLevel::None, 
    JournalBlockLevel::InUse, 
    false);

Statt wie im Beispiel die Tabelle ProdJournalTable zu serren, kann auch die InventJournalTable auf diese Art & Weise gesperrt werden.