業務システムでは、データベースやファイル、APIなどを使って、別のシステムとデータを連携することがあります。
私もアプリSEとして、ASTERIA Warpを使って連携フローを作成・修正し、DB・FTP・RESTの連携を設定・実装した経験があります。
ASTERIA Warpでは画面上でフローを作成できますが、実際に連携を設定するときは、製品の操作だけ分かればよいわけではありませんでした。
特にREST連携では、HTTPメソッドやURI、Content-Type、HTTPステータスコードなど、RESTやHTTP側の仕組みを理解する必要がありました。
この記事では、ASTERIA Warpがどのような製品なのかを、現在の公式情報と、私が実際にDB・FTP・REST連携を実装した経験を分けながら紹介します。
なお、ASTERIA Warpにはバージョンやエディションによる違いがあります。現在の製品仕様と、私が利用していた当時の経験は分けて扱います。
ASTERIA Warpとは
ASTERIA Warpは、複数のシステムやサービスの間でデータを連携するための製品です。
現在のASTERIA公式サイトでは、基幹システムやクラウドなど100種類以上の接続先をつなぐ、ノーコードのデータ連携基盤として紹介されています。
フローサービスでは、フローデザイナー上にアイコンを配置し、必要な設定を行いながら連携処理を組み立てます。
プログラムを一から記述する形とは異なり、処理の流れを画面上で確認しながら作成できるのが特徴です。
私も実務では、このフローを自分で作成したり、既存のフローを修正したりしていました。
DB・FTP・RESTの連携を実装した
私がASTERIA Warpを使用したときは、DB・FTP・RESTの3種類の連携を自分で設定・実装していました。
DBとの連携ではデータベースに接続し、FTPではファイルを使った連携を扱いました。
ASTERIA WarpのREST連携では、HTTPを利用して別システムと連携します。
ASTERIA Warp上では同じようにフローとして処理を組み立てていきますが、接続先によって必要になる知識は同じではありません。
REST連携ではHTTPの知識も必要だった
REST連携で私が意識していたのが、HTTPメソッド、URI、Content-Type、HTTPステータスコードです。
たとえば、どのURIに対してどのHTTPメソッドでリクエストを送るのかを理解する必要があります。
送受信するデータによっては、Content-Typeとして「application/json」や「text/plain」などを設定することもありました。
HTTPステータスコードについても、それまで扱っていた終了コードとは考え方が異なりました。
私の場合、正常終了といえば「0」という感覚に慣れていましたが、HTTPでは2xxが成功を表します。
200は代表的な成功時のステータスコードですが、HTTPでは成功が200だけとは限りません。
また、4xxはクライアントエラー、5xxはサーバーエラーというように、ステータスコードの種類によって意味合いが異なります。
そのため、REST連携では、HTTPメソッドやContent-Typeだけでなく、返ってくるステータスコードが何を意味するのかも理解しておく必要がありました。
ASTERIA Warpの現在の公式ドキュメントでも、RESTコンポーネントにはHTTPメソッド、接続先URL、Content-Typeなどの設定があり、HTTPレスポンスのステータスコードを取得できるようになっています。
ASTERIA Warp公式ドキュメント「REST – HTTPサービスの呼び出し」
HTTPステータスコードの分類については、HTTP Semantics（RFC 9110）で2xxがSuccessful、4xxがClient Error、5xxがServer Errorと定義されています。
まとめ：ASTERIA Warpでも連携先の知識は必要だった
私はASTERIA Warpを使い、フローの作成・修正と、DB・FTP・REST連携の設定・実装を経験しました。
私の経験では、画面上で連携フローを作成できても、REST連携ではHTTPメソッド、URI、Content-Type、HTTPステータスコードなど、連携方式そのものの理解も必要でした。
