Thoughts on element prefix vs. suffix

When I read Evaldas Landauskas’s blog post Development guidelines: Prefix Vs. Suffix, I thought I would write a comment below the post and share a few ideas, but then I decided that it’d be better to write my own blog post. Here I have a much better control over formatting and the content will be more visible than if it’s hidden in a mere comment.

I’m not going to dispute the argument that prefixes are better; I’ve seen teams using various approaches and I’m fine with most of them. On my current projects, we also use prefixes for most things. But I want to add a few more things to consider.

The statement that you can’t search objects by suffix because you can’t handle those ending with _Extension is underestimation of regular expressions. For example, if I want to find elements ending with either Xyz or Xyz_Extension, I can use Xyz(_Extension)?$. Is it complicated? Yes, a bit. Is it impossible? Definitely not.

Nevertheless are we doing the right thing in the first place? Isn’t our goal to find elements in our model? If so, searching by a part of name doesn’t really match our intention. We should model:”XYZ project” instead.

Finding all elements starting with a company prefix is nice, but it’s not what people usually need. A more common task is finding extensions of an existing element, such as a table. I think this should be really easy, because it’s both common and important, but we lack really good tools for that. As a workaround, some people choose starting names of extension classes with the name of the original object, which allows them to see all extensions together. We can use regular expressions again to deal with prefixes as well, such as searching for something like type:class SalesTable.*_Extension$, but any solution based on name simply isn’t good enough, in my opinion. And references aren’t great for this purpose either. But we have to live with what we have, or to build better tools.

Changing the topic, I’m also not sure where this statement came from: “We should follow Microsoft’s pattern and suffix it as well.”. As far as I know, Microsoft doesn’t address vendor prefixes/suffixes at all and general naming conventions say that “A subject area specific application object is prefixed with the name of the subject area the object belongs to, for example Cust*, Invent*, Ledger*, Proj*, Vend*”. Therefore names like RevRecAmountPercentList look correct to me.

We surely can find many places where Microsoft isn’t following best practices, just note that SalesFormLetter extending FormLetterServiceController is a special case. It used to extend FormLetter class, but it has changed when SysOperation framework was introduced. One could argue that the name should have been FormLetter_Sales instead of SalesFormLetter, but naming conventions say that it can be the case and not that it must.

I would like to thank Evaldas for giving me something to think and write about. 🙂

Security API

The product that used to be called Microsoft Dynamics 365 for Finance and Operations (I truly don’t know how I should call it these days) allows defining security elements both by developers (delivered together with code) and by power users though GUI (stored in database). You may have a need to work with security objects in code and you want to get information from both sources. An API providing a unified view would be handy.

I’m not going to cover it in detail, but let me show you an example: an iteration of security privileges and getting information about security permissions contained in privileges:

using Microsoft.Dynamics.AX.Security.Management.Domain;
 
class SecurityApiDemo
{
    public static void main(Args _args)
    {
        var privilegesRepo = SysSecurity::GetSecurityRepository().Privileges;
        var privEnumerator = privilegesRepo.LoadAll().GetEnumerator();
 
        while (privEnumerator.MoveNext())
        {
            Privilege privilege = privEnumerator.Current;
            setPrefix(strFmt("Privilege %1", privilege.Name));
 
            var grantEnumerator = privilege.ActionMenuItemGrants.GetEnumerator();
            while (grantEnumerator.MoveNext())
            {
                MenuItemGrant grant = grantEnumerator.Current;
                info(strFmt("%1 (%2)", grant.Name, grant.Grant.ToString()));
            }
        }
    }
}

Apart from ActionMenuItemGrants, there are also DisplayMenuItemGrants, OutputMenuItemGrants, DataEntityGrants, ServiceOperationGrants and DataModelGrants.

Beta exam MB-500

Today I took the beta exam MB-500: Microsoft Dynamics 365: Finance and Operations Apps Developer; I think it’s going to be made generally available on January. I was already planning to take it when I received an email with a significant discount, therefore I had no reason to hesitate.

They didn’t show me my score – they’ll do it „within two weeks after the exam’s live publication date“. But I don’t think I have to worry…

I usually dislike many exam questions – they’re often vaguely formulated, outdated, off the exam topic, testing things that are easy to test but irrelevant and so on.

Questions of this exam are firmly on topic – I don’t remember any where I would question whether the topic itself is relevant. But there are surely things to improve.

Here a few examples:

All answers of one question mention an action in GUI which simply doesn’t make sense, so technically neither answer is correct. It’s clear that the actual question was about something else, but it may be confusing and it doesn’t look very professional.

In one lab, the ALM process described there doesn’t make a good sense to me and it goes directly against Microsoft best practices, therefore I don’t think it’s a good idea to put it there. Then you must answer questions not based on how things should be done in practice, but what fulfills the artificial restrictions – and hope that authors of the exams didn’t forget about them when defining “correct” answers.

In one question, I was asked to implement a very common piece of code, but the options didn’t include any of the ways how it’s normally done. What I assume is the right answer is technically correct, but nobody would ever do it and I don’t believe that many people remember the method – I didn’t it. I’m convinced that this isn’t what exams should test.

I also found some basics mistakes in code, such as incompatible types that would cause failure already on compilation, or answers that can be correct or not depending on context (which wasn’t provided).

After taking an exam, there is time for evaluation and I was keen to cover all these points in detail there. But the time allocated was completely insufficient; then it simply kicks you off. And when I got a warning popup that I had only one minute left, the UI became unresponsive and I was unable to complete at least the thing I writing at the moment. Effectively, I got even one less minute that intended.

It sounds pretty strange to me – you invite somebody to take a beta exam and give you feedback, but they you make providing detailed feedback impossible. The time slot for evaluation should be longer – even for regular exams, but especially for beta exams that should be all about collecting feedback. And a bit more review of technical correctness wouldn’t harm either.

Calling async method from X++

There is a trend in the .NET world to make time-consuming calls asynchronous, to prevent applications from getting blocked when waiting for a response from a web service and things like that. Many existing APIs were enhanced with asynchronous variants of previously synchronous actions and some newer APIs offer only asynchronous methods. So… how can we call such asynchronous methods from X++?

For a demo, imagine that I want to read the content of a file. I can use StreamReader.ReadToEnd() or the asynchronous alternative, ReadToEndAsync().

ReadToEnd() returns a string, therefore I can simply assign the result to a string variable.

str file = "devenv.exe.config";
 
using (var reader = new System.IO.StreamReader(file))
{
    str s = reader.ReadToEnd();
}

By the way, the code is written for F&O, where we can simplify our code with using and var keywords, but the core logic can be used in older versions of AX as well. .NET Interop as such was introduced in AX 4.0.

ReadToEndAsync() doesn’t return a string, it returns a task returning a string (Task<string>). A task represent a piece of work to be done, in this case reading the file. In normal .NET development, you could use threads for parallel processing for a long time before tasks (Task Parallel Library) were introduced, but tasks make it all much easier. It’s been further enhanced by adding async and await keyworks to languages such as C#, which allows writing code for dealing with asynchronous methods in a very succinct way.

We don’t have async/await in X++, but we surely can work with tasks directly. When I call an async method, I get a task object and the easiest thing I can do with it it is waiting for completion and then accessing the result:

str file = "devenv.exe.config";
 
using (var reader = new System.IO.StreamReader(file))
{
    var task = reader.ReadToEndAsync();
    task.Wait();
    str s = task.Result;
}

I’ll get exactly the same result as in the synchronous variant mentioned above.

This is actually a synchronous execution of an asynchronous API, therefore it doesn’t bring many advantages for parallelism, but it’s often what you want anyway. For instance, you call your logic from a batch job (you don’t mind blocking), you can’t continue without the result and the API doesn’t support synchronous operations.

You can build something more interesting on top of this simple example. For instance, you can create several tasks (without calling Wait()), put them into an array and then use Task.WaitAll() to execute all of them at once (in parallel if possible) and wait for completion.

To make things truly asynchronous, you would need callback methods instead of waiting for completion.