An interesting issue I came across recently with regard to deploying a BPD from Process Centre ...
This assumes you're deploying to a cluster of Process Servers (v7.5.1) that are sitting behind an IHS webserver and that you have set up things in 100Custom.xml such that the deployment is routed via that webserver
It also assumes that you have removed all virtual host aliases on the process server cell leaving only the webserver port... i.e no http(s) comms will match a vhost alias except that of the webserver
If you have this setup, the deployment will fail and flag the following error in Process Centre's AppTarget SystemOut.log
This assumes you're deploying to a cluster of Process Servers (v7.5.1) that are sitting behind an IHS webserver and that you have set up things in 100Custom.xml such that the deployment is routed via that webserver
It also assumes that you have removed all virtual host aliases on the process server cell leaving only the webserver port... i.e no http(s) comms will match a vhost alias except that of the webserver
If you have this setup, the deployment will fail and flag the following error in Process Centre's AppTarget SystemOut.log
....
....
Caused by: com.lombardisoftware.core. TeamWorksException: Could not retrieve data, HTTP response code: Not Found
Caused by: com.lombardisoftware.core.
....
....
On enabling trace within your IHS plugin you'll notice that the POST request over which the deployment is being attempted trying to match a vhost entry of <hostname>:443 even though you've set your process server port to 11000 and that is the actual TCP port being used.
....
....
TRACE: ws_common: websphereVhostMatch: Failed to match: lonbpmwebst.gslb.db. com:443
....
....
....
I'm not sure why yet, but it seems that for some reason the $WSSP plugin header is being set to 443, which, if you're as OCD as I am won't exist because you would have removed that particular vhost entry.
The workaround for now is to recreate the 443 alias under the relevant virtual host but it's not elegant.
We saw that on our project last year. Since then, I've just been adding 443 back into my Virtual Hosts, along with (say) 8443 and 8444.
ReplyDelete