SharePoint RER Emekliye Ayrılıyor: 1 Temmuz 2027 Son Tarih
Şöyle başlayayım: Eğer hâlâ SharePoint Online tarafında Remote Event Receiver (kısaca RER) kullanan bir çözümünüz varsa, bu yazıyı sonuna kadar okumanızı öneririm. Çünkü Microsoft tarihi netleştirdi — 1 Temmuz 2027 (kendi tecrübem). O tarihten sonra RER’ler tetiklenmeyecek. Kayıt yönteminiz ne olursa olsun. Nokta.
Aslında bu haber çok da sürpriz değil. Azure ACS’nın emekliliği duyurulduğunda, bu günün geleceği zaten görünüyordu. Ama biliyorsunuz, kurumsal tarafta “iki yıl var daha” cümlesi çoğu zaman “şimdilik dokunmayalım” anlamına geliyor. Sonra bir bakıyorsunuz, altı ay kalmış ve envanterde 40 tane RER var. Tanıdık geldi mi?
Kısaca ne oluyor?
Açıkçası, Remote Event Receiver’lar, SharePoint Add-in modelinin bir parçasıydı. Bir liste öğesi eklendiğinde, güncellendiğinde ya da silindiğinde SharePoint sizin WCF servisinize haber uçuruyordu. Klasik senaryo. Yıllarca iş gördü.
Şöyle ki, Gel gelelim bu mekanizmanın kimlik doğrulama tarafı Azure ACS‘ye bağlıydı. ACS emekliye ayrılınca doğal olarak RER’lerin de ipi o zincirde koptu (ciddiyim). Microsoft geçiş için bir köprü kurdu — Microsoft Entra uygulaması üzerinden kayıt. Bu da bir çözüm ama kalıcı gibi durmuyor. Daha çok nefes aldıran bir ara durak, hani.
“Entra ile kayıtlı RER’ler de 1 Temmuz 2027’de duracak. Yanı bu geçiş, hedefe götüren yol değil; hedefe gitmek için size verilen ek süre.”
Zaman çizelgesi — sadeleştirilmiş hali
Karışıklık olmasın diye tarihleri tek yerde toplayayım:
| Tarih | Ne oluyor? |
|---|---|
| 2 Nisan 2026 | Azure ACS ile kayıtlı RER’ler düzgün çalışmıyor. Servis tarafında ACS ile SharePoint’e geri çağrı yapamıyorsunuz. |
| 1 Temmuz 2027 | Hepsi biter. Entra ile kayıtlı olanlar dahil. Tüm RER’ler tetiklenmeyi durdurur. |
Dürüst olmak gerekirse, 2 Nisan 2026 için “geçti bile” diyebilirsiniz. Doğru. Ama sahada hâlâ eski RER’lerini fark etmemiş, işleri sessizce aksayan ekipler var. Loglara bakılmıyor, alert kurulmamış, süreç yavaş yavaş bozuluyor. Klasik teknik borç yanı.
Yerine ne geliyor? SharePoint Webhooks
İlginç olan şu ki, Microsoft’un önerisi net: SharePoint Webhooks. Ama açık konuşayım — birebir yerine geçen bir çözüm değil bu (en azından benim deneyimim böyle). Aralarında ciddi bir yaklaşım farkı var. Şöyle özetleyeyim:
- Sadece asenkron. Yanı “-ed” olayları (ItemAdded, ItemUpdated gibi). Bir işlemi durdurmak, iptal etmek yok artık.
- Değişikliği kendiniz çekeceksiniz. Webhook size sadece “bak, bir şey öldü” der. Ne öldü, kim yaptı, hangi öğe? Bunları GetChanges API’siyle sız sorgulayacaksınız. — ciddi fark yaratıyor
- Kapsam listelerle sınırlı. Şu an için liste öğeleri üzerinde — yanı liste ve doküman kütüphaneleri. — ciddi fark yaratıyor
- HTTP POST tabanlı, standart web API. WCF çilesine son diyebiliriz; bu iyi haber.
“-ing” olaylarına ne olacak?
İşte can alıcı nokta burası. Bazı senaryolarda RER’in “ItemDeleting” gibi senkron olayını kullanıp bir dosyanın silinmesini engelliyorduk (kendi tecrübem). Onay mekanizması vardı, yetki kontrolü vardı… Şimdi bunlar yok.
Microsoft’un önerisi şu: koruma amaçlı kullanıyorsanız dosyayı SharePoint’in kendi izin modeliyle koruyun ya da gizli bir kütüphaneye taşıyın. Kulağa mantıklı geliyor ama her senaryoya oturmuyor açıkçası. Mesela iş akışına bağlı koşullu bir engelleme yapıyorsanız — o mantığı baştan tasarlamanız gerekecek. Belki Power Automate onay adımı olur, belki Logic Apps ile ön-doğrulama olur, belki uygulamanın kendi UI’ında yakalarsınız; duruma göre değişiyor işte.
Alternatif: Microsoft Graph Change Notifications
Bir de şu var — sadece SharePoint webhook’a kilitlenmeyin derim ben.Microsoft Graph change notifications, çoğu senaryoda daha modern bir seçenek oluyor. Bilhassa de uygulamanız. Graph kullanıyorsa, iki farklı bildirım modeli yerine tek yerden yönetmek daha temiz kalıyor (kendi tecrübem)
Evet, doğru duydunuz.
Ayrıca Graph tarafında OneDrive ve SharePoint drive’ları için “driveItem” bildirimleri var ki bunlar bazı senaryolarda SharePoint webhook’un veremediği granülariteyi verebiliyor. Yanı karar verirken sadece “webhook’a nasıl geçerim” diye bakmayın; yeni tasarımda hangi bildirım modeli benim iş yüküme daha uygun diye sormak lazım aslında. Bu konuyla ilgili Azure Storage Göçü: Planlamadan Kesime Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.
Sahada bu geçiş nasıl yaşanıyor?
Kurduğum yapılarda sık gördüğüm tablo şu oluyor: RER’ler yıllar içinde birikmiş, bazılarının sahibi belli değil, bazıları çalışıyor sanılıyor ama aslında çoktan bozulmuş durumda; sadece kimse fark etmemiş çünkü tetiklediği event kritik değilmiş gibi düşünülmüş.
Bu yüzden geçiş planına başlarken kod yazmaktan önce envanter çıkarmak gerekiyor bence.
Elinizde ne var, hangisi ne yapıyor, hangisi gerçekten gerekli, hangisi ölü kod? Bunları netleştirmeden webhook yazmaya başlarsanız üç ay sonra “bu neden vardı ki?” deyip sildiğiniz kodlarla uğraşırsınız.”
İşte tam da bu noktada devreye giriyor.
Envanter için pratik yol
PnP PowerShell ile tenant genelinde tarama yapıp RER kayıtlarını listeleyebilirsiniz; kaba. Işe yarayan bir başlangıç şablonu aşağıda: Daha fazla bilgi için Azure Files NFS ile Linux İş Yükleri: Sahadan Notlar yazımıza bakabilirsiniz. Bu konuyla ilgili WSL Container Public Preview: Windows’ta Linux Konteyner Devri yazımıza da göz atmanızı tavsiye ederim.
Connect-PnPOnline -Url "https://tenant.sharepoint.com" -Interactive
# Site kolleksiyonlarını gez
$sites = Get-PnPTenantSite -Detailed
foreach ($site in $sites) {
Connect-PnPOnline -Url $site.Url -Interactive
$lists = Get-PnPList
foreach ($list in $lists) {
$receivers = Get-PnPEventReceiver -List $list.Title
if ($receivers) {
foreach ($r in $receivers) {
[PSCustomObject]@{
Site = $site.Url
List = $list.Title
ReceiverName= $r.ReceiverName
EventType = $r.EventType
Url = $r.ReceiverUrl
}
}
}
}
}Bunu CSV’ye atın, sahiplerini bulun, kritiklik seviyesini verin.
Daha açık söyleyeyim, klasik teknik borç yönetimi gibi görünüyor ama baya iş görüyor.”
Türkiye tarafındaki durum: sessiz bir risk
Açık konuşayım; Türkiye’deki kurumsal SharePoint kullanıcılarında bu mesele özellikle iki grup için riskli görünüyor. Birincisi, 2015-2018 aralığında SharePoint Add-in modeliyle çözümler geliştirmiş ve sonra o çözümlere pek dokunmamış bankalar ile büyük holdingler. Kod hâlâ üretimde çalışıyor sanılıyor ama sahibi belki çoktan şirketten ayrılmış bile olabilir.” Bu konuyla ilgili Azure SDK Haziran 2026: Transcription ve Planetary Pro GA’da yazımıza da göz atmanızı tavsiye ederim.
Şahsen, İkinci grup işe SharePoint üzerinden EBYS, doküman onay akışları veya evrak yönetimi yapan kamu ve kamuya yakın yapılar.
Bu tür projelerde “-ing” olaylarıyla kurulmuş silme/güncelleme engelleri sıkça var.
Bunları webhook’a geçirmek doğrudan bir “kod göçü” değil; bayağı bildiğiniz tasarım değişikliği. Ve o tasarım değişikliğinin analizi de çoğu zaman geliştiriciden değil iş biriminden gelecek cevaplara bağlı oluyor.
Bu da işi uzatır tabiî.”
Ben olsam 2026 sonuna kadar analizi bitirirdim.
2027’nın ilk çeyreğinde deployment’a çıkmak bana daha güvenli geliyor.
Son üç ayı sürprizlere ayırırdım çünkü sürpriz mutlaka çıkar.
Evet.
Tam da öyle.
Küçük ekip vs büyük kurumsal: iki farklı yol
Küçük bir ekipseniz ve elinizde diyelim 2-5 RER varsa yaklaşım basit:
Her birini teker teker webhook’a çevirin,
GetChanges endpoint’iyle değişiklikleri çekin,
bir Azure Function ya da App Service içinde host edin.
Maliyet? Consumption plan’da çalışan bir Function için aylık birkaç dolar eder; TL bazında konuşursak kahve parası gibi kalıyor.
Ama Function App’in güvenliğini doğru kurmayı unutmayın,
retry mantığını atlamayın,
validation token cevabını da düzgün dönün —
çünkü webhook subscription’ları 5 saniye içinde 200 dönmezseniz Microsoft tarafından iptal ediliyor.
Büyük kurumsal yapıdaysanız tek tek göç yerine end-to-end event routing katmanı düşünebilirsiniz.
Yanı tüm SharePoint webhook’larını tek endpoint karşılasın (mesela API Management arkasında çalışan bir Function), oradan iş kuralına göre Service Bus veya Event Grid’e dağıtsın.
Bu yaklaşım ilk kurulumu biraz uzatır. Sonraki 20-30 entegrasyonda size zaman kazandırır.
FinOps tarafında da tek noktadan izleme imkanı verir.
Bak şimdi burada iş değişiyor.” Headlamp Knative Eklentisi: Serverless’ı Görsel Takip yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor.
Süre dolmadan yenilemeyi ihmal ederseniz sessizce ölür.
Bunu yenileyen zamanlanmış görev (timer function) kurmak sonradan başınızı ağrıtmıyor.
Tam tersi rahatlatıyor.
Sık yapılan hata: değişiklikleri yakalama mantığını yanlış kurmak
Evet!
Webhook’lar RER’lerden farklı olarak size “ne değişti” bilgisini vermez.
Sadece “bir şey öldü, gel bak” der.
Sız de GetChanges API’sını bir
İşte tam burada iki tuzağa dikkat:
- `Change token` kaybolursa , ya baştan tararsınız (yavaş ve pahalı), ya da bazı değişiklikleri atlarsınız.
Token’ı kalıcı yerde tutun — Table Storage olur,
Cosmos DB olur,
ne olursa olsun;
ama in-memory tutmayın. - `Idempotency` önemli .
Aynı değişiklik iki kez size bildirilebilir.
İşlemi buna göre tasarlayın,
aynı öğeyi iki kere işlemek yan etki yaratmasın.
`
Bu iki noktayı atlarsanız üretimde `bazen çalışıyor bazen çalışmıyor` gibi sınır bozucu` .
`bir sisteme kavuşursunuz.` .
`Sonra debug etmesi cehennem oluyor.` .
`Baştan doğru kurun.` .
Sıkça Sorulan Sorular
1 Temmuz 2027’den sonra RER’lerim silinecek mi, yoksa sadece çalışmayı mı bırakacak?
Kayıtlar teknik olarak dürüyor, ama tetiklenmiyor artık. Yanı SharePoint size event göndermiyor. Kayıtları kendiniz temizlemeniz gerekiyor; otomatik bir silme falan yok, bence bunu takvime almakta fayda var.
Entra ile kayıtlı RER’im var, tekrar bir şey yapmam gerekiyor mu?
Kısa vadede işi kurtarıyor açıkçası, ama 1 Temmuz 2027’de o da bitiyor. Yanı Entra kaydı sadece nefes aldıran bir köprü gibi düşünün. Asıl göç webhook veya Graph change notifications’a olmalı — ne kadar erken o kadar iyi.
Webhook ile “-ing” (senkron) olaylarını taklit edebilir mıyım?
Hayır, maalesef. Webhook’lar sadece olay sonrası tetikleniyor. Mesela engelleme mantığı gerekiyorsa SharePoint izin modeliyle, gizli kütüphanelerle veya iş katmanınızın kendi doğrulama akışıyla çözmeniz gerekiyor.
SharePoint webhook ile Microsoft Graph change notifications arasında ne fark var?
İtiraf edeyim, Kabaca şöyle açıklayayım: SharePoint webhook liste öğesi seviyesinde çalışıyor. SharePoint API üzerinden yönetiliyor. Graph change notifications işe Microsoft Graph çatısı altında çok daha geniş bir kapsam sunuyor — hani kullanıcılar, mailler, drive item’lar da dahil. Uygulamanız zaten Graph tabanlıysa, bence Graph tarafına geçmek daha tutarlı bir mimarı veriyor.
Webhook subscription’ım sessizce ölürse nasıl fark ederim?
Açıkçası kendi tarafınızda izleme kurmazsanız fark edemezsiniz — tecrübeme göre bu en çok gözden kaçan nokta (şaşırtıcı ama gerçek). Bir “heartbeat” mantığı ekleyin: subscription’larınızı düzenli sorgulayan, süresi biteni yenileyen ve ölenler için alert üreten bir job kurun. Mesela Azure Monitör veya Application Insights’a alert bağlayabilirsiniz (ciddiyim)
Kaynaklar ve İleri Okuma
Microsoft 365 Dev Blog — Remote Event Receivers are retiring (orijinal duyuru)
SharePoint Webhooks — Resmî Dokümantasyon
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