Google Calendar Extended Properties ile Randevu Kimliği Nasıl Eşlenir?

Kısa yanıt: Randevu kimliği takvim olayına nasıl bağlanır?

Randevu sistemiyle Google Calendar arasında eşleme yaparken, takvim olayının görünen başlığını kimlik alanı olarak kullanmayın. Calendar API'nin extendedProperties alanı, uygulamaya özgü bir anahtar ve değeri olayla birlikte saklamak için tasarlanmıştır. Örneğin uygulamanızdaki değişmeyen randevu kimliğini bir private property olarak yazıp daha sonra bu değere göre olayı bulabilirsiniz. Bu yöntem, aynı saat ve aynı adla açılan iki randevunun karışmasını azaltır; fakat tek başına çift kayıt, yetki veya saat dilimi sorunlarını çözmez. Google'ın güncel extended properties kılavuzu private ve shared kapsamlarını, yazma ve arama yollarını açıklar.

Bu yazı, takvim görünümünün düzenlenmesinden çok iki sistemin aynı randevuyu tanıması sorununa odaklanır. Randevu türlerini takvimde ayırmak istiyorsanız Google Calendar etiketleriyle randevu yönetimi ayrıca yararlı olabilir. Eşleme ve süreç otomasyonu için Webinle otomasyon yazılımları sayfasında hizmet kapsamını inceleyebilirsiniz.

Önce hangi kayıt kaynak olacak, karar verin

Takvim ve randevu uygulaması aynı verinin iki kopyası gibi düşünülürse ilk iptal veya tarih değişikliğinde çelişki oluşabilir. Önce bir asıl kayıt belirleyin: randevuyu web formu, CRM veya kurum içi panel oluşturuyorsa randevu kimliği orada üretilsin; takvim olayı bu kayda bağlansın. Takvim üzerinden doğrudan açılan etkinlikler de iş akışına girecekse, bu olaylar için ayrı bir kabul ve eşleme süreci tanımlayın. Sadece takvim başlığında müşteri adı geçiyor diye otomatik hasta veya müşteri kaydı yaratmayın.

Kimlik değerini kullanıcıya görünen bilgiyle karıştırmayın. Ad, telefon veya açıklama metni değişebilir; stabil kimlik ise ilgili işlem devam ettiği sürece aynı kalmalıdır. externalAppointmentId gibi anlaşılır bir anahtar seçmek, hangi uygulamanın alanı yazdığını belgelemek ve yeniden kullanım kuralını belirlemek bakım işini kolaylaştırır. Gerçek kişisel veriyi kimlik değerinin içine koymak yerine anlamsız bir iç tanımlayıcı kullanmak daha ölçülü bir tasarımdır.

Bir kayıt birden çok takvim kopyasında görünebilir. Google'ın kılavuzuna göre private property, istekteki calendarId ve eventId ile belirlenen yerel kopyaya özgüdür; shared property ise etkinliğin katılımcıları tarafından görülebilir ve düzenlenebilir. Bu yüzden iç eşleme kimliği için hangi takvim kopyasını yazıp okuyacağınızı önceden sabitleyin. Katılımcıların görmesi gerekmeyen bir operasyon bilgisini sırf bütün kopyalarda bulunsun diye shared alana taşımayın. Paylaşım ihtiyacı varsa veri minimizasyonunu ve erişim modelini ayrıca değerlendirin.

Yazma ve bulma akışını tasarlayın

İlk oluşturma akışında randevu kaydını, takvim olayını ve aralarındaki kimlik bağını tutarlı sırayla işleyin. Olay oluşturulduktan sonra takvim olay kimliğini kendi sisteminizde saklamak, sonraki değişikliklerde doğrudan Events.get kullanmanıza imkân verir. Buna ek olarak extended property, kayıp eşleme tablosunu onarma veya belirli bir harici kimliğe bağlı etkinliği arama işinde işe yarayabilir. Calendar Events referansı get, list, insert ve patch işlemlerini ayrı yöntemler olarak listeler.

Extended property eklerken aynı anahtarı yeniden yazmanın önceki değeri değiştirdiğini hesaba katın. Kılavuz, belirli alanları diğerlerine dokunmadan değiştirmek için patch kullanımını anlatır. Bununla birlikte API referansı, patch çağrısının kota maliyetine ve belirtilen alanların mevcut değerleri değiştirme davranışına dikkat çeker. Toplu senkronizasyonda bu ayrıntıları inceleyip get + etag'li update ile patch seçeneklerini ihtiyaçlarınıza göre ölçün; bütün uygulamalar için tek yöntem ilan etmeyin.

Arama gerektiğinde Events.list üzerindeki privateExtendedProperty veya sharedExtendedProperty filtresini anahtar=değer biçiminde kullanabilirsiniz. Private alanda arama, doğru takvim kopyasının kapsamına bağlıdır. Aynı kimlik için birden fazla sonuç dönmesini olağan başarı saymayın: bu durum çift yaratılmış olay, eski kayıt veya hatalı anahtar tekrarına işaret edebilir. Sonuçları olay durumu, takvim kimliği ve beklenen randevu kaydıyla karşılaştırın. Sıfır sonuçta da körlemesine yeni olay oluşturmak yerine önce doğru takvimi ve silinmiş ya da taşınmış olay ihtimalini kontrol edin.

Değişiklik ve iptal senaryolarını ayrı test edin

Bir randevunun saati değiştiğinde kimlik sabit kalmalı, olay zamanı güncellenmelidir. Değişen açıklama veya katılımcı listesi için aynı olaya yazdığınızdan emin olun. İptalde takvim olayını silmek mi, durumunu işaretlemek mi gerektiğine operasyon ekibiyle karar verin; müşteri bildirimi bu karara bağlı olabilir. Hata alındığında tekrar deneme mantığı yeni olay üretmeye değil, önce mevcut bağın doğrulanmasına dayanmalıdır.

Özellikle dört testi otomasyon kabulüne ekleyin: aynı istek iki kez geldiğinde tek takvim olayı kalması; takvim olayı manuel düzenlendiğinde sistemin farkı nasıl ele aldığı; bağlantı kesildiğinde yarım kalan yazmanın nasıl uzlaştırıldığı; bir katılımcı kopyasındaki private alanın başka kopyada arandığında nasıl davrandığı. Bu testlerde gerçek müşteri verisi yerine örnek kimlikler kullanın. Takvim API'sinin başarı yanıtı, randevunun işletme açısından doğru işlendiğini kendi başına kanıtlamaz.

İzleme kaydında randevu kimliği, takvim kimliği, olay kimliği, işlem türü ve hata sınıfı yeterli olabilir. Telefon, hasta notu veya müşteri adı gibi ayrıntıları gereksiz yere günlüğe taşımayın. Hangi sistemin en son yazdığını ve hangi olayın yeniden denendiğini görmeden çift kayıt hatasını çözmek güçleşir. İş akışı yüksek hacimliyse oran sınırı ve yeniden deneme stratejisini ayrıca doğrulayın; bu yazı belirli bir kota veya performans vaadi vermez.

Hangi durumda bu yaklaşım uygun değildir?

Yalnızca takvim üzerinde elle yönetilen, harici randevu kaydı bulunmayan bir akışta uygulama kimliği eklemek fazladan karmaşıklık yaratabilir. Birden çok işletme veya sağlayıcı takvimi aynı olaya yazıyorsa private/shared seçimi tek başına veri sahipliğini çözmez. Ayrıca extended property bir tam müşteri veritabanı değildir; randevu geçmişi, izinler ve denetim kayıtları için kendi sisteminizin veri modelini koruyun. Google'ın alan sınırları olduğunu da dikkate alarak büyük açıklamaları veya belgeleri bu anahtar-değer yapısına sıkıştırmayın.

Karar vermeden önce bir örnek randevunun oluşturma, güncelleme ve iptal yolunu çizin. Her adımda asıl kayıt, takvim kopyası, kimlik ve hata halinde yapılacak işlem belli oluyorsa entegrasyonu küçük bir pilotla sınayabilirsiniz. Webinle ile bir randevu otomasyonu değerlendirmesi yaparken mevcut kayıt sistemi, takvim sayısı ve hata örneklerini paylaşmanız çözüm kapsamını netleştirir.