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.
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
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.
4 comments