ファイル連携・EDI
ファイル転送は社内で最も古い仕事で、たいてい最も見られていません。cron 上のシェルスクリプト、リトライなし、通知なし、何が動いたかの記録なし。Dagu は転送コマンドをそのまま残し、その周りに到着待ち、検証、リトライ、履歴を足します。
受注ファイル、請求データ、給与の抽出、銀行データ、在庫連携は、いまもファイルとして定時に動いています。転送そのものは解決済みの問題です。足りていないのは、たいていその周辺すべてです。
多くのスケジューラでは、sleep とカウンタでポーリングループを書き、その後ずっと保守することになります。Dagu には待機アクションがあるので、到着の待ち時間はコードではなく宣言になり、来なかったファイルは実行をハングさせずに失敗させます。
# 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
大きな音を立てて失敗する転送は小さな問題です。静かに失敗する転送は、後から突き合わせをやり直すプロジェクトになります。足す価値があるのは運用の層です。
ファイルを社外に出せないのは、金融、医療、公共では普通の前提です。自社のホスト上で動く単一バイナリなら、SFTP で相手先に届き、基幹システムにはローカルで届きます。経路に第三者のサービスが入りません。
# 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
障害の後で問われるのは、たいていファイルの中身ではありません。いつ届いたか、完全だったか、誰が再実行したかです。
マネージドファイル転送製品は、たいてい接続数、取引先数、または転送サーバー数で課金されます。取引先が増えるたびに請求が増えるのはそのためです。
Dagu は転送をスケジュールし、監視します。MFT プラットフォームそのものではありませんし、本当に製品が必要な要件もあります。
FAQ
定時の SFTP とファイルベースの連携についてはたいてい置き換えられます。転送を実行し、到着を待ち、検証し、リトライし、通知し、履歴を残します。AS2、OFTP2、認定 EDI VAN 接続、取引先向けポータル、否認防止の受領証については置き換えられません。それらは MFT プラットフォームの機能で、スケジューラがそう装うべきではありません。
短い間隔のスケジュールで実行し、先頭に wait.file ステップを置いてください。パスを監視し、現れた時点で後続に進みます。ステップにタイムアウトを付けておけば、来なかった配信は永久に待たずに失敗して通知されます。送信側から呼べる場合は、webhook で外部から実行を起動することもできます。
SSH 上の SFTP が sftp.upload と sftp.download として組み込まれており、S3 互換のオブジェクトストレージも組み込みです。それ以外は通常のコマンドステップとして実行するため、FTPS、rsync、ベンダー製クライアントなど既存のツールが、スケジュールと監視に包まれた状態でそのまま動きます。
SSH の鍵認証が既定で、相手先が踏み台の内側にある場合は踏み台も指定できます。シークレットはワークフロー側で宣言し、環境変数、ファイル、Vault、クラウドのシークレット管理などのプロバイダから解決します。値は実行ログで伏字になります。
はい。Dagu は外部データベースやブローカーを必須としない自己完結のバイナリなので、オンプレミスや閉域ネットワークで動作します。分散実行も自社ネットワーク内のコーディネーターとワーカーの間の gRPC で完結します。