Development Mistakes

There are three overlooked areas in development that contribute to poor system performance and poor user experience. Including these areas in your development toolset will help to reduce these issues in the production environment when all the users are using the system.

Caching utilisation

There are multiple levels of caching in D365F&SCM. When dealing with frequently access data, or large datasets caching correctly is critical for system and user experience performance.

Two key areas to consider with caching are display fields and table caching. Display fields are used on forms and return data that is read only to the screen. Using this data can lead to an extensive amount of SQL requests, which will impede speed. We can significantly reduce this by ensuring display fields are cached. We can achieve this by adding an attribute to the display method code:

[SysClientCacheDataMethodAttribute(true)]

There are some best practice guild lines for table caching. We should apply the following caching lookup methods based on the table group.

There is one more table group called miscellaneous. Any custom table will automatically be assigned to this table group. Ideally, we should change this group to reflect the function of the table data, then we can apply the appropriate cache lookup.

This is only a suggestion and could be altered depending on the results seen in the system.

Query optimisation

One of the biggest causes of performance issues is query optimisation. As a developer, you need to ensure you only return the data you need, reducing the stress and time to return the data. Firstly, you should list the fields needed and secondly, you should filter the record so only the records required are returned.

The elimination of nested queries will significantly improve the performance. A nested query is when you have a SQL query returning a data set, then a second SQL query returning another dataset based on the first set.

This typically looks like:

While
Select accountnum from CustTable
where CustTable.custgroup == ’10’
{
Select count(recid) from SalesTable
where selectable.custaccount == CustTable.accountnum;

info(strfmt(‘Customer account %1 has %2 sales orders’, CustTable.accountnum, SalesTable.recid));
}

This code will get all customers that belong to the customer group ’10’ then get the sales order count for them. If there is 100 customers in this customer group, then this script would cause 101 SQL requests for data. The first for the initial customer selection, then one for each of the customers to get the sales order count.

You can easily optimise this code by removing the need for the nested query.

While
    Select accountnum from CustTable
        where CustTable.custgroup == ’10’
    join count(recid) from salestable
        where salestable.custaccount == CustTable.accountnum
{
    info(strfmt(‘Customer account %1 has %2 sales orders’, CustTable.accountnum, SalesTable.recid));
}

Both pieces of code with provide the same results, but the second example will result in 1 SQL request for data. This reduces the stress on the SQL Server and significantly improves the performance.

Error handling

A common mistake is the inadequate error handling. There are two key things to consider when error handling. The first is trapping, and the second is logging the errors.

The developer needs to check events that might fail before processing them or surround them with a try catch routine to trap the errors. A simple example of error handling is dividing two numbers, something that happens often is an ERP system. If the sum is being divided by zero, then the system will generate an error. To mitigate this, the developer should check the values before completing the division and handle the issue if the value is zero.

It is important to provide good, clear information to the user when an issue occurs. This is done with the infolog, providing the user with information provided by the developer and/or the system related to the cause of the error. Any developer created error responses must include clear and user friendly information to help them move forward, while also providing key information should additional support be required.

Providing clear information will reduce user frustration, while implying the support cycle of issues that might arise.

Conclusion

In summary, avoiding common D365F&SCM development mistakes is crucial for the success of the project. By including these approaches into the development cycle, you can prevent issues that may compromise the system’s performance and useability.