Talep hep aynı cümleyle geliyor: “Bu raporu her akşam dosya olarak alıp karşı tarafın SFTP’sine bırakalım.” Cümle makul duruyor ve genellikle sorgulanmadan kabul ediliyor.
Oysa cümle bir tasarım kararını çoktan vermiş: aktarım protokolünü. Dosyanın hangi biçimde, hangi adla ve kimin sorumluluğunda üretileceği ise daha önce gelir. Protokolle başlayan projeler, üretim tarafı belirsiz kaldığı için devreye alma haftasında tıkanıyor.
Gerçek neden çoğu zaman şu: dosyayı üreten taraf ile taşıyan taraf farklıdır, ama talep tek bir kutu olarak yazılmıştır.
Doğrulanmış dosya isteği ne gönderir
Kapsamı net söylemek işi kolaylaştırıyor. Rapor veya iView çıktısı için doğrulanmış yol, dosyanın SAP uygulama sunucusundaki tanımlı bir dizine yazılmasıdır: hedef dizin, uygulama sunucusu, dosya adı, ayırıcı, çıktı biçimi ve bölme sayısı ayarları ERP isteğine konur.
Bu çalışma SAP tarafında bir arka plan işi başlatabilir; dönen iş adı ve numarası dosya servis kaydına yazılır. Böylece “dosya oluştu mu?” sorusunun karşılığı kullanıcı değil kayıt oluyor.
Sınır da aynı cümlenin içinde: fiziksel yazma işlemi SAP tarafındaki çalışmaya ve dizin izinlerine bağlıdır. İstek gönderilmiştir; dizine yazılıp yazılmadığını hedef sistem söyler.
Dosya adı, tüketen tarafla yapılan sözleşme
Dosya adları tanımlı bir eklentiyle tarih ve saat gibi dinamik parçalar alabilir. Küçük bir ayrıntı gibi görünür; oysa adlandırma düzeni dosyayı okuyan tarafın sözleşmesidir. Karşı sistem belirli bir kalıp bekliyorsa bunu baştan sabitlemek gerekiyor.
Büyük çıktılar bölünebildiği için bölme davranışını da aynı kararın parçası saymalı. Bir de biçim sorusu var: dosyayı insan mı okuyacak, sistem mi? Sistem okuyacaksa ayırıcı ve karakter kümesi üzerinde anlaşmak, biçim seçmekten daha belirleyici.
FTP/SFTP beklentisini nereye koymalı
Sunucudan sunucuya aktarıma gelince: bunu ürün içi bir dosya aktarım motoru varsayarak planlamayın. Yardım metinlerinde anlatılan FTP/SFTP akışını doğrulayan bir uygulama kodu bulunmadığı için biz de bunu bir ürün işlevi olarak sunmuyoruz.
Pratikte iki yol kalıyor:
- E-posta eki. Çıktı PDF, XLSX, CSV veya HTML eki olarak tanımlı alıcı gruplarına gönderilir.
- SAP-local dizin. Dosya uygulama sunucusundaki dizine yazdırılır; taşıma işi kurumun mevcut dosya aktarım altyapısında kalır.
İkinci yolda sorumluluk sınırını proje başında yazmak gerekiyor: dosyayı kim üretiyor, kim taşıyor, eksik dosyayı kim fark ediyor?
Üretim görev olarak da çalıştırılabildiği için, gece oluşmayan bir dosyayı sabah kullanıcıdan değil kayıttan öğrenmek mümkün. Pratikte en çok işe yarayan alışkanlık ise şu: dosya adına tarih koymak ve hedef dizinde beklenen dosyanın varlığını kontrol eden bir gözden geçirme adımı tanımlamak. Bu adım olmadan, oluşmayan dosyayı fark eden ilk kişi genellikle onu bekleyen taraf oluyor.
Bir sonraki adım için somut bir öneri: elinizdeki dosya taleplerinden birini alın ve tek satırda üçe bölün — kim üretecek, kim taşıyacak, kim kontrol edecek? Bu ayrımı birlikte yapmak, çoğu dosya projesinde ilk toplantının konusu olmalı.