zplCloud Blog
طباعة الملصقات مع Azure Service Bus: الطابور كمشغّل
شكلان للحمولة وطابور واحد: سجل JSON يملأ تصميمًا، أو ZPL خام داخل ظرف. ومع PeekLock لا يضيع شيء ولا يُطبع شيء مرتين.
الطابور هو المشغّل أصلًا
إذا كانت أنظمتك تتحدث أصلًا عبر Azure Service Bus، فمهمة الطباعة رسالة كأي رسالة. اشتراك Data Streaming من نوع Service Bus يستهلك طابورًا أو اشتراك موضوع ويطبع كل رسالة—بلا مهمة استطلاع وبلا وسيط طباعة وبلا خادم طباعة Windows بين الناقل والطابعة.
الجزء المثير أن الرسالة يمكن أن تكون واحدة من شيئين، ويقرر zplCloud لكل رسالة:
- سجل JSON - مفاتيح الكائن تملأ روابط تصميم ملصق. استخدمه عندما يعرف المرسل البيانات لا التخطيط.
- ظرف ZPL - كائن JSON يحمل ZPL منتهيًا. استخدمه عندما ينتج المرسل ZPL أصلًا ويحتاج فقط وصوله إلى طابعة.
كلاهما يمر عبر نفس الاشتراك؛ لا تضبط وضعًا.
إعداد الاشتراك
| الحقل | القيمة |
|---|---|
| النوع | Service Bus |
| إعداد الاتصال | سلسلة اتصال النطاق |
| الموضوع | اسم الطابور، أو topic/Subscriptions/اسم الاشتراك |
| تصميم الملصق | التصميم المستخدم لسجلات JSON |
| الطابعة | طابعة الهدف الافتراضية |
سلسلة الاتصال مخزنة مشفرة AES أثناء السكون.
طابور أم موضوع يقرره حقل Topic بالاتفاق: إذا احتوت القيمة /Subscriptions/، تُعامل كـtopic/Subscriptions/اسم الاشتراك؛ وإلا فهي اسم طابور. يمكنك أيضًا تركه فارغًا ووضع EntityPath=printer في سلسلة الاتصال.
الاشتراكات لا تُنشأ تلقائيًا. أنشئ اشتراك الموضوع مرة في البوابة أو Service Bus Explorer أو المحاكي (topic.1/Subscriptions/subscription.1)؛ zplCloud يستهلكه فقط.
بخلاف تكامل Kafka، يعمل Service Bus سحابيًا فقط—المستهلك في الخادم الخلفي ويتصل خارجيًا. لا نسخة وكيل محلية، لأن نطاق Service Bus متاح عبر الإنترنت على أي حال.
الحمولة أ - سجل JSON لتصميم
{ "ean": "4006381333930", "qty": 2, "dest": "Ramp 4" }
تُطابق المفاتيح روابط التصميم بالاسم. المفاتيح بلا ربط تُتجاهل؛ الروابط بلا مفتاح تُنشأ فارغة.
إذا لم يكن الجسم JSON إطلاقًا، يُربط النص كله كـ$message—يكفي لملصق حقل واحد.
خطأ إنشاء يسمي الحقل المسبب بدل تسليمك رسالة SDK:
ZPL-Renderfehler bei qty: Wert 'zwei' → ...
عادة مشكلة نوع أو طول: حقل رقمي أُطعم كلمة، أو قيمة أطول مما يستوعبه الحقل.
الحمولة ب - 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"- كل طابعة في مساحة العمل، Weblink وطابعات الوكيل البعيدة معًا.
كل هدف يُحسب كملصق مستقل ضد حصتك، فالبث إلى ثماني طابعات ثمانية ملصقات. هذا هو النموذج الصحيح لإشعار تغيير وردية؛ خطأ مكلف لملصق لكل طلب.
دلالات التسليم: PeekLock وماذا يحدث عند فشل طباعة
هنا حيث يكون تكامل الطابور جديرًا بالثقة أو لا. المستقبل يعمل بوضع PeekLock مع PrefetchCount = 0—الاستلام ليس حذفًا، ولا تُخزَّن رسائل في العملية، فإيقاف الاشتراك أو إعادة تشغيله لا يبتلع دفعة أو يكررها أبدًا.
| النتيجة | ماذا يحدث للرسالة |
|---|---|
| طُبعت | Complete - تغادر الرسالة الناقل |
| فشل طباعة، تسليم < 3 | Abandon - تُعاد تسليمها، ثم تراجع 10 ثوانٍ قبل الاستلام التالي |
| فشل طباعة، تسليم ≥ 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 يتضمن نقطتي تدفق (Kafka أو Service Bus)؛ كل نقطة إضافية 10 € شهريًا. انظر صفحة الأسعار.
أي حمولة يجب أن ترسل
| سجل JSON | ظرف ZPL | |
|---|---|---|
| يحتاج المرسل إلى معرفة | أسماء الحقول | تخطيط الملصق الكامل |
| تغييرات التخطيط | عدّل التصميم، المرسلون دون تغيير | كل مرسل يجب إعادة نشره |
| طابعة لكل رسالة | طابعة الاشتراك | printer، بما فيه بث * |
| خطوط وباركود وRFID | يعالجها التصميم | مسؤوليتك |
أرسل السجلات إن استطعت. يبقى التصميم قابلاً للتعديل من مالكي الملصق، وتغيير التخطيط لا يتطلب إصدارًا في النظام الذي ينشر الرسائل. أرسل الأظرفة عندما يخرج ZPL من نظام لا تتحكم فيه، أو عندما يجب أن تبلغ رسالة عدة طابعات دفعة واحدة.