Customer is using the old HTTP input. So I copied a workflow and changed it to NodeJS. When testing everything worked fine, both the old and the new workflow. However when I switch the ports between HTTP input and NodeJS (8080 and 8082), I would expect everything to work. However:
stopping Workflow after the change in order to activate the new settings takes a long time. Eventually I killed the Workflow process after which the service started without problems
When I test the new config using Postman, I don’t get any feedback from the webserver, it does receive the data. So my “new” workflow is all of a sudden not working anymore using NodeJS with the “old” HTTP input port.
Would you be able to describe what steps you have taken? The reason why I am asking this is because I couldn’t reproduce this issue by replacing the HTTP Server Input Workflow plugin Workflow plugin by the NodeJS Server Input Workflow plugin and changing the HTTP port to 8082 (1) and changing the NodeJS port to 8080 (2) in OL Connect Enterprise Workflow version 2023.2.
(1) Workflow Configuration application > OL Connect Workflow button > Preferences > OL Connect Workflow Preferences window > Plug-in > Inputs-HTTP server 1 > Port (8080 recommended)
(2) Workflow Configuration application > OL Connect Workflow button > Preferences > OL Connect Workflow Preferences window > Plug-in > NodeJS Server Input 1 > Port
So it seems that things go wrong when you also exchange the HTTP action between the 2. When I don’t do that the port switch is working indeed.
Also when I then try to stop the Workflow service this takes forever, using an entire CPU.
Indeed saw some old and recent stuff. Cleaned up, restarted. Did some testing, noticed that the old HTTP service is still started although there are no old inputs in the workflows anymore. When I killed this service the NodeJS input was finally working.
Somehow there seems to be some interference between the 2?
Did some more testing and without the HTTP input service I still see issues and hangups (CPU usage).
Made a final change: excluded some folders in the Windows Defender configuration … seemed to be working a lot better however after some tests the Workflow is back to CPU using again, so hangup.
The NodeJS workfolder is empty …
If the HTTP Server is still running, then there has to be an HTTP Input task somewhere in your configuration. The service cannot start by itself, it is launched by the Workflow service at start-up time only if at least one HTTP Input task is present in the configuration.
nope … doublechecked and also noticed that the http workdir remains empty after a restart. Normally subfolders are created named after the http actions. NodeJS does this at runtime I noticed
Long shot, but I have seen a setup where the Workflow’s http service startup type was changed from Manual to Automatic. To check, use windows Services console (services.msc), find Workflow HTTP/SOAP service and check the Startup type.
Well that’s a mystery I need to resolve, otherwise I won’t get any sleep this weekend…
(ok… maybe I’m exaggerating a bit… )
But anyway, if you are comfortable sharing the configuration with me, do so via private message.
If you can’t share it, then you may want to use the Workflow Search utility to look for any reference to the HTTP task. The tool comes with fairly comprehensive, integrated help, so you should be able to understand its usage quickly.
In some older versions of Connect Workflow, having a polling interval of 0 seconds on HTTP/NodeJS would cause a full core to be used at all times. Changing the polling interval to 1 second solves it. Maybe some processes have a 0 second polling interval in your process?
so the attachment is in de node where I would expect a link to the datafile in some tempdir? Causing some hangup in Workflow that eventually it solved because it’s probably digesting some stuff?
This works fine with the old HTTP input.
I suppose that the HTTP/SOAP service still gets started? If so, can you please confirm whether the Workflow Configuration send to the Workflow service also doesn’t contain any Workflow processes that contain the Input SOAP Workflow plugins, including inactive Workflow processes and ignored Input SOAP Workflow plugins?
I don’t think the old HTTP service is the issue. I see that NodeJS receives the data, size of the req. is correct. However the .dat file in the spooldir is 0 Kb … so somewhere in between NodeJS and PP Workflow there is an issue? Previously I noticed that the node was filled with the data instead of a link to the datafile.
Filesize doesn’t matter however when I send a file/body from Postman it looks like the 3cd*, if the host sends a file it looks like the 764*
Postman works fine, host causes the hangup/delay/failure. It works fine with the HTTP input so what’s the difference with NodeJS?
Based on the information provided so far I assume that it’s probably better to open a ticket via the support portal because I assume that scheduling a remote session is required to investigate the issue at hand.
)
