sdgtw v.2.00 probe not connecting to SNOW
Article ID: 125332
Updated On:
Products
Issue/Introduction
sdgtw probe which was previously working would no longer connect to SNOW.
No environment changes known.
According to customer, no firewall was blocking the connection from the specific Primary hub/source machine to SN but the connection failed with the MDR error despite restart/cold start, reinstall, or robot restart.
Jan 25 21:20:11:654 [Thread-53, sdgtw] Exception in making the connection to MDR:java.lang.NullPointerException
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe.initiateAlarmSynchronizer(SDGtwProbe.java:270)
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe.initializeAndConfigureNim(SDGtwProbe.java:170)
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe.access$000(SDGtwProbe.java:68)
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe$1.run(SDGtwProbe.java:130)
at java.lang.Thread.run(Unknown Source)
sdgtw Nim.log showed:
[26/01/19 02:20:13:013 MST] [qtp53485142-31] ERROR common.GenericSOAPDispatchService: com.xxxx.xml.ws.client.ClientTransportException thrown in Invoke With Retry: Exception Message: 'HTTP transport error: java.net.ConnectException: Connection refused: connect': attempting call #2
[26/01/19 02:20:19:019 MST] [qtp53485142-31] ERROR common.GenericSOAPDispatchService: Type of exception thrown in Invoke Try: 'com.sun.xml.ws.client.ClientTransportException': Unknown problem occurred with message: 'HTTP transport error: java.net.ConnectException: Connection refused: connect'
[26/01/19 02:20:19:019 MST] [qtp53485142-31] ERROR common.GenericSOAPDispatchService: WebserviceException thrown in Invoke With Retry: Exhausted all retries with exception message 'HTTP transport error: java.net.ConnectException: Connection refused: connect'
Environment
-Any UIM version
- sdgtw 2.0
Cause
Resolution
-Observe if your specific REST URL referenced in the above document (last step) is working or not? Please check with SDM team.
-Once it IS successful, go to probe configuration, verify the credentials again and SAVE it.
-Deactivate and activate the probe once before you validate the credentials.
-Confirm no firewall is blocking the connection.
As it turned out, as per the Network team, a Security change was implemented the night before for an entire subnet group and this primary hub (where the sdgtw is installed was impacted by that change). The new Security policy was set to not allow any traffic previously sent over MPLS, from port 80/443, through the proxy unless it was specifically allowed.
We were told by the Network team that we could try using the proxy so they supplied the proxy settings but the Primary hub could not get TO/through the proxy until the GPO was modified and the Lan settings were changed. After that we were able to verify the SNOW server login page loaded.
Since the policy change now demanded that all http/https traffic be sent through the proxy, we had to configure the sdgtw proxy settings so we tried various combinations working with the customer but to no avail.
Notes:
URL: https://abc.service-now.com
username: <in our scenario this was required>
password: <also required>
Client URL: <https://server.service-now.com>
Proxy Server: <yourproxy.hosting.net>
Proxy Port: 8080
Proxy User: <your_service_user_name>
Proxy Password: <proxy_password>
Proxy Protocol: http OR https, but in our case although we were told the proxy doesn't require https connection, it had to be set to https for it to connect.
sdgtw connection proxy configuration was NOT needed until the security policy was changed.
An internal resource stated the proxy doesn't support https and that we didn't need a username and password for the proxy and various combinations did not work after testing, but after adding a username and password as well as setting the protocol to https, we were able to connect.
Additional Information
Attachments
Feedback
