This is a Consultant-Level definition of Service Based Architecture, without all the techno-geek speak <smiles>

SBA is a web service (for our definition, I'm going to say web site. That's not technically correct but it's really very close and it's a better mental image)

So, SBA is a web site (service) that you can use to view and update data from Dynamics GP 2015. Why bother? Can't we just use eConnect, SQL queries, Integration Manager?

You access SBA from a URL, like this: https://vmgp2015.devshed.local/GPService/Tenants(DefaultTenant)/Companies(Fabrikam,%20Inc.)/Dynamics/Inventory/Items(100xlg). This URL returns (in a browser, or to whatever tool you use) all the data on the TWO 100XLG item. Cool, right? It's that simple.

One advantage is that the SBA web site (service) can be called from apps, which have a hard time running complicated data access code. Since it is accessed via a URL, apps can easily manage it. Here's an app that I coded in a few hours:

In about 50 lines of code I retrieved the Location Codes from TWO and displayed them. Imagine the possibilities.

Here's Mariano Gomez on hooking up SBA to Microsoft's new Project Siena (Consultant-level tools to build apps. Really. )

http://www.gpug.com/gpugsummit/participate-summit/ourlibrary/viewdocument?DocumentKey=4fd4f5f5-ce9d-472e-a318-aafde09c141e&tab=librarydocuments&CommunityKey=a2dad28f-23bb-4426-adda-04f9e22d61d4

Microsoft says that with eConnect they have to maintain two code bases, and by going to SBA they'll only have to maintain one code base.

I'd love to hear your comments.