फ़ाइल ट्रांसफ़र और EDI

फ़ाइल आई ही नहीं, और सोमवार तक किसी ने ध्यान नहीं दिया।

फ़ाइल ट्रांसफ़र संस्था का सबसे पुराना काम है और आम तौर पर सबसे कम निगरानी वाला: cron पर एक शेल स्क्रिप्ट, न पुनःप्रयास, न सूचना, न इसका कोई रिकॉर्ड कि क्या भेजा गया। Dagu ट्रांसफ़र के आदेश वैसे ही रखता है और उनके चारों ओर आगमन की प्रतीक्षा, सत्यापन, पुनःप्रयास और इतिहास जोड़ देता है।

Dagu इंस्टॉल करें रेसिपी देखें

फ़ाइल की प्रतीक्षा एक चरण है, आपके द्वारा संभाला जाने वाला पोलिंग लूप नहीं

हर ट्रांसफ़र पर पुनःप्रयास और विफलता की सूचना

नेटवर्क के भीतर चलता है, इसलिए फ़ाइलें किसी क्लाउड सेवा से होकर नहीं जातीं

सेल्फ़-होस्टिंग निःशुल्क, प्रति कनेक्शन कोई लाइसेंस नहीं

वह एकीकरण जिसे कोई आधुनिक नहीं बनाता

ऑर्डर फ़ाइलें, चालान, वेतन निष्कर्षण, बैंक डेटा और स्टॉक फ़ीड आज भी तय समय पर फ़ाइलों के रूप में चलते हैं। ट्रांसफ़र स्वयं हल हो चुकी समस्या है। कमी आम तौर पर उसके आसपास की हर चीज़ की होती है।

स्क्रिप्ट जानती है कि फ़ाइल कैसे भेजनी है। वह यह नहीं जानती कि दूसरा छोर बंद हो तो क्या करना है
विफलता आगे की प्रक्रिया में बैठे किसी व्यक्ति को पता चलती है, अक्सर कई दिन बाद, क्योंकि न आई हुई फ़ाइल और शांत दिन एक जैसे दिखते हैं
कोई नहीं बता सकता कि कौन-सी फ़ाइल कब गई और पूरी थी या नहीं, क्योंकि इसे कहीं दर्ज ही नहीं किया गया

फ़ाइल की प्रतीक्षा एक चरण है

अधिकांश शेड्यूलर आपसे 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

चुप्पी ही विफलता का तरीका है

जो ट्रांसफ़र शोर के साथ विफल हो वह छोटी समस्या है। जो चुपचाप विफल हो वह मिलान की पूरी परियोजना बन जाता है। जोड़ने लायक हिस्सा यही परिचालन परत है।

retry_policy दूसरे छोर के थोड़ी देर अनुपलब्ध रहने को संभाल लेती है, और ट्रांसफ़र की अधिकतर विफलताएँ यही होती हैं
mail_on.failure और handler_on.failure छूटी डिलीवरी को उसी घंटे किसी व्यक्ति तक पहुँचा देते हैं
max_active_runs: 1 धीमे ट्रांसफ़र को अगले निर्धारित रन से टकराने और वही फ़ाइल दोबारा भेजने से रोकता है

दोनों सिरे आपकी सीमा के भीतर रहते हैं

ऐसी फ़ाइलें जो नेटवर्क से बाहर नहीं जा सकतीं, वित्त, स्वास्थ्य और सार्वजनिक क्षेत्र में सामान्य बात हैं। आपके अपने होस्ट पर चलने वाली एक बाइनरी साझेदार तक 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

केवल फ़ाइल नहीं, प्रमाण रखें

किसी घटना के बाद प्रश्न शायद ही फ़ाइल की सामग्री पर होता है। प्रश्न यह होता है कि वह कब आई, पूरी थी या नहीं, और किसने दोबारा चलाया।

हर रन में प्रति चरण लॉग, स्थिति, समय और पुनःप्रयास की संख्या सुरक्षित रहती है
ऑब्जेक्ट स्टोरेज में संग्रह को वर्कफ़्लो का चरण बनाने से अवधारण आदत के बजाय एक कार्यक्रम बन जाता है
पुनःप्रयास भी उसी दर्ज मार्ग से होते हैं, इसलिए हाथ से की गई रिकवरी स्वचालित रन जितनी ही दिखाई देती है

शुल्क प्रति सर्वर, प्रति कनेक्शन नहीं

प्रबंधित फ़ाइल ट्रांसफ़र उत्पाद आम तौर पर प्रति कनेक्शन, प्रति साझेदार या प्रति ट्रांसफ़र सर्वर लाइसेंस होते हैं, इसीलिए हर नए व्यापारिक साझेदार के साथ बिल बढ़ता है।

Community सेल्फ़-होस्टिंग निःशुल्क है, सर्वर और वर्कर की संख्या असीमित
लाइसेंस वाला स्तर प्रति Dagu सर्वर मूल्यांकित है और उसमें SSO, भूमिका पृथक्करण तथा ऑडिट लॉग जुड़ते हैं
साझेदार जोड़ने का अर्थ एक वर्कफ़्लो फ़ाइल जोड़ना है, इससे लाइसेंस संख्या नहीं बदलती

जब MFT उत्पाद बेहतर उत्तर हो

Dagu ट्रांसफ़र निर्धारित करता है और उन पर निगरानी रखता है। यह पूर्ण MFT प्लेटफ़ॉर्म नहीं है, और कुछ आवश्यकताएँ वास्तव में वैसा ही उत्पाद माँगती हैं।

प्रोटोकॉल की व्यापकता: यदि AS2, OFTP2 या प्रमाणित EDI VAN कनेक्शन चाहिए, तो उसी के लिए बना उत्पाद लें
साझेदारों के लिए सेल्फ़-सर्विस पोर्टल, प्रति साझेदार क्रेडेंशियल रोटेशन और अ-अस्वीकरण रसीदें MFT की विशेषताएँ हैं, शेड्यूलर की नहीं
जो अनुपालन व्यवस्थाएँ प्रमाणित ट्रांसफ़र उत्पाद माँगती हैं, वे सामान्य प्रयोजन के ऑर्केस्ट्रेटर को स्वीकार नहीं करेंगी, चाहे वह तकनीकी रूप से कुछ भी कर सके

FAQ

Practical questions before adopting

क्या Dagu प्रबंधित फ़ाइल ट्रांसफ़र उत्पाद की जगह ले लेता है?

निर्धारित SFTP और फ़ाइल-आधारित एकीकरण के लिए आम तौर पर हाँ: यह ट्रांसफ़र चलाता है, आगमन की प्रतीक्षा करता है, सत्यापन करता है, पुनःप्रयास करता है, सूचना देता है और इतिहास रखता है। AS2, OFTP2, प्रमाणित EDI VAN कनेक्टिविटी, साझेदार सेल्फ़-सर्विस पोर्टल या अ-अस्वीकरण रसीदों के लिए नहीं। ये MFT प्लेटफ़ॉर्म की विशेषताएँ हैं और शेड्यूलर को इसका दिखावा नहीं करना चाहिए।

समय के बजाय फ़ाइल आने पर कैसे शुरू करें?

वर्कफ़्लो को छोटे अंतराल पर चलाएँ और उसे wait.file चरण से शुरू करें, जो पथ की जाँच करता है और फ़ाइल दिखते ही आगे बढ़ जाता है। चरण को टाइमआउट दें ताकि कभी न आने वाली डिलीवरी अनंत प्रतीक्षा के बजाय विफल होकर सूचना दे। यदि भेजने वाला पक्ष कॉल कर सकता है तो रन को वेबहुक से बाहर से भी शुरू किया जा सकता है।

कौन-से प्रोटोकॉल समर्थित हैं?

SSH पर SFTP 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.

Dagu इंस्टॉल करें रेसिपी देखें