ArcherPoint Dynamics NAV Developer Digest - vol 233
The NAV community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV experts and devotees around the world. We hope these insights will benefit you, too.
How to Find All Published Events in a NAV Database or Object
Suresh shares: “To find all the published events in the database or on in a specific object type/object, choose the All Events Boolean on the page, or for a specific object type, set the Object ID to 0. You can also view the code and subscribers for a particular event from the page.”
Kyle adds: “If you are in AL, this can (almost) be done directly. Suppose you want to see all of the published events for Codeunit 80. Define a variable of type Codeunit for ‘Sales-Post’. Right-click on ‘Sales-Post’ and do Go To Definition. It won’t show you any code, but it will show you all public functions and published events.”
Matt T reminds us: “Don’t forget that you don’t even need to know all of the published events. Just use the events recorder. Start it, execute your process just like the user would, stop it, and look at all of the events that were hit.”
How to Call an XMLport in AL
Kyle gives us another Developer Tip of the Day: “How to call an xmlport in AL. This took me a bit of internet research and experimentation to get it working. In the new cloud/BC/D365 world, for security reasons, we are not given access to local filesystems. So they had to come up with a different way to get files into an xmlport using a ew function called UploadIntoStream.
I could not figure out how to get it to stop prompting – sometimes I know the filename and don’t need a prompt, but UploadIntoStream insists that the filename variable be writeable. It prompts, and then returns you the filename you selected.
codeunit 50099 “Temp Kyle”
{
trigger OnRun();
begin
InFileName := ‘c:sharePricing.xml’;
UploadIntoStream(”, ”, ”, InFileName, InFileStream);
PricingXML.SetSource(InFileStream);
PricingXML.Import();
Message(‘Bing!’);
end;
var
PricingXML: XmlPort “Temp Pricing Import”;
InFileName: Text;
InFileStream: InStream;
}
Text Constraints and Naming Conventions in C/AL
Kyle has a question: “Question about text constants. Should we switch to names like KyleIsADorkErr or stick with Text001 in C/AL development?”
Helle: I believe naming the text constant ‘KyleIsADorkErr’ is more correct now, and Microsoft switched to that naming convention some years ago, because it’s more meaningful and readable. As always, it takes a while with new standards to catch up, because MS doesn’t change code just to change it! They did that once for naming variables, and it became a nightmare.”
Subscriber Codeunits: A Discussion
Suresh asks: “Should the subscriber Codeunits have only the Event subscriber functions, or can we add other functions into the Codeunit which we use or call in the Subscriber Function? I always limited those Codeunits to only have subscribers and have added other functions/helper functions into a new separate Codeunit called ‘Sales Management’ or ‘Purchase Management’ based on the module and called those in them. But just want to check how everybody is doing this.”
Bill W offers: “As far as I know, it’s not a standard to split it out. I personally don’t have a problem adding other functions in the subscriber Codeunits.”
Kyle H adds: “I add in other functions, but I make sure they apply to that same publisher Codeunit. Usually little tools that enable the subscribers to do what they need to do, top-down style.”
Bill W agrees: “Yes, good point. I also make them directly applicable to the contents of the subscribers. You wouldn’t find some random Job Planning line function in the Sales Header subscriber Codeunit.“
Matt S states: “I do it by functionality of purpose. A subscriber can be part of a piece of local purpose. For example, in CSM, order management subscribes to sales document post published Event to gather information needed to know when it needs to submit shipping information to Magento or Amazon.”
Tom H includes: “I generally add local functions to the subscriber codeunit, assuming that the functions would only be used by that Codeunit. If there was a function that could do work for another Codeunit, I’d put it in a management Codeunit.”
We welcome your comments on this edition of Developer Digest.
If you are interested in NAV development, be sure to see our collection of NAV/BC Development Blogs.
Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.