As a customer/user, it can be a big problem when our customizations or ISV code does certain behavior like calling external web services or sending alert emails. Frequently, there’s some kind of configuration option to change that behavior: for example, a URL is stored in the database and can be changed through the GUI.
But, I can almost guarantee that every customer will be bitten at least once by doing a database refresh and accidentally sending test data out as though it was production data. Many administrators will eventually find themselves with a fairly lengthy checklist when they do a database refresh. For customers trying to do careful testing or frequent training, this can be time consumingt and possibly error-prone, even if automated as much as possible.
As developers, I feel we have an obligation to do more than meet the bare minimum of requirements; we should write code that is as easy as possible for end users, saving them time when possible. It should be a matter of professionalism, if not pride, for us. Therefore, I urge you to write code that can be configured once and will work the same in both sandbox and production environments.
How do we do that?… I recommend using a pattern with the GetUrl() method.
str prodAXUrlPattern = 'myprod.operations.dynamics.com'
str testAXUrlPattern = 'mytest.sandbox.operations.dynamics.com'
str prodWebService = 'production.isvwebservice.com'
str testWebService = 'test.isvwebservice.com'
if (strContains(UrlUtility::GetUrl(), prodAXUrlPattern))
{
MyISVClass::CallWebservice(prodWebService);
}
else if (strContains(UrlUtility::GetUrl(), testAXUrlPattern))
{
MyISVClass::CallWebservice(testWebService);
}
else
{
Throw error('This D365 environment has not been configured.');
}
Implementing something like this will require more work up front, but every administrator will thank you for foolproofing things against against costly mistakes.
Learning Dynamics 365 for Operations / X++ 