WebDirect allows FileMaker developers to run a FileMaker application directly in a browser without web programming effort. Users with little to no coding experience can completely transform their user experience by opening up access to a browser.
WebDirect depends on having both fmscwpc (Custom Web Publishing) and jwpc (Java runtime) processes running and in a healthy state. If one of them is down, then WebDirect is down on the machine where one of these processes is not running. This applies to both the primary and secondary (worker) machines.
Below are screenshots of the potential statuses of the Web Publishing Engine in the admin console’s Connectors > Web Publishing page.
When the status is” unavailable,” you can try restarting the server or WPE, which usually takes a few seconds or even minutes to get back up and running. However, I prefer to investigate the root cause of why it went offline to prevent such issues from recurring in the future. In the remainder of this blog post, I will discuss one of the steps I take in such situations.
Undocumented Health Check Endpoint
You can get a more detailed status of the Web Publishing Engine (WPE) by checking the JSON response of the server’s /fmi/mwpew/wpe/info endpoint (https://{primary or secondary server hostname}/fmi/mwpew/wpe/info). This endpoint does not require authentication.
If you are curious about the backend of this endpoint, the origin of this endpoint is http://127.0.0.1:16002/fmswpew/wpe/info. 127.0.0.1, the same server that opened the URL, so make sure you run it on the FileMaker Server. The fmshelper process is the process that listens to requests to 16002.
This endpoint is especially helpful when the status is “Unavailable,” and you need more information about what’s wrong. Of course, you can run “fmsadmin restart wpe -y,” but it’s better to know which process caused the status to show up as “Unavailable.” Is it Java or the Web Publishing Engine? The answer to that should guide you toward the next step in your root cause analysis. Note that the Web Publishing Engine can be offline even if the status is “running.” I’ve noticed that this endpoint is more accurate than the status I see in the admin console.
Sample Responses from FileMaker Server 20.3.1
Below are some sample responses to familiarize yourself with the response of this endpoint.
The responses were returned by FileMaker Server on Windows. The process name on macOS and Ubuntu wouldn’t have the “exe” extension.
{
"cwpc":
{
"autoStart": true,
"componentKey": 8,
"enabled": true,
"id": 2244,
"processName" : "fmscwpc.exe",
"running": true
},
"jwpc":
{
"autoStart": true,
"componentKey": 9,
"enabled": true,
"id": 4468,
"processName" : "java.exe",
"running": true
},
"result": 0
}The values we care about most are cwpc.running and jwpc.running. Both are Boolean values.
Web Publishing Component Process Not Running
If the web publishing component process is not running (cwpc.running is false)
{
"cwpc":
{
"autoStart": true,
"componentKey": 8,
"enabled": true,
"id": 2244,
"processName" : "fmscwpc.exe",
"running": false
},
"jwpc":
{
"autoStart": true,
"componentKey": 9,
"enabled": true,
"id": 4468,
"processName" : "java.exe",
"running": true
},
"result": 0
}Solution: If cwpc.running is false, run “fmsadmin start wpe” to start up the cwpc process.
I would use fmsadmin restart wpe, in this case, to always force a restart whether the process is offline or hung up
Java Runtime Process Not Running
If the Java runtime process is not running (jwpc.running is false):
{
"cwpc":
{
"autoStart": true,
"componentKey": 8,
"enabled": true,
"id": 2244,
"processName" : "fmscwpc.exe",
"running": true
},
"jwpc":
{
"autoStart": true,
"componentKey": 9,
"enabled": true,
"id": 4468,
"processName" : "java.exe",
"running": false
},
"result": 0
}When you attempt to open the WebDirect launch center, it will return a 502 Bad Gateway HTTP error in this case.
Solution: if jwpc.running is false, run “fmsadmin start jwpc” to start up the jwpc process.
Other Internal Endpoints
Another example of a hidden endpoint is http://127.0.0.1:16002/fmswpelocal/workers/list, which lists the worker machines. However, you can get the same information through the Admin API.
There are other interesting endpoints for the internal Admin API. You can use it to get pretty much anything on the admin console, including server performance stats.
Using the Endpoint with External Load Balancers
When using an external load balancer, you can have a cluster of secondary machines handling WebDirect users without any WebDirect user burdening the primary machine. In this setup, it is possible to have a group of secondary machines that handle WebDirect users without overloading the primary machine. An external load balancer can be used to distribute the load of WebDirect users instead of FileMaker Server’s built-in load balancer (FLB), which allows more resources to be dedicated to other components, such as the Database engine, Script engine, Data API, and OData. We’ve successfully implemented such architectures before, and we’d be happy to help you with it to meet your enterprise network architecture requirements.
Deployments with External Load Balancers
The /fmi/mwpew/wpe/info endpoint is also useful in these deployments with external load balancers. The load balancer can use this endpoint to determine the “healthiness” of secondary machines. In other words, the load balancer would consider an upstream server (primary/secondary machine) as a healthy upstream server for WebDirect users only if the results of both cwpc.running and jwpc.running are true. This should be easier to use than the Admin API since not all load balancers can handle a separate call for authentication in their health check flows.
You could also check the returned HTTP code of https://{server hostname}/fmi/webd. HTTP 200 OK would mean that the upstream server is healthy, but the caveat is that sometimes it returns HTTP 200 while WPE is offline.
Health Check for Secondary Machines
A good health check for secondary machines would cover the following:
- /fmi/mwpew/wpe/info HTTP response code is 200 OK
- /fmi/mwpew/wpe/info TLS certificate is valid (verified certificate)
- /fmi/mwpew/wpe/info response time is below a certain threshold, such as below 150 ms
- /fmi/mwpew/wpe/info > cwpc.running is true
- /fmi/mwpew/wpe/info > jwpc.running is true
Make sure you enable sticky sessions on your load balancer. Use secondary machines, and do not run WebDirect on the primary machine. If a worker is down, then have the external load balancer (such as F5 BIG-IP, NGINX, or HAProxy) cut traffic to that worker (a.k.a upstream server) so new connections don’t go through it.
Monitoring and Automated Remediation
You can monitor the cwpc.running and jwpc.running values using a monitoring tool such as Zabbix to track the status over time and trigger an automated flow to restart the components.
You can also automate restarting jwpc and cwpc through a PowerShell or bash script. However, it would be better if you resolve the root cause of what’s causing WPE or JWPC to crash in the first place.
Both “running” values can be “true,” but WebDirect might still be offline. In these rare cases, I would check the healthiness of the web server and make sure that the TLS certificate installed on the server is fully compatible with the FileMaker Server.
It is the web server (IIS, Nginx, Apache) that forwards traffic to the internal workings of WebDirect. If the web server is not functioning, then nothing will be able to reach WebDirect even if the WebDirect components are running fine.
Monitoring Your Web Publishing Engine Moving Forward
Understanding and effectively monitoring the Web Publishing Engine can be pivotal for maintaining seamless operation in your FileMaker environment. If you’re encountering persistent issues or need expert assistance setting up a robust load-balanced architecture for WebDirect, don’t hesitate to reach out. Our team is well-versed in these challenges and ready to help you achieve optimal performance and reliability for your setup.
