Undoubtedly the most demanded by D365FO users is to be able to view data in real time. It is true that all D365FO data is in real time, it would be more difficult if it was out of date; but many customers / users, before migrating to D365FO, use certain platforms that provide them charts or statistics with an accuracy and a criticality that can’t be lost with the new tool.
Take the case of a production plant that measures the performance of a production line at all times. This performance is measured based on the number of products that pass through a sensor per second. When this frequency decreases, it constitutes a loss for the company and may be the consequence of an upstream problem or that the production capacity is simply not being used 100%.
Theoretically, these factors and these measurements have to be planned and programmed in the system, but nothing is ideal and perfect, and in the end, everything is subject to human actions and external events.
So, going back to our example, we have a production manager who is constantly monitoring the performance of the production chain and, based on these values, establishes action plans on resources. You can even see if one of your production lines has stopped for some reason. When migrating your current solution to D365FO we cannot deprive you of those immediate indicators.
Below, I show some of the alternatives in D365FO that we could use and the drawbacks that we would find with each of them:
Technology | Real-time | Disadvantages |
PowerBI embedded | No | Entity Store has to be refreshed |
​Power Platform | Yes, but with an offset of several seconds (maybe minutes) | It requires creating graphs and interfacing the data between D365FO and Dataverse. Maintenance of various applications (D365FO and PowerPlatform) |
External application | Yes | Since we migrated to D365FO, it is not very good that this part is not within the ecosystem |
Native graphics | Yes | Refresh the form required |
Therefore, we see that the different options detailed in the table are approximations that could be useful to us. When we expose them to the client, the first two are automatically discarded because, apart from not meeting the requirement, they could lead to a failure in the plant because they are not reliable in real time.
As D365FO experts, we have to choose the latter. Developing an external application that does not depend on Dynamics does not make much sense if we want to make a good impression on the client and we want their production plant to be fully integrated in the cloud.
Solution design
We need to show in a linear graph the number of products that circulate through a sensor at all times so that the operator / manager knows at all times the performance of his production line.
Necessary elements and characteristics:
Data source (table or similar)
New form
Line graph
Sensor on the production floor
Interface to send information from the plant to Dynamics
Form autorefresh
Data origin
First of all we create a table with two fields where we will enter the data. A field for the value to be stored and another to record the date and time of the measurement:
New form
We create a form with the following structure. We can see the Chart type control where we can setup the different values ​​and types of chart that we can use:
Line graph
Next we configure our graph according to the data in the table and the visualization that we want to obtain:
Sensor on the production floor
This point is the least rigid since it will depend practically entirely on the client's infrastructure. It can be a service that records a measurement in an SQL table or even a reader that sends the reading through a COM port to a server.
Interface to send information from the plant to Dynamics
In any case, and for the example that we are developing, we have assembled a PowerApp that sends a random number to Dynamics every 4 seconds through a service published in D365FO.
The D365FO project would be as follows once the example is finished:
Autorefresh
The auto-refresh of the form is the most important part because somehow, we have to ensure that, without having to refresh the page, the content of our graph will be updated with the refresh rate we want.
An example of this can be observed and extracted from the new control in the D365FO plant. There the current time is shown (upper right corner) and it is updated every minute without having to refresh the form:
It does this with a "Timer" type control in which we can predefine a refresh time in seconds (or parameterize it) and in the elapsed method, add the functionality that we want to be executed every time the timer reaches its end (after the X seconds):
[Control("Custom")]
class KeepAliveTimer
{
public int elapsed()
{
int ret = super();
element.setDateTimeLabel();
return ret;
}
}Once we have everything ready, it is time to run the PowerApp to send the data and open the Dynamics form so that we can see the result and ... VOILÀ! We have a sensor that sends information to D365FO every 4 seconds and a graph that shows us the measurement with a refresh rate of 10 seconds (we can lower it even more).
We can go much deeper and change the properties of the graphics in order to achieve better results. I’ll conclude byadding an image of a categorized chart:
I hope it is helpful and you can implement something similar. Real time will no longer be a problem !!!
I want to thank the colleagues who investigated on this subject and did some research.