التكامل
PostgreSQL كمصدر بيانات للملصقات: استعلام واحد وآلاف الملصقات
البيانات الرئيسية للأصناف موجودة في PostgreSQL، ومنها يجب أن تخرج الملصقات. الطريق المعتاد تصدير CSV يصبح قديمًا لحظة اكتماله. والطريق الأفضل: تبقى قاعدة الب…
البيانات الرئيسية للأصناف موجودة في PostgreSQL، ومنها يجب أن تخرج الملصقات. الطريق المعتاد تصدير CSV يصبح قديمًا لحظة اكتماله. والطريق الأفضل: تبقى قاعدة البيانات هي المصدر، وتستعلم طباعة الملصقات منها مباشرةً.
كل ما هو موصوف هنا ينطبق أيضًا على MySQL وMariaDB - فقط سلسلة الاتصال تبدو مختلفة.
طريقان إلى قاعدة البيانات
عبر الوكيل، عندما تكون قاعدة البيانات داخل شبكتك. يفتح وكيل zplCloudCli اتصالًا صادرًا إلى المنصة، وينفذ الاستعلام محليًا ولا يعيد إلا صفوف النتيجة. تبقى سلسلة الاتصال على جهازك وحده. ولا حاجة إلى أي منافذ واردة.
مباشرةً من السحابة، عندما تكون قاعدة البيانات قابلة للوصول أصلًا - مثل Azure Database for PostgreSQL أو Amazon RDS. عندها تتصل المنصة بنفسها؛ وتُخزَّن سلسلة الاتصال مشفرة AES في قاعدة بيانات المنصة، ولا يُفك تشفيرها إلا لتنفيذ الاستعلام.
طريق الوكيل: تسجيل الخادم
يتعرف الوكيل على قواعد بياناته عبر خيار أو متغير بيئة أو ملف. والطرق الثلاث متكافئة.
# كخيار عند بدء التشغيل
zplcloud proxy --agent "Warehouse" \
--postgres WMS="Host=pg.internal.lan;Database=wms;Username=zplcloud;Password=...;SSL Mode=Require"
# أو كمتغير بيئة
export ZPLCLOUD_PG_WMS_CONNECTION="Host=pg.internal.lan;Database=wms;Username=zplcloud;Password=..."
zplcloud proxy --agent "Warehouse"
# أو كملف pgservers.json بجوار الملف التنفيذي أو تحت ~/.zplcloud/
# { "postgresServers": { "WMS": "Host=pg.internal.lan;Database=wms;Username=zplcloud;Password=..." } }
الاسم الذي يلي الخيار (WMS) هو ما يظهر لاحقًا في قائمة الاختيار. ولـ MySQL يكون الخيار --mysql، ولـ MariaDB --mariadb، مع متغيرات وملفات مطابقة.
نصيحة من الواقع العملي: أنشئ مستخدم قاعدة بيانات مخصصًا بصلاحيات قراءة فقط على الجداول التي تحتاجها الملصقات تحديدًا. الوكيل لا ينفذ إلا SELECT، لكن الحساب الذي لا يستطيع أكثر من ذلك هو الضمان الأقوى.
إنشاء مصدر البيانات
ضمن مركز البيانات ← مصادر البيانات ← جديد اختر النوع PostgreSQL (عبر الوكيل) أو PostgreSQL (Cloud)، ثم الوكيل والخادم. يستقبل حقل الاستعلام أمر SELECT واحدًا:
SELECT a.sku, a.description, a.ean, s.bin, a.best_before
FROM article a
JOIN stock s ON s.article_id = a.id
WHERE a.active = true
يقرأ زر الحقول الأعمدة دون تحميل أي بيانات - وبعدها تصبح متاحة في المصمم كروابط. ويتحقق زر اختبار من الاتصال.
ما يجوز أن يحتويه الاستعلام
القواعد صارمة عمدًا، لأن مصدر البيانات وُجد للقراءة لا للكتابة:
- أمر
SELECTأوWITHواحد فقط، بلا فاصلة منقوطة، وبلا تعليقات، وبلا أوامر متعددة. - تصل قيم التصفية إلى قاعدة البيانات دائمًا كمعاملات، ولا تُجمَّع أبدًا كنص. لذلك لا يمكن حقن SQL عبر صف التصفية.
- تُطبّق قاعدة البيانات التصفية والفرز و
LIMIT/OFFSET، لا المنصة. فتؤدي فهارسك عملها. - 1000 صف كحد أقصى لكل عملية جلب، ومهلة 15 ثانية.
هذه الصفوف الـ 1000 ليست سقفًا للطباعة: ففي التشغيلات الكبيرة تجلب المنصة جزءًا تلو الآخر على الخادم، حتى 50,000 ملصق دفعة واحدة. ولا يُحتفظ في الذاكرة إلا بجزء واحد في كل مرة.
أين تُستخدم البيانات
مصدر البيانات الجاهز متاح في كل مكان تُحتاج فيه البيانات:
- واجهات الطباعة (Print Views) - رابط URL محمي مع نموذج يبحث فيه شخص ما برمز EAN ويطبع الملصق الناتج.
- الطباعة الدفعية - كل نتائج الاستعلام دفعة واحدة، تُرسل إلى الطابعة على أجزاء.
- المصمم - كبيانات ربط، فتعرض المعاينة قيمًا حقيقية بدلًا من العناصر النائبة.
أخطاء شائعة
- «The query must start with SELECT.» تكفي فاصلة منقوطة في النهاية لإطلاق هذا الخطأ. احذفها.
- لم يُعثر على أعمدة. الأعمدة المحسوبة تحتاج إلى اسم:
SELECT price 1.19 AS grossبدلًا منSELECT price 1.19. - فشل الاتصال. خوادم PostgreSQL القابلة للوصول مباشرةً تشترط عادةً TLS: ومكان
SSL Mode=Requireفي سلسلة الاتصال. - الوكيل غير متصل. يحافظ الوكيل على الاتصال بنفسه. وتعرض صفحة نظرة عامة على الوكلاء في مركز البيانات أيها موجود وأي خوادم يُبلغ عنها.