Python ile Teams SDK artık GA: Benim Sahada Gördüklerim
Ne yalan söyleyeyim, Microsoft Teams tarafında Python desteğinin genel kullanıma açılması, kağıt üstünde ufak bir duyuru gibi durabilir. Ama işin aslı şu: bu karar birçok ekip için bayağı kritik. Çünkü Python zaten otomasyonun, ajanların, veri işleme katmanının ve LLM tabanlı orkestrasyonun doğal dili öldü. Şimdi bu dünyayı Teams içine daha temiz taşıyabiliyorsunuz.
Ben bunu ilk okuduğumda aklıma direkt şu geldi: “Nihayet.” Yıllardır kurumsal müşterilerde aynı döngüyü gördüm; AI tarafını Python’da kuruyorlar, entegrasyonu ayrı bir servisle bağlıyorlar, sonra Teams’e mesaj atmak için araya bir katman daha ekleniyor. 2024 Kasım ayında İstanbul’da bir finans kuruluşuyla yaptığımız çalışmada da tam böyle olmuştu (en azından benim deneyimim böyle). Model tarafı Python’da, iş akışı başka yerde, — kendi adıma konuşayım — kullanıcı etkileşimi işe Teams’e sonradan yamalanmıştı. Şimdi bu parçalar biraz daha doğal birleşiyor.
Ha bu arada, hemen şunu da söyleyeyim: GA olması “artık her şey pürüzsüz” demek değil (kendi tecrübem). Güzel haber ama henüz ham sayılabilecek yerleri var. En çok da de kurumsal tarafta güvenlik, gözlemlenebilirlik. Yaşam döngüsü yönetimi olmadan hiçbir SDK tek başına mucize yaratmıyor. Benim bakışım net: Bu sürüm doğru yönde atılmış sağlam bir adım, fakat prod ortamda yine mimarı disiplin gerekiyor.
Neden bu duyuru önemli?
Şöyle düşünün: Elinizde iyi çalışan bir Python ajanınız var. Veri alıyor, sınıflandırıyor, karar veriyor, hatta gerektiğinde LLM çağırıyor. Fakat Teams entegrasyonu zayıfsa kullanıcı deneyimi kopuk kalıyor. Kullanıcıya e-posta atıyorsunuz, başka sistemde ticket açıyorsunuz, bir de Teams’de manuel bildirım geçiyorsunuz… İşte o noktada bütün sihir dağılıyor.
Vallahi, Python desteği burada tam ortadan giriyor. Microsoft’un TypeScript ve.NET stack’lerinde sunduğu modern deneyimin aynısını Python geliştiricilerine de vermesi bence kritik. Çünkü şirketlerin büyük kısmında AI prototipleri zaten Python ile başlıyor. Kurumsal müşterilerimde özellikle 2025’in ilk çeyreğinde gördüğüm şey şu öldü: Deneme ortamı hızlı kuruluyor ama üretime geçişte dil bariyeri yüzünden ekip yoruluyor.
Şimdi gelelim işin can alıcı noktasına.
Açık konuşayım; bazı ekipler sırf “Teams entegrasyonu” için ekstra mikroservis yazıp dürüyor. Sonra bakım maliyeti şişiyor. Küçük startup iseniz bu yaklaşım sizi çok yormaz belki ama enterprise seviyede her ekstra servis demek ekstra izleme, ekstra yetki modeli ve ekstra operasyon yükü demek. Yanı mesele sadece kod yazmak değil… Mantıklı değil mi? operasyona ne kadar yük bindirdiğiniz de önemli.
Python ekosistemiyle doğal uyum
İşte, ne yalan söyleyeyim, Ben AZ-104. AZ-305 hazırlık süreçlerinde bile hep aynı mantığı anlatıyorum: Doğru servis seçimi sadece teknik uygunlukla ilgili değil; ekip alışkanlığıyla da ilgili. Python tarafında çalışan veri bilimcilerinin ya da AI mühendislerinin çoğu zaten decorator mantığına aşina. Bu SDK’nın event routing yaklaşımı o yüzden yabancı gelmiyor.
Geçen sene Ankara’da orta ölçekli bir üretim firmasının iç iletişim botunda benzer bir yapı denedik. Bot önce JSON döküp sonra karmaşık dispatcher’larla boğuşuyordu; en sonunda event bazlı yapıya geçince kod yarıya indi diyebilirim. Evet, yarıya yakın! İşte böyle durumlarda “developer ergonomics” lafı havada kalmıyor.
Kısa bir not düşeyim buraya.
Sahada beni en çok etkileyen üç şey
İlk konu decorator-based activity routing. Bu model çok basit görünüyor ama günlük kullanımda fark yaratıyor. Mesaj geldi mi? Decorator var. Mention mı öldü? Başka handler var. Conversation event mi? Onun yolu ayrı. Kafanızdaki akış ile kodun yapısı birbirine yaklaşıyor.
İkinci konu Builtin OAuth. Bakın şimdi, token işi çoğu projede kimsenin sabah kalkınca özlediği bir şey değil! 2023 Ağustos’ta İzmir’de bir sağlık sektörü projesinde en çok zamanımızı alan kısım model değildi; kimlik doğrulama akışıydı. SDK bunun bir kısmını kendi içinde toparlayınca takım rahatlıyor. Daha fazla bilgi için NL2SQL’de Asıl Soru: Prompt mu, Veritabanı mı? yazımıza bakabilirsiniz.
Üçüncü konu işe Type-safe Microsoft Graph access. Burada kağıt üstünde küçük görünen ama pratikte ciddi değer üreten bir detay var: app_graph ve user_graph ayrımıyla hem uygulama adına hem kullanıcı adına işlem yapmak daha anlaşılır hâle geliyor. Hele kurumsalda yetki sınırları net olunca bu ayrım altın değerinde oluyor.
Benim kısa hükmüm şu: Python desteği sadece “bir dil daha eklendi” haberi değil; AI odaklı kurumsal uygulamaları Teams içine taşımayı bayağı kolaylaştıran stratejik bir adım.
Kod tarafında işler nasıl görünüyor?
Aşağıdaki örnek bana oldukça tanıdık geliyor çünkü mantık sade tutulmuş durumda. Tam olarak üretim mimarisi değil elbette ama başlangıç için işini görüyor: Bu konuyla ilgili Azure Functions’ta Retry Fırtınasını Durdurmak: Backoff ve Circuit Breaker yazımıza da göz atmanızı tavsiye ederim.
Bir dakika — bununla bitmedi.
pip install microsoft-teams-apps
from microsoft_teams.apps import App, ActivityContext
from microsoft_teams.api import MessageActivity
app = App()
@app.on_message
async def handle_message(ctx: ActivityContext[MessageActivity]):
await ctx.send(f"You said: {ctx.activity.text}")
await app.start()Bence burada esas mesele satır sayısı değil; satırların ne kadar anlam taşıdığıdır aslında ciddiyim diye söylüyorum bunu.
Eskiden aynı işi yapmak için dispatcher yazılırdı,
mapping tablosu tutulurdu,
edge case’ler ayrı dosyalara kaçardı…
şimdi işe temel mesaj akışı birkaç satırla kurulabiliyor.
Garip. Hoş yanı.
| Konu | Küçük ekip | Büyük kurum |
|---|---|---|
| Sprint hızı | Daha hızlı başlarsınız | İlk günler yavaş olabilir |
| Yetki modeli | Daha basit yönetilir | Dikkatli tasarlanmalı |
| Maliyet | Düşük giriş bariyeri | Gözlemleme maliyeti artar |
| Sürdürülebilirlik | Ekip azsa kolay ilerler | Mimarı standart şart olur |
E tabi eksik taraf yok mu? Var tabiî.
Mesela ilk denememde ben ufak bir yapılandırma hatası yüzünden authorization akışında garip bir durum yaşadım;
hata mesajı çok net değildi ve çözmek için birkaç kez loglara geri dönmem gerekti.
Çözümü işe basitti:
scope tanımlarını temizledik ve tenant bağlamını yeniden kontrol ettik.
Ama işte bazen sorun teknoloji değil… yanlış varsayım oluyor.
Peki neden?
Küçük startup ile enterprise arasında fark nerede?
Araya gireyim: Küçük ekipseniz hedefiniz genelde hızlı proof-of-concept olur. O durumda bu SDK size iyi hız kazandırır;
çünkü Python ekibi zaten elinizdedir ve Teams entegrasyonu fazladan sürtünme yaratmaz. Biraz aceleye gelir gibi dursa da çoğu zaman yeterli.
Büyük kurumdaysanız hikâye değişir.
Burada tek soru “çalışıyor mu?” değil;
“loglanıyor mu?”,
“kim erişiyor?”,
“hangi veri dışarı gidiyor?”,
“incident olduğunda ne olacak?”
sorularıdır uzayıp gider…
Kurumsal müşteri ortamlarında benim gördüğüm kadarıyla en sık unutulan nokta telemetry oluyor.
Evet,
tam da öyle.
Yanı teknikten çok görünürlük eksik kalıyor bazen (şaşırtıcı ama gerçek)
Bence enterprise tarafında ilk yapılacak iş şu üçlü olmalı: Daha fazla bilgi için Kubernetes v1.36’da PSI GA: Sinyali Gürültüden Ayırmak yazımıza bakabilirsiniz.
- Kapsamları daraltın; app permission modelini baştan netleştirin.
- Teleskop gibi izleyin; loglama ve metric toplama katmanını erken koyun.
- Sınırları çizin; hangi aksiyonlar kullanıcı adına hangileri uygulama adına yapılacak belirleyin. (bence en önemlisi)
Maliyet konusu neden önemli?
Peki Azure tarafında maliyet nasıl düşünülmeli? Dürüst olayım:
SDK ücretsiz diye proje ucuzlamıyor!
Asıl maliyet compute,
storage,
messaging trafiği ve operasyonel emek üzerinden geliyor bulunuyor kendini gösteriyor diyeyim…
Türkiye’de TL bazlı bütçe planlayan şirketlerde kur farkı yüzünden görünmeyen maliyet çok hızlı büyüyebiliyor.
Bu kısım biraz can sıkıcı,
ama gerçek böyle.
Neyse uzatmayalım,
hesap orada patlıyor genelde. Daha fazla bilgi için Microsoft Agent Framework ve AGT: Ajanları Üretimde Güvende Tutmak yazımıza bakabilirsiniz.
Eğer bütçeniz kısıtlıysa tam kapsamlı agent platformuna hemen dalmak yerine önce hafif başlayın derim:
önce tek kanal,
sonra tek iş senaryosu,
ardından sınırlı Graph erişimi.
Bu yaklaşım özellikle KOBİ’lerde daha sağlıklı çalışıyor.
Büyük organizasyonlarda işe erken standardizasyon şart;
yoksa beş farklı ekip beş farklı Teams botu çıkarıp ortalığı karıştırabiliyor…
Sız ne dersiniz?
Böyle olunca bakım mı kolaylaşıyor sanıyorsunuz?
Hiç sanmam.
Aksine zorlaşıyor.”
💡 Bilgi: İlk PoC aşamasında en pahalı parça genelde model çağrıları ya da fazla loglama oluyor sanılıyor; halbuki asıl masraf çoğu zaman bakım süresi oluyor.
Bana göre nerede parlıyor?Burası biraz kişisel görüş kısmı. Iki yerde parlıyor:
biri iç operasyon botları,
diğeri domain-specific ajanlar.
Mesela onay akışları,
bilgi getirme,
durum sorgulama,
hatırlatma gönderme…
Bunlar Teams içinde çok doğal dürüyor.
Bir bankacılık projesinde Eylül 2024’te buna benzer şekilde belge onay bildirimlerini aktarmıştık;
kullanıcılar e-postaya göre daha hızlı cevap verdi çünkü zaten gün boyu Teams içindeydiler.
Şaşırmadım açıkçası,
ama sonuç yine de iyiydi.”Ajan senaryolarında da güzel dürüyor çünkü orchestration logic’i doğrudan konuşma kanalına bağlayabiliyorsunuz.
LLM’den gelen cevabı yalnızca metin olarak vermek zorunda değilsiniz;
adaptive card ile zenginleştirip karşı tarafa düzenli gösterebiliyorsunuz.
Kağıt üstünde küçük detay gibi dursa da pratikte etkileşim kalitesini yükseltiyor.
Yine de kart tasarımı kötü olursa bütün güzellik bozulur… evet maalesef olur öyle şeyler!
Bak şimdi,
iyi görünen kart bazen kötü akışı kurtarmıyor.”Benden kısa pratik reçete;
Eğer bugün başlayacaksanız ilk iş şu olsun:
SDK’yı lokal ortamda ayağa kaldırın,
tek bir mesaj handler yazın,
sonra Graph erişimini kontrollü ekleyin.
Üçüncü adımda telemetry koyun.
Dördüncüde güvenlik kontrolünü sıkıştırın.
Bu sırayla giderseniz duvara toslama ihtimaliniz düşer.
Kısacası acele etmeyin,
ama oyalanmayın da.
Sıkça Sorulan Sorular
Python desteği artık gerçekten üretime hazır mı?
Evet, genel kullanıma açıldı yanı ciddi projelerde kullanabilirsiniz.
Ama açıkçası prod’a çıkmadan önce yetkilendirme, logging. Hata yönetimini ayrıca düşünmeniz gerekiyor.
SDK hazır olsa da mimarı sorumluluk yine sizde kalıyor.
Python’da Teams app geliştirmek.NET veya TypeScript’e göre avantajlı mı?
Doğrusu, Eğer ekibiniz zaten Python ağırlıklıysa bence evet, bayağı avantajlı olabilir. Burada, en çok da AI agent, otomasyon. Veri işlemi olan projelerde tek dil üzerinde gitmek işleri epey sadeleştiriyor. Ama frontend yoğun senaryolarda yine de TypeScript güçlü kalıyor.
Bütçesi düşük küçük ekipler nereden başlamalı?
Tecrübeme göre küçük ekipler önce tek amaçlı bir bot ya da ajanla başlamalı. Hani tek kanal, tek kullanım senaryosu — ve gereksiz Graph izinlerinden uzak durun. Böylece hem maliyet hem bakım yükü düşük kalıyor.
Büyük kurumlarda en hayatı risk ne?
Bence, Aslında en kritik risk kontrolsüz yetki genişlemesi. Gözlemlenebilirlik eksikliği.
Mesela bir bot çalışıyor olabilir ama kim ne yaptı izlenmiyorsa kurumsal kullanım zayıf kalıyor.
O yüzden audit log ve telemetry’yi erken kurmanızı öneririm.
Bunu mevcut Python LLM stack’imle birlikte kullanabilir mıyım?
Evet,. Tam da bunun için anlamlı.
Orkestrasyon katmanınızı koruyup sonuçları Teams üzerinden kullanıcıya aktarabiliyorsunuz.
Peki, bu yaklaşım özellikle RAG ya da workflow automation projelerinde gerçekten iyi çalışıyor.
Kaynaklar ve İleri Okuma
Microsoft Teams Platform Dokümantasyonu
Tuhaf ama, Microsoft Graph Genel Bakış
Daha önce ajan orkestrasyonunun nasıl devredildiğini anlattığım yazıda akış mantığını detaylandırmıştım:
Handoff Orchestration: Ajanlar Topu Nasıl Devrediyor?
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.
Yorum gönder