Custom menu items licensing caveat

In Dynamics 365 Finance and Operations (F&O) menu items are used to launch forms, operations or processes, reports and more. When a developer creates new form, runnable class or report, a custom menu item is also created to launch that particular new form, runnable class or report.

In the application, menu items have two licensing properties:

• Maintain User License
• View User License

When a new custom menu item is created, the default value of the Maintain User License and View User License properties defaults to None. At first glance, this fine and is not changed by most developers. In fact, this is dangerous because but the None value is automatically translated Enterprise or Operations in most cases unless specified otherwise by the underlying AOT elements. So for customisations, it always translates to Enterprise.

The important message here is: on your custom menu items, don't leave the value of the Maintain User License and View User License properties to None, always set the Maintain User License and View User License properties to Universal. Unless your custom menu item is referring to a standard element of course, then you can set it accordingly.

How to view data in a temporary table using SQL Server Management Studio

Temporary tables are used quite often in Dynamics 365 Finance and Operations (F&O) and you can find them everywhere in the standard code and forms. There are different types of temporary tables but in this article we are using the TempDB type. The main advantage of the TempDB type is that you can join them with regular tables because they physically exist in the database.

Every time a temporary table is instantiated in F&O, an actual table is created in the SQL Server tempdb database. The name of the table is unique each time. When the temporary table buffer in F&O goes out of scope, the data in the temporary table is discarded and the table is automatically deleted at some point.

Sometimes when you are troubleshooting code that's using a temporary table, you need to view the contents of a temporary. This cannot be done easily like a regular table using the F&O table browser or SQL Server Management Studio (SSMS). So this begs the question, how do you actually view the data of a temporary table?

The answer is by using the X++ getPhysicalTableName method of the intantiated temporary table. This retrieves the physical SQL Server table name of the temporary table. The most basic method is to temporarily add a line of code using the info method to display the table name. You can then use the table name to query the database with SSMS and view the data as long as the temporary table buffer is still in scope in F&O.

Warning: don't do this in production! The above is only applicable for dev and sandbox environments. This article is for education purposes and does not explain the best possible way to get the table name for your situation. To make thing a bit more elegant, you could write the table name to a log table (e.g. SysExceptionTable) instead of displaying a message in the infolog and you could do execute the line of code for your user account only. This way users won't notice it's there.

Get the physical SQL table name in code

public class MyTmpTableTest
{
    public static void main(Args _args)
    {
        TmpRecIdFilter tmpRecId; //note: TableType must be TempDB
    
        //add some dummy records to the temp table.
        for (Counter cntr = 1; cntr < 50; cntr++)
        {
            tmpRecId.RefRecId = cntr;
            tmpRecId.insert();
        }

        //show the temp table name. this is the only line of code you need,
        //the rest of the code here is just for this test class.
        info(tmpRecId.getPhysicalTableName());

        //for this test class we use a work around to keep temp table bufffer
        //in scope so that the data can be viewed using SSMS.
        //as soon he main method exists and the temp table buffer is out of
        //scope, the data will be lost in the table.
        Box::infoOnceModal('Table name', 'Table name', tmpRecId.getPhysicalTableName(), curUserId());
    }
}

Viewing the data in SQL Server Management Studio

• Get the table name.
• Connect to the F&O database using SSMS.
• Open a new query with the table name form the first step e.g. "select * from [your_temp_table_name_here]"

Get the last workflow comment

The code snippet below retrieves the last workflow comment of a workflow using the workflow correlation ID.

One of my customers requested a custom workflow with a separate approval e-mail message in Outlook using a custom template in F&O. In the email message, they wanted the full details from F&O including the comment of the person who submitted the workflow for approval.

To answer a question about this on the Microsoft F&O forum, I found this code in my code archive and thought it might be worth sharing.

public static str getLastTrackingComment(WorkflowCorrelationId _workflowCorrelationId)
{
    WorkflowTrackingTable           trackingTable;
    WorkflowTrackingCommentTable    trackingCommentTable;

    if (_workflowCorrelationId)
    {
        trackingTable = Workflow::findLastWorkflowTrackingRecord(_workflowCorrelationId);

        if (trackingTable)
        {
            trackingCommentTable = WorkflowTrackingCommentTable::findTrackingRecId(trackingTable.RecId);
        }
    }

    return trackingCommentTable.Comment;
}

Use a custom form as a dialog in a custom runnable class

Sometimes there is a requirement to perform a simple operation in Dynamics 365 Finance and Operations using some limited input from the user before the operation is executed.

A real world example of custom records and a custom form to view, edit and process "records" Due to customer privacy, I can't use the real names of the records and will just refer to the data a "record". The requirement is to update a single field of a read only record. The record is not allowed to be edited in the form because of its status. In the form datasource active method, there is code to check the status of the record and sets the datasource allowEdit property according to the status of the record. However, due to certain factors, sometimes the record is not processed in time and the date of the record is not current anymore, it's now in the past. This creates a catch 22. This record cannot be processed because the date is in the past and the date cannot be updated because it's read only due to the status. The solution is, the clicks on a menu item button on the form to change the date of the record. When the user click the menu item button, a dialog is displayed showing a date field. The use can only choose a date in the future. The validation on the form makes sure a valid date is selected when the user clicks in the OK button.

This article recommends some basic level of code knowledge and desing patterns and doesn't go into detail and inner workings of the code. However, it demonstrates a simple pattern for a runnable class using a custom form dialog.

Recommended code knowlege:

• You know what a runnable class is
• You have basic knowledge of how the runnable class pattern works
• You know how to create a form of type dialog and know ho to add input fields on the form
• You know how to add validation on the form to validate the user input data
• You know how to ge variable values in code from a form object of the input fields of the form

What you need to do to implement the pattern (in a nutshell):

• Create your own runnable class with a static main method, run and prompt methods
• Create your own form (type dialog) with required input fields on the form.
• Add an OK button to the form that calls the forms closeOK method.
• Add an Cancel button to the form that just closes the form whithout doing anything
• Copy the code below to your own runnable class.
• Change the class name on the main method to your own class
• Change the form name in the prompt method to your own own form name
• Retrieve the input values from the form object in the prompt method if user has clicked the OK button
• Finally, implement the business logic in the run method

Runnable class code

public final class MyCustomRunnableClassWithCustomFormAsDialog
{
    private FormRun mFormRun;
    //add input form class variables
    
    public void run()
    {
        //add logic here.
    }
    
    public boolean prompt()
    {
        Object obj;
        
        mFormRun = classFactory.formRunClass(new Args(formStr(MyCustomFormDialog))); // Change form name.
        mFormRun.init();
        mFormRun.run();
        mFormRun.wait();
        
        if (mFormRun.closedOk()) //did the user click OK?
        {
            obj = mFormRun;
            //retrieve form variables values from form obj and set class variable here.
        }
        
        return mFormRun.closedOk();
    }
    
    public static void main(Args _args)
    {
        MyCustomRunnableClassWithCustomFormAsDialog operation = new MyCustomRunnableClassWithCustomFormAsDialog();
        
        if (operation.prompt())
        {
            operation.run();
        }
    }    
}

Extended Data Types

This is another article I wrote ages ago that was originally published on Axaptapedia, which no longer exists. I found a copy online thought it was worth sharing as a blog as most of it remains relevant for Dynamics 365 Finance and Operations.

I have not edited the content but I left out a part about creating EDTs in code by an another author who added that later.

Side note: An extended data type is also referred to a an EDT.

Okay, enough of that. Let's start!

Introduction

Extended data types are very important and if used correctly, very powerful. An extended data type is a user-defined definition of a primitive data type. The following primitive data types can be extended: boolean, integer, real, string, date and container.

Inheritance

Name is a standard string EDT that represents the name of a person, company or object. If a property on Name is changed, all EDT's that inherit from it will automatically reflect the changed value. For example if the standard length is not long enough, it can be increased and all child EDT's will automatically be increased along with it. All database fields, forms and reports where the EDT is used, will also reflect the changed property.

Properties

Some of the properties that can be modified are StringSize, Alignment, DisplayLength, Label and HelpText.

Number sequences

When creating a number sequence, an extended data type is required to associate the number sequence with.

Advantages

1. Consistency in data model, forms and reports.

2. Automatic lookups (if table relation property is set).

3. Improve readability in code.

Use PowerShell to search for labels fast

Here is a quick and simple method I use a lot to search for labels using PowerShell. It's seriously fast!

Let's start.

1. Open PowerShell and change the current directory to your LocalPackages folder. Change the path according to your system. Make sure you have enough permission on the local packages directory. This is why I always open PowerShell as Administrator.

cd C:\Users\mrbean\AppData\Local\Microsoft\Dynamics365\10.0.1935.92\PackagesLocalDirectory

2. Let's search for the label "Invoice" using the PowerShell "findstr" command. The command below will search in all the en-US label files.

findstr /s /l /i /n /E /c:"=Invoice" *en-US.label.txt

Explanation of the command arguments:

• /s: Searches subdirectories.
• /l: Performs a literal search (case-sensitive by default).
• /i: Makes the search case-insensitive.
• /n: Displays line numbers in results.
• /E: Matches the pattern at the end of a line.
• /c:"=Invoice": Searches for the exact string =Invoice.
• *en-US.label.txt: Targets all files with the en-US.label.txt extension.

Note: The "/E" argument in the PowerShell command returns all lines of text that end with "Invoice". Because we are dealing with Dynamics 365 Finance label files that have and ID and label text separated with an "=" I've included "=" in the search. The causes the command to return the exact labels we search for. Copy and paste the label ID from the results.

Methods as table fields in workflow designer

The problem is that by default, only table fields are visible in the workflow designer and sometimes it is required to use business logic to drive the workflow.

The solution to this problem is to add custom parm methods to the workflow document class of the workflow in question. The example below is from one of my custom workflows. I have simplified the code a bit for this example.

If you are working with a standard workflow, you could add your own parm methods in a class extension of the workflow document class.

The parm methods must have three arguments. In the example below, the workflow is based on SalesTable (don't ask ne why). So the TableId and RecId passed to the parm method by the system is related to the current SalesTable record. You will have to modify this to find the related record in your workflow of course.

Note:

• Add methods to the workflow document class (class extending WorkflowDocument).
• The parm method must have three arguments: CompanyId, TableId and RecId.
• The method name must start with "parm".

Example

    public class MyApprovalWorkflowDocument extends WorkflowDocument
    {
        public MyEnum parmHasCreditLine(CompanyId _companyId, TableId _tableId, RecId _recId)
        {
            SalesTable salesTable;
            MyEnum hasCreditLine; //custom base NoYes enum with label which will be visible in the workflow designer

            changeCompany(_companyId)
            {
                salesTable = SalesTable::findRecId(_recId);

                if (salesTable)
                {
                    if (salesTable.type().myHasCreditLine())
                    {
                        hasCreditLine = MyEnum::Yes;
                    }
                    else
                    {
                        hasCreditLine = MyEnum::No;
                    }
                }
            }

            return hasCreditLine;
        }
    }