Insights
CCM
Här är avvägningen gällande Zebra-utskrifter som du behöver känna till.
OpenText Exstream on-premise stöder Zebra (ZPL) etikettutskrift. Molnversionen Communications gör det inte. Om Zebra-utskrifter är en del av din process, planera för detta innan du migrerar.
OpenText Exstream är en kapabel CCM-plattform. On-premise-installationer har en lång historia av att stödja ZPL-utskrift – språket som driver Zebras termiska skrivare – som en del av en bred portfölj av utskriftskanaler. Etiketter för lager, utskick, kliniska miljöer, produktionsgolv: on-premise-stacken kan hantera det.
Molnversionen är en annan historia. ZPL-utskrift stöds inte. Om din organisation förlitar sig på Zebra-etikettutskrift som en del av din dokument- eller kommunikationsprocess, följer den funktionen inte med dig när du flyttar till OpenText Communications.
Detta är ingen liten fotnot. För organisationer där etikettutskrift är operativt betydelsefullt är det en lucka som kräver en plan innan migreringen påbörjas – inte efter.
Varför detta upptäcks sent i migrationsprojekt
Etikettutskrift tenderar att ägas av driftavdelningen, inte av teamet som definierar CCM-migreringen. CCM-arbetsströmmen fokuserar på kundriktad utskrift: brev, kontoutdrag, fakturor, digital leverans. Etiketter ses som en logistikfråga, hanteras av ett separat team, ofta körs på infrastruktur som helt föregår CCM-plattformen.
Resultatet är att ZPL-funktionaliteten kartläggs som en befintlig funktion i Exstream on-premise, molnversionen utvärderas utifrån de dokumentutskriftsdimensioner som är viktigast för projektteamet, och luckan i etikettutskriften upptäcks sent – ibland efter att planeringen för driftsättning redan har påbörjats.
Vid den tidpunkten tenderar alternativen att vara obekväma: försena migreringen, investera i ett separat system för etiketthantering, eller acceptera en manuell lösning som återinför den operativa komplexitet du försökte eliminera.
Vad luckan faktiskt innebär för din arkitektur
ZPL (Zebra Programming Language) är standarden för termisk etikettutskrift. Det hanterar allt en etikettprocess kräver: variabla textfält, adressblock, partinummer, utgångsdatum, efterlevnadsidentifierare, logotyper, grafiska layoutelement, och – kritiskt – streckkoder och QR-koder som genereras direkt på skrivarhårdvaran.
När din CCM-plattform inte längre kan producera ZPL, händer typiskt sett en av tre saker:
- Etikettprocessen kopplas helt bort från CCM-lagret och överlämnas till ett fristående system för etiketthantering – vilket innebär att data, logik och integrationsarbete dupliceras.
- En utvecklare bygger en anpassad ZPL-generator som ligger utanför plattformen – vilket fungerar tills det inte gör det, och blir en underhållsbörda.
- Etikettkravet nedprioriteras eller hanteras manuellt – vilket sällan är hållbart vid operativ volym.
Inget av dessa är en bra lösning. Den rätta lösningen är att täppa till luckan på integrationslagret, med hjälp av ett verktyg som är specialbyggt för denna typ av processorkestrering.
Hur ENIT Flowbuilder täpper till luckan
ENIT Flowbuilder är en low-code integrationsplattform designad för just denna typ av processorkestrering. Den är inte begränsad till en specifik utskriftstyp – den kan konsumera strukturerad data från vilken källa som helst och dirigera den till vilken utskriftskanal som helst, inklusive en korrekt formulerad ZPL-ström som skickas direkt till en Zebra-skrivare eller en slutpunkt för etiketthantering.
För etikettgenerering hanterar ett Flowbuilder-flöde hela kravet:
- Textfält fyllda med källdata – namn, adresser, produktkoder, batchreferenser, utgångsdatum.
- Grafiska element och etikettlayoutstrukturer
- Bilder — logotyper, efterlevnadsikoner, produktbilder — med korrekt upplösning för termisk utskrift
- Streckkoder och QR-koder: Code 128, EAN-13, DataMatrix, QR och andra vanliga standarder
- Välformulerad ZPL-utdata, redo för direkt utskrift eller vidarebefordran nedströms
Avgörande är att detta inte kräver att man ersätter opentext. Arkitekturen är additiv: Communications cloud fortsätter att hantera kundriktad dokumentutskrift, och Flowbuilder hanterar de kanaler som molnversionen inte når. Båda hämtar data från samma uppströms datahändelse. Gapet för etikettgenerering stängs utan att införa en ny silo eller en parallell CCM-investering.
Migrationssamtalet värt att ha tidigt
Om din organisation utvärderar en flytt från Exstream on-premise till molnversionen — eller om du redan är i processen — är frågan om etikettutskrift värd att ta upp nu. Frågorna att ställa:
- Vilka affärsprocesser är för närvarande beroende av ZPL-utdata från Exstream on-premise?
- Är dessa processer verksamhetskritiska, eller har de tillräckligt låg volym för att hanteras annorlunda?
- Vad är datakällan för etikettgenerering — och flödar den redan genom ditt integrationslager?
- Hur ser en smidig överlämning av etikettansvaret ut, och vem äger det efter migreringen?
Att få dessa svar innan migrationsplaneringen är klar är betydligt billigare än att upptäcka bristen under UAT.
Den bredare poängen för arkitekter och processägare
Molnmigreringar av företags CCM-plattformar är inte enkla lyft funktion för funktion. Funktioner som finns i den lokala stacken — utdatakanaler, drivrutinsstöd, integrationsmönster — kanske inte finns i molnversionen, och dokumentationen gör inte alltid detta uppenbart.
ZPL-stöd i opentext Exstream är ett specifikt exempel. Principen generaliseras: innan du förbinder dig till en moln-CCM-migrering, mappa dina nuvarande utdatakanaler mot molnplattformens faktiska kapacitet, inte dess marknadsföringsmaterial.
Där luckor finns är de lösbara — men de måste lösas på arkitekturnivå, med rätt verktyg på plats, innan migreringen är klar. Att eftermontera utdatakapacitet efter driftsättning är alltid dyrare än att planera för det.
ENIT Flowbuilder är en del av det svaret. Om du arbetar med detta för opentext, Quadient, Smart Communications eller någon annan CCM-plattform, går vi gärna igenom hur det ser ut för din specifika miljö.
