Eric's Tech Blog

 Microsoft recently changed their rules regarding Azure issued token expirations.  Tokens will now expire after an hour and it appears there's very little you can do about that.  So, what do you do?  You need to make use of the refresh token.  A refresh token allows you go generate a new token and will have a much longer expiration time - Azure tokens have a three month lifespan by default.  When you generate a new token, you get a new refresh token also.  This means that while your token only lasts an hour, you can go as long as three months before you need to actually go through the token request process again.  As long as you use your refresh token before it expires (and it's not revoked), your access will effectively never expire. From a security perspective, this is a good thing as it limits the damage that a misplaced token can do since a token can be revoked in no more than an hour.  From a development perspective, it means that applications using these tokens will now h

I was recently setting up Zetadocs on a new server (existing database) and I got this message when closing the General Settings screen. Exception of type 'Microsoft.Dynamics.Nav.Types.Exceptions.Encryption.NavEncryptionKeyNotFoundException' was thrown. I couldn't find the error anywhere in Google, hence this post.  The problem is that on a new server, the key needed to decrypt Sharepoint Online's login information will not have been installed.  To fix this, first connect to the service where Zetadocs was first installed (or is working) and open the Enrcryption Management screen. Click the "Export Encryption Key" button and save the key to a file.  You will be prompted to secure the file with a password. Once you have the file saved, copy it to the new server then go into the Encryption Management screen on its service and click "Import Encryption Key".  Enter the password for your file and the new key will be imported.

With Microsoft's declaration of intent to remove support of basic authentication for cloud Business Central instances, it's time to start figuring out the not-so-new kid on the block: OAuth.  OAuth (Open Authentication) has been around for some time now and it provides many advantages over legacy methods.  One of the biggest ones has been Single Sign On.  Rather than having to create a multitude of accounts for an ever growing list of websites, you can use you Gmail account or Facebook login.  The client site then gets a token that is unrelated to your actual credentials and you have one less password to worry about.  Of course, this all comes at a cost and it can be pretty painful if you have any applications that need to be migrated and you are on the bleeding edge where documentation is sparse and a bit confusing.  After trudging through the muddy waters of Business Central OAuth documentation, I'm pleased to say I've come out the other side and I can now help you,

First, forgive the title of this post.  I couldn't help myself. Now that we're past that, every now and then I get called on to make SOAP work for customers.  It used to be pretty popular back in the day (2009-ish) but now REST (specifically OData in the NAV/BC world) is all the rage.  I like OData, it's easier to work with for most purposes but even now there are still a few things that SOAP is better at.  One thing that makes SOAP difficult is that it's got a more complex structure and is not easily understood.  With OData, you just set your verb and give it a little JSON and you're up and running.  I recently had to help someone get SOAP working and in the process I debugged the calls with Wireshark and Fiddler and I wanted to document what I got out of that.  It might just help me a few years from now and help someone else sooner. First the basics.  In the interest of being complete, I'll jot down the first steps just in case anyone else is looking.  To get

Today I was updating some report objects from a text file for an older BC13 upgrade.  Yes, even at this late date BC13 can be an "upgrade".  Long story.  Anyhow, in the process of pulling in reports I got an error message To upgrade reports, you must have Microsoft SQL Server 2016 Report Builder installed. The problem is, I did have SQL Server 2016 Report Builder installed.  Some cursory Googling revealed that someone else had run across this and their solution was to install an older version of the report builder.  Not satisfied with this option, I ran the import under Process Monitor .  Process Monitor showed that BC was looking for Microsoft.ReportingServices.RdlObjectModel.dll and not finding it.  Sure enough, that file was nowhere to be found.  I did find an article on that indicating that it was a part of older report builder installations and I managed to find it on my development system under some Docker containers (of all places).  I copied it to the RoleTailored Cl

 Recently, I've noticed that trying to debug a sandbox that isn't named "Sandbox" has not worked.  The first few times I just worked around it but I finally came to a place where I couldn't ignore it anymore.  While my extension was deploying to the correct sandbox, the browser was opening to the default sandbox and errors were just causing the web client to hang and VS Code's debugger to terminate.  The solution was pretty simple: there is a server option in the launch.json that you can use to specify the correct URL.  Once I did that, debugging worked as it should.