ailenin en hızlı ve en hafif üyesi. büyük düşünmek için değil, çok ve hızlı iş yapmak için tasarlanmıştır. sınıflandırma, özetleme, log analizi, veri çıkarma, gelen isteği doğru agent’a yönlendirme gibi yüksek hacimli işlerde rakipsizdir. multi-agent mimarilerde genelde ön kapıda durur: istekleri karşılar, ayıklar, zor olanları ağabeylerine paslar. dakikada binlerce çağrı atacağın bir pipeline kuruyorsan, hem hızına hem de faturaya bakıp teşekkür edeceğin modeldir.

ailenin iş atı. hız, maliyet ve zeka arasındaki dengeyi en iyi kuran model olduğu için production’daki kod asistanlarının, ide entegrasyonlarının ve agent’ların büyük kısmının arkasında o vardır. günlük development’ın neredeyse her şeyini karşılar: feature yazar, bug bulur, test üretir, pull request açıklaması yazar, yanlış anladığın bir framework’ü sana anlatır. bunu da seni bekletmeden yapar. her ekipte bir sonnet vardır: toplantılarda en çok konuşan o değildir, ama sprint sonunda kapanan ticket’ların yarısı ondadır.

ailenin ağır topu, fable gelene kadar da en yetenekli üyesi. büyük refactor’lar, mimari kararlar, sıfırdan bir servis tasarlamak, kimsenin elini sürmek istemediği 2000 satırlık legacy fonksiyonu parçalara ayırmak gibi işlerde kullanılır. güçlü olduğu yer planlamadır. koda dalmadan önce problemi anlar, yapacağı değişikliği adım adım kurgular, sonra da o plana sadık kalır. uzun agent oturumlarında yolunu kaybetmez, yarıda bıraktığı işi nerede bıraktığını bilir. kod review’da da iyidir; “çalışıyor ama” diye başlayan yorumları genelde haklı çıkar.

ailenin en yeni ve en güçlü üyesi, anthropic’in “mythos sınıfı” modellerinden kamuya açılan ilki. diğer modellerin “bu biraz karmaşık” dediği yerde işe başlar. asıl farkı derinliktir. kimsenin çözemediği race condition’ı, üç servis arasında kaybolan bir veri tutarsızlığını, dokümantasyonu olmayan eski bir sistemin mantığını ona verirsin; uzun uzun düşünür, sonra da genelde doğru noktaya parmak basar. büyük kod tabanında saatler süren otonom görevleri dağılmadan sonuna kadar götürebilmesi de cabası. basit işler için fazla gelir, kahve almaya kamyonla gitmek gibidir. ama gerçekten zor bir problemle karşılaştığında açtığın sekme budur.

anthropic’in geliştirdiği yapay zeka model ailesi. developer dünyasında “kod yazan yapay zeka” denince akla ilk gelen isimlerden biri olmayı hak ederek başarmıştır. asıl gücü kod tarafındadır. tek fonksiyon yazdırmak için değil, koca bir repo’yu okutup “şu modülü refactor et, testleri de düzelt” demek için kullanılır. uzun context sayesinde yüzlerce dosyalık projeyi kafasında tutar, bir yerde değiştirdiği şeyin üç klasör ötede neyi kıracağını genelde senden önce fark eder. claude code ile terminale yerleşir. dosya okur, komut çalıştırır, testi koşar, hata alırsa düzeltip tekrar dener. yani sen ticket’ı tarif edersin, o da junior developer gibi değil, işini bilen bir meslektaş gibi uçtan uca götürür. bunu yaparken de ne yaptığını, neden yaptığını anlatır, git diff’ine bakınca sürprizle karşılaşmazsın. tool kullanımında ve agent senaryolarında da güçlüdür. mcp’yi (model context protocol) çıkaran da anthropic’tir; bugün yarım internetin agent’larını tool’lara bağlamak için kullandığı standart buradan doğmuştur. bir diğer artısı, bilmediği yerde uydurmaması. var olmayan bir api endpoint’ini ya da kütüphaneyi kendinden emin şekilde önermek yerine “bundan emin değilim, dokümana bakalım” demeyi tercih eder. production’a kod gönderen herkes bu özelliğin ne kadar değerli olduğunu bilir. kısacası, pair programming’de klavyeyi ona bıraktığında içinin rahat ettiği nadir modellerden.

SAP sisteminde ilk kullanılan işlem kodlarının başında gelir. Kullanıcı açmak için girilir sadece Basis danışmanın yetkisi olmalıdır, evettir, bu kadardır.

frontend ciler kızmasın ama logic backendden(abap) gelir odata veya cds+odata publish ile gönderilir frontend ise bu veriyi nasıl göstereceğini ayarlar

sap dünyasının web e açılan kapısı. bir zamanlar webdynpro vardı oldlar iyi bilir. Geliştirme ortami webide(bunun yerine sap bas i sundu bulut tabanlı) veya vs code vardır ki ben çoğunlukla bunu kullanırım ancak extension u kurmanız gerekir çünkü kendi ui5 kütüphanesi vardır “sap.m” m ise mobileyi temsil eder

Bazen koca bir süreç bu tablolar üzerinden döner. Eğer birden fazla tablo kullanılacaksa süreçte developer aralarında ki ilişkiyi iyi kurmalı ki yazdığı kodun kalitesi open sql de ortaya çıksın. Maintenance table + view ile ağaç yapısı bir tcode a bağlanırsa yönetmesi çok daha kolay olur ancak işin içine event ler girmeye başlayınca çarşı karışabilir :)

son dönemde işin içine yapay zeka ve mcp (model context protocol) server destekleri de girmeye başladı. artık sadece sistemleri birbirine bağlamakla kalmıyor, iflow'ları veya api'leri ai agent'ların doğrudan kullanabileceği araçlar olarak dışarı açıp ajan tabanlı senaryolara da zemin hazırlıyor.

sap btp altında yer alan, eski adıyla cpi (cloud platform integration) olarak bildiğimiz bulut tabanlı entegrasyon platformu. şirket içindeki mevcut sap veya sap dışı sistemlerle dış dünyadaki cloud uygulamaları birbiriyle konuşturmaya yarar. gelen veriyi alır, formatını değiştirir (xml, json, csv ne gerekiyorsa), gerekli yerlere yönlendirir ve karşı tarafa iletir. içinde sap'nin hazır sunduğu standart paketler vardır ama proje bazlı işlerde genelde sıfırdan özel akışlar (iflow) tasarlanır. veri dönüşümleri için message mapping, biraz daha kompleks iş kuralları için de groovy script sıkça kullanılır. bağlantı tarafında eli oldukça geniştir. soap, rest, odata, sftp, idoc, rfc gibi aklınıza gelebilecek çoğu protokolü destekler. lokaldeki s/4hana ya da ecc sistemlerine erişirken de araya cloud connector girer ve güvenli bir tünel üzerinden haberleşmeyi sağlar. sadece akış tasarlamakla kalmaz, api management ve event mesh gibi diğer modülleri de aynı çatı altında toplayarak entegrasyon süreçlerini tek merkezden yönetme ve izleme imkanı verir.

kim bu slovakyalisalyangoz?

açılımı general data protection regulation. avrupa birliği’nin 25 mayıs 2018'de yürürlüğe soktuğu, 99 maddelik kişisel veri koruma tüzüğü. türkiye’deki karşılığı kvkk, kendisi de gdpr’ın biraz daha az korkutucu kuzenidir. ceza kısmı ciddidir: 20 milyon euro ya da şirketin global cirosunun yüzde 4'ü, hangisi büyükse. bu rakamı duyan her yönetim kurulu bir gecede “veri gizliliği bizim için öncelik” demeye başlamıştır. hayatımıza en somut katkısı, girdiğimiz her siteye selam veren çerez banner’larıdır. “tümünü kabul et” butonu kocaman ve renklidir, “tercihleri yönet” ise gri, minik ve 47 tane checkbox’ın arkasına saklanmıştır. avrupalı internet kullanıcısı günde ortalama 30 kez onay verir, hiçbirini okumaz. sap tarafında ise apayrı bir dünyadır. “unutulma hakkı” (madde 17) kağıt üzerinde basittir: müşteri “verimi silin” der, silersin. pratikte o müşterinin kaydı 2009'dan beri fi’da, sd’de, z’li tablolarda, bw’de, bir de kimsenin hatırlamadığı bir interface log’unda durur. ilm projesi başlatılır, blocking kuralları yazılır, retention süreleri muhasebeyle tartışılır. vergi mevzuatı “10 yıl saklayacaksın” der, gdpr “gereğinden fazla tutmayacaksın” der, danışman ikisinin arasında kalır. ihlal olduğunda 72 saat içinde otoriteye bildirim zorunludur (madde 33). bu 72 saatin ilk 48'i “gerçekten ihlal mi bu” toplantısıyla, kalan 24'ü de hukukçunun dönüşünü beklemekle geçer. her projenin bir dpo’su vardır. toplantılara nadiren katılır ama katıldığında projenin en sevilmeyen insanı olur, çünkü sorduğu tek soru hep aynıdır: “bu veriyi neden tutuyoruz?” bonus: yapay zeka projelerinde artık ilk slayt mimari değil, “kişisel veri llm’e gidiyor mu?” sorusudur. cevap evetse proje dpo onayına gider, dpo onayı da genelde bir sonraki çeyreğe kalır.

açılımı business technology platform. tek bir ürün sanılır, aslında kalabalık bir servisler ailesidir. her bayram toplanırlar ama kimin kimin nesi olduğunu kimse tam bilmez. aile büyüğü hana cloud’dur. evin bütün masrafını o çıkarır, açık unutulduğunda da bütçeyi o bitirir. integration suite ailenin çalışkan abisidir, herkesi herkesle konuşturur ama kendi derdini kimseye anlatamaz. xsuaa kapıdaki bekçidir, kimseyi içeri almaz, sebebini de söylemez. destination service ise “ben bağlarım” diyen ama 401 alınca telefonu açmayan amcadır. build ailesi ayrı bir koldur. önce workflow management diye doğmuş, sonra process automation olmuş, şimdi build’in bir odasında yaşıyor ama nüfustaki adı hâlâ düzeltilmedi. ai core ailenin yeni gözdesidir, herkes ondan çok şey bekler, o da genelde bir llm’e aracılık etmekle yetinir. joule ise eve yeni gelen gelindir, misafirin yanında çok güzel konuşur, misafir gidince “bu konuda yardımcı olamıyorum” der. ailenin geri kalanı da kalabalıktır: cloud foundry, kyma, abap environment, event mesh, work zone, document ai... her birinin bir görevi vardır ama hepsini tek seferde anlatabilen biri henüz çıkmadı. çıksa bile bir sonraki teched’de isimler değişince baştan öğrenmek zorunda kalacak. aileye katılmak için subaccount açman, entitlement ataman, role collection tanımlaman ve cpea kredisinin nereye gittiğini hiç sormaman yeterlidir.

“geçici çözüm” olarak açılıp 12 yıl prod’da yaşayan yapıdır. içinde kimin, neden, hangi projede yarattığı bilinmeyen alanlar bulunur. dokunulmaz, sorgulanmaz, silinmez. clean core döneminde varlığı itiraf edilmesi gereken günahtır.