Dynamics GP Developer Insights: Service Based Architecture Overview
Hi everyone, my name is Kevin Racer and I’m a Senior Program Manager Lead on the Dynamics GP team. I spend my days working on improving our architecture and tools.
Overview
A good number of you have probably seen or heard about the change to our architecture designed to better embrace services and the cloud. We've officially referred to it as our Service Based Architecture code named "DexNext". This change is scheduled for the Microsoft Dynamics GP 2015 release around Q4 2014 and has a number of pieces that developers, partners and customers need to be aware of if they want to take full advantage of these new and exciting capabilities. In this article I am going to broadly describe the architecture as its technologies and then in subsequent blogs the team will follow up with deeper dives on the specific components.
Let's start with what Service Based Architecture means. If you think of the term service oriented architecture (SOA) then you are on the right track because that's what the new architecture essentially models. We call it service "based" because it more accurately describes what we are doing. Any functionality in any dictionary can be exposed as a service call, which makes it the "base" for the services as well as the base for web and desktop clients. Our aim with this was consistent with what we did with the web client in that we are evolving our architecture by adding technological capability while continuing to leverage existing resources.
Technologically speaking the architecture lets developers precisely control what gets exposed through the endpoint and includes the ability to define in .NET the makeup of the data you want to exchange. While .NET is an added factor, the experience is still primarily a sanScript one so for those of you with that skillset it continues to have value. The endpoint API conforms to a REST based pattern which is very simple to understand yet allows the invocation of some very complex operations. We will also provide a Discovery Endpoint that describes all available service calls in a particular deployment. This description includes things like parameter type requirements, a description of the method and an example URI to call it. You can think of Discovery as real time documentation that is always current.
In order to deliver this new service based capability we are also deepening our interaction capability with .NET. In GP 2015 you will be able to directly reference .NET assemblies and new up objects to use. This helps the service exposure side by enabling you to use a .NET object as a single parameter instead of a bunch of singleton Dex types. It also gives you greater ability to consume a service since you can now leverage all the coolness of the .NET platform to do your serialization, http requests etc. As an added bonus this also helps your non service sanScript code do more (think collections)!!
Authentication to the service will initially support windows auth. We are planning on expanding that to Azure AD and subsequent claims based methods post RTM. From an authorization perspective the architecture integrates into the GP security model so access to the service calls can be tightly controlled by user/role giving customers complete control over who can read, create or update data.
I said it pretty well in a past blog Roadshow Content Review: Part 1 so to sum up I'll plagiarize myself a bit here and say "The Service Based Architecture broadens our ability to interact with the Cloud, provides a connective base for companion application development and greatly broadens our ability to think big about the future of Dynamics GP and the functionality we can begin to build and offer."
Keep tuned to this blog for more in depth articles from the team.
Until next time
Kevin