Alternative to data obfuscation to TEST your D365FO integrations

 When doing integrations one rely completely on the data that is generated by the LOB applications to test integrations. Moreover, using this data for testing purposes can lead to issues related with privacy and security. For this reasons there are sample data that is available but the scope is very narrow and it is only applicable for process testing. 

It is desirable to have ways to produce this data in an ad-hoc manner as when it comes to integrations the scenarios can be quite diverse.

In this article I'll explain a set of scripts that can produce huge amount of valid randomized data considering the master data available in D365FO. 

Consider the following scenario: 

  • A LOB that generates huge amount of sales orders (100.000+ lines per day) and send them to D365FO for creation, and further invoicing. 
  • 5.000+ customers
  • 30.000+ items
  • You cannot re-use production data. 
Although obfuscation of the data is a possible solution does not guarantee that all the relevant scenarios will be generated, plus the effort - without a proper tool - to do it could be considerable in order to maintain all the environments in sync for the testing.

Another solution can be as follow: 

  • Grab all available customers in your instance
  • Grab all available items in your instance
  • Generate randomized amount of sales order per Customer with a randomized numbers of sales order lines per item. 
  • Randomize unit prices and quantities
With simple python and odata calls I was able to generate as many data I wanted. Later, it is possible to generate a valid list of SQL sentences to create tables and records - if SQL fits your scenario - to be used by your integrations. 


Conclusion

Using this tool I generated more than 15.000+ valid sales order lines in less than a minute. This technique fit is purpose and provides a flexible tool that can be adapted to any scenario. While testing the integration it is likely to have errors with D365FO validations - for instance decimal quantities but the item only accepts whole numbers - but it is exactly the purpose of testing, identify an error and decide upon it. 


Disclaimer: All the data used for this example was taken out of a regular CONTOSO dataset. 

Comments

Popular posts from this blog

Telemetry and Monitory with Applications Insights and Dynamics 365 F&O

Infamous "The natural key for some table was not found" solved once and for all