one more thing….

Yesterday , I explained how to use Fiddler Use Fiddler with NAV to monitor Network traffic.

What I did not mention is the last issue I needed to resolve.

The final call initially failed with a weird message  :

The remote certificate is invalid according to the validation procedure

Google could not help me here, all kinds of suggestions to disable the certificate checking. Not something you want to do when contacting a payment provider..

Finally I started to suspect Fiddler of some sort of wrong doing.

I  stopped Fiddler and tried again.   YES!  Triumph! Even without turning off the machine.config proxy..

Funny thing is that Postman did not have this problem…… Even with fiddler turned on

Use Fiddler with NAV

Fiddler is a nice tool for sniffing network traffic.

It can be downloaded here: http://www.telerik.com/fiddler.

When I needed to sniff my network traffic (NAV Consume Webservice Black-Belt ) I discovered that Fiddler “out-of-the-box” does not show the Network packages from NAV.

This is cause NAV instance is running as a service and Fiddler only looks at processes within your current session.

If you need to sniff the network packages from NAV as well please follow these steps:

This is done like this:

  1. Go to : C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
  2. locate the file machine.config.
  3. open the file (first create a backup)
  4. locate the section <system.net>  (or create this section at the bottom , within configuration tag).
    Update the section to:

      <!-- The following section is to force use of Fiddler for all 
           applications, including those running in service accounts -->
      <system.net>
         <defaultProxy
            enabled = "true"
            useDefaultCredentials = "true">
            <proxy autoDetect="false" bypassonlocal="false" 
                proxyaddress="http://127.0.0.1:8888" 
                usesystemdefault="false" />
          </defaultProxy>
      </system.net>
  5. Restart NAV Service tier.
  6. (do not forget to remove this section (use the backup from step 3) and restart NAV after sniffing.

This makes the NAV calls visible within Fiddler!

 

Cheers!

NAV Consume Webservice Black-Belt

Often a small assignment turns out to be somewhat more….

Also this time the question was simple.
“Please develop some code that calls this webservice, the information is at the providers site, use JSON”.

so I went to the providers’ site and found some documentation:

API Specs

Apparently : need to Use X-APIKEY request header to identify myself. And I can test my apikey with this API Call:

GET //v1/transaction HTTP/1.1
Accept:application/json, text/plain, */*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Connection:keep-alive
Host:api.spryngpayments.com
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36
X-APIKEY:zJqFMRBDT8BPgkPO81UC0js2TWoFK

So I started with a test codeunit :

4 variables: (all on server)

HTTPWebRequest - System.Net.HttpWebRequest.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
HTTPWebResponse- System.Net.HttpWebResponse.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
Streamreader - System.IO.StreamReader.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
String  : Text[1024]

one-function “Do-IT”

HttpWebRequest := 
    HttpWebRequest.Create(https://sandbox.spryngpayments.com/v1/api_key'');
HttpWebRequest.Method := 'GET';
HttpWebRequest.ContentType('application/json');
HttpWebRequest.Headers.Add('X-APIKEY','my ApiKey');
HttpWebResponse := HttpWebRequest.GetResponseAsync.Result;
StreamReader := StreamReader.StreamReader(HttpWebResponse.GetResponseStream);
String := StreamReader.ReadToEnd;
HttpWebResponse.Close();
MESSAGE(String);

And go!

KaBooommmmm

this is a no go! an Ugly error appears:

An existing connection was forcibly closed by the remote host

hmm what to do…

Tried a bunch of things:

  • ask the provider –> should work, no clue
  • search on mibuso –> nope
  • add an issue on mibuso  this is the issue
  • use an alternative app ( Postman – the perfect tool for testing RESTAPI and more)
  • changed to HTTP  –> Got a permanent redirect ( to the HTTPS)
  • tried another REST API –> works like a charm  (try it yourself here)
  • tried another api with HTTPS –> works perfectly

No luck following these paths. Need to have a root cause, in order to find a solution.

So I used Fiddler , a great tool to sniff your network traffic. Installed on my system and go.

B*mmm .. no trace of the NAV webcall.

Found out this is since NAV is running as service and the service needs to be informed to reroute all package through fiddler.

This is done like this:

  1. Go to : C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
  2. locate the file machine.config.
  3. open the file (first create a backup)
  4. locate the section <system.net>  (or create this section at the bottom , within configuration tag).
    Update the section to:

      <!-- The following section is to force use of Fiddler for all 
           applications, including those running in service accounts -->
      <system.net>
         <defaultProxy
            enabled = "true"
            useDefaultCredentials = "true">
            <proxy autoDetect="false" bypassonlocal="false" 
                proxyaddress="http://127.0.0.1:8888" 
                usesystemdefault="false" />
          </defaultProxy>
      </system.net>
  5. Restart NAV Service tier.
  6. (do not forget to remove this section (use the backup from step 3) and restart NAV after sniffing.

This made the NAV calls visible within Fiddler! ( and added a blog)

After some sniffing between the Postman’s successful calls and the NAV unsuccessful call the root cause became clear:

The problem was caused during establishing the HTTPS connection :

Postman ( success):

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.3 (TLS/1.2)
Random: 42 86 E5 DA 44 4D E2 F8 B6 BF 4F B6 1E D1 C0 CA F3 85 F2 D3 BF B4 06 AF 46 75 D4 17 20 0E EB 53
Time: 17/05/2086 14:00:02
SessionID: empty

NAV (failure)

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.1 (TLS/1.0)
Random: 58 B4 37 85 AE 5F 31 3F AF 51 2D EC C5 BB CF B9 86 59 95 9E 30 BA 14 F1 FA 63 B3 5A 12 DB 60 C2
Time: 28/10/2040 07:59:36
SessionID: empty

A Different type of HTTPS was used.

Apparently the API required a higher level of security than my call was offering.

Googled my way into this difference and found that it is a .NET 4.5 feature to use TLS/1.2, however this is turned off by default.

Needed to  add only one line of code and 2 variables.

ServicePointManager :
 [System.Net.ServicePointManager.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089']
SecurityProtocol :
[System.Net.SecurityProtocolType.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089']

Working code:

ServicePointManager.SecurityProtocol := SecurityProtocolType.Tls12;//FIX
HttpWebRequest := 
    HttpWebRequest.Create(https://sandbox.spryngpayments.com/v1/api_key'');
HttpWebRequest.Method := 'GET';
HttpWebRequest.ContentType('application/json');
HttpWebRequest.Headers.Add('X-APIKEY','my ApiKey');
HttpWebResponse := HttpWebRequest.GetResponseAsync.Result;
StreamReader := StreamReader.StreamReader(HttpWebResponse.GetResponseStream);
String := StreamReader.ReadToEnd;
HttpWebResponse.Close();
MESSAGE(String);

And the result:

new-bitmap-image

Mission accomplished!