OASIS WS-Calendar + iCalendar (RFC 5545) Saha Dispatch Protokolü: Sistemler Arası Görev Senkronizasyonu

Olgun saha hizmet organizasyonunda iş emri tek noktadan değil çoklu kaynaktan doğar: CRM'de müşteri talebi açılır, ERP'de planlı bakım çıkar, IoT sensör eşik aşımında otomatik tetikleme yapar, müşteri portalı self-service iş açar, üçüncü taraf çağrı merkezi entegrasyonu ekler. Service Council 2024 anketinde 100+ tekniker organizasyonların %78'i 3+ kaynaktan gelen iş emrini yönetiyor. Sentezsiz aktarımda dispatch dublikasyonu (aynı iş iki ayrı kaynaktan açılıyor) ortalama %14. Standart bir senkron protokol şart — OASIS Web Services Calendaring TC ve IETF RFC 5545 (iCalendar) bu boşluğu doldurur.

RFC 5545 IETF Standards Track olarak 2009'da yayınlandı, takvim ve görev objelerini tanımlar. Saha dispatch için kritik üç bileşen: (1) VEVENT — zaman aralıklı görev (örnek 'Yarın 14:00 İzmit klima bakım'), DTSTART/DTEND, LOCATION (Türkiye Coğrafi Koord Sistemi destekli), CATEGORIES (skill), ATTENDEE (tekniker), STATUS (CONFIRMED/TENTATIVE/CANCELLED). (2) VTODO — bitiş tarihi olan görev (örnek 'Cuma'ya kadar müşteri rapor üret'), PERCENT-COMPLETE, PRIORITY. (3) VJOURNAL — geçmişe yönelik servis kaydı. Her obje benzersiz UID, son güncelleme DTSTAMP ve SEQUENCE numarası taşır — çakışma yönetimi temelinde.

OASIS WS-Calendar Technical Committee RFC 5545'i SOAP/REST servisleri üzerinde standartlaştırır. Çekirdek operasyonlar: GET (kaynaktan görev çek), PUT (görev gönder), POST/PROPFIND/REPORT (CalDAV — RFC 4791). RFC 5546 iMIP protokolü iki ayrı sistem arası görev davet/güncelleme/iptal mesajlaşmasını standartlaştırır: METHOD=REQUEST (yeni atama), METHOD=REPLY (tekniker kabul/red), METHOD=COUNTER (alternatif zaman teklifi), METHOD=CANCEL (iptal). RFC 6638 scheduling extensions çakışmaları (örnek iki sistem aynı slot'a iş atadı) atomik karar verir.

IoT tetikli saha iş emirleri (sensör eşik aşımı, makine arıza alarmı) ETSI TS 103 264 oneM2M çerçevesinde standartlaştırılıyor. oneM2M Common Service Functions (CSF) içinde 'Triggering' modülü sensör verisinden iş emri üretir, içerik formatı RFC 5545 VEVENT olarak iletilir. Örnek akış: Endüstriyel klima titreşim sensörü RMS değeri 4.5 mm/s aşıyor → oneM2M IN-CSE (Infrastructure Node) tetikleyicisi VEVENT objesi üretir (DTSTART = now + 4 saat, CATEGORIES = predictive_maintenance, LOCATION = makine ID) → FSM platformu webhook üzerinden alır, dispatch'e ekler. IEEE 1888 Green Smart Facility standardı bu akışı bina otomasyon sistemleri için detaylandırır.

Çoklu kaynak senkronizasyonunda en zor problem versiyon çakışması: aynı iş emrini iki sistem aynı anda düzenliyor. RFC 5545 SEQUENCE alanı her güncellemede 1 artar — en yüksek SEQUENCE kazanır. CalDAV (RFC 4791) HTTP ETag header'ı kullanır — sunucu objenin hash'ini döner, istemci güncelleme PUT'unda If-Match header'a koyar, sunucu eşleşmiyorsa 412 Precondition Failed döner. Pratik dispatch örneği: dispatcher müşteri görüşmesinden sonra 15:00 → 16:30'a kaydırdı (SEQUENCE 1 → 2), aynı anda CRM 15:00 statüsünü 'CONFIRMED' yaptı (SEQUENCE 1 → 2). İki sistem senkronlanırken çakışma — RFC 6638 'Calendar User Address' önceliği veya manuel resolution adımı. CalConnect endüstri konsorsiyumu bu çakışma desenleri için referans testler yayınlar.

FSM platformu RFC 5545 + WS-Calendar uyumlu hale getirmek için tipik 8 haftalık pilot: Hafta 1-2: mevcut iş emri veri modeli RFC 5545 alanlarına eşlenir (örnek work_order_id → UID, scheduled_start → DTSTART, technician_id → ATTENDEE CN parametresi). Hafta 3-4: CalDAV REST endpoint'leri açılır (/caldav/{tenant}/jobs/), GET/PUT/REPORT methodları desteklenir. Hafta 5-6: iMIP webhook entegrasyonu (CRM/ERP'den METHOD=REQUEST mesajlarını al). Hafta 7: oneM2M IoT bridge (test sensör verisi → VEVENT üretimi). Hafta 8: çakışma testleri (eşzamanlı 2 sistem güncelleme senaryoları), ETag/SEQUENCE doğruluk doğrulama. Pilot sonuçları tipik: dispatch dublikasyon %14 → %1.2, senkron gecikme 4-12 saatten ortalama 6 dakikaya düşüyor.

iCalendar ATTENDEE alanı tekniker e-posta + isim taşır, LOCATION alanı müşteri adresi içerir — bu kişisel veri kapsamına girer. KVKK 6698 Madde 6 özel nitelikli olmayan ama Madde 10 aydınlatma + Madde 12 güvenlik tedbiri zorunlu. Senkron protokolde TLS 1.3 + mutual authentication (mTLS) standart, depolanan VEVENT objelerinde end-to-end encryption (örnek CalDAV-Encrypted Objects taslağı) önerilir. KVKK Veri Güvenliği Rehberi 2024 bulut tabanlı çoklu sistem senkronizasyonunda 'kişisel veri işleme envanteri' güncelleme yükümlülüğünü vurgular — RFC 5545 alanları envantere dahil edilmeli.