SMF Connection error in Boomi

Anoj

Hi there,
I'm fairly new to Solace. I'm trying to set up a Solace PubSub+ connection in Dell Boomi (using Solace Connector in Boomi). I have been able to set this up successfully to connect to a Solace Cloud instance but when trying to connect to the local solace, I get a connection error. So I have a few questions regarding my setup:

• When using Solace Cloud, I'm given credentials to use for SMF under connections (I believe) which worked perfect. For Solace local (docker), I have my message-vpn setup with 'basic authentication' enabled with 'no authentication' as 'auth type'. I believe, I should be able to setup the connection with 'admin' username (default) and no password? Screenshot of the message-vpn attached.

• Is there a way to troubleshoot connection from my Boomi machine(I have SSH access) to Solace? I can confirm that basic connectivity is okay (can ping both directions).

Thank you in advance.

amackenzie

Where is your Atom running? If it's on the same host as your Docker container for the broker, you would need to set up a Docker network to talk to each other.

Anoj

Thanks for your reply @amackenzie . The Boomi Atom is running on a different VM but on the same VNet.

amackenzie

Did you add 55555 to your VMs network port configuration? The error message is saying it cannot communicate on the host:port.

Anoj

Thank you so much @amackenzie . I think you've put me on the right path. I see there's no ports mapped. This might be because of the switch missing on the last docker restart. I found that there's a docker run script used to start a docker (background :I inherited the current solace setup). This resembles instructions on the Solace documenation website (e.g. https://docs.solace.com/Solace-SW-Broker-Set-Up/Docker-Containers/Set-Up-Docker-Container-CentOS-Azure.htm) . If we were to follow the documentation, where would the port mapping happen (docker to VM)?

#!/bin/bash
sudo docker run \
--network=host \
--uts=host \
--shm-size=2g \
--ulimit core=-1 \
--ulimit memlock=-1 \
--ulimit nofile=2448:42192 \
--restart=always \
--detach=true \
--memory-swap=-1 \
--memory-reservation=0 \
--env 'username_admin_globalaccesslevel=admin' \
--env 'username_admin_password=XXXXX' \
--env 'nodetype=message_routing' \
--env 'routername=primary' \
--env 'redundancy_matelink_connectvia=10.XXX.X.51' \
--env 'redundancy_activestandbyrole=primary' \
--env 'redundancy_group_password=XXXXXXX' \
--env 'redundancy_enable=yes' \
--env 'redundancy_group_node_primary_nodetype=message_routing' \
--env 'redundancy_group_node_primary_connectvia=10.XXX.X.50' \
--env 'redundancy_group_node_backup_nodetype=message_routing' \
--env 'redundancy_group_node_backup_connectvia=10.XXX.X.51' \
--env 'redundancy_group_node_monitor_nodetype=monitoring' \
--env 'redundancy_group_node_monitor_connectvia=10.XXX.X.8' \
--env 'configsync_enable=yes' \
-v /opt/vmr/internalSpool:/usr/sw/internalSpool \
-v /opt/vmr/diags:/var/lib/solace/diags \
-v /opt/vmr/jail:/usr/sw/jail \
-v /opt/vmr/softAdb:/usr/sw/internalSpool/softAdb \
-v /opt/vmr/var:/usr/sw/var \
-v /opt/vmr/adb:/usr/sw/adb \
--name=solacePrimary store/solace/solace-pubsub-standard:9.2.0.14

TomF

Hi @anoj, It's looks like you're having a few challenges, so let's get you started. Firstly, you have --network=host in the Docker command line. What this should mean is that there are no port mappings required - the container shares the network with the host machine. The Docker documentation talks about this in more detail.
So, you should be able to see port 55555 (note: NOT 5555 as you have above).
Looking at your other post of the message-vpn being down, it's likely that the container isn't providing any messaging service, which is why port 55555 is not responding. I'll talk about why that might be in your other post.

swenhelge

Hi,
There is a docker example that shows how to expose ports (see further below)
However I don't think this is required as the docker template uses "host" network driver.
First thing to do is to see if anything is listening on 55555 (note - in your last screen you are checking for 5555 instead).

• Examine all network interfaces and verify that a new one was not created.
  ip addr show

• Verify which process is bound to port 55555, using the netstat command. You need to use sudo because the process is owned by the Docker daemon user and you otherwise won’t be able to see its name or PID.
  sudo netstat -tulpn | grep :55555

( I have taken the se steps form - https://docs.docker.com/network/network-tutorial-host/
Here is an example where the default network driver (bridge) is used:
https://github.com/SolaceLabs/solace-single-docker-compose/blob/master/template/PubSubStandard_singleNode.yml

Anoj

Thanks @TomF and @swenhelge !
It does seem that when we use the '-network=host' switch, 'docker container port CONTAINERNAME PORT' command is not usable (it seems to just return which ports are exposed explicitly).

I resorted to using a simpler docker run where I am explicitly exposing the ports (note that the redundancies have been removed for simpler troubleshooting). I can confirm that port 55555 is being listened to on the Solace VM (first screenshot). Also could see that the Boomi atom could reach out to Solace on port 55555 (second screenshot). I still seem to get a 'timeout' when trying to 'Test Connection' from Boomi. I've reached out to Boomi Support as well.

#!/bin/bash
sudo docker run \
-d \
-p 8080:8080 \
-p 55555:55555 \
-p 80:80 \
-p 8008:8008 \
--shm-size=1g \
--env username_admin_globalaccesslevel=admin \
--env username_admin_password=XXXXXX \
--name=solace solace/solace-pubsub-standard

[screenshots removed by request - TM]

TomF

Hi @Anoj, OK, it sounds like you're making progress. The next stage I suggest is to check that messaging is working. Open a browser tab and point it to 10.124.4.50:8080. This should open PubSub+ manager. Then click the "Try Me" menu item on the left
Click the connect button (after filling in the username and passwords) and see if the connection can be made. There will be some helpful error messages at the bottom which will help us get to the bottom of the problem. Once we've checked you can connect to the broker, we can move on to working out what's going on with the Boomi connector.

Anoj

Hi @TomF , messaging is working okay when trying from the 'Try Me!' tab.
I also had solace installed in a couple of other VMs (setup for redundancy before) so I tried to connect to solace message VPN on VM#1 from the solace on VM#2 and VM#3 .

• Open http://VM2IP:8080 in browser.
• Subscribe to a ws://VM1:8008 in 'Try Me!' tab subscriber.
• Open http://VM2IP:8080 in browser.
• Subscribe to a ws://VM1:8008 in 'Try Me!' tab subscriber.
• Send message from VM1 (http://VM1:8080) publisher in 'Try Me!' tab.
• Observe the same message from VM2 and VM3.

In summary, I could listen to messages sent from Solace VM1 from Solace VM2 and Solace VM3. I think I'm safe to assume that the network communications between the 3 VMs at least is sound (at least for port 8008)?

TomF

Good, OK, so we have brokers working and passing messages. That means we can concentrate on getting the Boomi Atom to work. The first thing we need to understand is if there is a working network connection from where the Boomi Atom is deployed to where the brokers are. It's possible there's a firewall or cloud service security policy that's preventing the network connection. The Atom will connect to the broker over port 55555. Is there a way you could run a network test, such as telnet, to VM1IP and VM2IP, just to check if those connections are open?

Anoj

Hi @TomF ,
Thanks for your continued support. I used a timeout to try and connect to Solace VM on port 55555 from the Boomi Atom. It looks like that was successful.

BoomiAtom$ timeout 1 bash -c 'cat < /dev/null > /dev/tcp/SOLACEVM/55555'
$ echo $?
0

What's happening here is that timeout will run the subcommand and kill it if it doesn't exit within the specified timeout (1 second in the above example). In this case bash is the subcommand and uses its special /dev/tcp handling to try and open a connection to the server and port specified. If bash can open the connection within the timeout, cat will just close it immediately (since it's reading from /dev/null) and exit with a status code of 0 which will propagate through bash and then timeout. If bash gets a connection failure prior to the specified timeout, then bash will exit with an exit code of 1 which timeout will also return. And if bash isn't able to establish a connection and the specified timeout expires, then timeout will kill bash and exit with a status of 124.
https://stackoverflow.com/questions/4922943/test-if-remote-tcp-port-is-open-from-a-shell-script

Interestingly, Boomi Support has asked me upload JAR files in order to be able to use Solace connector; which I think is wrong. I do not intend to use the JMS connector and hence shouldn't need the JAR files in question? "")

https://help.boomi.com/bundle/connectors/page/int-JMS_connection_Solace.html

TomF

OK, so it looks like we have the network connectivity we need from the Atom to Solace. The next step is to look at the Connector configuration to make sure that's correct. Looking at your original configuration, you have the host address, then the MessageVpn as "default," and the client username as "admin".

First things first, can you verify that the "default" messageVPN is enabled and "up".

Secondly, I doubt very much you want to use the client username of "admin." There are two classes of users in PubSub+: management and client. "admin" sounds very much like a management username and is probably the username you use to log on to the web interface. Messaging users have different client usernames. The good news is there is already one created for you, with the original name of "default." Drill in to the "default" messageVPN, then open the "Access Control" menu on the left hand side. Select "Client Usernames" at the top. Check that the "default" client username is enabled.

Once that's done, change the client username setting in the Boomi Connector to "default."

Anoj

Thanks @TomF ! At the moment, I am able to connect to the Solace VM#1 from the 'Try Me!' tab. The credentials I'm using to connect here is what I'm trying. The fact that I'm able to connect would also confirm that the Message VPN is up. The only difference here seems to be the ports. Also to note, I tried to connect Boomi to a Solace Cloud instance and that worked fine (so the connector itself is working).

Thanks again for your continued support.

Anoj

I found something interesting in Boomi. The test connection in Boomi seems to use 'Boomi Cloud' but we are using self hosted Boomi. Let me look into this as well.

amackenzie

that would definitely be a problem as the Boomi Atom Cloud cannot reach your broker, correct?
I can look into why you cannot test the broker connection on a local Atom. I get the same thing when I use the Boomi-deployed version of the connector, however, if I use a private connector (which we have on our account from when we were doing development on the connector), it allows testing connection on any Atom. This might be part of the way Boomi deploys the partner connectors.
But... you can move on to creating a Connection Operation like GET or LISTEN and try it out that way. I would suggest bypassing the Test Connection for now and just set up a simple process with a GET as the operation consuming messages from a queue on the broker. Deploy that to your local atom, execute it and see if the connection works. It sounds like it should. Then you can branch out to more ambitious processes.

Anoj

That makes sense

Thanks @amackenzie !