Enterprise resource planning (ERP) and customer relationship management (CRM) systems are very helpful in organising, streamlining and structuring business processes across the company. They allow companies to automate certain management and business tasks and unify data across the board, helping them to reduce overhead and make the overall workflow more efficient. To fit the needs of a large number of companies across different industries, such systems come with a wide variety of features spread between several modules optimised for different departments.
Yet, despite the rich feature set, many companies face the need to tweak said system to their own unique needs. To meet this demand, products such as Microsoft Dynamics 365 come with necessary tools that allow their clients to implement custom solutions within the system.
Dynamics 365 is a ERP and CRM system, launched by Microsoft in 2016. The system is positioned as an extended relationship management (xRM) solution, as it can be configured to manage any given process and reflect relationships in any business domain.
In the biggest Dynamics 365 package, the following modules are pre-installed: Sales; service; marketing; field service; project service; and resource scheduling
The main purpose of Dynamics 365 is to make data entities and the connections among them available to every business domain. The web interface provides a wide range of functions and customisations. It’s possible to adapt existing data entities or create new ones in order to describe business processes.
If package functionality does not suffice it’s possible to implement necessary Dynamics 365 functionality yourself. A special software development kit (SDK) is available for such purposes. In previous versions of Dynamics (Dynamics AX), it was necessary to write code in the X++ language (an object-oriented language with similarities to C#) in the MorphX integrated development environment. This X++ code was then compiled into some sort of intermediate language. However, Microsoft developers recently updated Dynamics so that now the code is compiled to a full intermediate language. Due to this update, it’s possible to write code in any language supported by the .NET platform.
You can implement the following additional functionality in Dynamics 365: Clients in the form of console utilities or WPF (Windows Presentation Foundation) for PC or mobile; extensions for processing of the Dynamics server itself; and extensions for processing Dynamics web forms.
Data can be imported via the web interface. The following file types are supported: *.xlsx, *.csv, *.xml, and *.txt. The interface can analyse what types of data are included in a file based on headers. Moreover, depending on the model that data is being uploaded to, configuration of field mapping will be offered. Import settings can be uploaded and saved so you don’t need to manually specify them each time.
There’s another more complex way to import data through code (which corresponds to the first case mentioned in the previous section). A program written in C# can read data out of any file. Rules for correlation between data and the model on the server (or the model itself) can be created right in code. Then all this information can be sent to the server. This method can be used either when it’s extremely difficult to convert data to a *.csv file or when complex modifications or filtering, which cannot be configured through the web interface, has to be applied to the existing *.csv file.
Microsoft Dynamics 365 server plug-ins
Now, let’s look at Microsoft Dynamics 365 server plug-ins. There are two types of plug-ins (extensions): synchronous and asynchronous. Synchronous extensions are added as part of Dynamics’ processing queue. Asynchronous extensions are processed in a separate pool after a certain operation has been executed.
Synchronous plug-ins can be assigned to events occurring either before an operation or after an operation.
The pre-event stage includes pre-validation – when it has not yet been determined whether a user can execute the operation – and pre-operation, after execution has been allowed.
It’s important to keep in mind that pre-validation can be performed out of transaction, while pre-operation cannot. This means that if an exception is returned from the pre-operation plug-in, the transaction will be declined. At the same time, for the pre-validation plug-in it may be accepted. Therefore, pre-validation can be registered as part of a transaction.
You should take into account that Dynamics 365 doesn’t allow selecting types of events for plug-in connections. Based on analysis of data transferred during an operation, it must be decided whether a plug-in should perform any actions. Therefore, it’s important to understand the necessity of a plug-in application and to return control to the Dynamics 365 processing queue as soon as possible. In this way, the processing speed will not be slowed.
Dynamics 365 doesn’t allow you to perform any custom actions during operation processing. Also, it’s important to note that all plug-ins are launched in a sandbox so they don’t have direct access to the file system, web resources, or several other functions.
Asynchronous plug-ins are processed in a separate queue after a certain operation has executed (including all synchronous post plug-ins).
It’s important to keep in mind the following peculiarities:
In the bounds of one operation, plug-in processing time is limited to two minutes. Exceeding this limit causes the TimeOutException. If more time is needed, you need to create a custom workflow.
Plug-ins should be created in such a way that they don’t store states inside themselves. As mentioned in the SDK documentation, it’s not guaranteed that even constructors will be called each time an operation is processed because Dynamics 365 caches your plug-ins.
Using Microsoft BizTalk server to import data to Dynamics 365
Let’s assume that you’ve bought Dynamics 365 and are using it to manage certain processes. At the same time, you have an instance of Monster2000 deployed and it performs some very important tasks. For some reason, it’s not possible to reassign these tasks to Dynamics 365. However, the result of Monster2000’s work is an important part of your company’s flow, and it has to be used in various Dynamics 365 services.
We could create our own application that would take the necessary data from Monster2000 and upload it via a client to Dynamics 365. This provides us with better control over imported data, but in many cases development is to time and cost-consuming.
An alternative to a custom-written solution is to use Microsoft BizTalk Server. BizTalk Server allows you to configure certain rules (either through the user interface or in code) for converting messages from one type to another. Moreover, BizTalk Server supports different endpoints.
Overall, Microsoft Dynamics 365 provides a variety of ways to expand its existing functionality, including already available solutions and all the necessary tools to write your own custom features. Custom development is more time-consuming and expensive than simply integrating an already available solution. However, any Microsoft Dynamics 365 review will tell you that available selection of ready-to-use third party components for the system is not very wide, and thus many companies that want to further tailor the system to their own needs would need to engage in custom development.
Ultimately, whether you decide to use custom written solution or an existing one, is entirely depends on the task at hand and resources that you wish to spare.
Artur Bulakaiev is a software developer at Apriorit