Webservice Debugging in AL using Docker

A common requirement in API development is Webservice Debugging in AL. Probably you have to write an AL extension to consume an external webservice. For sure, you want to intercept the web requests and interprete the results or the errors. But Webservice Debugging in AL isn‘t that easy using Docker containers. Although there are developers using the trial-and-error approach, seeing what’s on the wire is way more useful. For years, Fiddler has served me well here. And at least for local On Prem installations Fiddler still works great.

But how about Dynamics 365 Business Central development using local Docker containers? How could we intercept the web requests here? The docker containers are encapsulated and i don’t want to edit error-prone network routes.

Overriding the proxy settings

I found a very quick but powerful solution to this problem. We simply override the proxy-settings of the container’s operation system using standard windows tools (bitsadmin.exe):

function SetContainerProxy {
    param(
            [string]$ContainerName,
            [string]$Proxy,
            [string]$Domain
        )
        $session = Get-BcContainerSession -containerName $ContainerName -silent
    
        Invoke-Command -Session $session -ScriptBlock { Param($Proxy, $Domain)
            & 'C:\windows\System32\bitsadmin.exe' /Util /SetIEProxy LocalSystem Manual_proxy $Proxy $Domain
        } -ArgumentList $Proxy, $Domain
    }

Now we call this new function on our workstation:

# The container we would like to update
$ContainerName = "bc-docker"
# Proxy bypass
$Domain = "mydomain.dom"

# host.docker.internal stores your docker host's ip address
# Port 8080 is the standard listening port of mitmproxy
$ProxySettings = "http://host.docker.internal:8080"

SetContainerProxy -ContainerName $ContainerName -Domain $Domain -Proxy $ProxySettings

As the docker container always stores and updates the docker-host ip address in host.docker.internal, we override the containers proxy setting using this constant value. This way the proxy settings stay up to date, although your local ip address could change after reboot 😀

In the result we force the web requests of the container through the docker-host (our workstation)! In the next step, we can intercept these requests. Cool, isn’t it?

Visualize the requests

For visualization of the requests i don’t use Fiddler anymore, although it should work as well (probably on port 8888). Instead, I’ve recently started using mitmproxy, an man-in-the-middle tool I install on my machine. So, after installing the tool and updating my docker container’s proxy settings, I can easily debug my web requests using mitmproxy ui.

See the single requests…

Inspect request, response and payload…

In my opinion, this makes local webservice and API development much easier… because it has, unlike Fiddler, absolutely no effect on our local system. For someone who regularly implements webservices, this combination of docker and the full control of web requests is absolutely unbeatable. You might even “pause” the request using mitmproxy and edit its contents 😀 have fun with Webservice Debugging in AL.

Jens Fritzsche

... is a technical consultant and developer at Comsol Unternehmenslösungen AG in Kronberg/Taunus. Major tasks are the architecture and implementation of complex, usually cross-system applications in and around Microsoft Dynamics 365 Business Central.