Mailbox Import/Export Graph API’leri GA: EWS’in Sonu Geldi
Bakın şimdi, bu haber beni biraz eski günlere götürdü. Yıllardır kurumsal müşterilerde Exchange Web Services (EWS) ile uğraşan biri olarak — evet, liste baya uzun — Microsoft’un mailbox import/export Graph API’lerini genel kullanıma (GA) açtığını görünce ister istemez durup baktım. Resmî duyuru da gelmiş, tamamdır.
Logosoft’ta bir kamu kurumunda yürüttüğümüz projede bunu net gördüm. Tahmin eder mısınız? Müşteri 5 yıllık archive verisini cloud’a taşımak istiyordu, ama EWS göçü için ortada ciddi bir tarih baskısı yoktu; şimdi bu yeni API’ler GA olunca planı yeniden kurmaları gerekiyor, fakat archive mailbox desteği gelmeden iş tam bitmiyor — yanı garip ama gerçek, GA duyurusu bazı ekiplerde rahatlatmak yerine kafa karıştırdı bile.
Küçük ve orta ölçekli işletmeler için tablo daha sade. Eğer 500 kullanıcının altındaysanız ve archive kullanmıyorsanız, bu API’leri test etmeye hemen başlayabilirsiniz; maliyet tarafında da Graph API çağrıları için ayrı bir lisans gerekmiyor, Microsoft 365 lisansınız varsa kullanabiliyorsunuz. TL bazında ekstra bir kalem çıkmıyor yanı.
Kısa bir not düşeyim buraya.
Pratik Bir Örnek: Folder Listeleme
Somut bir şeyle ilerleyelim. Bir kullanıcının mailbox folder hiyerarşisini almak istiyorsanız, Graph API tarafında iş aslında oldukça düz gidiyor; ama küçük bir detay var, önü atlayınca sonra kafa karışıyor:
GET https://graph.microsoft.com/v1.0/users/{user-id}/mailFolders
Authorization: Bearer {access_token}
# Response (kısaltılmış)
{
"value": [
{
"id": "AAMkAD...",
"displayName": "Inbox",
"totalItemCount": 1247,
"childFolderCount": 3
},
{
"id": "AAMkAD...",
"displayName": "Archive",
"totalItemCount": 8934,
"childFolderCount": 12
}
]
}
Tuhaf ama, Burada gördüğünüz şey, klasörlerin kaba bir haritası gibi düşünebilirsiniz. Peki sonra ne oluyor? Sonrasında tek tek item export etmek için ayrı endpoint çağırıyorsunuz, dönen stream’i saklıyorsunuz ve gerektiğinde import ediyorsunuz; Microsoft’un özellikle altını çizdiği nokta şu: bu stream formatı opak, yanı açıp içine bakayım, biraz kurcalayayım derseniz yolun sonu pek hoş olmuyor.
Çok konuştum, örnekle göstereyim.
Araya gireyim: Evet.
Araya gireyim: Sadece export edin, saklayın, import edin. Bu kadar basit görünüyor ama işte hayatı nokta da burada; bu pattern dışına çıkarsanız destek tarafı size pek sıcak bakmıyor, hatta çoğu zaman doğrudan “bu senaryo bizim önerdiğimiz akış değil” deyip kenara çekiliyorlar.
İlk Adımlar İçin Önerim
- Önce dev tenant’ınızda bir test app registration yapın, gerekli permission’ları verin; küçük başlayın ki sorun çıktığında nerede patladığını rahat görün. — ciddi fark yaratıyor
- Küçük bir mailbox üzerinde folder listing testleri yapın — hiyerarşiyi anlayın, çünkü ilk bakışta basit duran yapı bazen beklenmedik şekilde dallanıp budaklanıyor. (bu kritik)
- Tek bir item’ı export edip aynı mailbox’a farklı bir folder’a import etmeyi deneyin; mesela burada akış doğru mu diye kontrol edin, sonra ufak ufak genişletin.
- Throttling davranışını ölçün — kaç paralel istek geçiyor, ne zaman 429 dönüyor; açık konuşayım, bunu baştan bilmezseniz production’da suratınıza çarpıyor.
- Ancak bundan sonra production planına geçin. Acele etmeyin.
Bu sırayı atlamayın. Gördüğüm hataların yarısı, ekiplerin doğrudan production verisiyle test yapmasından kaynaklanıyordu; yanı önce laboratuvar gibi düşünün, sonra gerçek ortama geçin, yoksa küçük görünen şeyler büyüyüp can sıkıyor.
Bakın, ne yalan söyleyeyim, Tam da öyle.
Enterprise vs Startup Yaklaşımı
Burada biraz ayrım yapmak gerekiyor. Çünkü iki tarafın derdi aynı değil, hatta bazen aynı masada konuşuyor gibi dursalar da bambaşka şeyler istiyorlar.
Startup ya da SMB iseniz: büyük ihtimalle bir ISV backup/archiving ürünü kullanıyorsunuzdur. Endişe etmeyin; Veeam, AvePoint, Barracuda gibi ürünler zaten kendi tarafında uyum işini toparlayacak gibi dürüyor. Sizin asıl yapmanız gereken şey basit: vendor’a gidip “EWS deprecation roadmap’ınız ne?” diye sormak (ciddiyim). Cevap netse tamamdır, rahat nefes alırsınız; ama cevap yuvarlaksa, işte o zaman alternatif bakmaya başlamak lazım. Peki neden? Çünkü bu tip belirsizlikler sonra insanın önüne sessizce çıkar, tam en yoğun dönemde.
Açıkçası, Enterprise yapıdaysanız: durum biraz daha karışık. Muhtemelen içeride yıllardır çalışan, ekibin kendi yazdığı custom EWS tabanlı entegrasyonlar var (compliance, e-discovery, custom reporting… liste uzayıp gidiyor). Şimdi açık konuşayım, bu kodları kim yazdı, hâlâ şirkette mi, dokümantasyon gerçekten dürüyor mu? Bu soruların cevabını bulun. Sonra Graph migration planını altı aydan kısa düşünmeyin; ben olsam bir yıl koyardım,. Test döngüsü uzuyor, regression çıkıyor, bir de üstüne hiç beklemediğiniz kenar senaryoları geliyor (bizzat test ettim). Evet.
Yaşadığım Bir Hata: Permission Karmaşası
Preview döneminde bir POC yaparken başıma gelen küçük ama sınır bozucu bir şeyi anlatayım. Mailbox import tarafında Mail.ReadWrite yetmiyor; işin içine import scope’u giriyor, yanı ilk bakışta “bu zaten yeterli” diyorsun ama sonra 403 tokadı geliyor.
Bunu biraz açayım.
Şunu fark ettim: İlk denemede ben de öyle oldum. Bir saat boyunca app registration içinde oradan oraya baktım, ayarları kurcaladım, consent tarafını kontrol ettim, hatta sorun bende mi diye iki kere geri döndüm; meğer yeni granular scope’lar portal UI’da pek net görünmüyormuş, manifest üzerinden eklemek gerekiyormuş.
Şunu söyleyeyim, Evet.
Daha açık söyleyeyim, şimdi GA ile bu taraf toparlanmış olmalı, en azından öyle umuyorum; yine de sız işi şansa bırakmayın, scope dokümanına bir göz atın, çünkü bazen en basit görünen izin detayı bütün akışı kilitleyebiliyor. İlginç, değil mi? Boşuna saç baş yolmayın.
Bağlantılı Konular ve Diğer Yazılarım
Modern Microsoft 365 tarafında kimlik, ajan yönetimi, bir de şu meşhur API göçü var ya, bunlar yeniden konuşuluyor. Eğer bu tarafa biraz daha eğilmek istiyorsanız, daha önce yazdığım Entra Agent ID GA: Sponsor Grup Tipi Kuralları Değişti yazısı baya iş görür. Hatta bazen insan şunu düşünüyor: “Tamam, konu kimlik diye başladık ama iş agent tarafına kaydı.” Neyse, oraya da girince taşlar biraz yerine oturuyor. Graph API’leri üstünden yapay zekâ ajanı kurmayı düşünüyorsanız, Microsoft Agent Framework ile.NET’te Ajan Kurmanın İncelikleri de güzel bir tamamlayıcı olur; özellikle pratik tarafta neyin nereye bağlandığını görmek açısından.
Cloud kontrol senaryolarında veri egemenliği deyince iş biraz sertleşiyor, çünkü konu sadece teknik değil, hukukî. Operasyonel tarafı da var. Bak şimdi, bu yüzden Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek yazımı da öneririm — özellikle kamu ve regüle sektörlerde mailbox verisinin nerede durduğu sorusu bir anda masanın ortasına geliyor. Kısa cevap yok. Uzun cevap işe biraz daha karışık, çünkü veri bazen bölgeye göre, bazen politika setine göre, bazen de bildiğiniz eski alışkanlıklara göre şekilleniyor; işte tam burada Azure Local tarafı devreye giriyor. Kontrol hissini fena olmayan bir seviyede tutabiliyor.
Kişisel Değerlendirmem
Dürüst olmak gerekirse, Açık olayım: Bu GA duyurusu, “tamam her şey hazır, yarın migration başlasın” demek değil. Daha çok, “ana akım senaryolar için artık güvenle ilerleyebilirsiniz, ama köşe vakaları için biraz bekleyin” demek. Microsoft’un burada izlediği yol bence fena değil; tüm mailbox tiplerini bir gecede teslim etmek yerine, önce en yüksek hacimli olanları toparlayip yayinladilar (ilk duyduğumda inanamadım). Evet, mantıklı.
Beklediğim kadar mi? Pek sayılmaz. Archive mailbox eksikliği, açık konuşayım, hâlâ can sıkıyor; çünkü gerçek hayatta işler tam da orada uzuyor (export, restore, uyumluluk derken konu dağılıyor). Ama doğru yönde atılmış bir adım bu, bunu da görmezden gelemem. Önümüzdeki 6-12 ayda public folder ve archive desteğinin de gelmesini umuyorum. Geldiği anda EWS’i artık kenara koyabiliriz — ki ben bunu 2007’den beri bekliyorum.
Sıkça Sorulan Sorular
Mailbox Import/Export API’leri ücretli mi?
Hayır, ekstra bir lisans almana gerek yok. Microsoft Graph’ın standart bir parçası olarak geliyor zaten. Ama şunu da söyleyeyim — çağrı sayısı Outlook resource limit’lerine bağlı, yanı throttling var. Yüksek hacimli işler yapıyorsan batch ve retry stratejisi kurmak şart.
EWS ne zaman tamamen kapanacak?
Şimdi, dürüst olmak gerekirse, Microsoft, EWS’in Exchange Online’da yavaş yavaş emekliye ayrılacağını açıkladı. Aslında son duyuruda Ekim 2026 civarı deniyordu, ama Microsoft bu tarihi daha önce de değiştirmişti. Bence en sağlıklısı resmî deprecation duyurusunu takipte tutmak — oradan anlık bilgi alırsın.
Archive mailbox için şu an ne yapmalıyım?
Bir bakıma, şunu fark ettim: Açıkçası şu an için archive mailbox senaryolarında hâlâ EWS ya da Compliance API gibi alternatiflere bağımlısın. Microsoft ileride archive desteği geleceğini söylüyor ama tarih vermiyor. Tecrübeme göre en mantıklı yaklaşım şu: kritik olmayan archive göçlerini beklet, önce primary. Shared mailbox migration’larından başla.
Preview döneminde yazdığım kod GA’da çalışacak mı?
Microsoft, API modelinin büyük ölçüde değişmediğini söylüyor. Yanı primary ve shared mailbox senaryolarında preview kodun büyük ihtimalle GA’da da sorunsuz çalışıyor. Yine de production’a geçmeden önce permission scope’larına ve response payload’larına bir göz at — hani küçük sürprizler olabiliyor.
Üçüncü parti backup ürünüm bu API’leri kullanıyor mu?
Bunu direkt vendor’una sormak en doğrusu. Mesela Veeam, AvePoint, CodeTwo gibi büyük ISV’ler preview döneminde testlere zaten başlamıştı. GA’dan sonra 3-6 ay içinde resmî destek duyurmaları bekleniyor. Bence vendor’ünün roadmap’ını şimdiden sorgulamak çok yerinde bir hamle.
Kaynaklar ve İleri Okuma
Microsoft 365 Developer Blog: GA Duyurusu
Microsoft Learn: Mailbox Import and Export APIs Resmî Dokümantasyonu
Microsoft Graph Throttling ve Outlook Resource Limits Kılavuzu
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.
4 comments