XJDF ve CIP4 Standartlari

NowToPrint baski operasyonlarini CIP4 diliyle tanimlar. Burada standartlarin rolu veriyi depolamak degil, verinin nasil tanimlanacagini, paylasilacagini ve mesajlasacagini belirlemektir.

---

Standartlarin rolleri

Standart	Rol	NowToPrint kullanimi
XJDF 2.2	Is tanimi ve kaynak semantigi	Kanonik master data, job intent ve snapshot modeli
XJMF	Operasyonel mesajlasma	Harici status ve komut siniri
PrintTalk 2.2	Ticari mesajlasma	RFQ, teklif, siparis ve onay akislari
JDF/JMF	Legacy interoperability	Sadece connector edge, asla ic cekirdek degil

---

Master data neden bu kadar kritik

XJDF uyumlulugu sadece job ticket gondermek demek degildir. Asil deger, master data semantiginin standarda uygun tasarlanmasidir.

NowToPrint'te temel model sunudur:

• generic class
• branded product
• supplier/source
• organization override veya installed asset
• immutable job snapshot

Bu sayede sistem ayni medya veya makineyi hem global standart dilde hem de tenant gercegine uygun bicimde kullanabilir.

Kanonik admin ve API kategori sozlugu de bu modele gore normalize edilir:

• media-types
• devices
• plates

Legacy papers, machines ve ctp isimleri yalnizca request sinirinda alias olarak kabul edilir; response ve cache yuzeylerinde kanonik adlar kullanilir.

---

Compatibility ve installed asset truth

2026 itibariyla NowToPrint su kurallari uygular:

• media-device compatibility matrix karar mekanizmasinin bir parcasi olarak ele alinir
• routing ve costing ayni installed machine truth'una bakar
• unsupported veya dogrulanamayan durumlar confidence dusurur ya da manual review gerektirir
• sistem emin olmadigi durumda sessizce kesin fiyat vermez

Bu yaklasim XJDF uyumlulugunu sadece schema seviyesinde degil, gercek operasyon mantigi seviyesinde de guclendirir.

---

PrintTalk ve XJMF siniri

PrintTalk ve XJMF yuzeylerinde en kritik kural vocabulary ayrimidir.

• PrintTalk = ticari belge dili
• external XJMF = harici olay ve durum dili
• internal workflow stage = platform ici olay dili
• PrintTalk audit stream ve XJMF signal stream ayri tutulur

Ic workflow stage'lerini dis Status alani icine yazmak interoperability'yi bozar. Bu nedenle NowToPrint bu iki dili ayri tutar.

---

ICS yaklasimi

NowToPrint ICS'i bir pazarlama etiketi olarak degil, birlikte calisabilirlik hedefi olarak ele alir.

Pratikte bu su anlama gelir:

• schema uyumu tek basina yeterli degildir
• export/import yuzeyleri kanonik modelle ayni semantigi tasimalidir
• unsupported alanlar sessizce yutulmaz
• review ve manual override durumlari audit edilebilir kalir

---

Adapter capability reporting

Legacy DFE entegrasyonlarinda asıl risk schema uyumu var sanilip sessiz field kaybina dusmektir. Bu nedenle connector katmani artik iki seviyeli rapor uretir:

• ham unsupportedFields listesi
• kanonik adapterCapabilityReport profili
• structured unsupportedFieldDetails listesi

Bu rapor su sorulara tek cevap verir:

• bu connector native XJDF/XJMF mi konusuyor yoksa bridge mi kullaniyor
• hedef format JDF 1.7 mi, vendor API mi
• vendor extension uygulanabiliyor mu
• hangi alanlar tamamen unsupported
• hangi alanlar vendor extension ile map ediliyor
• hangi durumda manual review zorunlu

Fiery, Konica Minolta ve PRISMAsync wrapper'lari ayni capability diliyle rapor verir. Uretim gonderim servisi de bu profili yukari katmanlara aynen tasir; boylece operasyon, maliyet ve audit ekipleri ayni interoperability truth'unu gorur.

GET /api/v1/xjdf/devices/{deviceId}/capabilities yaniti da artik adapterCapabilityReport alanini tasir. Boylece admin ve dashboard katmanlari cihazin yalniz XJDF capability bilgisini degil, bridge gerektirip gerektirmedigini de gorebilir.

/dashboard/print-shop/settings/equipment kartlari da ayni profili artik ekipman seviyesinde gosterir. Operator, bir cihazin Bridge, Vendor API veya gelecekte Native XJDF/XJMF yolunda olup olmadigini; hangi transport'u kullandigini ve vendor extension'a dayanip dayanmadigini UI uzerinden gorebilir.

Bu equipment-level gorunum, job-level unsupported-field raporunun yerine gecmez. unsupportedFieldDetails ve manual-review gereksinimi halen yalnizca gercek submit / conversion aninda dolu kabul edilir; dashboard karti ise baglanti mimarisinin baz profilini gosterir.

POST /api/production/jobs/submit-dfe akisi artik bu job-level gercegi de kalici hale getirir. Submit sonrasi productionQueue/{orgId}/jobs/{jobId} kaydi dfeSubmission snapshot'ini; bagli platform_orders kaydi ise xjdfAdapterReview snapshot'ini alir. Boylece workflow review queue, adapter bridge kaynakli manual-review gereksinimini yalniz connector log'unda degil, order truth icinde de gorebilir. Review queue karti ayni snapshot'tan DFE job kimligini ve Bridge/Native adapter yolunu da yuzeye tasir.

Queue tarafindaki JobSubmitDialog da artik ayni canonical adapter truth ile calisir. Dialog sadece pending durumundaki ve henuz productionQueue icinde aktif job'a donusmemis siparisleri submission-ready aday olarak sunar; DFE submit basarili oldugunda ise machineJobId, Bridge/Native adapter yolu, manual-review gereksinimi ve unsupported-field / warning sayisini ayni modal icinde operatora gosterir. Boylece direct-submit akisi, review queue'yu beklemeden daha ilk anda interoperability riskini gorunur hale getirir.

Bu submit siniri artik guvenlik ve provenance tarafinda da daha serttir:

• submit-dfe ve device capability route'lari aktif organization uyeligi ve rol tabanli yetki kontrolu olmadan kritik uretim aksiyonlarini kabul etmez
• DFE submit basarili ama warningsiz olsa bile dfeSubmission snapshot'i kalici olarak yazilir; yani audit izi artik yalniz sorun durumlarinda degil her submit'te olusur
• Fiery connector config'i explicit override yoksa TLS varsayar; production bridge katmani artik 443 + TLS cizgisini canonical default kabul eder
• job-level XJDF uretimi ProcessSet, GeneralID, product-level kimlikler ve media-resource cozumleme ile daha zengin bir canonical payload uretir; basliktan heuristik cikarim tek sinyal olmaktan cikar

---

Ilgili rehberler