“Eşleme tamam, ne zaman yazmaya başlıyoruz?” Bu soruya verilen cevap çoğu projede aynı: yazacağımız tablo henüz yok.
Haricî veriyi SAP’ye taşıyan projelerde ilk gerçek engel genellikle alan eşlemesi değil, hedef tablonun kendisidir. Tablo yoktur; olması için bir yapı kararı, bir veri öğesi seti, bir aktivasyon ve bir transport isteği gerekir. Bu adım atlandığında proje “eşlemeyi yaptık ama yazamıyoruz” noktasında bekler.
Bekleme teknik bir gecikme gibi görünür; gerçekte bir sahiplik sorunudur. Tabloyu kim tanımlayacak, hangi paketle gidecek, isteği kim onaylayacak? Bu üç soru cevaplanmadan eşleme ekranındaki hiçbir ilerleme sonuç üretmez.
YTIDX adı, 16 karakter ve veri öğesi seçimi
DDIC yönetimi bu işi bir sihirbazla yürütür. Örnek veriden veya kaynak alanlardan bir SAP tablo yapısı önerilir. Ardından alan adı, veri tipi, uzunluk, ondalık, anahtar, zorunluluk, varsayılan değer ve veri öğesi tanımlanır; mevcut veri öğesi SAP kataloğundan seçilebilir ya da yenisi oluşturulabilir.
Adlandırma tarafında iki sınır baştan bilinmeli: hedef tablo adı YTIDX ön ekiyle başlar ve en çok 16 karakter olur. Tasarım custom tablolar etrafında kuruludur; standart SAP iş tablolarına serbest yazma bu akışın iddiası değildir.
Aktivasyon ve transport adımı SAP standardında kalır
Tablonun oluşturulması ve güncellenmesi DDIF_TABL_PUT, paket ilişkilendirmesi TADIR arayüzü, aktivasyon DDIF_TABL_ACTIVATE ve silme RS_DD_DELETE_OBJ üzerinden yürür. Bunlar SAP standardı fonksiyonlardır; buradaki katkı, aynı adımların bir proje akışı içinde sırayla çağrılması ve sonucun kaydedilmesidir.
Açık transport istekleri listelenir, isteğin değiştirilebilir durumda olduğu doğrulanır ve gerekirse yenisi oluşturulur. Silme veya yeniden oluşturma öncesinde tabloda veri bulunup bulunmadığı kontrol edilir. Bu kontrol rahatlatıcıdır ama değişiklik prosedürünüzün yerine geçmez; yıkıcı işlemleri üretim sisteminde kendi onay akışınız dışında çalıştırmayın.
Kullanıcı, tarih ve saat denetim alanları tabloya son sıralara otomatik eklenir ve standart veri öğelerini kullanır.
Metin alanı uzunluğunu sözleşmeye göre seçmek
Hedef tablo bir kez oluşturulup veri aldıktan sonra alan adını veya tipini değiştirmek ucuz değildir. Bu yüzden ilk turda üç şeyi karara bağlamak gerekir: anahtar alan kümesi, tarih ve saat alanlarının tipi, metin alanlarının uzunluğu.
Uzunluk seçiminde işe yarayan ölçüt şudur: kaynaktaki bugünkü en uzun değer değil, kaynağın sözleşmedeki sınırı. Bugün on karakterlik bir müşteri kodu yarın on iki karakter olabilir; tanımı sözleşme sınırına göre kurmak daha az kırılgan bir tablo üretir. Kaynak yapı değiştiğinde SAP alan kataloğunu yeniden okuyup yerel tanımla eşitlemek de mümkündür.
Somut bir başlangıç önerimiz var: hedef tabloyu oluşturmadan önce alan listesini ve anahtar kümesini tek sayfaya çıkarın, SAP ekibiyle yarım saatlik bir oturumda gözden geçirin. Aktivasyondan sonra yapılan her düzeltme, o yarım saatten fazlasını istiyor.