Agentic SAP Otomasyonu: AI Çok Adımlı Bir Geliştirmeyi Nasıl Planlar?

AI araçlarını değerlendiren SAP ekiplerinin çoğu aynı testi yapar: "Bana bir ALV raporu yaz." Model bir şeyler üretir, kod editöre düşer, iş biter. Ama gerçek bir SAP geliştirmesi nadiren tek nesnedir. Yeni bir müşteri talebi genellikle bir Z-tablo, o tablonun alanları için data elementleri, onların altında domainler, veriye erişen bir fonksiyon modülü veya sınıf ve en tepede bir program demektir — hepsi de belirli bir sırayla oluşturulmak zorunda. "Agentic" kelimesinin işe yarar bir anlamı varsa, tam olarak burada başlar: aracın tek bir isteği yanıtlaması değil, çok adımlı bir işi planlayıp adım adım yürütebilmesi.

1. Gerçek bir geliştirme tek nesne değildir

Bir örnek üzerinden gidelim: "Tedarikçi teslimat performansını izleyen bir rapor istiyorum, sonuçlar yeni bir tabloda da saklansın." Bu tek cümlelik istek, SAP'ta şu nesnelerin sırayla oluşturulması anlamına gelir — teslimat gecikmesi için bir domain, onu kullanan bir data elementi, bu alanları taşıyan bir Z-tablo, tabloyu besleyen bir hesaplama mantığı (fonksiyon modülü ya da sınıf), ve tüm bunları çağıran çalıştırılabilir bir program. Üstelik hepsi bir paketin içinde ve bir transport talebine bağlı olmak zorunda.

Klasik bir AI asistanıyla bu işi yapmaya kalkarsanız, orkestrasyon yükü tamamen sizde kalır: SE11'e girip domaini açar, sonra sohbete dönüp "şimdi data elementini yaz" dersiniz, sonra tekrar SAP'a geçersiniz. Model her turda bağlamın bir kısmını kaybeder, siz de aslında bir derleyicinin yapması gereken işi — bağımlılıkları takip etmeyi — elle yaparsınız. Zaman kazancı buharlaşır.

mdp/aigui'nin "Planla ve Uygula" modu bu boşluğu kapatmak için var. Bir ihtiyacı tarif edersiniz; AI gereken tüm SAP nesnelerini çıkarır, bağımlılık sırasına dizer ve size bir plan olarak sunar. Süreç dört fazdan oluşur: Keşif, İnceleme, Yürütme ve Uygulama.

2. Keşif: AI önce sizin sisteminizi okur

Plan çıkarmadan önce cevaplanması gereken sorular var: Bu tablo zaten var mı? Hangi paketin altına gitmeli? Benzer bir fonksiyon modülü daha önce yazılmış mı? Keşif fazı tam olarak bunu yapar — ADT (ABAP Development Tools) REST API üzerinden sisteminize bağlanıp mevcut nesneleri, paket yapısını ve veri sözlüğünü okur.

Bu adımın atlanamaz olmasının nedeni basit: hiçbir dil modelinin eğitim verisinde sizin Z-nesneleriniz yoktur. İki SAP sistemi birbirinin aynısı değildir; müşteriye özel alanlar, append yapıları ve yıllar içinde birikmiş isimlendirme gelenekleri yalnızca canlı sistemden okunabilir. Genel bir sohbet botunun ürettiği plan ile sisteminizi okumuş bir aracın ürettiği plan arasındaki fark, çoğu zaman planın uygulanabilir olup olmamasıdır.

Keşif ayrıca gereksiz iş üretmeyi de engeller. Aradığınız hesaplamayı yapan bir fonksiyon modülü sistemde zaten varsa, plana yeni bir nesne eklemek yerine mevcut olanı çağırmak doğru karardır — ve bunu ancak sistemi gerçekten okuyan bir araç bilebilir.

3. Bağımlılık sırası: neden domain'den başlanır?

SAP'ta nesneler birbirine dayanır ve bu bağımlılıklar aktivasyon sırasını belirler. Bir data elementi, dayandığı domain aktif değilse aktive edilemez. Tablo, alanlarının data elementleri hazır değilse oluşturulamaz. Program, çağırdığı sınıf ortada yoksa derlenmez. Bu yüzden plan rastgele bir yapılacaklar listesi değil, sıralı bir zincirdir:

• Paket: tüm nesnelerin kapsayıcısı — yoksa önce o oluşturulur.
• Domain: teknik tip ve değer aralığı tanımı, zincirin en altı.
• Data elementi: domaine dayanır, alanın semantik anlamını ve etiketlerini taşır.
• Tablo / yapı: alanlarını data elementlerinden alır.
• Fonksiyon modülü / sınıf: tablo ve tiplere dayanan iş mantığı.
• Program: hepsini birleştiren, çalıştırılabilir üst katman.

Bu sıra ABAP geliştiricileri için yeni bir bilgi değil — zaten her gün uyguladıkları disiplin. Değişen şey, sıranın takibinin araca devredilmesi: hangi nesnenin hangisini beklediğini not tutarak izlemek yerine, planı okuyup doğruluyorsunuz. Sözlük nesnelerinin (tablo, yapı, data elementi, domain) uygulama içinden oluşturulup aktive edilebilmesi de bu zincirin SAP GUI'ye çıkmadan tamamlanabilmesini sağlıyor.

4. İnceleme: plan onayınıza gelir, düzenlenebilir

Keşif bittiğinde AI planı doğrudan uygulamaya geçmez; plan önce size gelir. Bu fazın varlığı tesadüf değil — bir planın yanlış olduğunu anlamanın en ucuz anı, henüz hiçbir nesne oluşturulmamışken olduğu andır. Sekiz nesne oluşturulduktan sonra "aslında bu tablo yanlış pakette olmuş" demek, temizlik işi demektir.

Planı yalnızca onaylamakla kalmaz, düzenleyebilirsiniz de. İsimlendirme standardınıza uymayan bir nesne adını düzeltmek, gereksiz bulduğunuz bir adımı çıkarmak veya eksik kalan bir şeyi eklemek bu aşamada mümkün. Pratikte bu, planın bir müsvedde olarak ele alınması gerektiği anlamına gelir: AI'ın çıkardığı taslak iyi bir başlangıç noktasıdır, ama kurumsal isimlendirme kuralları ve paket disiplini gibi yalnızca sizin bildiğiniz kısıtlar bu aşamada plana işlenir.

Bu, ekiplerin insan geliştiriciler için zaten uyguladığı disiplinin AI'a taşınmasıdır — kimse tasarımı gözden geçirilmemiş bir işi doğrudan sisteme almaz. AI'ın ürettiği planın bundan muaf tutulması için bir neden yok.

5. Yürütme ve uygulama: adım adım, her adımda onay

Onaylanan plan tek bir "hepsini yap" butonuyla sisteme boşaltılmaz. Nesneler adım adım uygulanır ve her adım sizin onayınıza bağlıdır. Kod içeren adımlarda üretilen kod önce satır bazlı diff görünümünde önünüze gelir — hangi satırın eklendiği, hangisinin değiştiği işaretlidir; siz onaylamadan editördeki kod değişmez.

Aktarım tarafında da SAP standartlarının dışına çıkılmaz. Değişiklikler için transport talebini (CTS) uygulama içinden arayabilir veya oluşturabilirsiniz; aktivasyon öncesinde syntax kontrolü çalıştırmak yine sizin elinizde. Üretilen kodun son hakemi dil modeli değil, SAP sisteminizin kendi syntax denetimidir — derlenemeyen kod aktive edilmez, hata görünür olur ve düzeltme aynı diff-onay akışı içinde yapılır. ATC statik analiz ve birim test desteği de aynı ortamda, bu zincirin devamı olarak hazırdır.

Adım adım ilerlemenin ikinci faydası, hatanın erken yakalanması. Zincirin üçüncü adımında bir şey ters gittiyse bunu o anda görürsünüz — sekizinci adımdaki program derlenmediğinde geriye doğru sebep aramak yerine.

6. "Agentic" ne değildir?

Kelime pazarlama diline hızla girdiği için sınırı net çizmekte fayda var. Agentic çalışma, AI'ın sisteminizde başıboş dolaşması değildir. mdp/aigui'de AI hiçbir zaman sizin bilginiz veya onayınız olmadan SAP sisteminize yazmaz: plan onaya gelir, her uygulama adımı onaya gelir, kod diff olarak onaya gelir. Aynı ilke veri tarafında da geçerlidir — doğal dil sorgularında üretilen her SQL kullanıcı onayına sunulur ve AI otomatik veri silmez.

Agentic olan şey, otonomi değil kapsam: aracın tek bir soruyu yanıtlamak yerine çok adımlı bir işi baştan sona kurgulayabilmesi, bunu yaparken gerçek sisteme bakabilmesi ve her kritik eşikte durup size sorması. Karar da, sorumluluk da her adımda geliştiricide kalır.

Bu ayrımın pratik bir sonucu var: agentic bir araç, kıdemli geliştiricinin yerini almaz — onun zamanının nereye gittiğini değiştirir. Sekiz nesnenin sırasını takip etmek, SE11 ile editör arasında gidip gelmek ve şablon kod yazmak yerine, planın doğru olup olmadığına ve iş mantığının gerçekten istenen şeyi yapıp yapmadığına bakarsınız. İkincisi zaten işin asıl zor kısmıydı.

Sonuç

Bir SAP AI aracını değerlendirirken "bana bir rapor yaz" testi yanıltıcıdır, çünkü gerçek işin en kolay parçasını ölçer. Daha iyi bir test şudur: aracınıza birden fazla nesne gerektiren bir ihtiyaç tarif edin ve çıkan planın bağımlılık sırasını, sizin sisteminizdeki mevcut nesneleri tanıyıp tanımadığını ve her adımda size sorup sormadığını inceleyin.

Keşif → İnceleme → Yürütme → Uygulama döngüsünün amacı, geliştiriciyi süreçten çıkarmak değil; onu bağımlılık takibinden kurtarıp asıl karar noktalarına yerleştirmek. Eclipse ADT ve SE38'e karşı bir konum da değil bu — mdp/aigui zaten aynı ADT altyapısını kullanır ve SAP'ın standart transport, aktivasyon ve syntax denetim mekanizmalarının içinde kalır. Değişen tek şey, planın ilk taslağını kimin çıkardığı.