XJDF ve CIP4 Standartları

NowToPrint baskı operasyonlarını CIP4 diliyle tanımlar. Burada standartların rolü veriyi depolamak değil, verinin nasıl tanımlanacağını, paylaşılacağını ve mesajlaşacağını belirlemektir.

---

Standartların rolleri

Standart	Rol	NowToPrint kullanımı
XJDF 2.2	İş tanımı ve kaynak semantiği	Kanonik master data, job intent ve snapshot modeli
XJMF	Operasyonel mesajlaşma	Harici status ve komut sınırı
PrintTalk 2.2	Ticari mesajlaşma	RFQ, teklif, sipariş ve onay akışları
JDF/JMF	Legacy interoperability	Sadece connector edge, asla iç çekirdek değil

---

Master data neden bu kadar kritik

XJDF uyumluluğu sadece job ticket göndermek demek değildir. Asıl değer, master data semantiğinin standarda uygun tasarlanmasıdır.

NowToPrint'te temel model şudur:

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

Bu sayede sistem aynı medya veya makineyi hem global standart dilde hem de tenant gerçeğine uygun biçimde kullanabilir.

Kanonik admin ve API kategori sözlüğü de bu modele göre normalize edilir:

• media-types
• devices
• plates

Legacy papers, machines ve ctp isimleri yalnızca request sınırında alias olarak kabul edilir; response ve cache yüzeylerinde kanonik adlar kullanılır.

---

Compatibility ve installed asset truth

2026 itibarıyla NowToPrint şu kuralları uygular:

• media-device compatibility matrix karar mekanizmasının bir parçası olarak ele alınır
• routing ve costing aynı installed machine truth'una bakar
• unsupported veya doğrulanamayan durumlar confidence düşürür ya da manual review gerektirir
• sistem emin olmadığı durumda sessizce kesin fiyat vermez

Bu yaklaşım XJDF uyumluluğunu sadece schema seviyesinde değil, gerçek operasyon mantığı seviyesinde de güçlendirir.

---

PrintTalk ve XJMF sınırı

PrintTalk ve XJMF yüzeylerinde en kritik kural vocabulary ayrımıdır.

• PrintTalk = ticari belge dili
• external XJMF = harici olay ve durum dili
• internal workflow stage = platform içi olay dili
• PrintTalk audit stream ve XJMF signal stream ayrı tutulur

İç workflow stage'lerini dış Status alanı içine yazmak interoperability'yi bozar. Bu nedenle NowToPrint bu iki dili ayrı tutar.

---

ICS yaklaşımı

NowToPrint ICS'i bir pazarlama etiketi olarak değil, birlikte çalışabilirlik hedefi olarak ele alır.

Pratikte bu şu anlama gelir:

• schema uyumu tek başına yeterli değildir
• export/import yüzeyleri kanonik modelle aynı semantiği taşımalıdır
• unsupported alanlar sessizce yutulmaz
• review ve manual override durumları audit edilebilir kalır

---

Adapter capability reporting

Legacy DFE entegrasyonlarında asıl risk schema uyumu var sanılıp sessiz field kaybına düşmektir. Bu nedenle connector katmanı artık iki seviyeli rapor üretir:

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

Bu rapor şu sorulara tek cevap verir:

• bu connector native XJDF/XJMF mi konuşuyor yoksa bridge mi kullanıyor
• 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'ları aynı capability diliyle rapor verir. Üretim gönderim servisi de bu profili yukarı katmanlara aynen taşır; böylece operasyon, maliyet ve audit ekipleri aynı interoperability truth'unu görür.

GET /api/v1/xjdf/devices/{deviceId}/capabilities yanıtı da artık adapterCapabilityReport alanını taşır. Böylece admin ve dashboard katmanları cihazın yalnız XJDF capability bilgisini değil, bridge gerektirip gerektirmediğini de görebilir.

/dashboard/print-shop/settings/equipment kartları da aynı profili artık ekipman seviyesinde gösterir. Operatör, bir cihazın Bridge, Vendor API veya gelecekte Native XJDF/XJMF yolunda olup olmadığını; hangi transport'u kullandığını ve vendor extension'a dayanıp dayanmadığını UI üzerinden görebilir.

Bu equipment-level görünüm, job-level unsupported-field raporunun yerine geçmez. unsupportedFieldDetails ve manual-review gereksinimi hâlen yalnızca gerçek submit / conversion anında dolu kabul edilir; dashboard kartı ise bağlantı mimarisinin baz profilini gösterir.

POST /api/production/jobs/submit-dfe akışı artık bu job-level gerçeği de kalıcı hale getirir. Submit sonrası productionQueue/{orgId}/jobs/{jobId} kaydı dfeSubmission snapshot'ını; bağlı platform_orders kaydı ise xjdfAdapterReview snapshot'ını alır. Böylece workflow review queue, adapter bridge kaynaklı manual-review gereksinimini yalnız connector log'unda değil, order truth içinde de görebilir. Review queue kartı aynı snapshot'tan DFE job kimliğini ve Bridge/Native adapter yolunu da yüzeye taşır.

Queue tarafındaki JobSubmitDialog da artık aynı canonical adapter truth ile çalışır. Dialog sadece pending durumundaki ve henüz productionQueue içinde aktif job'a dönüşmemiş siparişleri submission-ready aday olarak sunar; DFE submit başarılı olduğunda ise machineJobId, Bridge/Native adapter yolu, manual-review gereksinimi ve unsupported-field / warning sayısını aynı modal içinde operatöre gösterir. Böylece direct-submit akışı, review queue'yu beklemeden daha ilk anda interoperability riskini görünür hale getirir.

Bu submit sınırı artık güvenlik ve provenance tarafında da daha serttir:

• submit-dfe ve device capability route'ları aktif organization üyeliği ve rol tabanlı yetki kontrolü olmadan kritik üretim aksiyonlarını kabul etmez
• DFE submit başarılı ama uyarısız olsa bile dfeSubmission snapshot'ı kalıcı olarak yazılır; yani audit izi artık yalnız sorun durumlarında değil her submit'te oluşur
• Fiery connector config'i explicit override yoksa TLS varsayar; production bridge katmanı artık 443 + TLS çizgisini canonical default kabul eder
• job-level XJDF üretimi ProcessSet, GeneralID, product-level kimlikler ve media-resource çözümleme ile daha zengin bir canonical payload üretir; başlıktan heuristik çıkarım tek sinyal olmaktan çıkar

---

İlgili rehberler