Bir talep geldiğinde ekip iki yoldan birini seçer: tanımlayarak çözmek ya da geliştirme açmak. Karar çoğu zaman teknik gerekçeyle değil, o hafta kimin müsait olduğuna bakılarak verilir.
İki yolun da bedeli var. Geliştirme açmak, sonraki her değişikliği kaynak koda bağlar; üç ay sonra raporu kimin neden öyle yazdığını anlamak için kod okunur. Tanımla çözmek ise sınırına geldiğinde durur: ihtiyaç tanımın ifade edebileceğinden derinse projenin ortasında yön değiştirmek gerekir.
Tanımla çözülen işlerin ortak yanı
Okuma, birleştirme, filtreleme, çıktı düzeni ve dağıtım tarafında tanım genellikle yetiyor. iDataView rapor tanımı kaynağı, alanları, bağlantıları, koşulları, seçim ekranını ve çıktı düzenini kapsar; üretilen ABAP kodu SAP’ye transport isteğiyle taşınır. Aktarım projeleri alan eşlemesi, yükleme yöntemi ve paket ayarlarıyla kurulur. Servis, e-posta ve dosya çıktıları da aynı seviyede kalır.
Bu işlerin ortak yanı şu: sonuç okunabilir bir tanım olarak duruyor. Değişiklik geldiğinde kaynak koda dönmek gerekmez ve tanımı açan biri neyin neden yapıldığını görebilir. Kazanç bir hız iddiası değil; altı ay sonra o tanımı devralacak kişinin işidir.
Kodun hâlâ gerektiği dört başlık
- Karmaşık iş kuralı. Koşullu hesaplama zincirleri, istisna yönetimi ve süreç mantığı tanımın ifade edebileceğinden derinleşebilir. Ürün özel ABAP kod bloklarına, sınıf/modül ve özel dönüşüm tanımlarına yer bırakır; ama o bloğun içeriği sizin sorumluluğunuzda kalır.
- Performans ayarı. Üretilen kodun belirli bir veri hacminde nasıl davranacağı indeks ve erişim yolu kararlarıyla ilgilidir. Bu iş geliştirici ve BASIS tarafındadır; kodun üretilebilmesi performansını kanıtlamaz.
- SAP iş doğrulaması. Bir tabloya satır yazmak, o kaydın iş açısından geçerli olduğunu göstermez. Aktarım akışı hedef tabloya paketler hâlinde yazar; standart doğrulamaların çalışması gerekiyorsa BAPI/RFC yolu ve geliştirici incelemesi gerekir.
- Hata sonrası toparlama. Bir paket hata verirse ondan önce yazılmış satırlar SAP’de kalabilir. Paketler arasında uçtan uca geri alma yoktur; tekrar çalıştırma ve mutabakat senaryosunu birinin tasarlaması gerekir.
Talep hangi kutuya giriyor: tanım mı, geliştirme mi?
Sınıflandırma için üç soru pratikte yetiyor. Sonuç bir okuma mı, yoksa SAP’de kayıt oluşturma mı? Kural tek bir tanımla ifade edilebiliyor mu, yoksa istisnalar mı yönetiliyor? Beklenen veri hacmi bugünkü test verisinin kaç katı?
Üçüncüsü en çok atlanan soru. Test verisinde sorunsuz çalışan bir tanım üretim hacminde farklı davranabilir; bu farkı projenin başında konuşmak, ortasında keşfetmekten iyidir.
Buradan çıkan sonuç net: düşük kodlu yaklaşım ABAP geliştirici veya BASIS ihtiyacını ortadan kaldırmıyor. Değiştirdiği şey iş bölümü — tekrarlayan tanım işleri ürün akışına giriyor, geliştirici zamanı gerçekten kod isteyen kısma kalıyor. Bekleyen taleplerinizden beşini alıp bu üç soruyla ayırın; hangi kutunun beklediğinizden dolu çıktığını görmek, kapasite planını konuşmak için iyi bir başlangıçtır.