Whether you are publishing or consuming web services, exceptions and dialog boxes that may be displayed while code runs must be handled correctly. Exceptions must be handled to prevent the system from ending the web service client execution. You can handle exceptions in the following ways:
- Writing conditional code inside Microsoft
- Writing the code in the web service client
The most robust solution is to use both methods.
Publishing Web Services
When publishing a web service, you must make sure that the code that you are publishing does not assume the ability to interact with a user through the UI. You can use the GUIALLOWED Function to suppress the UI. For example, you can use this function to determine whether a codeunit is being called from the RoleTailored client or from a web service client. You must make sure to suppress errors when a codeunit is called from a web service client.
When implementing a conditional code check in Microsoft Dynamics NAV, you should implement the check only around code that could cause an error. You should not encapsulate the whole business logic.
|The server returns the following exception when trying to invoke a dialog UI through a web service: Microsoft.Dynamics.Nav.Types.Exceptions.NavNCLCallbackNotAllowedException: Callback functions are not allowed.|
C/AL Keywords That Can Cause Faults or Exceptions
Variables of the Dialog Data Type or any of the functions listed as dialog functions can cause callback not allowed exceptions when they are called from a web service application. The MESSAGE Function (Dialog) is the only function in this category that does not cause an exception.
Other keywords that you should not use are:
You should also avoid operations on client-side Automation and .NET Framework interoperability objects.
Consuming Web Services
You must handle exceptions in client code that calls a Microsoft Dynamics NAV web service. Appropriate exception capturing code should be included around any call to a Microsoft Dynamics NAV web service.