ابدأ مجاناً

التكامل

طباعة ZPL من S3 أو Azure Blob - وأرشفة الملصقات المطبوعة هناك

تخزين الكائنات هو المكان الذي توجد فيه ملفات الطباعة أصلًا: ملصقات الشحن من مزوّد خدمة الشحن، ودفعات مُصيَّرة مسبقًا من ERP، وأرشيفات محفوظة وفق قواعد الاحتف…

تخزين الكائنات هو المكان الذي توجد فيه ملفات الطباعة أصلًا: ملصقات الشحن من مزوّد خدمة الشحن، ودفعات مُصيَّرة مسبقًا من ERP، وأرشيفات محفوظة وفق قواعد الاحتفاظ. يغطي هذا الدليل الاتجاهين - طباعة ZPL من حاوية تخزين (bucket)، وكتابة ZPL المطبوع مرة أخرى إليها.

ينطبق كل ما يلي على Amazon S3 وAzure Blob Storage. ولأن واجهة S3 موحدة، تعمل كذلك MinIO وCloudflare R2 وWasabi وBackblaze B2 وCeph.

إنشاء اتصال تخزين

ضمن تدفق البيانات ← التخزين ← اتصال جديد تُنشئ الاتصال مرة واحدة. الاسم مهم: فبه تخاطب الرسائل هذا الاتصال لاحقًا.

الحقلS3Azure Blob
الحاوية (Bucket / Container)اسم الـ bucketاسم الـ container
المنطقةمثلًا eu-central-1غير مستخدم
نقطة النهايةفارغ لـ AWS، وإلا مثلًا https://minio.example.comغير مستخدم
نمط المسار (Path style)فعّله لـ MinIO وCephغير مستخدم
البادئةاختياري، مثلًا zpl/اختياري
بيانات الاعتمادAccessKey=…;SecretKey=…سلسلة اتصال أو رابط SAS للحاوية

تُخزَّن بيانات الاعتماد مشفرة AES في قاعدة بيانات المنصة. ولا تعود أبدًا إلى المتصفح - فالنموذج يُظهر فقط أن بيانات اعتماد موجودة. ومع S3 يمكنك الاستغناء عنها تمامًا: عندها تُطبَّق سلسلة بيانات اعتماد AWS المعتادة، مثل دور IAM الخاص بالبيئة.

يتحقق زر اختبار من صحة حاوية التخزين والصلاحيات قبل طباعة أي شيء.

الاتجاه 1: طباعة ZPL من حاوية التخزين

يمكن لرسالة الناقل أن تحمل ZPL جاهزًا. لكن مع الملفات الكبيرة يصبح ذلك مرهقًا - فكثير من الوسطاء يحددون سقفًا لحجم الرسالة، والملصق الذي يتضمن رسمًا مضمّنًا يكبر بسرعة. الأفضل أن تشير الرسالة إليه فقط.

{
  "schemaVersion": 1,
  "printer": "rp:7",
  "zplRef": { "storage": "archive", "key": "orders/4711.zpl" }
}

storage هو اسم اتصالك، وkey مفتاح الكائن داخله. وتُضاف البادئة المُعدّة في البداية: مع البادئة zpl/ يصبح المثال أعلاه zpl/orders/4711.zpl.

يُجلب الملف وقت الطباعة، لا عند الاستلام. ولا يُحلّ الاسم إلا ضمن نطاقك أو نطاق شركتك - فلا يمكن الوصول إلى اتصال شخص آخر عبر رسالة، حتى لمن يعرف اسمه.

الاتجاه 2: تخزين ZPL المطبوع والإبلاغ عنه

يُسمى الاتجاه المعاكس وجهة الإخراج. وهي تجمع ثلاث خطوات تجري بعد طباعة ناجحة، وتُفعَّل كل منها على حدة:

1. التخزين - يُكتب ZPL المطبوع كملف في اتصال تخزين.

2. الإشعار - تُرسل رسالة إلى ناقل، أيٍّ من النواقل السبعة.

3. التشغيل - طلب HTTP POST إلى عنوان URL خاص بك، موقّع بـ HMAC-SHA256.

يأتي اسم الملف من قالب. وجميع الأوقات بتوقيت UTC:

القالب:  {yyyy}/{MM}/{dd}/{subscription}/{id}.zpl
النتيجة: 2026/09/09/Outbound/8f3c1e2a9b7d4c0e.zpl

المتاح: {yyyy} {MM} {dd} {HH} {mm} {ss} و{subscription} و{printer} و{key} (مفتاح رسالة الناقل) و{id} لمعرّف فريد لكل ملصق.

يتلقى الإشعار والـ webhook الحمولة نفسها:

{
  "schemaVersion": 1,
  "event": "label.printed",
  "utc": "2026-09-09T12:34:56.7890000Z",
  "subscription": "Outbound",
  "printer": "rp:7",
  "storageKey": "zpl/2026/09/09/Outbound/8f3c1e2a.zpl",
  "storageUrl": "https://archive.s3.eu-central-1.amazonaws.com/zpl/2026/09/09/...",
  "zplBytes": 812,
  "zpl": null
}

لا يُضمَّن ZPL نفسه إلا إذا طلبته صراحةً. وإلا فقيمة الحقل null ويكفي العنوان - مما يُبقي الرسالة صغيرة.

فيمَ يفيد هذا

  • قواعد الاحتفاظ. ملصقات الشحن مستندات خاضعة للاحتفاظ. وأرشيف في حاوية التخزين الخاصة بك، ضمن قواعد دورة الحياة لدى مزوّدك، يفي بذلك دون نظام ثانٍ.
  • إعادة الطباعة دون إعادة تصيير. ما طُبع مرة موجود بايتًا ببايت. وإعادة الطباعة هي الملف نفسه، لا تصيير جديد.
  • التسليم إلى الأنظمة اللاحقة. يُبلغ الـ webhook نظام ERP بأن الكرتون 12 قد وُسم، ويسلّم في الوقت نفسه رابط السجل.

فشل التخزين لا يوقف الطباعة أبدًا

التخزين والإشعار والـ webhook كلها تجري بعد الطباعة. وإذا تعذر الوصول إلى حاوية التخزين لبرهة، يُطبع الملصق رغم ذلك؛ ويُسجَّل الخطأ كنص في سجل الاشتراك. فلا ينبغي لأرشيف أن يعطّل العمليات.

يمكن تجربة وجهة الإخراج في أي وقت بزر اختبار: فهي تخزّن ZPL نموذجيًا وتطلق الإشعار والـ webhook دون طباعة أي شيء.