Skip to main content

On my virtual desktop I have two ways I do an API call to ServiceNow to create an incident.

With Postman it is working. I've managed to create an incident in ServiceNow serveral times.
With One Desktop, with the same URL, header and JSON body I get Connection reset every time. And the Json call response debug file isn't even created.


So here is my Postman setup:

Authorization is a basic auth. Headers:

When I run this I get the following response:

{

    "import_set": "ISET0012345",

    "staging_table": "u_str_call",

    "result": u

        {

            "transform_map": "STR - Call API",

            "table": "incident",

            "display_name": "number",

            "display_value": "INC0217277",

            "record_link": "https://mydev.service-now.com/api/now/table/incident/8c47e2e6472fb11016fd2e61e36d4336",

            "status": "inserted",

            "sys_id": "8c47e2e6472fb11016fd2e61e36d4336"

        }

    ]

}

Now here is my One Desktop setup:

And my component with Json Call:

This is my Json Call:

And the headers:

You can see there is no auth header here. I assume it gets that from the server I defined. But I've tried it with and without. It makes no difference.

And this is what the request debug file shows:

POST https://mydev.service-now.com/api/now/import/u_str_call HTTP/1.1 Accept: application/json Content-Type: application/json

{ "u_short_description":"Ataccama DQ issue 2", "u_description":"Ataccama DQ Rule violated, sent via Json Call in component", "u_category":"Incident", "u_urgency":"4", "u_impact":"3", "u_service":"Data Management", "u_support_offering":"DDS", "u_correlation_id": "123SFSF23"}

And this is the error that I'm getting (always in threes for some reason):

2024-01-12 11:55:36 INFO]    org.apache.http.impl.client.DefaultHttpClient I/O exception (java.net.SocketException) caught when connecting to {s}->https://mydev.service-now.com:443: Connection reset 2024-01-12 11:55:36 eINFO]    org.apache.http.impl.client.DefaultHttpClient Retrying connect to {s}->https://mydev.service-now.com:443 2024-01-12 11:55:36 oINFO]    org.apache.http.impl.client.DefaultHttpClient I/O exception (java.net.SocketException) caught when connecting to {s}->https://mydev.service-now.com:443: Connection reset 2024-01-12 11:55:36 :INFO]    org.apache.http.impl.client.DefaultHttpClient Retrying connect to {s}->https://mydev.service-now.com:443 2024-01-12 11:55:36 nINFO]    org.apache.http.impl.client.DefaultHttpClient I/O exception (java.net.SocketException) caught when connecting to {s}->https://mydev.service-now.com:443: Connection reset 2024-01-12 11:55:36 ;INFO]    org.apache.http.impl.client.DefaultHttpClient Retrying connect to {s}->https://mydev.service-now.com:443

What am I missing here?

I've investigated further and it turns out our Postman setup uses the proxy to connect and for this it also has a certificate (.crt file). It looks very much I'm going to need a proxy certificate for One Desktop as well. But I don't know yet how to configure it.


Hi @Marcel-Jan just followed up with you over here. If you have any additional questions please let us know 🙋‍♀️


Well I hoped that I solved the proxy issue, but it now looks like it didn't.

Today I dived deeper into the Connection reset error. This article about it is quite good: Troubleshooting java.net.SocketException: Connection reset - Mastertheboss

I decided to try this out on the One App server by creating a workflow that runs this component. When I ran it oin the server I also got the Connection reset error. But running this on the server allowed me to do follow the network connection with tcpdump. It looked something like this:

$ sudo tcpdump -i any host mydev.service-now.com

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

19:16:35.903542 IP teoneapp01.mywork.nl.55780 > vip-192.168.0.123.cust.service-now.com.https: Flags , seq 1080682698, win 29200, options mss 1460,sackOK,TS val 1110873471 ecr 0,nop,wscale 7], length 0

19:16:35.924730 IP vip-192.168.0.123.cust.service-now.com.https > teoneapp01.mywork.nl.55780: Flags S.], seq 738545154, ack 1080682699, win 28960, options mss 1460,sackOK,TS val 425338985 ecr 1110873471,nop,wscale 9], length 0

19:16:35.924776 IP teoneapp01.mywork.nl.55780 > vip-192.168.0.123.cust.service-now.com.https: Flags .], ack 1, win 229, options nop,nop,TS val 1110873492 ecr 425338985], length 0

19:16:35.927293 IP teoneapp01.mywork.nl.55780 > vip-192.168.0.123.cust.service-now.com.https: Flags P.], seq 1:426, ack 1, win 229, options nop,nop,TS val 1110873494 ecr 425338985], length 425

19:16:35.930174 IP vip-192.168.0.123.cust.service-now.com.https > teoneapp01.mywork.nl.55780: Flags R.], seq 1, ack 426, win 229, length 0

 

Flags sR.] (in the last row) is the Connection reset that is happening. And as you can see the reset is coming from the ServiceNow address. That means that my request actually reaches their server. So by the looks of it, I have passed the proxy. So why I get this reset from ServiceNow is still unanswered, but this at least is one step further.

 


Today we finally found the solution. By requesting a firewall rule from my One App (test) server to ServiceNow I finally was able to create an incident and get a response back.

We had our security team consulting us in this. Bit strange they overlooked this. But I can finally start developing my solution.


Hi @Marcel-Jan it’s great that this has been resolved now, thanks for getting back to us here. 


Reply