Codename DexNEXT - Part 1

Codename DexNEXT - Part 1 of 2

You have probably been hearing the term kicked around the circles for almost a year now, but codename DexNEXT represents a major milestone in the evolution of the Microsoft Dexterity development platform and the Microsoft Dynamics GP application - Microsoft Dexterity is Microsoft Dynamics GP's native development platform.

DexNEXT is fundamented on the vision that Microsoft Dynamics GP needs to consume as well as expose services to become a solid cloud offering. After all, when referencing "cloud", in reality we are referring to the various services that live in the cloud. It is generally accepted that the Microsoft Dynamics GP 2013 web client is the first step in that direction.

As such, starting with Microsoft Dynamics GP 2015, and to a certain extent, Microsoft Dynamics GP 2013 R2 the Microsoft Dexterity and Microsoft Dynamics GP development teams are evolving the core architecture to support services as a native component. The key requirements driving this evolution are:

- Elasticity and scalability
- Support for various form factors
- Functionality exposed via an integration layer
- Support for various localization models (international markets)
- Systems interconnectivity and interoperability with other service-based applications
- Support for platform tools
- Continuous support for the current investment (time, money, and code base).

The immediate objectives of this strategy are to:

- Develop a long term strategy centered around services
- Expose sanScript logic as a service call
- Enhance Dexterity's .NET capabilities
- Better alignment with Windows Azure

The current service architecture has been mainly focused around the use of eConnect and Web Services at the integration layer. Recently, we have seen additional work carried out around the delivery of Windows Store companion apps, with Business Analyzer being the first application of this kind. Then there's the web client, exposed via a Windows Communication Foundation (WCF) service and consumed via a browser.

Current Service Architecture

The new service-based architecture aims to change this a bit by delivering native services, derived from existing Microsoft Dynamics GP business logic.

DexNext Service Architecture 
In the above schematics, the GP Services replace the traditional eConnect and Web Services integration components, while being tightly coupled to the Microsoft Dynamics GP dictionary resources - integration are not done through database calls, but rather a unified set of RESTful service calls.

We can always speculate about the long term vision of this architecture. It is not inconceivable to believe elements such as the user interface and core application functions - the entire application - can be seen as services that can be consumed by other applications such as Windows Store companion apps and even application offered through the Windows Azure marketplace. This will also facilitate integration to other non-Windows platforms and applications.

In my next article, I will talk about some of the underlying changes Microsoft Dexterity will be undergoing in order to accommodate to expose and consume services.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/

Comments

Post a Comment

Popular posts from this blog

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

Image
Hello all! It's been quite a while since I've actually written anything of remote interest to anyone who follows my blog, but at the same time, you will be pleased to know that I've been quite busy in the consulting front, with upgrades, server migrations, complex multi-instance postings involving 10's of thousands of transactions, wrapping up some Field Service Automation projects, and the list goes on and on. This time around I want to bring to the forefront, an issue I encountered updating  from Microsoft Dynamics GP 2013 SP2 to Microsoft Dynamics GP 2013 R2 plus the latest service pack. Background My client requested a server migration to a new environment where they wanted to deploy Dynamics GP 2013 R2 web client (plus the latest service pack) and upgrade their relational database management system to Microsoft SQL Server 2014. This is something I'm absolutely comfortable with (for the most part) given also that my client was sitting at Microsoft Dynamics...
Read more

Do I have to use those "Z-" currency IDs in GP?

Image
I know this seems like a trivia question, but recently I have come across a number of clients who have been using Microsoft Dynamics GP for a number of years and have been told by their former partners that they *must* use the predefined currency IDs created after adding the sample company, with no real explanation to support these claims. Case in point, my new client in Saudi Arabia, has been struggling for years to understand why they were told to prefix all currency IDs with the "Z-". So they went ahead and setup "Z-SR" for the Saudi Real. If you are familiar with Microsoft Dynamics GP and the sample company, Fabrikam, you may have noticed by now that after adding the sample company (which is not a requirement by any means), you will get a number of predefined currencies such as Z-US$ (US Dollars), Z-UK (British Pounds), Z-C$ (Canadian Dollars), Z-AUD (Australian Dollars), and so forth, accompanied by a number of exchange rate tables. If you are not familiar wi...
Read more

Microsoft Dynamics GP Scrolling Windows and Line Sequence Numbers

Image
I thought I would write about something meaningless that no one really thinks about. However, I realized that this is a compelling topic since it makes for some interesting discussion around the ability to insert line items withinin most transaction scrolling windows. Let’s take some time to understand where Line Sequence Numbers come from. A Line Sequence Number is auto generated by Dynamics GP and uses a seed value of 16,384 as a basis for the first line. Each subsequent line in the scrolling window is incremented by this number, so line number 2 would have a Line Sequence Number value of 32,768, line number 3 would have Line Sequence Number Value of 49,152, and so on. Since most GP transaction entry scrolling windows allow inserting rows in between line items, the newly inserted Line Sequence Number value is calculated as an average between the previous and the next line item sequences, i.e., if you were to insert an item in between row 1 and row 2 in the scrolling window -- keep in...
Read more