Switch from HTTP input to NodeJS (2022.2)

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:

  1. 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
  2. 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.

Are there any best practises doing this?

Dear @sybren.kuperus,

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.

Small update: killing the service and restarting it works however the Workflow service keeps on claiming an entire CPU. In idle mode :wink:

There are probably unprocessed requests in Workflow’s working folders.

  • Stop/Kill the service
  • Using Windows File Explorer, navigate to C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\http
  • Delete everything in that folder
  • Do the same thing for C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\nodeJS
  • Restart the service

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 :wink:

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.

Nope it’s on manual.

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… :stuck_out_tongue: )

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?

@jouberto: this was fixed back in version 2020.1 for all inputs.

So I changed HTTP to NodeJS on the production server (running the same version) and I noticed the following:

  1. no cpu hangup, connection works and keeps working
  2. Old HTPP service running although it is not used (no subfolders created in the workdir)

Now what’s the difference between the 2 machines … :slight_smile:

Update: Postman test works fine, when the real host sends data the file in de spooldir for PP looks like this

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.

So what is happening in NodeJS?
I found this: https://stackoverflow.com/questions/19917401/error-request-entity-too-large
Indeed I noticed that the datafile was > 1 Mb …

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.