نقل الملفات وEDI

لم يصل الملف، ولم يلاحظ أحد حتى يوم الاثنين.

نقل الملفات أقدم مهمة في المؤسسة وعادة أقلها مراقبة: نص برمجي في cron، بلا إعادة محاولة، بلا تنبيه، بلا سجل لما جرى نقله. يبقي Dagu أوامر النقل كما هي ويضيف حولها انتظار الوصول والتحقق وإعادة المحاولة والسجل.

انتظار الملف خطوة، وليس حلقة استقصاء تتولى صيانتها بنفسك
إعادة محاولة وتنبيهات إخفاق مع كل عملية نقل
يعمل داخل الشبكة، فلا تمر الملفات عبر خدمة سحابية
الاستضافة الذاتية مجانية، بلا ترخيص لكل اتصال
01

التكامل الذي لا يجدده أحد

ملفات الطلبات والفواتير ومستخرجات الرواتب والبيانات المصرفية وتغذية المخزون ما زالت تتحرك كملفات وفق جدول زمني. النقل نفسه مسألة محلولة. الناقص عادة هو كل ما يحيط به.

  • النص البرمجي يعرف كيف يرسل الملف، لكنه لا يعرف ما العمل حين يكون الطرف الآخر متوقفًا
  • يكتشف الإخفاق شخص في مرحلة لاحقة، غالبًا بعد أيام، لأن غياب الملف يبدو مثل يوم هادئ
  • لا أحد يستطيع الإجابة عن أي ملف انتقل ومتى وهل كان مكتملًا، لأن لا شيء سجّل ذلك
02

انتظار الملف خطوة

معظم المجدولات تفرض عليك كتابة حلقة استقصاء بـ sleep وعداد، ثم صيانتها. في Dagu إجراء انتظار، فتُعلَن نافذة الوصول بدل برمجتها، والملف الذي لا يصل أبدًا يجعل التشغيل يخفق بدل أن يعلّقه.

  • يستقصي wait.file ظهور مسار أو اختفاءه بالفاصل الزمني الذي تختاره
  • المهلة تحوّل التسليم الفائت إلى تشغيل مخفق مع تنبيه، بدل مهمة معلّقة حتى ينظر أحدهم
  • يجري التحقق كخطوة مستقلة، فيتوقف الملف المبتور أو التالف عند هذا الحد بدل أن يغذي عملية الاستيراد
الوارد: انتظار وتحقق واستيراد وأرشفة
# edi-inbound.yaml
schedule: "0 * * * *"
max_active_runs: 1

s3:
  bucket: corp-edi-archive
  region: ap-northeast-1

steps:
  - id: wait_for_delivery
    action: wait.file
    with:
      path: /var/spool/edi/orders.csv
      poll_interval: 30s
    timeout_sec: 1800

  - id: verify
    run: |
      cd /var/spool/edi
      sha256sum -c orders.csv.sha256
    depends: wait_for_delivery

  - id: import
    run: /opt/core/import-orders.sh /var/spool/edi/orders.csv
    depends: verify
    retry_policy:
      limit: 2
      interval_sec: 300

  - id: archive
    action: s3.upload
    with:
      key: edi/inbound/orders.csv
      source: /var/spool/edi/orders.csv
    depends: import

  - id: mark_done
    action: file.move
    with:
      source: /var/spool/edi/orders.csv
      destination: /var/spool/edi/done/orders.csv
      create_dirs: true
    depends: archive

handler_on:
  failure:
    run: /opt/edi/notify-failure.sh

mail_on:
  failure: true
03

الصمت هو نمط الإخفاق

عملية النقل التي تخفق بصوت عالٍ مشكلة صغيرة، أما التي تخفق بصمت فتتحول إلى مشروع تسوية. الطبقة التشغيلية هي الجزء الذي يستحق الإضافة.

  • تغطي retry_policy تعذّر الوصول المؤقت إلى الطرف الآخر، وهو سبب معظم إخفاقات النقل
  • يوصل mail_on.failure وhandler_on.failure التسليم الفائت إلى شخص ما خلال الساعة نفسها
  • يمنع max_active_runs: 1 تداخل نقل بطيء مع التشغيل المجدول التالي وإرسال الملف نفسه مرتين
04

يبقى الطرفان داخل حدودك

الملفات التي لا يجوز أن تغادر الشبكة هي الحالة الطبيعية في القطاع المالي والصحي والعام. ملف تنفيذي واحد على خادمك يصل إلى الشريك عبر SFTP وإلى النظام الأساسي محليًا، دون خدمة طرف ثالث في المسار.

  • ينقل sftp.upload وsftp.download الملفات بمصادقة المفاتيح، وعبر مضيف وسيط عند الحاجة
  • يستطيع سير العمل نفسه الوصول إلى نظام داخلي عبر SSH وإلى تخزين كائنات لنسخة الأرشيف
  • لا شيء يمر عبر سحابة مورّد، فتبقى أسئلة إقامة البيانات والتدقيق بسيطة
الصادر: استخراج ومجموع اختباري وإرسال
# edi-outbound.yaml
schedule: "30 18 * * 1-5"
max_active_runs: 1

ssh:
  user: edi
  host: sftp.partner.example.com
  key: ~/.ssh/edi_key

steps:
  - id: extract
    run: /opt/core/export-invoices.sh ./outgoing/invoices.csv
    retry_policy:
      limit: 2
      interval_sec: 120

  - id: checksum
    run: |
      cd ./outgoing
      sha256sum invoices.csv > invoices.csv.sha256
    depends: extract

  - id: send_file
    action: sftp.upload
    with:
      source: ./outgoing/invoices.csv
      destination: /inbound/invoices.csv
    depends: checksum
    retry_policy:
      limit: 3
      interval_sec: 60

  - id: send_checksum
    action: sftp.upload
    with:
      source: ./outgoing/invoices.csv.sha256
      destination: /inbound/invoices.csv.sha256
    depends: send_file

handler_on:
  failure:
    run: /opt/edi/notify-failure.sh

mail_on:
  failure: true
05

احتفظ بالدليل لا بالملف فقط

بعد أي حادثة نادرًا ما يكون السؤال عن محتوى الملف، بل عن وقت وصوله وهل كان مكتملًا ومن أعاد تشغيله.

  • يحتفظ كل تشغيل بسجلات لكل خطوة وبالحالة والتوقيتات وعدد المحاولات
  • جعل الأرشفة إلى تخزين الكائنات خطوة في سير العمل يحوّل الاحتفاظ من عادة إلى جدول
  • تمر إعادة التشغيل بالمسار المسجل نفسه، فتكون الاستعادة اليدوية ظاهرة مثل التشغيل الآلي
06

التسعير لكل خادم لا لكل اتصال

تُرخَّص منتجات النقل المُدار للملفات عادة لكل اتصال أو لكل شريك أو لكل خادم ناقل، ولهذا تنمو الفاتورة كلما أضاف العمل شريكًا تجاريًا جديدًا.

  • الاستضافة الذاتية لإصدار المجتمع مجانية، بخوادم وعمّال بلا حد
  • المستوى المرخَّص يُسعَّر لكل خادم Dagu ويضيف الدخول الموحد وفصل الأدوار وسجل التدقيق
  • إضافة شريك تعني إضافة ملف سير عمل، ولا يتغير عدد التراخيص
07

متى يكون منتج MFT هو الجواب الأفضل

يجدول Dagu عمليات النقل ويشرف عليها، لكنه ليس منصة MFT كاملة، وبعض المتطلبات تستدعي منصة فعلًا.

  • اتساع البروتوكولات: إذا لزمك AS2 أو OFTP2 أو اتصال معتمد بشبكة EDI VAN فاستخدم منتجًا مبنيًا لذلك
  • بوابات الخدمة الذاتية للشركاء وتدوير بيانات الاعتماد لكل شريك وإيصالات عدم الإنكار خصائص MFT لا خصائص مجدول
  • أنظمة الامتثال التي تشترط منتج نقل معتمدًا لن تقبل منسقًا عام الغرض مهما كانت قدراته التقنية

FAQ

Practical questions before adopting

هل يحل Dagu محل منتج النقل المُدار للملفات؟

بالنسبة إلى SFTP المجدول والتكامل القائم على الملفات، نعم غالبًا: ينفذ النقل وينتظر الوصول ويتحقق ويعيد المحاولة وينبّه ويحتفظ بالسجل. أما AS2 وOFTP2 والاتصال المعتمد بشبكة EDI VAN وبوابات الخدمة الذاتية للشركاء وإيصالات عدم الإنكار، فلا. هذه خصائص منصة MFT ولا ينبغي لمجدول أن يدّعي غير ذلك.

كيف أشغّله عند وصول ملف بدل التشغيل بجدول زمني؟

شغّل سير العمل بجدول قصير وابدأه بخطوة wait.file التي تستقصي المسار وتتابع فور ظهوره. امنح الخطوة مهلة كي يخفق التسليم الذي لا يصل أبدًا وينبّه بدل الانتظار بلا نهاية. يمكن أيضًا بدء التشغيل خارجيًا عبر webhook إذا كان الطرف المرسل قادرًا على استدعائه.

ما البروتوكولات المدعومة؟

SFTP فوق SSH مدمج عبر sftp.upload وsftp.download، ونقل تخزين الكائنات مدمج لنقاط النهاية المتوافقة مع S3. وما عدا ذلك يعمل كخطوة أوامر عادية، فتستمر أدواتك الحالية لـ FTPS أو rsync أو عميل المورّد في العمل محاطة بالجدولة والإشراف.

كيف تُدار بيانات الاعتماد؟

مصادقة SSH بالمفاتيح هي الوضع الافتراضي، مع دعم مضيف وسيط عندما يكون الشريك خلفه. تُعلَن الأسرار على مستوى سير العمل وتُحل من مزوّد مثل متغيرات البيئة أو ملف أو Vault أو مدير أسرار سحابي، وتُخفى قيمها في سجلات التشغيل.

هل يعمل حيث لا يوجد اتصال بالإنترنت؟

نعم. Dagu ملف تنفيذي مكتفٍ ذاتيًا لا يشترط قاعدة بيانات خارجية ولا وسيط رسائل، فيعمل داخل المؤسسة وفي الشبكات المغلقة. ويستخدم التنفيذ الموزع منسقًا وعمّالًا عبر gRPC داخل شبكتك.

Next step

Start with one workflow.

Install Dagu, move one script that runs on cron today into YAML, and decide from a real run history.