Out-of-the-box Business Central APIs often use complex types. Addresses on entities and documents, line details, units of measures, journal dimensions, these are just a few examples. There may be more. A typical instance of a complex type looks like this:
The question is: can you do something like this in your own custom APIs?
And the answer is: yes and no.
Let’s start with the “yes” part of the answer.
Just in case you have fallen victim of the confusion I see often in online communities, blogs, but also Microsoft official documentation: Dynamics 365 Business Central sandbox is not the same as Dynamics 365 Business Central preview. They are two different things. Keep in mind, in this blog post I am not talking about sandbox container environments (on-prem); I am only talking about online sandbox environments.
This is not pure semantics. Things in sandbox environments (and I mean, real sandbox environments of Business Central) differ from things in preview environments.
In just under two weeks I’ll have to present how to use OAuth 2.0 authentication to call REST APIs of Dynamics 365 Business Central. Should be easy. Not only I have already done
OAuth integrations, but there is also a nice step-by-step tutorial by Microsoft specifically done for Business Central. So, I followed the steps to the letter (as much as that was possible), and after all was done, I tried to use Postman to get myself an OAuth 2.0 token for invoking Business Central REST APIs, but it didn’t work. No matter what I did, Postman kept returning this:
(Could not complete OAuth 2.0 login. Check Postman Console for more details.)
So I checked the Postman Console for more details.
(access_denied; Error)
Quite some detail.
After a ridiculous amount of time troubleshooting this, I figured it out. Depending on how your Business Central trial account was configured you may encounter this problem. On top of it add the fact that the documentation isn’t exactly straightforward and at couple of places leaves you (educated-)guessing. So I decided to write this blog in case you (or myself at some future point after I will have forgotten I’ve been in this mess) ever need it.
In the last post, I explained how to use tasks, but I didn't explain yet how to make them useful. Tasks are most useful when they automate certain file operations,…
Now that you know how to get gulp up and running in VS Code, and how to export tasks from your gulp file, let’s talk about tasks themselves. What are they, what are they good for, and how to write them.
Gulp – being a task automation tool – is all about tasks. Anything you do about programming, which is not writing the code itself, can be considered a task, and can very likely be automated. Some tasks are automated already, like compiling your code, building your app. In case of AL development, there are many more already automated tasks, like creating a demo workspace or deploying your app to NAV. If you can automate them, tasks are immensely powerful because they save time and eliminate error.
If you are a web developer, your tasks can include bundling your source files and minifying them. For me, when building pre-2018 control add-ins, most important tasks were bundling source files, zipping the resource file, deploying a control add-in and importing the control add-in using PowerShell. All of these I have automated using gulp, and I’ll explain every single one of them in this series.
But for now, let’s simply take a look at how to write gulp tasks.