Öğrenci bilgi sistemi entegrasyonu, ders kataloğunun ve ders programının web sitesine elle girilmesini ortadan kaldırır. Veri OBS'de tutulur, Drupal bu veriyi okur ve yayımlar. Bu yazımızda entegrasyonun üç yöntemini, OBS ile YÖKSİS'in bu yapıdaki rolünü, hangi bilginin hangi sistemde tutulacağını ve dönem geçişlerinde sık karşılaşılan sorunları anlatıyoruz.

Üniversite web sitelerinde ders bilgisi çoğu zaman iki yerde birden tutulur. Bir tarafta OBS, diğer tarafta bölüm sitesindeki elle hazırlanmış ders listesi vardır. Müfredat değiştiğinde biri güncellenir, diğeri unutulur. Entegrasyonun amacı bu ikiliği bitirmektir. Aşağıda bunun hangi yöntemlerle yapıldığını ve her yöntemin hangi veri türüne uyduğunu ele alıyoruz.

Öğrenci bilgi sistemi entegrasyonu web sitesinde ne sağlar?

OBS, üniversitenin akademik verisinin resmî kaynağıdır. Ders kataloğu, dönemlik ders programı, müfredat, kayıtlar, notlar ve akademik takvim burada tutulur. Web sitesi bu verinin yalnızca gösterildiği yerdir ve içeriği OBS ile çelişmemelidir.

Entegrasyon kurulduğunda aynı bilgi iki kez girilmez. OBS'de yapılan değişiklik siteye kendiliğinden yansır. Uygulamada taşınan veri kısa bir liste oluşturur ve her türün davranışı farklıdır.

  • Ders kataloğu. Ders kodlarını, adlarını, kredi ve AKTS değerlerini, tanımları ve ön koşulları kapsar. Müfredat yılına bağlı olarak yılda birkaç kez değişir.
  • Dönemlik ders programı. Şubeleri, ders saatlerini, derslikleri, öğretim elemanlarını ve kontenjanları içerir. Kayıt döneminde her gün değişir.
  • Programlar ve müfredat. Bölümleri, programları ve dersleri bunlara bağlayan kuralları tanımlar. Senato kararıyla değiştiği için seyrek güncellenir.
  • Akademik takvim. Dönem kodlarını, ders ekleme ve bırakma tarihlerini içerir. Küçük bir veri kümesidir, diğer tüm içerikler buna bakar.
  • Öğrenciye özel kayıtlar. Bir öğrencinin kendi ders programını, borç durumunu ve mezuniyet ilerlemesini kapsar. Kişisel veri sayılır, yalnızca kimlik doğrulamasından sonra gösterilir.

İlk dört tür kurumsal veridir ve herkese açık sayfalarda yayımlanabilir. Beşinci tür kişisel veridir ve ayrı kurallara tabidir.

Üç entegrasyon yöntemi ve hangi veriye uygun olduğu

Entegrasyonların büyük bölümü üç yöntemden birine girer. Doğru yöntemi seçmek için verinin ne sıklıkla değiştiğine, kaç kişinin okuduğuna ve bir kişiye ait olup olmadığına bakılır.

Zamanlanmış aktarım: katalog ve program sayfaları

Bu yöntemde OBS, ders ve program verisini belirli aralıklarla dışa aktarır. Aktarım genellikle geceleri çalışır. Drupal gelen veriyi kendi içerik yapısına dönüştürür: Ders için bir içerik türü, program için başka bir içerik türü, bölüm ve dönem bilgisi için sınıflandırma terimleri tanımlanır.

Bu işi Drupal çekirdeğindeki Migrate API yapar. Migrate Plus ve Migrate Tools modülleri JSON, XML ve CSV kaynaklarını ekler, aktarımı çalıştırma ve geri alma komutlarını sağlar. Daha basit beslemelerde Feeds modülü daha az yapılandırma gerektirir.

Aktarılan veri Drupal'daki diğer içerikler gibi davranır. Aranabilir, önbelleğe alınabilir ve İngilizce sürümü hazırlanabilir. Editörler bu kayda OBS'de bulunmayan alanlar ekleyebilir. Programın tanıtım metni, kapak görseli ve mezun görüşleri Drupal tarafında tutulur, resmî kayıt değişmez.

Zamanlanmış aktarım, belirli bir düzenle değişen ve çok kişinin okuduğu veri için uygundur. Saat başı değişen veri için uygun değildir, çünkü gece çalışan aktarım gün içindeki değişiklikleri yansıtmaz.

Canlı okuma: kontenjan ve güncel durum

Bu yöntemde veri kopyalanmaz. Sayfa açıldığında Drupal, OBS servisine sorgu gönderir ve gelen sonucu gösterir.

External Entities modülü bu amaçla geliştirilmiştir. Verisi Drupal veritabanında değil uzak bir REST servisinde duran bir varlık türü tanımlar. Bu sayede uzak veri, Views ve görünüm modları gibi bilinen araçlarla kullanılabilir. Yalnızca liste gösterilecekse Views Remote Data daha hafif bir seçenek sunar.

Canlı okuma, kontenjan ve şube durumu gibi anlık değişen veriler için uygundur. İki noktaya dikkat etmek gerekir. Önbellekleme yapılmazsa her sayfa açılışı bir servis çağrısı üretir. Ayrıca sitenin çalışması OBS servisinin çalışmasına bağlı hale gelir. Bu nedenle her veri türü için önbellek süresi belirlenmeli ve servise ulaşılamadığında sayfada bilgilendirme mesajı gösterilmelidir. Kayıt haftalarında yoğunluk arttığı için bu iki ayar önceden test edilmelidir.

Kimlik doğrulamalı sorgu: öğrenci portalı

Üçüncü yöntem öğrenci portalını kapsar. Öğrencinin kendi ders programı, borç durumu ve mezuniyet bilgisi bu yöntemle gösterilir. Veri oturum açan kişi için anlık olarak çekilir, sayfada gösterilir ve Drupal'da saklanmaz.

Kimlik bilgisi kampüs tek oturum açma sisteminden gelir. Oturumdaki öğrenci kimliği, OBS sorgusunun anahtarı olur. Kimlik eşleşmesi yanlış kurulursa sorgu başka bir öğrencinin kaydını getirir, bu nedenle portal kurulmadan önce eşleşmenin doğrulanması gerekir.

Kimlik tarafındaki seçenekleri SAML, Shibboleth, LDAP ve CAS ile SSO entegrasyonu yazısında ele aldık. Kimlik doğrulama kurulduktan sonra OBS sorgusu tek bir istekten oluşur. Bu istek sunucu tarafında, kurumun servis kimlik bilgileriyle yapılır; tarayıcıya hiçbir kimlik bilgisi gönderilmez.

Bazı üniversiteler portal işlevini Drupal'a taşımaz, OBS'nin kendi öğrenci arayüzüne yönlendirir. Bu yaklaşım daha az geliştirme gerektirir. Drupal tarafında portal kurmak, OBS verisinin haber, etkinlik ve kampüs hizmetleriyle aynı ekranda gösterilmesi istendiğinde anlam kazanır.

Türkiye'de kampüs sistemleri: OBS, YÖKSİS ve e-Devlet

OBS ve veri sözleşmesi

Entegrasyonun başlangıç noktası, OBS'nin hangi veriyi hangi biçimde dışa açabildiğidir. Üretici ürünlerinde web servisi ve dönemsel dışa aktarma seçenekleri bulunur. Kurum içinde geliştirilen sistemlerde ilk iş, bilgi işlem birimiyle bir veri sözleşmesi tanımlamaktır. Bu sözleşme üç soruyu cevaplar: Hangi alanlar aktarılacak, hangi biçimde aktarılacak, hangi sıklıkla aktarılacak.

Taşıma yöntemi kalıbı değiştirmez. OBS'nin servisi varsa External Entities ya da özel bir Migrate kaynak eklentisi bu servisi kullanır. OBS yalnızca dosya üretebiliyorsa, SFTP konumuna düzenli bırakılan CSV veya XML dosyası üzerinden aktarım kurulur. Dosya tabanlı aktarım daha eski bir yöntem gibi görünse de izlenmesi ve hata durumunda geri alınması kolaydır.

YÖKSİS: program ve birim tanımları

YÖKSİS, Yükseköğretim Kurulu'nun merkezî bilgi sistemidir. Üniversitelerin öğrenci, program ve birim verisini YÖKSİS'e bildirmesi OBS üzerinden yürür; web sitesi bu bildirimin tarafı değildir.

Web sitesi açısından YÖKSİS'in önemi, program ve birim tanımlarının resmî kaynağı olmasıdır. Bir programın adı, kodu ve akademik birim ağacındaki yeri YÖKSİS'te tanımlıdır. Web sitesindeki program sayfalarının bu tanımlarla aynı bilgiyi göstermesi, kurum içi raporlama ile dışa açık sayfaların tutarlı kalmasını sağlar.

Bu tutarlılık pratikte tek bir alanla kurulur. OBS'den gelen program verisindeki YÖKSİS birim kodu, Drupal'daki program içerik türünde ayrı bir alan olarak tutulur. Program adı değişse bile kod sabit kaldığı için sayfa kimliğini korur ve aktarım doğru kayda gider.

e-Devlet ve öğrenci belgeleri

Öğrenci belgesi gibi resmî belgeler e-Devlet üzerinden alınabildiği için web sitesinin bu belgeleri üretmesi gerekmez. Portal kurgusunda sitenin görevi, öğrenciyi doğru servise yönlendirmek ve OBS'den gelen güncel durumu göstermektir. Bu ayrım, hem geliştirme yükünü hem de kişisel veri işleme kapsamını azaltır.

Yurt dışı sistemleri: Banner, PeopleSoft ve Ethos

Uluslararası ortak programı veya yurt dışı kampüsü olan kurumlar, farklı sistemlerle de çalışır. Ellucian Banner ve Colleague, Ethos adlı birleşik REST katmanı üzerinden veri sunar. Ethos, iki üründe de aynı veri modelini kullanır ve Avrupa dahil dört bölgede ayrı uç noktalarla barındırılır. Oracle PeopleSoft Campus Solutions ise tarih bazlı geçerlilik mantığıyla çalışır; bir dersin tek bir tanımı yoktur, tarihe bağlı tanım geçmişi vardır ve sorgunun doğru müfredat yılını istemesi gerekir. Her iki sistemde de yukarıdaki üç yöntem aynı şekilde uygulanır, yalnızca alan eşlemesi değişir.

Hangi bilgi hangi sistemde tutulur?

Projedeki en belirleyici karar teknik değildir. Hangi alanın hangi sistemde tutulacağının yazılı hale getirilmesidir.

OBS akademik ve resmî bilgiyi tutar. Ders kodu, ders adı, kredi, AKTS, ön koşul, müfredat kuralı, ders saati ve dönem tarihi bu kapsamdadır. Drupal bu alanları düzenlemez, yalnızca gösterir. Sitedeki bir ders tanımı hatalıysa düzeltme OBS'de yapılır ve bir sonraki aktarımda siteye yansır.

Drupal ise OBS'nin kapsamı dışında kalan bilgiyi tutar. Programın tanıtım metni, öğretim üyesi görüşleri, kariyer çıktıları, görseller, başvuru yönlendirmeleri, İngilizce sürüm ve arama motoru meta verileri bu kapsamdadır. Bu alanlar aktarılan kayda bağlıdır ama ondan ayrı saklanır, böylece aktarım sırasında üzerine yazılmaz.

Bu ayrımın alan alan bir tabloya dökülmesi ve öğrenci işleri ile web ekibinin tabloyu birlikte onaylaması önerilir. Tablo, iki yaygın sorunu baştan çözer. Birincisi, sitede yapılan bir düzenlemenin gece aktarımında geri alınmasıdır. İkincisi, OBS'de kapatılan bir dersin elle hazırlanmış bir sayfada görünmeye devam etmesidir.

Web sitesinden OBS'ye veri yazmak teknik olarak mümkündür ancak farklı bir risk sınıfına girer. Kurumların çoğu başvuru ve kayıt işlemlerini OBS arayüzünde yürütür, web sitesini ise OBS'ye karşı yalnızca okuma yetkisiyle çalıştırır. Başlangıç için önerilen kurgu budur.

Entegrasyon katmanında KVKK

Entegrasyon öğrenciye özel kayıtlara eriştiği anda kişisel veri işlenmeye başlar. KVKK açısından ders kataloğu ve ders programı kurumsal veri sayılır. Bir öğrencinin kendi ders programı, notu veya borç bilgisi kişisel veridir ve amaçla sınırlı biçimde işlenmesi gerekir. Uluslararası öğrencisi bulunan kurumlar için GDPR de aynı ilkeleri getirir.

Üç uygulama kuralı bu yükümlülükleri karşılar.

  • Kurumsal veri açık sayfalarda yayımlanır, kişisel veri yalnızca kimlik doğrulaması sonrasında gösterilir.
  • Kişisel veri anlık olarak çekilir ve saklanmaz. Öğrenci kaydı ne Drupal tablosunda ne de ortak sayfa önbelleğinde tutulur.
  • Servis sorgusu yalnızca sayfanın gösterdiği alanları ister. Veri sözleşmesi dar tutulduğunda gereksiz alan hiç taşınmaz.

Hangi servis hesabının hangi veriye ne zaman eriştiğinin kaydı tutulmalıdır. Bu kayıt, denetim talebi geldiğinde ihtiyaç duyulan bilgiyi sağlar. Konunun genel çerçevesini Drupal'da KVKK ve GDPR uyumu yazısında anlattık.

Dönem geçişlerinde sık karşılaşılan sorunlar

Entegrasyonlar genellikle yayın gününde değil, tasarımın öngörmediği ilk olayda sorun çıkarır. Aşağıdaki altı durum için önceden karar alınması gerekir.

  • Dönem geçişi. OBS yeni dönemi açtığında site hâlâ eski dönemi güncel gösterebilir. Güncel dönem bilgisi sabit bir tarihten değil, OBS akademik takviminden alınmalıdır.
  • Kapatılan dersler. Ders dışa aktarımdan çıkar ama Drupal sayfası yayında kalır. Aktarımın bu sayfayı yayından mı kaldıracağı, arşivleyeceği mi yoksa yerine geçen derse mi yönlendireceği baştan belirlenmelidir.
  • Müfredat yılı karışması. Gelecek yıl geçerli olacak ders tanımı, sorgu yıla göre filtrelenmediğinde bu yılın sayfasında görünür.
  • Önbellek süresi. Canlı okunan veri önbelleğe alındığında kontenjan açıldıktan sonra bir süre eski değer görünür. Önbellek süresi veri türüne göre ayarlanmalı, kayıt haftasında kısaltılmalıdır.
  • Servis limitleri. Her istekte OBS'ye sorgu gönderen bir ana sayfa bileşeni yoğun günlerde istek limitini doldurur. Sorgu sonuçları önbelleğe alınmalı, servis yanıt vermediğinde sayfa boş kalmamalıdır.
  • Kimlik eşleşmesi. Tek oturum açma sistemi ile OBS farklı kimlik alanları kullanabilir. Eşleşme portal kurulmadan önce gerçek hesaplarla test edilmelidir; hem personel hem öğrenci kaydı bulunan kişiler ayrıca kontrol edilmelidir.

Bu altı başlığı kapsayan kısa bir işletim notu, yayın öncesinde hazırlanırsa sonraki dönemlerde tekrar eden sorunların çoğu önlenir.

Entegrasyon hangi düzeyde kurulmalı?

Her üniversitenin üç yöntemi birden kullanması gerekmez. İhtiyaç düzeyi, sitede gösterilecek veriye göre belirlenir.

Tanıtım düzeyindeki bir site için program sayfaları yeterlidir. Program sayısı az ve müfredat kararlıysa bu sayfalar elle de yönetilebilir.

Katalog düzeyindeki bir site zamanlanmış aktarım gerektirir. Çoğu kurum için asıl kazanç buradadır, çünkü yüzlerce ders sayfasının elle güncellenmesi ortadan kalkar.

Portal düzeyindeki bir site kimlik doğrulamalı sorguları da ekler. Bu düzey, OBS verisinin kampüsün diğer içerikleriyle aynı ekranda gösterilmesi istendiğinde tercih edilir. Düzeyler arasındaki maliyet farkı belirgindir; kurulum eforu ile lisans tasarrufunun nasıl karşılaştırılacağını açık kaynak ve lisanslı sistemlerde TCO analizi yazısında ele aldık.

Entegrasyon planlaması nereden başlar?

Öğrenci bilgi sistemi entegrasyonunda teknik iş, projenin küçük kısmıdır. Süreyi belirleyen, kurum içi mutabakattır. Web sitesi hangi alanları okuyacak, her alan hangi sistemde tutulacak, veri hangi sıklıkla yenilenecek ve dönem geçişinde ne yapılacak. Bu dört soru öğrenci işleri ile birlikte cevaplandığında kurulum tek seferde tamamlanır.

Drupart bünyesindeki Drupal4edu ekibinin Sabancı Üniversitesi, ODTÜ ve Yıldız Teknik Üniversitesi gibi kurumlar için geliştirdiği Drupal platformları, web sitesinin kurumun resmî sistemlerinden veri okuduğu bu tür bir entegrasyon katmanı üzerine kurulur. Yaklaşımımızın ayrıntılarını eğitimde Drupal sayfasında bulabilirsiniz.

Drupal OBS entegrasyonu hakkında sık sorulan sorular

Üniversitenin OBS'si Drupal web sitesine entegre edilebilir mi?

Evet. Belirleyici olan OBS'nin veriyi nasıl dışa açtığıdır. OBS'nin web servisi varsa Drupal, External Entities modülüyle veriyi saklamadan okuyabilir ya da Migrate API ile ders ve programları içerik olarak aktarabilir. OBS yalnızca dosya üretebiliyorsa düzenli bırakılan CSV veya XML dosyası üzerinden aktarım kurulur. Kurum içinde geliştirilen sistemlerde ilk adım, bilgi işlem birimiyle hangi alanların hangi biçimde ve hangi sıklıkla aktarılacağını tanımlamaktır.

Drupal, OBS entegrasyonunda öğrenci verisini saklar mı?

Kişisel veri için saklamaması gerekir. Ders kataloğu ve ders programı gibi kurumsal veri, aranabilmesi ve tanıtım içeriğiyle birlikte kullanılabilmesi için Drupal'a aktarılır. Bir öğrencinin kendi ders programı veya borç bilgisi ise kimliği doğrulanmış öğrenci için anlık çekilir, gösterilir ve saklanmaz. Öğrenci kaydının Drupal veritabanında veya ortak sayfa önbelleğinde tutulmasına gerek yoktur. Bu ayrım, KVKK kapsamındaki yükümlülükleri karşılamanın en basit yoludur.

Ders verisi ne sıklıkla güncellenmeli?

Veri türüne göre değişir. Ders kataloğu ve program verisi yılda birkaç kez değiştiği için gece çalışan bir aktarım yeterlidir, bazı kurumlar haftalık aralık kullanır. Dönemlik ders programı kayıt döneminde her gün değişir; bu veri için daha sık aktarım veya kısa önbellekli canlı okuma gerekir. Kontenjan ve şube durumu kayıt haftasında canlı okunmalıdır. Tüm veri türleri için anlık eşitleme kurmak, performans ve kararlılık açısından gereksiz bir yük oluşturur.

OBS entegrasyonu ile LMS entegrasyonu arasındaki fark nedir?

İki entegrasyon farklı veri taşır. OBS, kayıtların ve akademik geçmişin resmî kaynağıdır. Moodle veya Canvas gibi öğrenme yönetim sistemleri ise dersin işlendiği ortamdır; materyal, ödev ve dönem içi not burada tutulur. OBS entegrasyonu katalog, program ve ders programı verisini siteye taşır. LMS entegrasyonu ise genellikle tek oturum açma ve öğrenciyi ders alanına yönlendirme üzerine kuruludur. LMS tarafını Moodle ve Drupal entegrasyonu yazısında ele aldık. İki proje aynı dönemde yayına girse bile ayrı planlanmalıdır.

OBS entegrasyonu KVKK açısından ne gerektirir?

Uyum, tek bir yazılım özelliğiyle değil bütün tasarımla sağlanır. Kişisel kayıtlar kimlik doğrulaması arkasında tutulur, saklanmak yerine anlık çekilir, sorgu yalnızca sayfanın gösterdiği alanları ister ve erişim kayıtları tutulur. Ders listesi ve öğretim elemanı adı gibi kurumsal bilgi, kurum politikası aksini belirtmedikçe açık sayfalarda yayımlanabilir. Hangi alanın hangi kapsama girdiğine web ekibi değil, öğrenci işleri ve kişisel veri sorumlusu karar verir. Bu karar entegrasyon kurulmadan önce yazılı hale getirilmelidir.

Son güncelleme: 14.09.2026 17:29