zplCloud Blog
Azure Service Bus के साथ लेबल प्रिंटिंग: कतार ट्रिगर के रूप में
दो पेलोड रूप, एक कतार: डिज़ाइन भरने वाला JSON रिकॉर्ड या लिफ़ाफ़े में रॉ ZPL। PeekLock के कारण न कुछ खोता है, न कुछ दो बार प्रिंट होता है।
कतार पहले से ट्रिगर है
यदि आपके सिस्टम पहले से Azure Service Bus पर बात करते हैं, तो प्रिंट कार्य किसी भी अन्य संदेश जैसा है। Service Bus प्रकार का Data Streaming सब्सक्रिप्शन कतार या टॉपिक सब्सक्रिप्शन खपाता है और हर संदेश प्रिंट करता है - कोई पोलिंग कार्य नहीं, कोई प्रिंट मिडलवेयर नहीं, बस और प्रिंटर के बीच कोई Windows प्रिंट सर्वर नहीं।
दिलचस्प हिस्सा यह है कि एक संदेश दो चीज़ों में से एक हो सकता है, और zplCloud प्रति संदेश निर्णय करता है:
- एक JSON रिकॉर्ड - ऑब्जेक्ट कुंजियाँ लेबल डिज़ाइन की बाइंडिंग भरती हैं। जब प्रेषक डेटा जानता है, लेआउट नहीं, तो यह उपयोग करें।
- एक ZPL लिफ़ाफ़ा - तैयार ZPL ले जाने वाला JSON ऑब्जेक्ट। जब प्रेषक पहले से ZPL उत्पन्न करता है और बस उसे प्रिंटर पर चाहता है, तो यह उपयोग करें।
दोनों उसी सब्सक्रिप्शन से गुजरते हैं; आप मोड कॉन्फ़िगर नहीं करते।
सब्सक्रिप्शन सेट करना
| फ़ील्ड | मान |
|---|---|
| प्रकार | Service Bus |
| कनेक्शन कॉन्फ़िग | नेमस्पेस कनेक्शन स्ट्रिंग |
| टॉपिक | कतार नाम, या topic/Subscriptions/subscriptionName |
| लेबल डिज़ाइन | JSON रिकॉर्ड के लिए उपयोग किया जाने वाला डिज़ाइन |
| प्रिंटर | डिफ़ॉल्ट लक्ष्य प्रिंटर |
कनेक्शन स्ट्रिंग आराम पर AES-एन्क्रिप्टेड संग्रहीत होती है।
कतार या टॉपिक Topic फ़ील्ड द्वारा परंपरा से तय होता है: यदि मान में /Subscriptions/ है, तो इसे topic/Subscriptions/subscriptionName माना जाता है; अन्यथा यह कतार नाम है। आप इसे खाली भी छोड़ सकते हैं और कनेक्शन स्ट्रिंग में EntityPath=printer डाल सकते हैं।
सब्सक्रिप्शन स्वचालित रूप से नहीं बनते। पोर्टल, Service Bus Explorer या एमुलेटर में एक बार टॉपिक सब्सक्रिप्शन बनाएँ (topic.1/Subscriptions/subscription.1); zplCloud केवल इसे खपाता है।
Kafka इंटीग्रेशन के विपरीत, Service Bus केवल क्लाउड-साइड चलता है - उपभोक्ता बैकएंड में रहता है और आउटबाउंड कनेक्ट होता है। कोई ऑन-प्रिम एजेंट संस्करण नहीं है, क्योंकि Service Bus नेमस्पेस वैसे भी इंटरनेट से पहुँच योग्य है।
पेलोड A - डिज़ाइन के लिए JSON रिकॉर्ड
{ "ean": "4006381333930", "qty": 2, "dest": "Ramp 4" }
कुंजियाँ नाम से डिज़ाइन की बाइंडिंग से मेल खाती हैं। बिना बाइंडिंग वाली कुंजियाँ अनदेखी होती हैं; बिना कुंजी वाली बाइंडिंग खाली रेंडर होती हैं।
यदि बॉडी बिल्कुल JSON नहीं है, तो पूरा टेक्स्ट $message के रूप में बंधा होता है - एकल-फ़ील्ड लेबल के लिए पर्याप्त।
रेंडर त्रुटि आपको SDK संदेश देने के बजाय कारण फ़ील्ड का नाम देती है:
ZPL-Renderfehler bei qty: Wert 'zwei' → ...
वह आमतौर पर प्रकार या लंबाई समस्या है: संख्यात्मक फ़ील्ड को शब्द खिलाया गया, या मान फ़ील्ड की क्षमता से लंबा।
पेलोड B - लिफ़ाफ़े में रॉ ZPL
जब प्रेषक के पास पहले से ZPL है, उसे लपेटें:
{
"schemaVersion": 1,
"zpl": "^XA^FO50,50^A0N,40,40^FDFrom the bus^FS^XZ",
"printer": "*"
}
इसे लिफ़ाफ़ा मानने के नियम जानबूझकर सख्त हैं:
- बॉडी JSON ऑब्जेक्ट होना चाहिए,
- उसमें
zplगुण होना चाहिए जो गैर-रिक्त स्ट्रिंग हो, - और उसे अतिरिक्त रूप से
printer(स्ट्रिंग) याschemaVersion(संख्या) ले जाना चाहिए।
आखिरी शर्त महत्वपूर्ण है। एक सादा डेटा रिकॉर्ड जिसमें संयोग से zpl नाम का फ़ील्ड हो, उसे नहीं हाईजैक करके रॉ प्रिंटर को नहीं भेजा जाता - वह अभी भी डिज़ाइन पथ से गुजरता है। यदि आप लिफ़ाफ़ा व्यवहार चाहते हैं, तो printer या schemaVersion के साथ स्पष्ट रूप से कहें।
लिफ़ाफ़ा मोड में डिज़ाइन बिल्कुल नहीं छुआ जाता: ZPL प्रिंटर पर बाइट-दर-बाइट जाता है।
प्रति संदेश प्रिंटर चुनना
लिफ़ाफ़े का printer उस संदेश के लिए सब्सक्रिप्शन के प्रिंटर को ओवरराइड करता है। दो संतरी प्रसारित करते हैं:
"*"या"all"- workspace में हर प्रिंटर, Weblink और रिमोट एजेंट प्रिंटर समान रूप से।
प्रत्येक लक्ष्य आपके कोटा के विरुद्ध अपना लेबल गिना जाता है, इसलिए आठ प्रिंटरों पर प्रसारण आठ लेबल है। यह शिफ्ट-परिवर्तन सूचना के लिए सही मॉडल है; प्रति-ऑर्डर लेबल के लिए यह महंगी गलती है।
डिलीवरी सेमेंटिक्स: PeekLock, और प्रिंट विफल होने पर क्या होता है
यह वह जगह है जहाँ कतार इंटीग्रेशन भरोसेमंद है या नहीं। रिसीवर PeekLock मोड में PrefetchCount = 0 के साथ चलता है - प्राप्त करना हटाना नहीं है, और प्रक्रिया में कोई संदेश बफ़र नहीं होता, इसलिए सब्सक्रिप्शन को रोकना या पुनः आरंभ करना कभी बैच को निगलता या दोहराता नहीं है।
| परिणाम | संदेश का क्या होता है |
|---|---|
| प्रिंटेड | Complete - संदेश बस छोड़ देता है |
| प्रिंट विफल, डिलीवरी < 3 | Abandon - पुनः वितरित, फिर अगली प्राप्ति से पहले 10 s बैकऑफ़ |
| प्रिंट विफल, डिलीवरी ≥ 3 | कारण Print-Fehler (MaxDeliveryCount erreicht) और विवरण के रूप में त्रुटि के साथ डेड-लेटर |
दो परिणाम स्पष्ट रूप से कहने लायक:
- प्रिंट विफलता उपभोक्ता को नहीं रोकती। Kafka पथ के विपरीत, सब्सक्रिप्शन चलता रहता है और पुनः प्रयास करता है; केवल व्यक्तिगत संदेश डेड-लेटर कतार तक बढ़ता है।
- सफलता का अर्थ है "बाइट्स प्रिंटर सॉकेट तक पहुँचे।" Zebra कभी ZPL लेबल स्वीकार नहीं करता, इसलिए पुष्टि की प्रतीक्षा का अर्थ होगा 20-सेकंड रुकना और डुप्लिकेट प्रिंट। भेजना सफल होते ही
Completeहोता है - डीबग कॉलम ठीक इसी मामले के लिएsent (no response)दिखाता है।
क्योंकि विफल संदेश हमेशा के लिए पुनः प्रयास करने के बजाय डेड-लेटर होते हैं, DLQ आपके उन लेबलों की कतार बन जाती है जो बाहर नहीं आए। यह एक सूची है जिस पर आप कार्य कर सकते हैं, जो पूरा मुद्दा है।
निष्क्रिय कीपालिव
यदि 60 सेकंड तक कुछ नहीं आता, तो सब्सक्रिप्शन लक्ष्य प्रिंटर को वेक कमांड भेजता है। Link-OS प्रिंटर कम-पावर स्थिति में चले जाते हैं, और इसके बिना शांत अवधि के बाद पहला संदेश वेक-अप विलंब का भुगतान करता है। कीपालिव फायर-एंड-फॉरगेट चलता है इसलिए यह प्राप्ति लूप को रोककर ढेर नहीं लगा सकता।
चलते समय आप क्या देखते हैं
प्रत्येक सब्सक्रिप्शन मान पूर्वावलोकन, प्रिंट परिणाम और एंड-टू-एंड ट्रेस के साथ अंतिम 50 संदेशों का रिंग बफ़र रखता है:
bus=12ms design=3ms zpl=18ms print=64ms total=85ms
bus एनक्यू और प्राप्ति के बीच का समय है - वह कतार की विलंबता है, आपकी नहीं। डीबग कॉलम अतिरिक्त रूप से प्रिंटर, ZPL बाइट गिनती, HTTP स्थिति और रॉ प्रतिक्रिया रिकॉर्ड करता है।
विफल संदेश स्थायी त्रुटि लॉग में भी लिखे जाते हैं, लेकिन केवल उनकी पहली डिलीवरी पर। उस गार्ड के बिना, Service Bus के अपने पुनः प्रयास उसी बुरे संदेश को तीन बार दर्ज करेंगे।
कोटा
प्रत्येक स्ट्रीम किया गया लेबल सब्सक्रिप्शन स्वामी की योजना के विरुद्ध रेंडर गिना जाता है। जब आप समाप्त होते हैं तो दो अलग संदेश दिखाई देते हैं:
Render-Limit erreicht (…/… Labels diesen Monat, Tarif …)- मासिक रेंडर बजट,Streaming-Kontingent erreicht (…)- स्ट्रीमिंग कैप विशेष रूप से।
Starter में परीक्षण के लिए स्ट्रीमिंग शामिल है, प्रति माह 100 स्ट्रीम किए गए लेबल की सीमा के साथ। Pro में 2 स्ट्रीमिंग एंडपॉइंट (Kafka या Service Bus) शामिल हैं; प्रत्येक अतिरिक्त एंडपॉइंट €10 प्रति माह है। मूल्य पृष्ठ देखें।
आपको कौन सा पेलोड भेजना चाहिए
| JSON रिकॉर्ड | ZPL लिफ़ाफ़ा | |
|---|---|---|
| प्रेषक को जानना चाहिए | फ़ील्ड नाम | पूरा लेबल लेआउट |
| लेआउट परिवर्तन | डिज़ाइन संपादित करें, प्रेषक अपरिवर्तित | हर प्रेषक को फिर से तैनात होना चाहिए |
| प्रति संदेश प्रिंटर | सब्सक्रिप्शन का प्रिंटर | printer, * प्रसारण सहित |
| फ़ॉन्ट, बारकोड, RFID | डिज़ाइन द्वारा संभाला | आपकी ज़िम्मेदारी |
यदि कर सकते हैं तो रिकॉर्ड भेजें। डिज़ाइन उन लोगों द्वारा संपादन योग्य रहता है जो लेबल के मालिक हैं, और लेआउट परिवर्तन के लिए संदेश प्रकाशित करने वाले सिस्टम में रिलीज़ की आवश्यकता नहीं होती। लिफ़ाफ़े तब भेजें जब ZPL किसी ऐसे सिस्टम से निकलता है जिसे आप नियंत्रित नहीं करते, या जब एक संदेश को एक साथ कई प्रिंटर तक पहुँचना हो।