Hi, I'm trying to get the following to work without any success. I have one server with IIS, two databases, two webspeedapplications and I want two webspeedbrokers. One for each database/application and both with there own compiled html-files. Problem is that the second webspeed broker keeps pointing to the first one. So it executes the compiled html-files of the first webspeed application and points to the first database. I've tried the following solution: knowledgebase.progress.com/.../P77545 I must mention that I placed the script-files into another directory and use .init files, so my url is: servername/.../wslogin.html and servername/.../wslogin.html Where in the .init files the following is added: etest.init: -i wsetest (for the first application) etestdev.init: -i wsetestdev cgiip -f C:\Progressx86\OpenEdge\properties\properties\ubroker.properties_Dev (for the second application that isn't working) Nameserver is disabled. Any suggestions ?
maybe you can drop cgi-bin all together and give akera.io a try :)
One 'messenger' inside the node.js server that can connect to multiple brokers (even with load balancing based on alias/weight)... each broker get's it's own mounting point - http://host/broker/some_file_to_run
You say the NameServer is disabled? Then how is cgiip finding any WebSpeed broker? The -i WServiceName tells the NameServer which WebSpeed broker to redirect the request too. Without a NameServer you must give the Host and Port of the WebSpeed Broker
In the cgiip.wsc, you will see 4 different ways to use the file: 2 and 4 expect the NameServer, 3 just explains how to point to another ubroker.properties (not in DLC). 1 is the format you should be using.
You need to set hostname port. The port is the WebSpeed broker port (not the NameServer), 3090 by default.
If both WebSpeed brokers are configured in a single ubroker.properties, then you don't need to use the -f and redirect to separate ubroker.properties files.
Lastly, I have no idea what the your .init files are doing, but if it is like the cgiip.wsc then is needs to either call the $DLC/bin/cgiip.exe and pass the host and port or, as with cgiip.wsc, be associated with cgiip.wsc by ISS (as in kbase: knowledgebase.progress.com/.../16091).
Hope this helps, Roy
Thanks for replying.
First, the two .init files are just a replacement of the .wsc files.
What I have is one messenger.CGIIP on port 3055 (what is set by default).
Then i have two webspeed brokers:
- wsetest on port 3055
- wsetestdev on port 3070
In my two .init files I have two lines:
So if i use /etest.init/wslogin.html or servername//etestdev.init/wslogin.html, both point to the same webspeed broker and same application (wsetest). Offcourse the two webspeedbrokers have different propath's and different .pf's.
If I change my Messenger.CGIIP to port 3090 and change the two .init files to 'hqserver 3090', nothing works.
If I change my Messenger CGIIP to port 3070 and change the two .init files to 'hqserver 3070', both point to wsetestdev.
I'm doing something wrong here, but I can figure out what .....
Thanks for replying, but at this point, I really don't have the time to look into a change of the configuration ... I can believe it's a better way to go, but like everybody, time-problem....
well that makes sense then. The port value will always point to the first WebSpeed broker.
So one .init should read:
the other .init should read:
again the -i (dash eye) is only used with a NameServer. If you are not using a NameServer it has no value and does nothing.
Well, I was also thinking the same, and i tried it, but both keep pointing to the same database/webspeed application ....
The port should override the [WebSpeed.messenger.CGIIP] port value, but lets try something.
for the first .init leave it the same.
for the second .init point to a different ubroker.properties
1) copy ubroker.properties to mydev.properties (or whatever)
2) change the default port in [WebSpeed.messenger] to 3070
second .init try
hpserver 3070 -f <path>/mydev.properties
And let me know, Roy
Is a good suggestion, tried it, but it didn't work ....
I didn't stop and start the adminservice, can that be the reason. It's a production environment, so maybe tonight I can start and stop the adminservice.
no, you don't need to restart the AdminServer. Each time a request is made to the cgiip.exe it should read the files listed.
the only thing you may have to restart is IIS for the changes you are doing.
I can only think the problem is with how the IIS is loading the INIT files.
Restarting IIS didn't help.
Maybe, for some reason, IIS always uses etest.init instead of etestdev.init (even if it's in the URL). I'll have look in that direction ...
Thanks for helping me out.