There are two types of Dynamics 365 Business Central Web Services that are supported: SOAP and OData. The Web services are a lightweight, industry standard way to make the app functionality accessible to a variety of external systems and users.
Developers can create and publish functionality as web services, where they expose pages, code units or queries and even upgrade a page web service by using an extension code unit. When MS D365 Business Central objects are published as web services, they are immediately available on the network.
Dynamics 365 Business Central Web Services are stateless and do not preserve the values of global variables or single-instance code units between calls.
Dynamics 365 Business Central Web Services Comparison
1. Comparing SOAP and OData Web Services
Developers planning to create Microsoft Dynamics NAV web services may need to decide which type of web service is better suited to their needs. The following table details the types of web service applications that you can create for the web service protocols.
|SOAP web services||OData web services|
|Pages||Yes: Create, Read, Update, and Delete operations (CRUD)||Yes: Create, Read, Update, and Delete operations (CRUD)|
Business Central supports OData web services in addition to the SOAP web services that have been available since Microsoft Dynamics NAV 2009.
SOAP Web Services
SOAP web services allow full flexibility for building operation-centric services. They provide industry standard interoperability. Windows Communication Framework has assisted SOAP services since its first release in .NET Framework 3.0, and further releases of the .NET Framework have added additional support and default bindings to make it simpler to build SOAP services using Windows Communication Framework.
The most common type of messaging pattern in SOAP is the Remote Procedure Call (RPC), where one network node (the client) sends a request message to another node (the server), and the server sends a response message to the client.
OData Web Services
The OData standard is well suited for web service applications that need a uniform, flexible, general purpose interface for exposing create retrieve update delete (CRUD) operations on a tabular data model to clients. OData is less suited for applications that are primarily RPC-oriented or in which data operations are constrained to certain prescribed patterns.
OData supports Representational State Transfer (REST)-based data services, which permits resources, recognized utilizing Uniform Resource Identifiers (URIs) and defined in an abstract data model (EDM), to be published and edited by web clients inside corporate networks and across the Internet using simple Hypertext Transfer Protocol (HTTP) messages.
OData services are lightweight, with functionality frequently referenced directly in the URI. Whereas SOAP web services expose a WSDL document, OData web services expose an EDMX document containing metadata for all published Dynamics 365 Business Central Web Services.
OData is supported in PowerPivot, a data-analysis add-in to Microsoft Excel that provides enhanced Business Intelligence capabilities. PowerPivot assists distribution and collaboration on user generated BI solutions in a Microsoft SharePoint Server environment.
The extensions to the Atom Publishing Protocol defined in the AtomPub extensions to the OData protocol documentation describe how the REST based data services can allow resources, identified using URIs and defined in an abstract data model (EDM), to be published and edited by web clients inside corporate networks and across the Internet using simple HTTP messages.
In addition to the AtomPub format, the OData implementation in Business Central also supports the JSON format, a somewhat less verbose format that may perform better in low-bandwidth environments.
Page Web Services
When you expose a page as a SOAP web service, you reveal a default set of operations that you can utilize to handle common operations such as Create, Read, Update and Delete. Page based web services provide built in optimistic concurrency management. Every operation call in a page based web service is handled as a single transaction.
For SOAP services, you can also use extension code units to extend the default set of operations that are available on a page. Adding an extension code unit to a page is helpful if you want to perform operations other than the standard Create, Read, Update and Delete operations.
The advantage of adding an extension code unit to a page is that you can make the web service complete by adding operations that are logical to that service. Those operations can utilize the same object identification principle as the basic page operations.
Codeunit Web Services
For SOAP services only, code unit web services give you with the most control and flexibility. When a codeunit is exposed as a web service, all functions defined in the codeunit are exposed as operations.
Query Web Services
When you expose a MS Business Central query as an OData web service, you can query that data to return a service metadata (EDMX) document or an AtomPub document.
Web Services and Regional Settings
Data is formatted according to the value of the Services Language setting for the similar MS D365 Business Central Server instance. The default value is en-us. This means that Business Central Server interprets all incoming data as the specified culture, such as dates and amounts.
If you know that the Services Language setting is always en-us, for example, your code can be based on that assumption. In a multilanguage environment, you will see more predictable transformations of data if data that is transmitted through Dynamics 365 Business Central Web Services is in a consistent culture.
Similarly, you can use the ServicesOptionFormat setting to specify how Business Central Server must understand option values. If you set the ServicesOptionFormat setting to OptionString, Business Central Server understand option values as the name of the option value, which is always en-us.
If you set the setting to OptionCaption, web service data will be interpreted in the language specified by the Services Language setting.
Web Services in Multitenant Deployments
If your Business Central solution is used in a multitenant deployment architecture, you must make sure that any code that generates or consumes a web service specifies the relevant tenant. Web services are set up in the application, but typically you want to consume company-specific and tenant-specific data.
If you use host names for tenants, the host name must be specified as an alternative ID. For example, the following URL consumes the Customer ODATA web service for a specific tenant:
If you use the GETURL method, the generated URL will automatically apply to the users tenant ID. The URL for accessing a web service in a multi-tenant deployment must specify the tenant ID in one of two ways: As a query parameter, or as a host name. For more information on Microsoft Dynamics 365 Business Central Web Services, please contact us.