AL Developer Preview – November 2018

Microsoft is ready with the November update of the Developer Preview

With this release, we bring you several new features that help building your solutions as extensions. Again this month we have fixed a large number of GitHub issues, see what’s been closed here: closed bugs in November.

This Developer Preview is available only through the Ready to Go program. Read more at http://aka.ms/readytogo. To get all fixes and features described in this blog post, please make sure that you are running an image with build number 26070 or newer.

https://community.dynamics.com/business/b/businesscentraldevitpro/archive/2018/11/19/developer-preview-november-2018

Blog text:

AL GitHub

In the period since the Business Central Fall 2018 release until now we have focused primarily on bringing down the number of active issues on AL GitHub repo. We have reduced the backlog from close to 900 active issues down to ~320. This was achieved through a combination of delivering ~350 fixes in the November update, close follow up on any outstanding questions and input-needed issues as well as by process change.

The process change is that AL GitHub from now on accepts only bug reports and feature requests related directly to AL and developer tools for Business Central insider builds. This means that:

• Any application related inquiries or requests should be directed to https://github.com/microsoft/ALAppExtensions

Any general questions should be directed to our support team or community forums:

• Business Central Community
• mibuso forum
• Dynamics User Group

Any issues related to already released versions of the product should be directed to our support team. You can open Support Request to CSS through PartnerSource portal or contact your Service Account Manager (SAM) in the local subsidiary to understand what is included in your contract as of support incident and PAH (Partner Advisory Hours). Your SAM might also step by step direct you how to open a support request or how to get credentials if this is the first time for you/your company.

Option to avoid new session upon deployment with CTRL + F5

A new launch.json option has been introduced – launchBrowser. This property indicates whether or not to open a new session – a new tab in your browser – upon publishing your AL extension. If the value is not specified or set to true, the session is started. If the value is explicitly set to false, the session is not started unless you launch your extension in debugging mode.

.NET Control Add-Ins

Legacy .NET Control Add-Ins can be used from AL through .NET interoperability. This type of add-ins is only supported in the Windows client and going forward we recommend that you convert your existing .NET and Javascript add-ins to native AL controladdins.

Given the following stub definition of the “Microsoft.Dynamics.Nav.Client.PingPong” .NET add-in:

namespace Microsoft.Dynamics.Nav.Client.PingPong
{
    /// <summary>
    /// Add-in for pinging the server from the client. The client will respond with a pong.
    /// </summary>
    [ControlAddInExport("Microsoft.Dynamics.Nav.Client.PingPong")]
    public class PingPongAddIn : WinFormsControlAddInBase {…}
 
}

We add the type declaration in AL making sure to reference the full type name and to set the IsControlAddIn property to true:

dotnet
{
    assembly("Microsoft.Dynamics.Nav.Client.PingPong")
    {
        type("Microsoft.Dynamics.Nav.Client.PingPong.PingPongAddIn";PingPongAddIn)
        {
            IsControlAddIn = true;
        }
    }
}

We can now use it from a page as a native control add-in.

page 50100 MyPage
{
    layout
    {
        area(Content)
        {
            usercontrol(PingPongControl; PingPongAddIn)
            {
                trigger Pong()
                begin
                    Message('Pong received.');
                end;
 
                trigger AddInReady()
                begin
                    Message('Ready');
                end;
            }
        }
    }
}

If you have a native add-in and a .NET add-in with the same name, inside a project, the .NET add-in will be the one used.

Testing Reports in AL

If you need to validate if a report produces correct data, you should use – Codeunit 131007 “Library – Report Dataset”. Extensions cannot use the file share as we used in the existing tests, so we need to save the reports to stream.

Usage

To initialize the class, you can use two methods:

• (Preferred) RunReportAndLoad – will run the report and initialize the Library – Report Data Set class
• LoadDataFromInStream – if you want to run the report separately and load the data in the instream manually

To verify the output you can use these two methods:

• AssertElementWithValueExists
• AssertElementWithValueNotExist

The other methods in the library should work as well as long as they do not contain “Tag” in the name.

Code example

// Exercise: Run the Report Remittance Advice - Journal.
XmlParameters := REPORT.RUNREQUESTPAGE(REPORT::"Remittance Advice - Journal");

LibraryReportDataset.RunReportAndLoad(REPORT::"Remittance Advice - Journal",GenJournalLine,XmlParameters);
 
// Verify: Verifying Total Amount on Report.
LibraryReportDataset.AssertElementWithValueExists('Amt_GenJournalLine',GenJournalLine.Amount);
 
RUNREQUESTPAGE is optional, it may be used to control the request page parameters. You need to implement RequestPageHandler in this case:

[RequestPageHandler]
PROCEDURE RemittanceAdviceJournalRequestPageHandler@4(VAR RemittanceAdviceJournal@1000 : TestRequestPage 399);
BEGIN
// Empty handler used to close the request page. We use default settings.
END;

Any changes done in the handler above will result in the XmlParameters being changed and applied automatically when the report runs. Examples of the implementation in the existing tests can be found in  Codeunit 133770 and Codeunit 134141.

Technical details

TestRequestPage SaveAsXML is using a different format than REPORT.SAVEASXML or REPORT.SaveAs. The reason is that the TestRequestPage.SaveAsXML is serializing the output of Report Previewer. This component will be deprecated at some point in the future; the new methods should be used for new tests. TestRequestPage SaveAsXML requires files to be saved to disk and loaded, while other methods work in memory, thus they are more efficient.

Because we need to support the existing tests, the codeunit is supporting both formats for now. TestRequestPage SaveAsXML is using Tags for values, while the new format uses attributes. This means we cannot use any public method that contains Tag in the name to test the reports generated in the memory.

AL Language Extension is now also supported on MacOS

Finally! After having been work in progress for more than 2 years, the distributed .vsix file is now supporting both Windows and MacOS.

The MacOS version contains the same functionality as the Windows version. There are, however, a few differences/limitations compared to the Windows version.

• Windows authentication is not supported.
• AAD authentication is using device login (http://aka.ms/DeviceLogin) to authenticate. The user experience is different. Instead of getting a login dialog, a notification window is shown in the lower right corner. The window shows the device login URL and the device code. Clicking the ‘Copy and Open’ button will place the code on the clipboard and open a browser on the device login page.

• RDL editing is not supported on Mac. ReportBuilder is Windows only, and there is no other available tool for editing the RDL.
• Word editing is limited. The “XML Mapping Pane” feature is not available in the MacOS version of Word so it is not possible to add fields to the document.
• Reports datasets, code, and requestpage can still be designed, modified, and deployed using the MacOS version.

 The MacOS version must be 10.12 (Sierra) or newer.

Outline View

The Outline view is a separate section in the bottom of the File Explorer. When expanded, it will show the symbol tree of the currently active editor.

The Outline view has different Sort By modes, optional cursor tracking. It also includes an input box which finds or filters symbols as you type. Errors and warnings are also shown in the Outline view, letting you see at a glance a problem’s location.

Isolated Storage

Isolated Storage is a data storage that provides isolation between extensions, so that you can keep keys/values in one extension from being accessed from other extensions. Keys/values in the Isolated Storage are accessible through an API. The involved data type is DataScope.

The methods supported for the DataScope data type are:

The DataScope Option Type Identifies the scope of stored data in the isolated storage.

DataScope is an optional parameter and if it is not passed the value would be Module.

Multi ID Ranges

Support for multi ranges for application object IDs. You can add an “idranges” property to the app.json which is an array of “idrange”. The “idrange” is still valid but you must either use “idrange” or “idranges” in the app.json file. For all objects outside the range, a compilation error will be raised. When you create new objects, an ID is automatically suggested from the first available range. Overlapping ranges are not supported and generates a compilation error will be raised.

Update to the AL reference documentation

Maybe you’ve already noticed, but last week, we refreshed the documentation with a new set of reference help for methods. We now have a 100% reflection of the methods that are available in AL with their syntax, parameters, return value and more. This is only a step on the way to having the same for properties and triggers, we will be working on this in the coming months. For now, explore the new methods here: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/library.