Omnistudio Integration Procedure を使い始める

学習の目的

この単元を完了すると、次のことができるようになります。

• Salesforce ヘルプ: 管理パッケージ用 Omnistudio の Integration Procedure について説明する。
  
• Integration Procedure の機能と用途を列挙する。
  
• Integration Procedure の利点を説明する。
  

このモジュールでは、管理パッケージランタイムとカスタムオブジェクトを使用する管理パッケージ用 Omnistudio について説明します。標準ランタイムの Omnistudio についての詳細は、Salesforce ヘルプの「Omnistudio」を参照してください。

このバッジが自分に適しているか確かめたい場合は、「Which Version of Omnistudio Do You Have? (所有している Omnistudio のバージョンは?)」を参照してください。

Omnistudio Integration Procedure について

サードパーティのソースのデータにアクセスして変換する必要があるがユーザー操作は必要ない場合や、ワークロードをクライアントからサーバーに移行することが望ましい場合は、管理パッケージ用 Omnistudio の Omnistudio Integration Procedure の使用を検討します。 

Omnistudio Integration Procedure は、Salesforce や外部システムのデータの読み取りや書き込みに使用するアプリケーションです。Integration Procedure は Omniscript や Flexcard などの Omnistudio コンポーネント、API、さらには Apex メソッドからもコールできます。 

Omnistudio Integration Procedure は、1 回のサーバーコールで複数のアクションを実行する宣言型のサーバー側プロセスです。これが何を意味するのかを理解できるように、この文を分割して考えてみます。 

• 宣言型: 管理パッケージ用 Omnistudio の Integration Procedure Designer でドラッグアンドドロップ要素を使用して、プロセスの構造を構築します。
  
• サーバー側プロセス: 通常はサーバーのほうがクライアントよりデータ処理が高速のため、サーバー側で処理することでパフォーマンスが向上します。
  
• 1 回のサーバーコールで複数のアクション: サーバーへの不要なラウンドトリップが回避されます。ラウンドトリップが増えるとパフォーマンスが低下するため、クライアントとサーバー間のコールを最小限に抑えることにメリットがある。
  

簡単に言うと、Integration Procedure はバックグラウンドでデータを取得、保存、操作するための手段です。Integration Procedure は次のようなシナリオで特に役立ちます。

• サードパーティのソースのデータにアクセスして変換する必要がある。
  
• ユーザー操作が必要ない。
  
• ワークロードをクライアントからサーバーに移行することが望ましい。
  

このモジュールでは、管理パッケージ用 Omnistudio のサービス管理レイヤーの基本コンポーネントの 1 つ、Omnistudio Integration Procedure の基本事項を学習します。 

Integration Procedure の機能

Integration Procedure がこうした目的を遂行できるのも、多くの優れた機能を備えているためです。では、そのいくつかを見ていきましょう。

Integration Procedure は複数のデータソースを処理する。Salesforce、外部システム (REpresentational State Transfer (REST) 経由)、アプリケーションプログラミングインターフェース (API) コール、Apex クラスからデータを読み取ります。

Integration Procedure が各種のテクノロジーのデータソースとして機能する。Omnistudio Omniscript や Flexcard からコールされ、そのコール元にデータを返します。また、API や Apex コードのデータソースとしても機能します。

Integration Procedure はポータブルである。Integration Procedure を一度作成したら、どこででも使用できます。Flexcard でも Omniscript でも同じものを使用できるということです。 

Integration Procedure では必要なデータのみが送受信される。パフォーマンスの検討時に見過ごされがちな要因が、ブラウザーとサーバー間で送信されるデータの量です。Integration Procedure の Response Action は、サーバーからブラウザーに返されるデータをトリミングします。この処理により、低速ネットワークやモバイル接続の使用時の問題の主な要因であるクライアントとサーバー間のデータの転送量を最小限に抑えることができます。 

次に例を示します。Integration Procedure が HTTP Action で、API キーを使用してデータをコールします。このデータは JSON として取り込まれ、余分な情報も含まれています (1)。アクション要素のプロパティを使用して JSON をトリミングし (2)、Omniscript Data Mapper Transform Action に必要なノードのみを送信します (3)。JSON がさらにトリミングされるだけでなく、対応付けをし直したうえでデータをコール元のツールに送信することができます。

Integration Procedure でバッチ処理が実行される。大量のデータが処理されますが、Salesforce でタイムアウトが発生することがありません。 

これまでに見てきたとおり、Integration Procedure は数種の優れた機能を備えています。次は、どのような処理によってデータ管理の作業が容易になるのかを見ていきます。

Integration Procedure の利点

Salesforce では可能な限り Integration Procedure をデータソースとして使用することを推奨しています。なぜでしょうか? 効率性と一貫性を備えた合理的な構造で、あらゆるデータソースの用途に適応させることができ、操作も簡単であるためです。 

これだけではありません。開発者が送受信するデータを細かく管理できるほか、次のようなメリットもあります。  

• 最適な柔軟性を備えている。
  
• 簡単に実装できる。
  
• Flexcard や Omniscript のパフォーマンスを大幅に向上させる。
  

Integration Procedure を使用するもう 1 つの大きな利点は、現在の設計が今後の変更にも対応可能であることです。 

たとえば、Flexcard の設計上、サーバーから何らかのデータが必要であるとします。ただし、そのデータがどのようなもので、どのように取得するかはまだ明確でないことがあります。こうした場合の解決策となるのが Integration Procedure です。

• サンプルデータを使用して Integration Procedure を作成し、Flexcard からその Integration Procedure をコールします。まだバックエンドシステムの準備ができていなくても、カードの設計を進めます。
  
• バックエンドシステムの準備が整った時点で Integration Procedure に変更を行うだけで、すぐに使い始めることができます。Flexcard には触れる必要がありません。
  

このアプローチは、フロントエンドの開発作業とバックエンドの開発作業を隔離しておきたい場合に適した手段です。

こうした利点のほか、Apex クラスの代わりに Integration Procedure を使用する場合にはさらにいくつかのメリットがあります。Integration Procedure を使用した場合の利点の例として次のものが挙げられます。

• メンテナンスや更新がはるかに容易になる。
  
• 開発時間が最大 97% 削減される。
  

この最後のメリットを詳しく見てみましょう。下表は、Omnistudio の実装にカスタム Apex クラスを使用した場合と Integration Procedure を使用した場合の開発時間を比較したものです。

Integration Procedure は、(自分で言うのもなんですが) 非常に便利です。

次の単元では、Integration Procedure Designer の詳細を学習します。 

リソース

• Salesforce ヘルプ: Integration Procedure (管理パッケージ用 Omnistudio)