Along with 3 other members of the Tidestone crew, I attended the reIMAGINE conference in Fargo, ND the week of November 10. You can see how we got prepared for reIMAGINE
The conference was comprised of sessions that demonstrated some of the great new features of Microsoft Dynamics GP 2015. The release date is not set in stone yet, but Microsoft has committed to a 6 month release schedule, which puts GP 2015 sometime at the end of 2014. Of all of the new features discussed, the most talked about was a feature named Service Based Architecture.
Service Based Architecture (SBA) is a shift in the GP integration strategy. It is a RESTful based web service framework that allows developers to present native GP business logic to an HTTP REST endpoint. One may ask, “Why is this important and how is it different from the integration tools already provided with GP?” Until now, GP has two main ways to integrate data: (1) Integration Manager, which is a macro based UI tool that allows you to easily import data from sources such as spreadsheets, and (2) eConnect, which is a set of SQL stored procedures that are duplicates of the native GP business logic. There is also GP Web Services, and I am considering one with eConnect as it sits on top and calls the eConnect procedures. eConnect is a great tool and has served us well for many versions of GP. However, it is not without its set of challenges. Some issues with eConnect are:
- Prone to Bugs - Microsoft has to maintain 2 versions of the GP business logic, one in the eConnect stored procedures and the other in the native GP Dexterity code. The issue arises when Microsoft makes a change to the GP UI business logic, and does not make the change to eConnect or makes a change that does not work the same way. This provides undesired results. SBA, along with .NET Interop (Stay tuned for a future blog on this subject), allows for the native Dexterity procedures to be wrapped in a RESTful based service. This means that there is one code base to maintain and when a change is made to it, not only does the UI get the change, but also any integrations based on SBA.
- eConnect does not include ALL of the GP business logic. There are many datasets ion GP that are not available in eConnect, even more when using the GP Web Service. With SBA, the entire GP business logic can be wrapped in a service. Microsoft will wrap what they deem to be the most important sets and give us as partners the ability to wrap any other data that we may need. SBA, also allows us as developers to wrap our customizations in a service. This means that we can make our custom data available to reporting and third party systems natively.
OK, so let’s talk about some practical uses for all this technical speak:
What does this actually allow us (you) to do? Answer: APPS BABY!! - REST is the most common form of web service being used today. Almost any type of application / reporting platform can consume it. Android, Apple & Windows based mobile platforms all consume REST services. Microsoft even has a drag and drop application named Siena that is used to build Windows 8 modern apps. This means that with a few clicks, application consultants or customers can build a Windows 8 app based off of GP data for your organization. No longer, do we require high level technical expertise to build quality applications that present GP data. This also saves you on licensing as these apps do not require a GP license to access them.
We are extremely excited about this new framework and the shift that GP is taking with SBA. Not only will Service Based Architecture standardize the code base that the service presents, but it will also standardize the method of delivery, i.e. REST. SBA is going to open some new doors very wide for the GP developer and customer. Hold on, it is going to be a wild ride!
Technical Director | Tidestone Solutions