Cosmos DB Built-in Connector for Logic Apps Standard GA Oldu
Bir haber düştü, Logic Apps tarafında uzun süredir beklenen bir şey nihayet resmileşti: Azure Cosmos DB’nın built-in connector‘ı, Logic Apps Standard için genel kullanıma açıldı. Preview’da bir süredir vardı zaten ama GA damgası vurulunca iş değişiyor — üretime çıkarabilirsin, SLA konuşabilirsin, mimarı kararını buna göre çakabilirsin.
Şimdi bakın, ilk duyduğumda “e connector zaten vardı, ne değişti?” diye düşünenlerden olabilirsiniz. Ben de öyle düşündüm başta. Ama işin aslı şu ki, buradaki mesele “yeni bir connector” değil — connector’ın nerede çalıştığı meselesi. Ve bu, göründüğünden çok daha büyük bir fark yaratıyor.
Managed vs Built-in: Aradaki Fark Neden Bu Kadar Önemli?
Bir şey dikkatimi çekti: Logic Apps dünyasında iki tür connector var. Managed connector‘lar, Microsoft’un multi-tenant altyapısında çalışıyor. Yanı sizin workflow’unuz Cosmos DB’ye bir istek yapacağı zaman, önce dışarıya bir çağrı gidiyor, oradan da Cosmos DB’ye uzanıyor; arada network hop var, throttling var, paylaşılan kaynaklar var. Kısacası yol biraz dolanıyor.
Dürüst olmak gerekirse, Built-in connector işe farklı. Doğrudan Logic Apps runtime’ının içinde, in-process çalışıyor. Yanı sizin workflow motorunuzla connector aynı süreçte oturuyor. Aradaki köprü kalkıyor — Basit gibi dürüyor ama etkisi fena değil.
Bunun pratik yansımalarını sahada çokça görüyoruz. Bir örnek vereyim: sipariş akışında Cosmos DB’ye 3 farklı yazma işlemi yapan bir workflow düşünün; managed connector ile her adımda 80-150ms arası ek gecikme görmek gayet normaldi, built-in tarafta işe bu yük neredeyse uçup gidiyor ve toplamda 300-400ms civarı kazanım çıkabiliyor. Peki bunu neden söylüyorum? Ufak gibi dürüyor ama kullanıcı tarafında hissediliyor.
Peki hangi durumda hangisini seçmeli?
Size bir şey söyleyeyim, Kararı net bir tabloya döktüğümüzde iş biraz berraklaşıyor, ama tabiî her senaryoda aynı cevap çıkmıyor; latency düşük olsun diyorsanız built-in tarafı çekici geliyor, maliyet. Peki bunu neden söylüyorum? Plan uyumu da devreye girince seçenekler iyice ayrışıyor (özellikle production’da), yanı tabloyu ezberlemek yerine kullanım şekline bakmak daha mantıklı oluyor.
Kısa bir not düşeyim buraya.
| Kriter | Managed Connector | Built-in Connector |
|---|---|---|
| Latency | Yüksek (network hop var) | Düşük (in-process) |
| Throughput | Shared quota’ya tabi | Plan’ınıza göre ölçekleniyor |
| Change feed | Yok | Var — native trigger |
| Bulk operations | Yok / kısıtlı | Var |
| Entra ID auth | Kısmen | Tam destek |
| Fiyat | Ayrı faturalanır | Logic Apps compute’a dahil |
| Consumption planla uyum | Uyumlu | Sadece Standard |
Yanı Consumption plan’da kalmak zorundaysanız built-in’i unutun. Ama Standard’daysanız bu artık default tercih olmaya aday. Bence yanı.
Change Feed Trigger: Aslında Asıl Yıldız Bu
Bazı özellikler vardır, ilk bakışta yan detay gibi görünür; sonra bir anda oyunun ortasına oturur. İşte change feed trigger tam öyle bir şey. “When an item is created or modified” tetikleyicisi Cosmos DB’nın dahili change feed mekanizmasını kullanarak workflow’u ayağa kaldırıyor; yanı container’a doküman düştüğü anda ya da güncellendiği anda akışınız kıpırdamaya başlıyor.
Daha önce bunu yapmak için ne gerekiyordu? Ya Azure Function yazacaktınız change feed processor ile, ya da Event Grid’i araya sokacaktınız. İkisi de ayrı altyapı demek, ayrı bakım demek, ayrı fatura demek; şimdi işe doğrudan Logic Apps içinden — kod yazmadan, evet yanlış duymadınız — event-driven mimarı kurabiliyorsunuz.
true yapmayı unutursanız connector kendisi oluşturmuyor ve trigger da sessizce bekliyor; hata fırlatıp bağırmıyor bile. GA sonrası ilk kurcalayanların en çok takıldığı yer burası öldü.
Nerelerde işe yarar?
- Sipariş güncellendiğinde CRM’e senkron yapılması gerekiyorsa burada baya iş görüyor.
- Kritik alan güncellemelerinde audit log’a düşmek için fena değil. (bence en önemlisi)
- Cross-region veri replikasyonu yaparken kendi mantığınızla akışı kurabilirsiniz.
düşük-kod ekiplerine ciddi bir kapı açıyor diyebilirim; IT tarafındaki business analyst kadrosu integration developer beklemeden Cosmos DB’yi mimariye bağlayabiliyor. Bu bana göre orta ölçekli Türk şirketlerinde yıllardır hissedilen boşluklardan biri idi: developer kaynağı sınırlı ama entegrasyon ihtiyacı bitmiyor. Logic Apps Standard + built-in connector ikilisi tam bu yere oturabilir.
“Built-in connector’ları kullanmıyorsanız, Logic Apps Standard’a geçmenin faydasını yarı yarıya kaçırıyorsunuz. Consumption’da da aynı managed connector’ları kullanmaya devam ediyorsanız, pahalı bir Standard planına para vermenin anlamı yok.”
İşte tam da bu noktada devreye giriyor.
>orders<> container’ınız var.Yeni bir sipariş düştüğünde Teams’e mesaj göndermek istiyorsunuz.Adımlar şöyle:
- Logic App Standard oluşturun
- Yeni bir stateful workflow ekleyin
- Trigger olarak “When an item is created or modified (Cosmos DB)” seçin — bunu es geçmeyin
- Connection’ı managed identity ile kurun
- Database ve container ismini girin,”Create Lease Container” = true yapın
- Sonraki adıma Teams “Post message” ekleyin
Workflow’un JSON tarafında trigger tanımı kabaca şöyle görünüyor:
{
"triggers": {
"When_an_item_is_created_or_modified": {
"type": "ServiceProvider",
"inputs": {
"parameters": {
"databaseName": "salesdb",
"containerName": "orders",
"leaseContainerName": "leases",
"createLeaseContainerIfNotExists": true,
"startFromBeginning": false
},
"serviceProviderConfiguration": {
"connectionName": "cosmosdb",
"operationId": "receiveDocument",
"serviceProviderId": "/serviceProviders/AzureCosmosDB"
}
}
}
}
}Dikkat:‘i false > bıraktım.Aksi hâlde container’da mevcut bütün dokümanlar için trigger patlar.Test ortamında birkaç kez yaşadım bunu;200 bin dokümanlık container’da Teams kanalı direkt spam bombardımanına dönüyor.Uyarayım,sonra ben demedim demeyin.
Ve işler burada ilginçleşiyor.
- Cross-partition sorgu maliyetini workflow tarafında görmek zor;RU tüketimi log’a doğrudan düşmüyor. (bence en önemlisi)
- MongoDB API tarafı hâlâ built-in connector kapsamında değil;sadece NoSQL API var.Mongo kullanıyorsanız managed tarafta kalmaya devam.
- Continuation token yönetimi büyük sorgu sonuçlarında biraz elle müdahale istiyor.
- Diagnostic tarafı biraz cılız;Application Insights entegrasyonu var ama connector-spesifik metrikler zayıf kalıyor.
Şöyle ki, Bir de şunu söyleyeyim:Change feed trigger’ın latest version mode‘da çalıştığını unutmayın.Yani bir doküman 5 kez güncellenirse size son hali gelir,ara güncellemeleri kaçırırsınız.Full fidelity change feed hâlâ preview aşamasında ve bu connector’da yok;audit senaryolarında bu gerçekten sınır koyuyor.
Kullanın çünkü uygun:
>
- >
- Cosmos DB’ye yoğun okuma/yazma yapan integration akışlarınız varsa burada iyi oturuyor.
>
> >
>
>
>
> > > Data API Builder 2.;0: REST Yolunu İş Yapına Göre Kurmak yazısına da bakabilirsiniz — Logic Apps ile Data API Builder’ı birlikte kullanmak bazı senaryolarda temiz sonuç veriyor diyebilirim,hatta şaşırtıcı derecede düzgün akıyor bazen.Küçük Ekipler Ve Büyük Kurumlar İçIn Ayrı Öneri Hayır, çalışmıyor. Built-in connector’lar sadece Logic Apps Standard plan’da var. Consumption plan’daysanız managed connector’ı kullanmaya devam etmeniz gerekiyor. Aslında bu bilinçli bir mimarı karar — built-in connector, Standard runtime’ın kendi süreç modeline entegre olduğu için Consumption’da pek bir anlamı olmuyor. Genelde 1-5 saniye arası. Cosmos DB change feed pull-based çalıştığı için connector, belirli aralıklarla lease container’ı kontrol edip yeni değişiklikleri çekiyor. Yanı gerçek anlamda “sub-second” event delivery beklemeyin. Ama şunu da söyleyeyim — Event Grid ile karşılaştırdığınızda event kaybı riski çok daha az, bence bu önemli bir artı. Data plane tarafında genellikle “Cosmos DB Built-in Data Contributor” rolü yeterli oluyor. Sadece okuma yapacaksanız “Cosmos DB Built-in Data Reader” da kullanabilirsiniz. Bir de şunu dikkat edin: control plane rolleriyle (mesela Contributor) data plane erişimini karıştırmayın — Cosmos DB’de bu iki tarafın rolleri ayrı ayrı yönetiliyor. Açıkçası şu an Microsoft’tan resmî bir tarih yok. NoSQL API önceliklendirildi. MongoDB API kullanıyorsanız managed connector’la devam etmeniz ya da custom bir çözüm (mesela Function) üretmeniz gerekiyor. Community feedback’e bakılırsa yol haritasında var gibi görünüyor, ama garanti yok. Evet, lease container da RU/s tüketiyor. Ama tipik olarak çok düşük — hani 400 RU/s manual throughput genelde yeterli oluyor. Serverless veya autoscale kullanıyorsanız bu daha da az. Tecrübeme göre bu container’ı monitored container’la aynı database’de tutmak mantıklı, operasyonel karmaşayı ciddi ölçüde azaltıyor. Announcing General Availability of the Azure Cosmos DB Built-in Connector for Logic Apps Standard Azure Logic Apps Built-in Connectors — Resmî Dokümantasyon Bunu yaşayan biri olarak söyleyeyim, Cosmos DB Change Feed Design Patterns
>
>
>
Sıkça Sorulan Sorular
Built-in connector Consumption plan’da çalışıyor mu?
Change feed trigger latency’si ne kadar?
Managed identity ile bağlanırken hangi role’ü vermeliyim?
MongoDB API için ne zaman geliyor?
Lease container ayrı bir maliyet yaratıyor mu?
Kaynaklar ve İleri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
0 comments