Copy of SQL Server ile API: TCMB Döviz Kurları Entegrasyonunda Modern (2025) vs. Geleneksel (2022) Yöntemler

Veritabanı yöneticileri ve geliştiriciler için dış kaynaklardan (API) veri çekip bunu ilişkisel veritabanına işlemek her zaman kritik bir ihtiyaç olmuştur. Bu makalede, TCMB (Türkiye Cumhuriyet Merkez Bankası) EVDS servisini kullanarak döviz kurlarını otomatik olarak çeken iki farklı yaklaşımı inceleyeceğiz: SQL Server 2025'in sunduğu modern, native yetenekler ve SQL Server 2022 (ve öncesi) için kullanılan OLE Automation yöntemleri.

1. Modern Yaklaşım: SQL Server 2025 ve Native REST API Desteği

SQL Server 2025, harici API çağrılarını yönetmek için geliştirilmiş yerleşik (native) fonksiyonlar sunarak oyunun kurallarını değiştiriyor. Bu yöntemde dışa bağımlılık minimumdur ve güvenlik en üst düzeydedir.

Yapılandırma ve Hazırlık

Bu yöntemi kullanabilmek için öncelikle external rest endpoint enabled özelliğinin aktif edilmesi gerekir. Bu, SQL Serverın HTTP isteklerini doğrudan motor üzerinden yapmasına izin verir.

Veri Çekme Mantığı (sp_invoke_external_rest_endpoint)

Bu yaklaşımın kalbi sp_invoke_external_rest_endpoint prosedürüdür. Geliştirilen sp_DovizGuncelle_Test prosedüründe görüldüğü gibi, karmaşık nesne yaratımlarına gerek kalmadan tek bir komutla API çağrısı yapılabilmektedir:

-- Dışarıya REST API çağrısı yapma özelliğini aktif et
EXEC sp_configure 'external rest endpoint enabled', 1;
GO
RECONFIGURE;

Açıklama: Bu komut, SQL Server'ın HTTP portlarını dinlemesine veya dışarıya istek atmasına izin veren "kapıyı" açar. SQL 2022 ve öncesinde böyle bir seçenek yoktur.

Modern Stored Procedure

Prosedürümüzü parçalayarak inceleyelim:

URL ve Header Hazırlığı TCMB servisine gitmeden önce URL dinamik olarak oluşturuluyor:

DECLARE @GuncelTarih DATE = CAST(GETDATE() AS DATE);
DECLARE @TarihFormat NVARCHAR(10) = FORMAT(@GuncelTarih, 'dd-MM-yyyy');
DECLARE @FullApiUrl NVARCHAR(MAX) = 'https://evds2.tcmb.gov.tr/service/evds/series=TP.DK.USD.A-TP.DK.EUR.A...&startDate=' + @TarihFormat + '&endDate=' + @TarihFormat + '&type=json';
DECLARE @Headers NVARCHAR(MAX) = N'{"key":"' + @ApiKey + '"}';

Native API Çağrısı İşte SQL 2025 farkı. Karmaşık nesne yaratımları yok, tek bir blok ile istek atılıyor:

BEGIN TRY
    EXEC @RetCode = sp_invoke_external_rest_endpoint
        @url = @FullApiUrl,
        @method = 'GET',
        @headers = @Headers,
        @response = @ResponseJSON OUTPUT;

Açıklama: sp_invoke_external_rest_endpoint komutu, belirtilen URL'ye GET isteği yapar, header'daki API anahtarını iletir ve dönen sonucu @ResponseJSON değişkenine basar.

JSON Parse ve Kayıt Gelen JSON verisi doğrudan SQL komutları içinde parçalanıp tabloya yazılıyor:

INSERT INTO DovizKurlari (BazParaBirimi, HedefParaBirimi, KurDegeri, IslemTarihi)
SELECT 'TRY', 'USD', CAST(JSON_VALUE(@ResponseJSON, '$.result.items[0].TP_DK_USD_A') AS DECIMAL(18,4)), @GuncelTarih
WHERE JSON_VALUE(@ResponseJSON, '$.result.items[0].TP_DK_USD_A') IS NOT NULL
UNION ALL
SELECT 'TRY', 'EUR', ...

2. Geleneksel Yaklaşım: SQL Server 2022 ve OLE Automation

Eski sistemlerde native destek olmadığı için, işletim sistemi (OS) yeteneklerini kullanmak zorundayız. Bu yöntem "dolaşık" ama işlevseldir.

Güvenlik Ayarları (Riskli Bölge)

Bu yöntemin çalışması için sistem yöneticisinin (DBA) şu izni vermesi gerekir:

-- OLE Automation Procedures özelliğini aktif et
EXEC sp_configure 'Ole Automation Procedures', 1;
RECONFIGURE;

Fark: SQL 2025'te sadece "REST endpoint" açılırken, burada tüm OLE otomasyon (işletim sistemi nesneleri oluşturma) yetkisi açılıyor. Bu, güvenlik açısından daha geniş bir yüzey alanı yaratır.

Nesne Yaratma ve İstek Gönderme Bir HTTP isteği yapabilmek için önce sanal bir "nesne" yaratıyoruz:

-- HTTP Nesnesi Oluşturma ve İstek Gönderimi
EXEC sp_OACreate 'MSXML2.ServerXMLHTTP.6.0', @Object OUT;
EXEC sp_OAMethod @Object, 'open', NULL, 'GET', @FullApiUrl, 'false';
EXEC sp_OAMethod @Object, 'setRequestHeader', NULL, 'key', @ApiKey; 
EXEC sp_OAMethod @Object, 'send';

Açıklama:

• sp_OACreate: İşletim sisteminde MSXML2 adında bir internet tarayıcısı motoru ayağa kaldırır.
• sp_OAMethod: Bu motora sırasıyla "adresi aç", "anahtarı ekle" ve "gönder" emirlerini verir. Her adım ayrı bir komuttur.

Yanıtı Alma ve Nesneyi Temizleme Yanıtı almak da ayrı bir iştir, iş bitince temizlik yapmak da:

-- Yanıtı Doğrudan Tablo Değişkenine Aktar
INSERT INTO @ResponseTable (ResponseText)
EXEC sp_OAGetProperty @Object, 'responseText';

EXEC sp_OADestroy @Object;

Kritik Nokta: sp_OADestroy komutu hayati önem taşır. Eğer bu satırı yazmayı unutursanız, hafızada (RAM) yaratılan o nesne silinmez. Saniyede 100 kere çalışan bir sistemde bu durum sunucuyu kısa sürede kilitler (Memory Leak).

Veriyi İşleme Veri önce @ResponseTable adlı geçici bir tablo değişkenine alınır, oradan okunup parse edilir:

INSERT INTO DovizKurlari ...
SELECT ... CAST(JSON_VALUE(ResponseText, '$.items[0].TP_DK_USD_A') ...
FROM @ResponseTable ...

Resmi küçültün

Resmi düzenleyin

Resmi silin

Sonuç: Mimari Evrim ve Karar Süreci

Bu çalışmada, TCMB EVDS API entegrasyonu örneği üzerinden SQL Server'ın dış dünya ile iletişim yeteneklerinin evrimini inceledik. İki farklı scripti karşılaştırdığımızda ortaya çıkan tablo şudur:

Kod Karmaşıklığı ve Bakım:

• SQL 2022 çözümü, işletim sistemi seviyesinde COM nesneleri (MSXML2) oluşturmayı, bu nesneleri yönetmeyi (sp_OAMethod) ve iş bitiminde manuel olarak yok etmeyi (sp_OADestroy) gerektirir. Bu süreç, kodun uzamasına ve hata yapma olasılığının artmasına neden olur.
• SQL 2025 çözümü ise sp_invoke_external_rest_endpoint sayesinde tüm bağlantı, istek ve yanıt alma sürecini tek bir satırda, atomik bir işlem (transaction) olarak halleder.

Performans ve Kaynak Yönetimi:

• Geleneksel yöntemde (2022), sp_OADestroy komutunun unutulması veya hata bloğuna (CATCH) düşülmesi durumunda nesnenin silinememesi, sunucuda ciddi bellek sızıntılarına (memory leak) yol açabilir.
• Modern yöntem (2025), bellek yönetimini SQL Server motoruna bırakır. Motor, istek tamamlandığında kaynakları otomatik olarak serbest bırakır, bu da sistem kararlılığını artırır.

Güvenlik:

• OLE Automation, SQL Server servis hesabına işletim sistemi üzerinde geniş yetkiler verilmesini gerektirir. Native REST desteği ise sadece dışarıya HTTP çağrısı yapacak izole bir yetki ile çalışır, bu da "En Az Ayrıcalık İlkesi"ne (Principle of Least Privilege) çok daha uygundur.

Özetle; Eğer altyapınız müsaade ediyorsa SQL Server 2025 yöntemine geçmek güvenlik, performans ve kodun sürdürülebilirliği açısından tartışmasız en doğru karardır. Ancak eski sistemlerde entegrasyon zorunluluğu devam ettiği sürece, geliştirdiğimiz OLE Automation tabanlı script, gerekli hata kontrolleri (TRY-CATCH) ve bellek temizliği (sp_OADestroy) yapıldığı sürece güvenilir bir "mühendislik çözümü" olarak kullanılmaya devam edilebilir.