Service Based Architecture is being introduced in Microsoft Dynamics GP 2015, and represents part of a larger paradigm shift for Dynamics GP developers in the way they will write code that integrates or interacts with Dynamics GP.
Up until now, the two main, native Microsoft ‘sanctioned’ methods for doing integrations outside of Dexterity with Dynamics GP were to use eConnect within another tool, or to use Integration Manager. eConnect provided a subset of Dynamics GP functionality that could be leveraged by integration developers to create relatively seamless, flexible solutions, while Integration Manager provided an interface that was somewhat intuitive and could be utilized by Dynamics GP power users themselves. Dynamics GP Web Services, which some might view as the third method for doing Dynamics GP integrations, really presented just a web front end to eConnect, and consequently shared its’ limitations.
In terms of enterprise-level functionality, Integration Manager, as a user-interface employing macros and requiring Dynamics GP to be open, is not normally a solution for back office work. That left most developers to utilize eConnect to do this type of more sophisticated, automated work.
Unfortunately, there have always been two major issues with eConnect. The first is that it represented only a subset of all the functionality found within Dynamics GP itself. This has been most evident in the limitations it placed around what types of updates and deletions it would support – but there are a number of creation activities that it also does not support. There are even more limitations when using the GP Web Services over top of eConnect.
The second limitation of eConnect, although less immediately evident, is that eConnect represents a completely separate, parallel system of SQL stored procedures interacting with Dynamics GP alongside of the Dexterity code compiled within Dynamics GP. The two versions are written in different code and not at the same time. This can create situations where they are out of synchronization – particularly right after a service pack. We have also seen situations where the eConnect version of the code has a bug in it – most prominently in some of the <GetNextNumber> functions.
The introduction of SBA addresses this issue by removing this ‘separate and kind of unequal’ system. The entire Dynamics GP business logic will be available through the mechanism of web services (not to be confused with the old Dynamics GP web services!). Microsoft will wrap the main features into web services for us, but developers will also have the ability to wrap any other of the application’s Dexterity procedures into web services as well. And extending this even further, developers will be able to wrap their own customizations in a service as well.
The impact of this is two-fold: there will no longer be two code bases for Great Plains to maintain, eliminating synchronization issues. And developers will have essentially the same scope of interaction with the database as someone operating directly in the UI.
On the consumption-of-services side, don’t confuse the current Dynamics GP Web Client and SBA. Although Great Plains does foresee merging the Web Client into SBA, they remain distinct at the present time. They are both separate, optional installations when configuring Great Plains, and do not currently overlap. And in terms of behavior, there is a significant difference between them – the Web Client depends on a stateful connection, while SBA uses a stateless connection. This makes SBA immune to the types of Async errors you might have experienced in the Web Client when the connection is broken.
Finally, the SBA is designed as set of services using REST – the most common type of web service today. What this means is that almost any type of application / reporting platform can consume it. Android, Apple & Windows based mobile platforms all consume REST services.
If you are looking to develop additional functionality in Dynamics GP, RSM can help. We are a top ranking partner with Gold Enterprise Resource Planning (ERP) Competency in the Microsoft Partner Network. Contact our professionals today to learn more – firstname.lastname@example.org or by phone at 855.437.7202.
By: Chris Djorup – Pennsylvania Microsoft Dynamics GP partner