Debug a web service data source
Even so the usage of a REST data source is, in general, simple and well documented, there are cases when you have problems setting it up. This post will show you an option how to take a look at the executed requests. The use case will be that WEBCON BPS is run on a local environment which calls a Business Central REST web service.
In case you are running WEBCON BPS on WEBCONAPPS or you don’t have admin permissions you can read Debug a web service data source WEBCONAPPS instead of chapter
Preparation of this post.
For the described use case we have the following prerequisites
- HTTP Toolkit, or another alternative to intercept and view HTTP requests.
- An account with admin permissions, to install the software and install the certificate in case of HTTPS secured requests.
Configuration of HTTP Toolkit
After the download and installation of HTTP Toolkit you can click on
Anything from the
Intercept screen for more information.
Info: If your web service communication doesn’t use https, you can skip the rest of this chapter.
This will show detailed documentation from which you need to download the
Certificate Authority via
Export CA certificate.
The downloaded file needs to be added as a trusted root certificate for the local machine. This can be done via the import wizard available from the context menu of the file, right click the downloaded file (1), select ‘Install certificate’ (2), choose ‘Local machine’ (3) and ‘Trusted root certificate authorities’ (4) via the browse dialog.
Configuration of WEBCON BPS
When you want to view the outgoing request send by WEBCON BPS you need to configure the proxy inside the Designer Studio. It’s available in the System Settings\Global Parameters\ Proxy.
Make sure to activate it and use the URL provided by HTTP Toolkit.
Warning: When you are finished, deactivate the proxy configuration. Otherwise all outgoing calls will fail, if you close HTTP Toolkit.
View outgoing web request
Successful request example
If everything is setup, you can test it using the
popup search to search for example for an item. The request will be visible in HTTP Toolkit under
View. One search consists of a failed first call, because it’s executed anonymously, and the second one is executed with credential and should succeed with status 200.
Typical problems with filter mode ‘web service’
Depending on the underlying quantity of returned records you should make use of the filter mode
using web service.
Quote from the help:
Filtering according to the phrase (typed or selected with the picker) can be carried out in 2 ways: (1) Filtering on the side of the Web Service allows the invoked phrase to be transferred as a parameter. This way, the whole logic of the search is kept on the side of the Web Service. (2) Filtering on the side of BPS means that all data returned by the Web Service can to be narrowed down to only those searched for by the user. This way, there is no need to implement a filtering system within the Web Service.
Using this filter mode via an OData capable web service will be simple. You can use the
Searched column and
Searched value to get the column / value entered by the user.
The above screenshot may introduce the first problem. By default
Everywhere is selected which will search all columns. In the example, this will cause a problem. The filter expects a single column but
Everywhere translates to a comma separated list of the
Searching columns. In our case the executed requests fails.
Info: Take a look at the successful example. You can see that only one column was selected in the popup search due to the selected field in the drop down.
There’s one other caveat, that’s the automatic creation of the response (1). The internal name of all elements inside a collection will be prefixed with the name of the collection (2). The
Picker Filter:Search Column will use these internal names. Which in turn will fail, because the name with the prefix will not be known by the called system.
Changing the internal name, will fix this but you may need to setup the picker fields again because the internal name is used in the configuration.
Web service requests from an action
Actually, there’s no need for HTTP Toolkit if a path transition executes a web service action. If you look in the history you will find the execution of the action and an error message:
If you switch to admin mode though, the log will be displayed. You will see the request as well as the response.
Info: WEBCON did make a dream of mine come true, when I first learned about this four years ago. How did I struggle with other platforms to get this information…