Devreye alma toplantısında sorulan soru genelde teknik değildir: “Yanlış giden satırları kim düzeltecek?”
SAP’den veri okumak alıştığımız yön. Okurken yanlış alanı seçerseniz kötü bir rapor elde edersiniz; sonucu kimse kullanmaz ve iş orada kapanır. Yazarken yanlış alanı seçerseniz SAP tarafında düzeltilmesi gereken kayıtlar oluşur ve bu iş artık veri ekibinin değil, süreç sahibinin masasındadır.
Bu yüzden haricî bir SQL kaynağından SAP’ye yazan bir projeyi planlarken üç şeyi baştan yazmak gerekir: eşlemenin nasıl doğrulanacağı, bir paket hata verdiğinde hedefte ne kalacağı ve ikinci çalıştırmanın güvenli olup olmadığı.
Eşleme simülasyonu, ilk paketten önce
TSAP akışında kaynak, haricî bir PostgreSQL veya Microsoft SQL Server tablosu ya da aktifleştirilmiş bir sorgu olabilir. Kaynak kolonları SAP hedef alanlarına eşlenir; alan bazında DDIC Fx formülleri uygulanabilir. Örnek veriden alan önerisi alınabilir, eşleme önizlenebilir ve dönüşüm simüle edilebilir.
Simülasyon adımı atlanabilir görünür; oysa karşılığını en çok veren adımdır. Tarih biçimi, ondalık ayırıcı ve boşluk dolgusu sorunları burada görünür, SAP’ye yazıldıktan sonra değil.
MDTAB paketleri ve hata sonrası kalan satırlar
Kaynak satırlar JDBC üzerinden paketler hâlinde okunur. Her paket JSON’a çevrilip Base64 kodlanarak SAP tarafındaki MDTAB komutuna gönderilir; hedef tablo adı, proje kimliği ve yükleme yöntemi aynı istekle taşınır. Okunan ve gönderilen satır sayısı, ilerleme ve hata ayrıntısı akış kayıtlarında durur.
Şimdi kritik cümle: bir paket hata verirse önceki paketlerde yazılmış satırlar SAP’de kalır. Uçtan uca geri alma yoktur. Bunu bir eksiklik olarak değil, planlamanız gereken bir davranış olarak okuyun. Yükleme yöntemi anahtar temelli güncelleme ise ikinci çalıştırma çoğu durumda güvenlidir; yalnızca ekleme ise mükerrer kayıt riski vardır.
Gün penceresi kullanan delta ayarı, kaynak sorguya tarih koşulu ekleyerek okunacak satırı sınırlar. Hedefte “sil ve yeniden ekle” garantisi vermez; mevcut uygulamada hedef tablo temizlenmez, satırlar güncelleme davranışıyla yazılır. Proje planındaki en yaygın yanlış varsayım da burada duruyor.
Denetim alanları ve ikinci çalıştırma
Hedef custom tabloya kullanıcı, tarih ve saat denetim alanları otomatik eklenir ve SAP tarafındaki yazma formu tarafından doldurulur. Küçük bir ayrıntı gibi görünür; oysa “bu satır ne zaman, hangi çalışmayla geldi?” sorusuna cevap veren tek yer burasıdır.
Kapsam notu: bu akışın çalışan kaynakları haricî PostgreSQL ve SQL Server tabloları, sorgular ve kullanıcı yüklemeli yerel dosyalar. “API’den okuyup SAP’ye yazalım” diye başlayan bir plan varsa hangi bileşenin okuduğunu ve hangisinin yazdığını önce netleştirin; yön belirsiz kaldığında projenin en pahalı varsayımı orada saklanır.
İlk adım için önerimiz: SAP’ye taşımak istediğiniz haricî tablonun en kritik beş alanını seçin. Küçük bir kapsamda birlikte yazalım, satırları SAP tarafında süreç sahibine gösterelim ve kararı o masada verelim.