Transform Your Business Central Integration: Empower Your System by Replacing SOAP Webservice with OData4

Let’s discuss the process of migrating from SOAP Web Services to OData4 in Business Central and utilizing it via API.

In Recent article we heard this “Expose UI pages as SOAP endpoints (warning)”, Read full article from here

Today, I’ll discuss a recent change which Microsoft is going to deprecates the usage of pages and Codeunits to create API Webservices through the Webservice page. So, what’s the solution? How can we transition from SOAP functions to OData4? Let’s dive in.

To begin, I’ll demonstrate by creating a Codeunit and declaring some functions within it. We’ll then expose the Codeunit as a Webservice and utilize those functions in the traditional SOAP format.

First, follow the steps below to create the Codeunit and define a function within it.

odeunit 50100 "TestWebCodeunit"
procedure InsertSalesData(inputdata: text): Integer
Resource: Record Resource;
Resource.Type := Resource.Type::Person;
Resource.Name := inputdata;

In the Codeunit mentioned above, I have created a function called “InsertSalesData” with a single parameter named “inputdata” of type text. When invoking this function, any value passed to the “inputdata” parameter will be used to create a new Resource record, with the value assigned as the Name of the resource.

Next, you need to publish this app and declare the codeunit as a Webservice. Please refer to the image below for the steps involved.


I have created a service named “WebContentforItem” and marked the “Published” field to generate a SOAP URL automatically.

Now, let’s proceed with testing this SOAP Webservice by copying the SOAP URL from the Webservice page.

To test this SOAP Webservice, I will be using Postman, an application already installed on my machine. I will authenticate the Webservice using OAuth2.0. If you would like to learn how to register the app for OAuth2.0, please visit this link for detailed instructions.

Soap to Odata4

Take a look at the response I received when using the SOAP URL with the XML body. The response is consistently in XML format. When setting up the SOAP URL for testing in the App, ensure that the following header properties are correctly configured:

1. Content-Type: Set the Content-Type header property to “application/xml” to indicate that the content being sent is in XML format.

2. SoapAction: Include the SoapAction header property with a value of urn:microsoft-dynamics-schemas/codeunit/TestWebCodeunit:InsertSalesData to specify that the expected response should include that codeunit function.

By ensuring that these header properties are correctly set, you can effectively test the SOAP URL in the App and receive the desired XML responses.

SOAP and OData4

Here are the results from Business Central: the Resource record has already been successfully created.

SOAP and OData4

In the above steps, we followed the old way of creating the API using SOAP. Now, let’s transition to using OData4 to consume the same API.

We can utilize the same Webservice that we created in the Web Service page of Business Central. However, there are some changes we need to make in Postman to test the data.

To compile the OData4 URL, follow the format below:<TenantID>/<Environmentname>/ODataV4/<servicename>_<functionname>?company='<CompanyName>’

For our specific case, the URL will be as follows:’CRONUS%20International’

Please check the above OData4 URL in Postman to proceed with testing.

SOAP and OData4

Here, you can observe that we have used the JSON format for the request body. Within the body, we have provided the function’s parameter along with its corresponding value. Please ensure that you accurately enter the correct WebserviceName and function name in the URL, as the URL is case-sensitive.

Additionally, take note of the Header tab, where we have defined only one property.

SOAP and OData4

That concludes this blog.

I hope you found it helpful. Please feel free to provide any feedback you may have.