For a long time, we have all been trying to put as many things as possible inside our NAV, using our ERP system more like a development platform than an ERP system. The reason for this is that it has been easy and if we keep all functionality inside NAV then we do not have to learn anything new, and further more we can keep a monopoly on how our customer has to work. But as the world changes we have to change with it. The idea behind having one system to rule them all is no longer the way our world works, if you take a look around the industry we are seeing more and more micro services and specialized systems, and since these smaller systems only has one focus, then there is no way that we can compete with them, with our giant system.
In many ways you can compare what is happening now, with what happened back in the day with development mythologies, where once everyone worked using
the waterfall model now a days we all try to work agile.
To put it in other words we can see our beloved NAV as a hammer while all these small systems all have their own tool shape, so while you can force a screw into a piece of wood using a hammer we all know that using a screwdriver is much easier 😉
If we look at how Microsoft is changing the way we can develop in the future though extensions, then it would also seem like that even they have seen the direction our world is moving. So, in the future we will all be working with NAV as just another system that is part of a larger network of connected services. The way that we do this is through different API’s, where some of the most common of course are webservices that use either SOAP or REST, but there are also a lot of other types of API’s and ways to get data, some system still uses the outdated method like file exchange, and furthermore the data that you receive can come in many different formats, where you have XML, JSON and CSV as the most common, some API’s also creates their own formats or they create their own standards of how their data is structured. All of these variations, can make even the best developer want to pull out his or her hair, and this is not made easier by the fact that C/AL and AL are very limited in what tools they have available. So wouldn’t it be great if all we had to do is call one service, which would always return the same data format, and yes you guessed it that is exactly what we will be creating in the next couple of posts, but be warned you will need to know at least some C# to be able to follow the examples, in this post there will be no coding but I will give a run though what a master service is and how it can help make your life easier, and in the next post I will cover the following topics:
- Create the foundation of the Master Service, creating the foundation for a 2 factor authentication app for NAV
- Setup up functionality in the Master Service, to generate a token and push it to NAV
- Create a small mobile app that that shows token in an app using our Master Service
So let us get into what a master service is and why we need it, first off let us be honest this is a nice to have and not a need to have, but with that being said it will make your life much easier as a NAV developer, and it will allow our NAV world to open op for new developers. Since we would be able to welcome aboard .NET developers (or whatever language you choose for your master service) which in turn means that we can keep our costs down, because .NET developers are nowhere near as expensive as NAV developers. Now you might be thinking, but why do we need .NET, we can easily just make this master service in C/AL and yes you are right, but one of the main reasons for choosing .NET is that it is a much larger and supported language than C/AL will ever be, meaning that .NET has much more modern tools to work with data of all types. The idea behind a master service is that NAV will make standard webservices available to the master service and consume the API’s need from the master service, so all logic will still be in NAV, but you will be able to always get the same format of data allowing you to easily work with the data.
The idea behind a master service is that it will be the point of entry for all communication between all of your products, what this means is that you really do not care from where your data is coming because you only ever have to connect to your master service. Another thing is if you like most of us have had to integrate with a third party webservice. Where we have had to setup a job que to keep us in sync because the third-party system could not push data to NAV, now I do not know about you, but I have had plenty of problems with the stability of job ques, resolving in that data was not updated correctly. But with a master data service this is no longer a problem because you will be able to tell the master data service to push the data to NAV and therefore no more job ques are needed, for system integration. Furthermore, by allowing all of your communication to go through one service, this will enable you to setup a DMZ where only your master service is running.
If you do not know what DMZ is, it is a term from the military which stands for demilitarized zone, like the zone that there is between north Korea and south Korea, so in other word it is a buffer zone. In the world of computers this is also what you use a DMZ for, it is a server between your local network and the internet, so if someone would be able to get access to your DMZ server they will not be able to get onto your local network (depending on how you setup your DMZ). DMZ is getting more and more important in a connected world because it is getting more and more difficult to keep track of who has access to what. But enough theory in the next post let us get to coding 🙂