EDI nedir ve API çağında neden hâlâ kullanılıyor?
EDI, iki şirketin ticari belgeleri insan eli değmeden değiş tokuş etmesidir. Sipariş, irsaliye, fatura; hepsi standart bir yapıda, doğrudan sistemden sisteme.
"JSON dursun, bu ne?"
EDI'yi ilk gören her yazılımcı aynı soruyu sorar: bugün REST API yazmak varken neden 1980'lerden kalma bir metin formatı kullanılıyor?
Cevap teknik değil, ticari. Bir perakende zinciri binlerce tedarikçiyle çalışır. Her biriyle ayrı bir API konuşmak yerine tek bir standart dayatır: "bize EDIFACT ORDERS gönderin". Standart, uyum sağlama maliyetini zincirin kendisinden tedarikçiye kaydırır — ve tedarikçi için de bu maliyet, her müşteriye ayrı entegrasyon yazmaktan ucuzdur.
Asıl mesele: N×M problemi
Diyelim 500 tedarikçi ve 20 zincir var. Herkes kendi API'siyle konuşsaydı teorik olarak 10.000 ayrı entegrasyon gerekirdi. Ortak bir standart bunu 520 entegrasyona indirir: herkes yalnızca standardı bir kez öğrenir.
Bu, EDI'nin çözdüğü asıl problemdir ve teknolojiyle ilgisi yoktur. Format değişse de problem aynı kalır; nitekim Peppol gibi modern ağlar da aynı mantıkla çalışır, yalnızca sözdizimi farklıdır.
Kim kullanıyor?
- Perakende zincirleri — sipariş ve fatura akışının neredeyse tamamı. Bir
markete tedarikçi olmak istiyorsanız EDI genellikle sözleşme şartıdır.
- Otomotiv — üretim hattı beslemesi ve tam zamanında (JIT) teslimat
çağrıları. Burada gecikme doğrudan bandın durması demektir.
- Lojistik — sevkiyat talimatları, taşıma durum bildirimleri, gümrük
belgeleri.
- Sağlık ve kamu — özellikle Avrupa'da ihale ve fatura süreçleri.
Türkiye'de de büyük zincir marketlerin tedarikçilerinden EDI beklemesi yaygınlaşıyor; çoğu zaman ilk karşılaşma da böyle oluyor: müşteriden gelen bir şartname ve ekinde örnek bir dosya.
Bir EDI mesajı neye benzer?
Aşağıdaki dört satır bir siparişin başlangıcıdır:
UNB+UNOC:3+8712345678901:14+8798765432109:14+260117:1030+REF00042'
UNH+ME000001+ORDERS:D:96A:UN:EAN008'
BGM+220+PO-2026-0042+9'
NAD+BY+8798765432109::9++MEGA RETAIL AS+Barbaros Bulvari 12+ISTANBUL+34353+TR'
Okunması zor görünse de mantığı basittir. Her satır bir segment, satır başındaki üç harf ise o segmentin ne anlattığını söyler:
| Segment | Anlamı |
|---|---|
UNB | Zarf başlığı: kimden kime, ne zaman |
UNH | Mesaj başlığı: bu bir ORDERS, D.96A sürümü |
BGM | Belge numarası: PO-2026-0042 |
NAD | Taraf bilgisi: BY alıcı demek |
Segmentlerin içi + ile veri elemanlarına, elemanlar da gerektiğinde : ile alt parçalara bölünür. Yapının tamamı budur; geri kalanı hangi kodun ne anlama geldiğini bilmekten ibarettir.
Peki gerçekten eski mi?
Format eski, mantık değil. EDI'nin çözdüğü problem — iki bağımsız sistemin ortak bir sözlükle anlaşması — bugün de aynı.
Üstelik bu standart onlarca yıldır kararlı. 2005'te yazılmış bir entegrasyon bugün hâlâ çalışıyor olabilir. API dünyasında bu cümle nadiren kurulur; sürüm yükseltmeleri, kaldırılan uç noktalar ve değişen kimlik doğrulama şemaları gündelik iştir. EDI'de "çalışıyorsa dokunma" gerçekten mümkündür.
Formatın maliyeti ise okunabilirlik. Sıkıştırılmış, insana göre tasarlanmamış bir sözdizimi bu; hata ayıklarken doğru araca ihtiyaç duymanızın nedeni de bu.
EDI ile API birlikte nasıl yaşıyor?
Pratikte ikisi bir arada bulunur. Yaygın kurulum şöyledir:
- İç sistemler kendi aralarında JSON konuşur
- Dış dünyaya açılan sınırda bir dönüştürücü katman durur
- Bu katman giden veriyi EDIFACT'e, gelen EDIFACT'i JSON'a çevirir
Yani EDI çoğu zaman uygulamanın içine değil, kenarına yerleşir. Bu ayrım önemlidir: iş mantığınızı EDI segmentleri üzerine kurmak yerine, kendi veri modelinizi koruyup sınırda çeviri yapmak uzun vadede daha az acı verir.
Nereden başlamalı
Karşınıza bir EDI dosyası geldiyse sıra şudur:
1. Dosyayı okuyabilir hale getirin. Hangi mesaj tipi, hangi taraflar, hangi kalemler? Bu adım entegrasyona girişmeden önce yapılmalıdır. 2. Ortağınızın şartnamesini isteyin. EDIFACT geniştir; her ortak alt kümesini ve zorunlu alanlarını kendi belgesinde tanımlar. Standart tek başına yeterli değildir. 3. Örnek dosyayla şartnameyi karşılaştırın. Şartnamede zorunlu denen bir alan örnekte boşsa, bu genellikle sizin değil şartnamenin eskimiş olduğunun işaretidir; sormak zaman kazandırır. 4. Sonra kod yazın. Ayrıştırıcıyı kendiniz yazmadan önce, elinizdeki dosyanın gerçekten ne içerdiğini görmüş olun.
İlk adım için tarayıcıda çalışan bir görüntüleyici yeterlidir; dosyayı hiçbir yere yüklemeden segmentlerin ne anlama geldiğini görebilirsiniz.