SQL Server Assembly that calls an API

Viewed 219

I am having an issue with SQL Server assemblies that have to make an API call to an outside service, SmartyStreets. I've created a DLL which references the SmartyStreets DLL. This new DLL will take address fields, call the API and return a varchar(max).

When testing in VS, I created a basic form for input addresses, it would call the DLL and then populate a text box with the results. My new DLL works.

I created the assembly for the SmartySteets DLL and it is set as follows:

CREATE ASSEMBLY SmartyStreets from 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\smartystreets-dotnet-sdk.dll' WITH PERMISSION_SET = UNSAFE;

I created the assembly for my DLL (which references the SmartyStreets DLL) as follows:

CREATE ASSEMBLY SmartyStreets_API from 'C:\Program Files\Microsoft SQL Server\MSSQL14.HMARK\MSSQL\Binn\SmartyStreetsDLL.dll' WITH PERMISSION_SET = UNSAFE;

The function was created:

CREATE function CLR_AddressStandardization ( 
              @sAddress1 nvarchar(max)
            , @sAddress2 nvarchar(max)
            , @sCity nvarchar(max)
            , @sState nvarchar(max)
            , @sZIP nvarchar(max)
            , @sCountry nvarchar(max)) returns nvarchar(max) 
EXTERNAL NAME SmartyStreets_API.[SmartyStreetsDLL.SSDLL].StandardizeAddress

Now I call the new function: select dbo.CLR_AddressStandardization('18600 Malyn','','Fraser','MI','48026','') It returns with "Error: The request was aborted: Could not create SSL/TLS secure channel."

I believe that something is preventing the SmartyStreets DLL the ability to make a call outside, but I dont know how to address this.

Any ideas?

3 Answers

This is an encryption handshake issue. Almost every time I see this it means that the application/process/operating-system making the https call to our API is trying to utilize a version of TLS that is older than TLS 1.2. SmartyStreets doesn't accept those older versions.

Sometimes all it takes is an update to the operating system, or the version of .Net

More information here:

https://smartystreets.com/blog/2019/10/removing-old-versions-of-tls

My advice: Don't do it this way round, you always gonna have trouble.

Even if you get it running now, you gonna pray with every windows update that it is still working, and lots of time you gonna have to reinstall your (unchanged) assemblies because some .NET framework assembly changed and SQL server detects an inconsistency and refuses to process the call.

Write a trigger that sets an "IsDirty" flag instead, put a partial index on it (WHERE IsDirty = 1) and write a service that checks whether there are dirty records and that calls the REST service (or whatever it is) for these records.

Like that it is going to work through all the updates without any problems. Only issue that it is not instantly but slightly delayed. Big advantage: You can still add / modify records if the service is down, they are going to be validated later.

The first possibility that comes to mind is that the other end of the web service requires an SSL channel, but your client call is not providing a client certificate - or the one you are providing is not trusted. You may have to configure the outbound call to provide a certificate, which may prove a bit difficult given the architecture of your solution. Your assembly could provide one programmatically.

Related