Have you ever had the need or the requirement to create a graphical diagram of the building blocks of your extension? Personally, a lot of time.
I think that explaining an overall solution architecture with a diagram is something that sometimes can help a lot. I personally use diagrams or UML notations a lot during the architectural phase of a software solution or a cloud solution (that involves different entities).
What about AL extensions?
To generate dependencies diagrams for AL extensions I’ve personally used in the past the nice GraphViz feature in the CRS extension (described by Waldo here). But I’ve always checked for something more…
If you’re an heavy Visual Studio user (I’m one of this strange people) I think you know that Visual Studio can create a dependency diagram of your solutions (Code Maps) by using the standard DGML format.
Directed Graph Markup Language (DGML) describes information used for visualization and to perform complexity analysis, and it’s the format used to persist code maps in Visual Studio. It uses simple XML to describe both cyclical and acyclic directed graphs. A directed graph is a set of nodes that are connected by links, or edges. Nodes and links can be used represent network structures, such as elements in a software project.
Why not having the chance to create a dependency graph of an AL extension by using the same format, and then using Visual Studio for analysis?
One year ago, I had the news that the Microsoft’s AL compiler team was working on supporting this feature (cool!) and I’ve started checking the AL compiler executable on quite every release for new “hidden features”. And it’s with the 7.x version of the AL Language extension that silently something is appeared to satisfy my needs 🙂
If you execute alc.exe /?, this is now the output:
As you can see, there’s something interesting here: a /generatecrossreferences parameter, that permits you to generate cross-reference information files. Interesting (a DGML file is basically a file that contains all code cross references)… but unfortunately, at the moment there’s no documentation on this.
To explain this hidden feature of the AL compiler, let’s consider the extension example that is present at the beginning of my “Mastering Dynamics 365 Business Central” book. This sample shows different things and tricks/patterns for creating AL extensions. The example creates a base extension (here called D365BCDemoExtension) and then creates a dependent extension (here called D365BCDemoDependencyExtension).
What happens if I want to have a dependency diagram of this dependent extension (here called D365BCDemoDependencyExtension)?
You can execute the following command:
alc.exe /project:PATH_OF_YOUR_PROJECT /packagecachepath:PATH_OF_YOUR_PACKAGES /generatecrossreferences
to generate a diagram of object dependencies in your apps.
To show this is action, I’m launching the following command from the Windows Command Prompt:
alc.exe /project:"C:\Users\StefanoDemiliani\Demo\D365BCDependentExtension" /packagecachepath:"C:\Users\StefanoDemiliani\Demo\D365BCDependentExtension.alpackages" /generatecrossreferences
and this is the magic output:
I have two new files created, and one is a DGML file… WOW!
Let’s open the DGML file with Visual Studio:
Wow… there’s a diagram of our extension with all the dependencies!
P.S. If you see only an XML file, you need to install the DGML Editor first (Tools –> Get tools and features –> Individual Component –> search for “DGML Editor”).
What’s really cool about that? It’s a DGML file, so you can inspect and navigate it. I can click for example on my D365BCDemoDependencyExtension and see the dependencies between objects declared in this extension:
You can explode every object of your application and see the dependencies of other objects on different apps simply by selecting the object that you want to inspect:
Very powerful, isn’it?
In this way you can create detailed diagrams of your extensions in order to better analyze your solutions. If you click on an object, you can immediatly discover the impact that this object has on other objects on your solution.
You can use this feature on every AL solution you have. If you have a complex solution (with tons of objects and links between objects), Visual Studio can have difficulties on opening your DGML file (it can take times due to the nodes and links numbers).
If you want something more on your Visual Studio to work with DGML files (expecially for large files), I recommend to install the DgmlPowerTools extension:
This extension adds some commands to the DGML viewer bar of your Visual Studio. For example, the Neighborhood mode allows you to filter the graph to show only a specified number of degrees of freedom away from the selected node, the Butterfly mode removes cycles in the graph so that you see only the tree of incoming and outgoing dependencies around the selected node, you can compare DGML graphs, you can aspply filters on the graph and make auto-grouping and more.
Visual Studio is my recommended tool for working with DGML files. If you want to use Visual Studio Code, just remember that there are some third-party extensions that work with DGML files but honestly I’ve not found them so reliable (DGMLViewer extension for example throws errors).
This AL language feature is actually undocumented, so expect to see more in the future (like the integration with the VS Code command palette). For the moment, if you need a solution diagram you have a great hidden tool at your fingertips… 😉
Stefano Demiliani 