--- title: "Set up web service for Data quality studio" slug: "set-up-web-service-for-data-quality-studio-web-service-validation" tags: ["Task topic"] updated: 2026-03-20T11:32:09Z published: 2026-03-20T17:44:40Z canonical: "docs.staedean.com/set-up-web-service-for-data-quality-studio-web-service-validation" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.staedean.com/llms.txt > Use this file to discover all available pages before exploring further. # Set up web service for Data quality studio You can use a web service in: - A validation rule to validate if a field value matches a value in another internal or external source. - An action rule to fill a field value with a value from another internal or external source. To set up a web service validation rule or action rule, first set up the web service to be used. You can find most of the required values to be set for the web service in the technical documentation as shared by the web service provider. ### Steps 1. Click **Data quality management**. 2. Click **Web services**. 3. Click **New**. 4. Enter a name for the web service. The name is for internal use in Data Quality Studio only. So, no match is required with the external web service name. In the **Web service** field, type a value. 5. In the **Description** field, type a value. 6. In the **Web Service URL** field, enter the URL of the web service. 7. If a web service requires a certificate, you can select it in this field. If the required certificate is not available, you first must add it to the certificate store of the VM or computer on which D365 F&SCM is running. In the **Certificate** field, enter or select a value. 8. Sub-task: Define web service settings. 1. Expand the **Settings** section. 2. Define the request method for the web service. Make sure it exactly matches with a request method that is available for the web service. In the **Request method** field, type a value. 3. Define the content type of the request that you send to the web service. Make sure to match the content type that is required by the web service. For example, application/json, text/xml, or text/plain. In the **Content type** field, type a value. 4. You can use a custom class to define the request that you send to the web service. You can, for example, use a custom class to add some binary code or other logic to the web service request. The custom class must extend the **DQSWebServiceCustomFormatBase** base class. Use the **PostData** method to define web service requests. In the **Custom request handler** field, enter or select a value. > [!NOTE] > Note > > - You can use a custom class both for SOAP and non-SOAP. > - In the lookup of this field, only the classes are shown that extend the **DQSWebServiceCustomFormatBase** base class. > - You can use the same custom class for request and response. > - If you use a custom class in the **Request data provider** field, the Input parameters must be defined in the custom class. So, you cannot define Input parameters for the web service. 5. Define the expected content type of the response that you get from the web service. For example, application/json, text/xml, or text/plain. In the **Accept** field, type a value. 6. A web service can apply encoding to a response message. If so, define the used encoding for the response message. In the **Accept encoding** field, type a value. 7. You can use a custom class to define the response that you expect from the web service. You can, for example, use a custom class to add some binary code or other logic to the web service response. The custom class must extend the **DQSWebServiceCustomFormatBase** base class. Use the **parseResponse** method to define web service response. In the **Custom response handler** field, enter or select a value. > [!NOTE] > Note > > - You can use a custom class both for SOAP and non-SOAP. > - In the lookup of this field, only the classes are shown that extend the **DQSWebServiceCustomFormatBase** base class. > - You can use the same custom class for request and response. > - If you use a custom class in the **Response parser** field, the Output parameters must be defined in the custom class. So, you cannot define **Output parameters** for the web service. 8. Indicate if the web service access type is **SOAP** (Simple Object Access Protocol). If the access type is **SOAP**, you must also define the message pattern. Select **Yes** in the **Use SOAP envelope** field. 9. If the web service access type is **SOAP**, enter the required SOAP segments and schema as provided by the web service. Also enter the parameters in the message body. If you send a request, the parameter values are added to the parameters in the body in the message pattern. In the **Message pattern** field, type a value. > [!NOTE] > Note > > - You can only define a message pattern if the content type is 'application/xml'. > - Make sure to define the request parameters in the **Parameters** section or in the **Custom request handler**. 9. Sub-task: Define web service parameters. 1. Every web service requires parameters. The parameters define the web service values that are used to validate or set a D365 F&SCM value. Expand the **Parameters** section. > [!NOTE] > Note > > - If you use a custom handler for the request or response, the parameters must be defined in the custom handler. > - If the web service: > - Uses SOAP, the parameter values are added to the parameters in the body in the message pattern. > - Does not use SOAP, the parameters and parameter values are added to the web service URL. 2. Click **New**. 3. Enter the name of the parameter. Make sure the parameter name matches the corresponding name in the web service. In the **Parameter name** field, type a value. 4. Define when the parameter is applied: In the **Direction** field, select an option. > [!NOTE] > Note > > If you have defined a: > > - Custom request handler, you cannot set up **Request parameters**. > - Custom response handler, You cannot set up **Response parameters**. - **Request**: Defines what you send to the web service. So, it is the input for the web service. - **Response**: Defines what you get from the web service. So, it is the output from the web service. 5. If the parameter direction is: In the **Parameter value** field, type a value. - Request, you can define a default value. On the validation rule or action rule properties, you can choose to override this value with another value. Some parameters you do not override. For example, parameters like 'apikey' or 'id'. - Response, no value can be defined because you receive the value from the web service. 6. You can use secured values to store secrets at a central place in Data Quality Studio. You can, for example, set up a secured value for a license key or access token. You can use a secured value as a request parameter value to get access to a web service. In the **Secured value** field, enter or select the desired secured value. > [!NOTE] > Note > > - Use secured values only for parameters with the direction '**Request**'. > - If you use a secured value, do not fill in the **Parameter value** field. 7. If the web service type is SOAP, in a web service message, a parameter can be used several times in different locations. You can use a path expression to define the exact location in the web service message to enter or find applicable value. In the **Path expression** field, type a value. > [!NOTE] > Note > > You can only define a path expression if the content type is 'application/xml'. 10. Sub-task: Make web service active. 1. If the web service setup is completed, you can make the web service active. As a result, it becomes available for selection for validation rules and action rules. Select **Yes** in the **Active** field. > [!NOTE] > Note > > If active and used in an active data quality policy version, you cannot make the web service inactive. 11. Close the page. ## Related - [Set up web service configuration](/set-up-web-service-configuration.md)