Az XML-en és a JDF-en túl: a következő lépés

Míg az XML és a JDF képezi a nyomtatási automatizálás alapját, újabb újabb formátumok jelennek meg, amelyek még hatékonyabbá tehetik a nyomtatók adatátvitelét.

A nyomtatási automatizálás folyamataiban használt szabványokat és fájlformátumokat ismertető sorozatunkban az XML-t és az XML szektorspecifikusabb változatát – a JDF-et és az újabb XJDF-et – vizsgáltuk. Vannak azonban más lehetőségek is, amelyek vagy kinőttek ezekből a formátumokból, vagy alternatívát kínálnak ezekhez a formátumokhoz.

Ezek közül az első a PrintTalk: a CIP4 (Nemzetközi Együttműködés a Folyamatok Integrálása Nyomdai előkészítésben, Nyomtatásban és Nyomtatás után) által kezelt rendszer. A CIP4 szerint a PrintTalk egy olyan közösségből nőtt ki, amelyet „nyomtatáskezelő rendszerek és e-kereskedelmi vállalatok alkottak, hogy meghatározzák a „legjobb gyakorlat” közös és nyílt kommunikációs felületét a nyomtatott termékeket vásárló és azokat gyártó vállalatok között.

Gyakorlatilag a JDF, XJDF, XML és CXML használatának támogatásával és kiterjesztésével a PrintTalk létfontosságú pénzügyi adatokkal egészítheti ki a vezetői információs rendszert (MIS).

„A PrintTalk lényegében a JDF vagy XJDF körüli burkolat” – magyarázza Rainer Prosi, a CIP4 műszaki igazgatója (a fenti képen).

A PrintTalk ideális szabvány azoknak, akik web-nyomtatásra alkalmas rendszerrel rendelkeznek, amely termékeket készít vagy rendel

„De míg a JDF vagy az XJDF valójában csak gyártási információ, addig a PrintTalk olyan fogalmakat tartalmaz, mint ez egy árajánlatkérés, vagy ez egy árajánlat, vagy ez egy számlában, vagy ez egy beszerzési megrendelés.

„A PrintTalk magában foglalja az üzleti tranzakciókat, és az üzleti tranzakcióknál azt is le kell írni, hogy miről szól a tranzakció, és itt jönnek a képbe a termékleírások – jelen esetben az XJDF-től. Ideális szabvány azoknak, akiknek van web-nyomtatási rendszere, amely termékeket készít vagy rendel. A PrintTalk segítségével leírhatja a megrendelt terméket, és olyan dolgokat is megadhat, mint például, hogy milyen áron alkudtak ki. Ezt be lehet tenni a munkajegybe, és el lehet küldeni egy MIS-nek, hogy meghatározza az adott feladat feldolgozását.

Pihenj egy kicsit

A JDF vagy XJDF változatai azonban nem az egyetlen lehetőség a nyomtatók, az ügyfelek és a gyártók számára, különösen, ha az interneten keresztül kell információkat küldeni. A JDF egyik hátránya – és az áramvonalasabb XJDF létrehozásának katalizátora – az volt, hogy szinte túl sok adatot lehetett beépíteni, ami a formátumot időnként meglehetősen nehézkessé tette. Ennek ellensúlyozására létezik REST API, vagy a teljes név megadása: Reprezentatív állapotátviteli alkalmazásprogramozási felület.

Az XML és a JSON fogalmilag nagyon hasonlóak, mivel strukturált tartalom, amely lehetővé teszi kulcsértékpárok meghatározását

Egyszerűbben fogalmazva, a REST API-k a JSON formátumot használják – amely nagyjából egyenértékű az XML-lel –, hogy a kompatibilis rendszerek között meghatározott feladatokhoz magasan meghatározott adatátvitelt hozzanak létre, és az információk könnyen továbbíthatók http-n keresztül.

„Az XML és a JSON elvileg nagyon hasonló abban, hogy strukturált tartalom, amely lehetővé teszi kulcsértékpárok meghatározását. A JSON gyakorlati előnyei a webes API-környezetben az, hogy számos keretrendszer létezik „beépített” JSON-képességgel, és a JSON is valamivel tömörebb. Az XML előnyei a kiforrottabb érvényesítési eszközök” – magyarázza Rainer.

„Akkor a REST API egyszerűen a JSON elküldését jelenti http-n keresztül. Az API-k könnyebben érthetők, mert nagyon dedikáltathatja őket a szoftveréhez. Ha JDF-et vagy XJDF-et használ, akkor absztrakt elképzelése van egy termékről vagy folyamatról, de ha van API-ja, akkor egyetlen bejegyzést készíthet például a felhasználói felület minden gombjához vagy minden szövegmezőhöz.

„Tehát mondhatjuk, ez a szövegmező pontosan az API ezen részére való. Ha valaki ezt használja, nagyon könnyen láthatja, hogyan illeszkedik a termékhez. De ez azt is jelenti, hogy ha a termék tulajdonságai megváltoznak, akkor az API-nak is változnia kell. És mivel ez specifikus, ez azt jelenti, hogy minden alkalmazáshoz egyedi kódot kell írnia.”

Jó beszélgetni

Noha az API-k specifikussága rendkívül hatékony, miután beállították és meghatározott célokra tervezték, vannak hátrányai.

„Ha a gyártók saját API-val rendelkeznek a termékeikhez, az természetesen nincs szabványosítva, a szabványosítás pedig kétoldalú érme. Ha szabványosít, akkor nagyon általánosnak kell lennie, mert mindenféle használati esetet meg kell vizsgálnia” – mondja Rainer.

Bár az API-k az adott feladatra vagy folyamatra jellemzőek, az XML és a JSON közötti hasonlóság azt jelenti, hogy lehetséges a formátumok közötti kompatibilitás.

"Aki azonban integrálni akar egy API-val, az csak az adott helyzetre teszi ezt, és be van zárva. Például, ha egy nyomtató meg akarja változtatni egy nyomdai előkészítési rendszer szállítóját, és a nyomtató a nyomdai előkészítési rendszer REST API-ját használja, akkor el kell dobnia mindent, amit a munkafolyamat beállításához tett, és újra kell kezdenie a nulláról."

Bár az API-k az adott feladatra vagy folyamatra jellemzőek, az XML és a JSON közötti hasonlóság azt jelenti, hogy lehetséges a formátumok közötti kompatibilitás, és a CIP4 jelenleg egy fordítóeszközön dolgozik.

„Elég egyszerű az XML lefordítása JSON-ra és vissza – van néhány figyelmeztetés, de általában meglehetősen egyszerű” – mondja Rainer.

„Amin a CIP4 dolgozik, az az XJDF egyenkénti fordítása JSON-ra, hogy a lehető legjobb keveréket kapja a két lehetséges világból. Létrehozhat REST API-kat, de ezek ezután szabványosítva lesznek, így nincs bezárva ugyanahhoz a berendezésgyártóhoz.

„Természetesen a gyártók szeretik, ha bezárhatják vásárlóikat; az ügyfelek nem. Így aztán jönnek az üzleti döntések, mert az ügyfeleknek el kell menniük a szállítóikhoz, és azt kell mondaniuk, hogy szabványokat és nagyobb rugalmasságot akarnak. Az a kérdés, hogy a gyártók valóban támogatják-e ezt… nos, ez a történet következő állomása!”