zplCloud Blog
SQL Server كمصدر بيانات: حلقة التصدير، مُلغاة
سلسلة الاتصال لا تغادر جهازك أبدًا. وتعمل عوامل التصفية والفرز والتقسيم إلى صفحات كاستعلامات T-SQL مُعلَّمة على خادمك.
حلقة التصدير، ولماذا تنكسر
بيانات الملصقات تعيش في ERP أو WMS أو قاعدة Azure SQL. سير العمل المعتاد هو التصدير إلى CSV وتصحيح أسماء الأعمدة والرفع والطباعة—ثم التكرار غدًا، لأن CSV قديم أصلًا.
مركز البيانات zplCloud يزيل التصدير. وكيل CLI داخل شبكتك يحمل سلسلة اتصال SQL Server، وترسل المنصة وصف استعلام، ولا تعود سوى صفوف النتيجة. قاعدة البيانات لا تُكشف للإنترنت أبدًا والبيانات الاعتمادية لا تُخزن في السحابة أبدًا.
هذا المنشور هو الآلية الدقيقة: ماذا يعمل أين، وأي SQL يُولَّد، وما الحدود الصارمة.
البنية في فقرة
zplcloud proxy يفتح اتصال TLS خارجي واحد إلى api.zplcloud.com (SignalR). بلا منفذ وارد وبلا قاعدة NAT وبلا VPN. عندما تفتح مصدر بيانات في المنصة، يرسل الخادم الخلفي للوكيل كائن طلب—استعلام أساسي وتصفية وفرز وإزاحة وحدًا—ويحوّله الوكيل إلى T-SQL وينفذه ضد SQL Server بمستخدم قاعدة البيانات الخاص بك ويعيد الصفوف. سلسلة الاتصال موجودة فقط في ذاكرة عملية الوكيل وإعداده المحلي.
الخطوة 1 - شغّل الوكيل بخادم أو أكثر
# عدة أعلام --sql مسموحة؛ الاسم هو ما تختاره في المنصة.
zplcloud proxy --agent "Lager" \
--sql PROD="Server=127.0.0.1;Database=erp;User Id=zplcloud;Password=…;Encrypt=True;TrustServerCertificate=True" \
--sql WAREHOUSE="Server=sql-wh.internal.lan,1433;Database=logistik;User Id=zplcloud;Password=…;Encrypt=True;TrustServerCertificate=True"
ما يعادله دون وضع الأسرار في سطر الأوامر (ستقع في تاريخ الصدفة):
# Windows PowerShell - متغير لكل خادم، الاسم في المنتصف
$env:ZPLCLOUD_SQL_PROD_CONNECTION = "Server=127.0.0.1;Database=erp;User Id=zplcloud;Password=…;Encrypt=True;TrustServerCertificate=True"
zplcloud proxy --agent "Lager"
لافتة البدء تدرج ما وجدته: SQL servers: PROD, WAREHOUSE. المصادقة على المنصة تستخدم --api-key <key> أو ZPLCLOUD_API_KEY.
أبقِه دائمًا للتشغيل غير المراقب:
- Windows:
setx ZPLCLOUD_SQL_PROD_CONNECTION "…"، أوzplcloud proxy --agent "Lager" --service-install --api-key sk_zplcloud_… - Linux/Raspberry Pi: نفس علامة
--service-install؛ يكتب وحدة systemdzplcloud-agent.serviceمعRestart=always - ملف بدل env:
sqlservers.jsonبجوار الثنائي أو في~/.zplcloud/، شكل{ "sqlServers": { "PROD": "Server=…" } } - Docker:
ZPLCLOUD_SQL_PROD_CONNECTIONفيdocker-compose.agent.yml
ملاحظات سلاسل اتصال تكلف الناس ساعة
Encrypt=True;TrustServerCertificate=Trueهو الزوج العملي لخادم داخلي بشهادة ذاتية التوقيع. احذفTrustServerCertificateحالما تحصل على شهادة حقيقية.- المثيل المسمى يحتاج
Server=host\INSTANCE؛ المنفذ غير الافتراضي هوServer=host,1433—فاصلة، لا نقطتان. - استخدم دخول SQL مخصصًا بـ
SELECTعلى الجداول التي تحتاجها الملصقات بالضبط. الوكيل ينفذ كل شيء بذلك المستخدم، لذا قاعدة البيانات هي حد الصلاحيات—لا المنصة.
الخطوة 2 - أنشئ مصدر البيانات
في مصادر البيانات يظهر الوكيل قيد التشغيل تحت Remote SQL Server برقاقة لكل اسم مكوّن. النقر على رقاقة يملأ النموذج مسبقًا.
| الحقل | القيمة |
|---|---|
| الاسم | Lager-Artikel |
| النوع | SQL Server |
| الخادم | PROD (الاسم من --sql PROD=…) |
| الاستعلام | SELECT ean, name, price FROM artikel |
اختبار ينفذ SELECT 1 ويعيد الخادم · قاعدة البيانات. الحقول يقرأ بيانات الأعمدة عبر SELECT TOP 1 * مع CommandBehavior.SchemaOnly—يجلب المخطط دون سحب البيانات. إذا لم يُرجع استعلام متداخل بعمق مخططًا، يعيد الوكيل المحاولة مرة مع SingleRow.
الخطوة 3 - ماذا ينفذ الوكيل فعلًا
استعلامك الأساسي يُغلَّف كاستعلام فرعي. التصفية والفرز والترقيم يضيفها الوكيل:
SELECT * FROM ( SELECT ean, name, price FROM artikel ) AS ds
WHERE ean LIKE @p0
ORDER BY name
OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY
ثلاثة أشياء تستحق القراءة مرتين:
1. القيم معاملات، لا دمج سلاسل أبدًا. باني التصفية يصدر @p0 و@p1 و… ويربط القيم عبر SqlCommand.Parameters. لا يوجد مكان تتحول فيه قيمة يدخلها المستخدم إلى نص SQL.
2. الترقيم أصلي. limit 10 يصبح FETCH NEXT 10 ROWS ONLY؛ SQL Server يقوم بالعمل ويعيد عشر صفوف عبر السلك، لا مليونًا.
3. عدّ الصفوف استعلام منفصل. عندما تطلب الإجمالي، ينفذ الوكيل SELECT COUNT(*) FROM (<base>) AS ds بنفس WHERE ونفس المعاملات.
الحدود الصارمة (من كود الوكيل)
| الحد | القيمة | حيث ينطبق |
|---|---|---|
| الصفوف لكل طلب | 1000 (RowCap) | limit مقيد إلى 1…1000؛ الافتراضي عند عدم الضبط 100 |
| مهلة الأمر | 15 ثانية | الاختبار والوصف والاستعلام والعد |
| نوع الجملة | SELECT فقط | الاستعلام الأساسي يُتحقق؛ الجمل المتعددة تُرفض |
| أعمدة الفرز/التصفية | معرّفات مُتحقق منها | لا تُمرَّر كـ SQL حر |
إذا احتجت أكثر من 1000 صف في عرض واحد—طباعة دفعة، كتالوج كامل—تقلّب المنصة خلال مجموعة النتائج بـOFFSET متزايد. كل صفحة طلبها المستقل بـ1000 صف ضد خادمك، لذا تبقى الذاكرة مسطحة مهما كان الإجمالي.
مهلة 15 ثانية مقصودة. إذا لم يستطع استعلامك الأساسي الإجابة في 15 ثانية، فهو ينتمي إلى عرض مفهرس أو جدول بالفهرس الصحيح، لا إلى مصدر بيانات ملصقات.
الخطوة 4 - استخدمه في المصمم وPrint Views
- المصمم ← تبويب بيانات الاختبار ← مصدر البيانات: اختر مصدر البيانات واضغط تحميل. تُنشأ روابط الحقول بصفوف حقيقية بدل نص مؤقت، فترى الأطوال الفعلية قبل وصول أي شيء إلى طابعة.
- Print Views ← الإعداد ← مصدر البيانات (مركز البيانات): معاينة العرض وطباعته تستخدمان الاستعلام الحي. المشغّل يرى بيانات حالية؛ لا أحد يعيد رفع CSV.
أنماط الفشل ومعناها
| العرض | السبب |
|---|---|
| الوكيل يبدأ لكن لا تظهر رقاقة | اسم --sql مفقود، أو الوكيل صادق بمفتاح من مساحة عمل أخرى |
اختبار يفشل فورًا | سلسلة اتصال خاطئة (مثيل، منفذ، بيانات) - الخطأ يُمرَّر من SQL Server |
اختبار يعلق ثم يفشل | مهلة 15 ثانية: خادم غير متاح من جهاز الوكيل، أو جدار حماية يُسقط الحزمة بصمت |
الحقول لا يعيد شيئًا | الاستعلام الأساسي متداخل جدًا لـSchemaOnly؛ الوكيل يهبط إلى SingleRow، الذي يحتاج وجود صف واحد على الأقل |
| الاستعلام يعمل، Print View فارغة | العرض مربوط بمصدر بيانات آخر، أو التصفية تستبعد كل الصفوف |
الخطة
مركز البيانات (مصادر SQL Server وMongoDB عبر وكيل CLI) جزء من خطة Pro. التفاصيل في صفحة الأسعار.