Microsoft Dynamics has come over a long way with respect to technology. It is an amazing experience to witness the journey of a beautiful product range from all proprietary languages to Microsoft .NET compatible platform. Now we, the developers and architects have the ability to connect all the products and establish a business logic in the service tire. We can access all the native ERP code base, forms, and tables and update as and when needed.
In this article, I want to put forward a concept that I have been cultivating for some time. Playing around with Dynamics 365 has made me more curious to explore the concept, I foresee in near future that all Dynamics products will be coming into a single platform. This could be helpful for any Microsoft Dynamics service company that has the same integration for different Dynamics products. In this discussion, I am going to include MS Dynamics AX, MS Dynamics CRM (365), Dynamics NAV and Dynamics GP.
Let us take an example of a service organization that works on common Microsoft Dynamics add-on. For example exchange rate. Exchange rate and taxes are important factors for any organization with Global business. All Microsoft Dynamics products support these feature extensively. However, both the exchange rate and taxes need a continuous update and run-time determination.
In our discussion let us consider that an organization developed connectors for all the following Microsoft Dynamics products. All the products work on different programming languages. –
1. Microsoft Dynamics AX – native programming language is X++. However, with Dynamics 360 we use the Visual studio for programming.
a. Retail and Point of sales – MPOS – Dot Net.
b. Mobile application
2. Microsoft Dynamics CRM – Dot Net based CRM application.
3. Microsoft Dynamics NAV – native programming language CAL.
4. Microsoft Dynamics GP – Dexterity is used to customize the application. Architecture:
Dot NET Web Services:
Let us assume that the organization built up a robust .NET tax engine and database. That is exposed as a web service. The web service is very generic and based on the parameters. It queries the master database and returns the result either for tax rate or exchange rate. We call this the Master Web Service, which is hosted in the service provider’s cloud.
Another secure web service is going to take care of product specific parameters as input, validation of the transaction based on the parameters and fetching the result from the above web service and return it back to the respective Microsoft dynamics product. This web service can be hosted in the same cloud or can be shipped as a package that customer can implement to their own IT infrastructure. That intelligent web service determines the source product and based on that it will interact will the respective databases and codebases of that particular product. For example –
Source = parameter that will be passed from the respective Dynamics products when it will call the service from the respective codes.
if (source =)
{
// work with AX.svc
// update the tables and classes.
} else if (source = )
{
// work with CRM.svc
// update the tables and classes.
} else if (source = )
{
// work with GP.svc
// update the tables and classes.
}
//The generic section that will cater with common business logic and data validation.
Microsoft Dynamics:
All Microsoft Dynamics products provide us an opportunity to work with web services from the respective native codes. To consume services over the internet, we must host services on Internet Information Services (IIS). Services that are hosted on IIS use the WCF message routing service. Through the service, we can expose a page/query/class/tables as a SOAP web service. We can create custom service with our custom code to cater to our solution requirements.
In this service, there will be three sets of actions.
• First one will validate the data that come from the EPRs or CRM.
• Second one will calculate the rates for all valid transactions.
• Third one will push back the result to the respective ERPs or CRM and let the product handle rest.
From Microsoft Dynamics point we are going to work extensively with the inbuilt feature to work with web services. We want to modify native Microsoft Dynamics products as less as possible. We do not want to add, modify or delete a single native table field of the Dynamics product. All will modify are codes (classes/methods/functions etc.).
Dynamics AX (AV.svc) :
Microsoft Dynamics AX supports Custom services or Document Services that expose AX functionality as web services. Microsoft Dynamics AX still runs on X++. In Dynamics 360 we have the opportunity to code X++ in Developer Studio. Services that are hosted on IIS use the WCF message routing service. These services are consumed from any dot NET application. Custom Services are used to expose very simple business entities as a service or to expose custom logic from Microsoft Dynamics AX. For example, address validation functionality for a customer or vendor. Document Services are used to expose business entities with varying degrees of complexity or to support medium-to-complex integration scenario involving business entities. For example, exposing any existing AX class or query to update tax detail. During a transaction process currency converter service be consumed from outside application or service and update the latest rate the table/class of AX.
Dynamics AX Retail POS (POS.svc):
AX POS and MPOS are mainly developed in .NET. From a .NET application is it easier to work with a Web Service. During a POS invoice transaction, the .NET code can interact with the service at the run time and fetch the tax rate or the exchange rate. This will use the same Web Service that is developed for the core AX Sales Order or Invoice. The service can update the tables directly or particular class based on the requirement.
Dynamics NAV (NAV.svc):
Microsoft Dynamics NAV 2016 supports creation and publishing of Microsoft Dynamics NAV functionality as web services. We can expose pages, code units, or queries as web services, and even enhance a page web service by using an extension of code unit. When we publish Microsoft Dynamics NAV objects as web services, they are immediately available on the network. A code unit web services provide us control and flexibility. When a code unit is exposed as a web service, all functions defined in the code unit are exposed as operations. We will use this service to integrate our business logic and accordingly update the tax rate or exchange rate at runtime in the service so that it updates the code units appropriately.
Dynamics CRM (CRM.svc) :
Web service is an integral part of Microsoft Dynamics CRM. Microsoft Dynamics CRM provides two important web services that are used to access CRM from an external application and invoke web methods to perform common business data operations like create, delete, update, find etc. in CRM. IDiscoveryService and IOrganizationService Web Service are used to work with external applications. IOrganizationService web service is the primary web service used for accessing data and metadata in CRM.
Dynamics GP (GP.svc) :
Like other Microsoft Dynamics products, GP comes with Web Services Integration. GP comes with few out of the box web services that we can expose to consume from a .NET application. Some of the examples are Sales Documents, Update Customers etc. We can create new web services from GP as per our requirement. In our example, we can expose Sales Documents web service and create a method to cater to the exchange rate. The master web service can be consumed from the .NET application and based on the parameters it will update GP tables and processes.
This is a draft concept of the solution. I know lot need to be explored and a lot can be done. I am excited that Microsoft is offering us to explore a lot in terms of technology and flexibility. I welcome your feedback and wisdom on this concept.
In this article, I want to put forward a concept that I have been cultivating for some time. Playing around with Dynamics 365 has made me more curious to explore the concept, I foresee in near future that all Dynamics products will be coming into a single platform. This could be helpful for any Microsoft Dynamics service company that has the same integration for different Dynamics products. In this discussion, I am going to include MS Dynamics AX, MS Dynamics CRM (365), Dynamics NAV and Dynamics GP.
Let us take an example of a service organization that works on common Microsoft Dynamics add-on. For example exchange rate. Exchange rate and taxes are important factors for any organization with Global business. All Microsoft Dynamics products support these feature extensively. However, both the exchange rate and taxes need a continuous update and run-time determination.
In our discussion let us consider that an organization developed connectors for all the following Microsoft Dynamics products. All the products work on different programming languages. –
1. Microsoft Dynamics AX – native programming language is X++. However, with Dynamics 360 we use the Visual studio for programming.
a. Retail and Point of sales – MPOS – Dot Net.
b. Mobile application
2. Microsoft Dynamics CRM – Dot Net based CRM application.
3. Microsoft Dynamics NAV – native programming language CAL.
4. Microsoft Dynamics GP – Dexterity is used to customize the application. Architecture:
Dot NET Web Services:
Let us assume that the organization built up a robust .NET tax engine and database. That is exposed as a web service. The web service is very generic and based on the parameters. It queries the master database and returns the result either for tax rate or exchange rate. We call this the Master Web Service, which is hosted in the service provider’s cloud.
Another secure web service is going to take care of product specific parameters as input, validation of the transaction based on the parameters and fetching the result from the above web service and return it back to the respective Microsoft dynamics product. This web service can be hosted in the same cloud or can be shipped as a package that customer can implement to their own IT infrastructure. That intelligent web service determines the source product and based on that it will interact will the respective databases and codebases of that particular product. For example –
Source = parameter that will be passed from the respective Dynamics products when it will call the service from the respective codes.
if (source =
}
//The generic section that will cater with common business logic and data validation.
Microsoft Dynamics:
All Microsoft Dynamics products provide us an opportunity to work with web services from the respective native codes. To consume services over the internet, we must host services on Internet Information Services (IIS). Services that are hosted on IIS use the WCF message routing service. Through the service, we can expose a page/query/class/tables as a SOAP web service. We can create custom service with our custom code to cater to our solution requirements.