デジタル変革のような流行語に対する先入観がどうであれ、また、企業内の現在の IT 戦略がどの段階にあろうと、クラウド移行プロジェクトの計画開始時であろうと、レガシー環境の維持と圧倒的多数のクラウド アプリケーションに追われていようと、あるいは、次の行き先を検討しているビジネスでも、アプリケーション、システム、ビジネス間の統合に何らかの形の API を使用している可能性は高いでしょう。
API はどこにでもあります。 ビジネスだけでなく、生活においても、API はどこにでもあります。 実際、API は、直接意識していなくても、企業 IT で使用されており、あなたの周りにあります。
API (アプリケーション プログラミング インターフェイス) は、あるアプリケーションまたはシステム内のデータ、リソース、処理ルーチンに別のアプリケーションからアクセスするための定義された方法です。 API は、クラウドおよび SaaS (Software as a Service) オファリングの重要な部分であり、将来のテクノロジー環境での使用において、その人気は高まり続けるでしょう。
しかし、API 拡張型から API 主導型まで、API は統合ユースケースでどのように活用するのがベストなのかという多くの議論の中心となってきています。
このブログでは、企業が統合を促進するために API を検討し始めることができる 4 つの重要な方法について簡単に触れます。
#1 – 製品の設定、管理、および監視用 API
誰かが「ヘッドレス管理」について議論するとき、このタイプの API 統合が言及されるものです。 ヘッドレス」環境とは、モニター、グラフィカル ユーザー インターフェイス (GUI)、またはキーボードやマウスなどのその他のデバイスなしで動作するコンピューターのことです。
このタイプの API により、管理 GUI で行えるあらゆるタイプの管理をクラウドで行えるようになります。 システムを「ヘッドレス」で実行し、キーボードに向かうことなく、また文字通り物に触れることなく管理することができます。 すべてのデータ管理機能は、REST APIを通じて利用できます。 翻訳や変換をAPIで管理する機能は限られていますが、その設計の一環として、変換がヘッドレスであるため、スタジオとランタイムが分離されています。 そのため、多くの点で、機能がある一方で、埋めるべきギャップも残っています。
取引先、AS2 接続、または証明書を管理するために GUI を使用するのではなく、これらのタスクを達成するために API を使用することになるでしょう。 代わりに、このシナリオをより明確に考えるには、次のようないくつかの主要な製品タスクを自動化する管理用 API であるかのように扱うことです:
- Manage
- Setup
- Configure
ここから次のステップは、データ移動用の REST API を完成させて、データ変換用に「ヘッドレス」戦略を改良することでしょう。
#2 – ファイルをアップロードおよびダウンロードするための API
データ移動の機能を見てみると、通常、複数の安全な通信プロトコルから始めることになるでしょう。 これらのプロトコルは、ファイル ベースの統合に使用される広範囲なもので、FTP、SFTP、AS2、およびよくあるケースとして、個人からシステムへのファイル フローのための安全なポータルが含まれます。 ファイルをアップロードする場合は、REST API を使用してそれを実現できます。また、統合プラットフォームとの間でファイルをプログラム的にアップロードおよびダウンロードするように設定できるサポート API も使用できます。 これらのタイプの API は、企業が従来のデータ移動の中でどのように動作し、その環境において多用途で柔軟なファイル ベースの統合シナリオをサポートできるかに関連しています。
#3 – ツールを使用して、API を使用して他のシステムを接続する
3 つ目の例は、社内システムに対して他のシステムによって提供されている API を中心に展開されます。 基幹業務システムの代表的な例としては、世界のCRM市場の約20％を占めるSalesforceや、ERPの分野で常に優位に立っているNetSuiteなど、挙げればきりがありません。 この場合、Salesforce と NetSuite はこれらの API を提供して、企業がそれらを使用して、ある種のアプリケーション ベースのクラウド統合を行うことができます。
#4 – 他のシステムで使用するための API を提供する Cleo ツールの使用
最後の 4 つめの例は、実際には前の例の反対側で、企業がシステムの API を使用する例です。 ここでは、企業は他の人がアクセスできるようにAPIを提示します。 例えば、製品を注文するためのAPIを提供する。 Salesforceの誰かが、自分たちの環境にアクセスし、APIを通じてプログラムによる操作を行えるようにしたいと考えています。
それは、社外の人が呼び出してアクセスできるAPIを世の中に提示することで実現します。 誰かが製品を注文したり、注文明細を確認したりするための API を提供したい場合、統合技術を使ってその API を構築し、人々が呼び出して自分の注文に何が起こっているかを理解しようとすることができます。
Presenting Vs.
Consuming API
3番目と4番目の例の重要な違いは、3番目の例は他の誰かが提供した API を呼び出したり消費したりしているのに対し、4番目の例は他の人々が呼び出すための API を提供していることです。
***
Cleo Integration Cloud により企業はアプリケーション、システム、取引先の間で部分的に API を使用した摩擦なき統合が行えるようになりました。 クレオはあらゆる種類の統合のための包括的なプラットフォームを提供するため、企業は幅広い統合シナリオに対応し、収益を生み出すビジネス プロセスを接続し自動化できます。
さらに、クレオ統合クラウドは REST および SOAP API の両方を柔軟に使用でき、ビジネスは両方を利用することができます。 さらに、XML や JSON など、両方の種類の API で一般的に使用される形式を変換するために使用できる変換機能が組み込まれています。 さらに、Cleo は、スプレッドシート、データベース、XML ファイルなど、さまざまな B2B 機能とフォーマットもサポートしているので、統合ツール ベルトが API だけに限定されることはありません。
ビジネス中心の相互作用の重要性が増し、エコシステム主導の統合が将来にわたって発展するにつれ、API は従来のファイル ベースの EDI を補強し続けるだけでしょう。 この文脈で、Cleo は API を使用した企業間統合の基盤を提供し、あらゆる統合ニーズを解決する能力を高め、B2B 統合と連動したアプリケーション統合を可能にします
。