Microsoft Dynamics GP at REST

Written By: Ross Boe

from April 30, 2015

Microsoft Dynamics GP 2015 is introducing a new concept to the Microsoft Dynamics GP world, REST web services. I would imagine that most users of Microsoft Dynamics GP are asking the same questions “What is REST?” and “Why should I care?” The answer to both of these questions is in the technical depths of what REST was intended to accomplish.

Web Services

The first step in our journey to understand REST is to look at the problem that REST is attempting to solve. The use of web services in application design is called service oriented architecture (SOA). The basic theory behind SOA is that all of the business logic of the application is hosted in a service that exposes methods for a client application to call. The client, or user interface (UI), in this case only needs to be concerned with presenting data for the end user to interact with. Once there is a separation between UI and business logic, we have accomplished two very important tasks. First, updating either the UI or business logic layers becomes much easier. Second, the UI is very lightweight and is only concerned with displaying information. So, since Microsoft is pushing the business logic of Microsoft Dynamics GP into a web services layer, they can start looking at other UI technologies, i.e. a pure web client (HTML5).

So let’s explore the advantages of web services a bit more to understand how important this is. Our very simple scenario: We have two companies, Company A and Company B. Both companies are being acquired in the next week. The acquisition process will require both companies to immediately change how they process invoices. Let’s see how this will play out:

Company A

Company A is a medium-sized business with 250 employees. They have a Windows application that runs their entire business. The application is installed on every desktop in the business and communicates directly with the SQL Server database. To update the invoicing process, they coordinate a change to the client application with the development team. To deploy the changes, the IT team at Company A will need to update the client application on every computer in the company. The timing is critical, so they spend several hours on a weekend to get every computer updated.

The other much larger disadvantage that Company A has is that the processing of their entire business is housed in a Windows application that will only run on a Windows PC. Their CFO would like to view and update invoices from his iPad. The effort to reproduce all the business logic is cost-prohibitive for them.

Company B

Company B is also a medium-sized business with 250 employees. They also have a Windows application that runs their entire business, and it is also installed on every desktop in the company. One key difference is that Company B designed their application to use web services for all the business logic. So, to update their invoicing process, they coordinated a change with the development team. To deploy the changes, the IT team needed to update the web services on the server, and they were done.

The CFO at Company B also wanted to view and update invoices from his iPad. The development team was able to create an iPad application that used the same web services as the desktop application for a fraction of the cost that Company A was looking at.

Now that we have seen the outcome of how Company A and Company B approached their application architecture differently, it becomes clear that using web services has tremendous advantages.

Why should we care about this? A couple of scenarios to think about. First, when it comes time for the end of the year update to Microsoft Dynamics GP. If all of the business logic of Microsoft Dynamics GP is in a service, and the desktop application is very “thin”, the annual update becomes much simpler. Another situation that could be common is the performance on a computer desktop. If all the computers in the company need to support the full Microsoft Dynamics GP client, the hardware requirements can be expensive. If the client is “thin” and a server does all the processing, you can consider Azure Cloud services and not buy the hardware but only pay for what you need.

And that brings us back to our topic: With Microsoft Dynamics GP 2015, Microsoft has created a REST web service.

JSON

Yes, that is another acronym that we need to understand. JSON stands for JavaScript Object Notation.

JSON is a standard way of transferring data between a web service and a client application. JSON is typically easier to read and understand than XML. It is also much easier to create a JSON string to represent data than it is an XML string to represent the same information. So from a software development standpoint this is very advantageous, especially as more and more software is being pushed to web browsers.

Almost all of the time REST and JSON go hand-in-hand. There are some rare occasions where a REST endpoint will use XML instead of JSON; those instances are really the exceptions and not the rule. In fact the GP REST endpoint contains a parameter that allows XML to be used. For the remainder of this article, though, we will assume that REST and JSON go together.

REST

REST is an acronym that stands for Representational State Transfer.

Now that we have an understanding of the concept of web services, we can explore why using REST is significant. Web services is not a new concept in software development; there have been many different ways of solving the communication problems over the years. There are currently two technologies that are most common, SOAP and REST. There are strengths and weaknesses of each technology, but since we are focused on REST, we will discuss the advantages of REST and why Microsoft chose a REST endpoint for Microsoft Dynamics GP.

 

Before we proceed, let’s show you two examples that we will use in our discussion.

SOAP Example

Examples taken from (http://www.w3schools.com/webservices/ws_soap_example.asp)

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version=”1.0″?>
<soap:Envelope
xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”
soap:encodingStyle=”http://www.w3.org/2001/12/soap-encoding”>

<soap:Body xmlns:m=”http://www.example.org/stock”>
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>

</soap:Envelope>

 

SOAP Response

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version=”1.0″?>
<soap:Envelope
xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”
soap:encodingStyle=”http://www.w3.org/2001/12/soap-encoding”>

<soap:Body xmlns:m=”http://www.example.org/stock”>
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>

</soap:Envelope>

REST and JSON Example

Request JSON:

{
“StockName”:”IBM”
}

Response JSON:

{
“Price”:34.5
}

Advantages of REST and JSON

Lightweight

The first advantage of REST is the fact that it is more lightweight than SOAP. SOAP is an XML-based standard, and the XML documents of a SOAP web services can become very complex and difficult to manage. It was very obvious in our examples that the number of characters going back and forth between the client and the web service is significantly fewer. Put this in the context of running a web service that handles hundreds or thousands of clients, and you can see why there is a big advantage to being lighter weight.

Readability

One of the ideals that champions of REST often turn to is that a JSON request is much more readable than a SOAP request. The examples above are very simple. However, the more complex the application, the complexity of SOAP goes up as well. A majority of the time this is not really an issue since the data transfer happens in the background, and the user does not see either the JSON or SOAP messages; however, when there are issues that arise and the messages need to be inspected, troubleshooting a JSON message will be much easier.

Formatting

This is probably one of the best advantages of using JSON and REST. When writing software to communicate with a web service from web browser, it is necessary to build the request using code. As you can see, generating and receiving a SOAP request can be very difficult. A JSON request, however, is very easy to build and parse once received.

Potential

By opening the floodgates of web services, specifically REST, Microsoft has signaled a change in direction for Microsoft Dynamics GP. The future of Microsoft Dynamics GP will be much more web-friendly and mobile-friendly. This is very important to consider as we look at what the REST endpoint really means.

Apps

One main driver behind the adoption of REST technologies is the ubiquity of apps in our mobile device-driven modern world. Apps operate in a space where the users are very aware of how much data they use, and often bandwidth can be minimal at times, depending on cellular reception. It is for this reason that a lot of people are very excited about Microsoft opening the doors with a REST endpoint in Microsoft Dynamics GP. The ability to create an App to interact with Microsoft Dynamics GP data is suddenly a possibility. Imagine the possibilities that open up for managing a business on the go.

Interoperability

Interop-a-what?

Interoperability is the ability of an application to communicate and live in an ecosystem of other applications within the business landscape. To date Microsoft Dynamics GP has been pretty tight with the ability to integrate with other systems. There is existing functionality such as eConnect and the previously existing SOAP based web services. The issues with both of these are twofold. First, the functionality exposed to external applications is limited. Second, the ability for applications to interact with these has been limited. These limitations made the options to sync Microsoft Dynamics GP with other systems and presenting data outside of the established Microsoft Dynamics GP methods limited and often expensive.

With the REST web service of Microsoft Dynamics GP, Microsoft has made much more functionality within Microsoft Dynamics GP available to an external application. By making more functionality available, the ability to integrate Microsoft Dynamics GP with external systems becomes much more attainable. The ability to display and even interact with the Microsoft Dynamics GP data becomes significantly easier. What this means is that eventually we will see integration processes becoming more real time and able to integrate more tightly with Microsoft Dynamics GP.

Conclusion

What we have seen in this article is that Microsoft has changed the game by opening the Microsoft Dynamics GP world up to REST. The advantages of a “thin” client for Microsoft Dynamics GP with all the business logic in a web service are just the beginning. The flexibility of Microsoft Dynamics GP in a web service brings a lot of options to the table with Azure hosting abilities. We will also see Microsoft Dynamics GP becoming more tightly integrated with the rest of the Microsoft Dynamics stack of applications. With this change, Microsoft has brought Microsoft Dynamics GP into the modern world, and we can be excited to see where it will go. In our next article concerning Microsoft Dynamics GP 2015, we will take a technical deep dive into working with the Microsoft Dynamics GP REST Endpoint.