OmniStudio Integration Procedure を使い始める

学習の目的

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

• OmniStudio Integration Procedure とは何かを説明する。
  
• Integration Procedure の機能と用途をいくつか挙げる。
  
• Integration Procedure の利点を説明する。
  

Integration Procedure の概要

「OmniStudio アーキテクチャ」モジュールを修了している場合は、OmniStudio の設定ツールのスイートや、Salesforce ユーザーがガイド付きユーザーエクスペリエンスを実現するためのリソースについて習得していることと思います。このモジュールでは、OmniStudio のサービス管理レイヤーの基本コンポーネントの 1 つ、OmniStudio Integration Procedure の基本事項を学習します。 

そもそも、OmniStudio Integration Procedure とは何なのでしょうか? これは、Salesforce や外部システムのデータの読み取りや書き込みに使用するアプリケーションです。Integration Procedure は OmniScript や FlexCard などの OmniStudio コンポーネント、API、さらには Apex メソッドからもコールできます。 

Integration Procedure については次のように考えることができます。サードパーティのソースのデータにアクセスして変換する必要があるがユーザー操作は必要ない場合や、ワークロードをクライアントからサーバーに移行することが望ましい場合は、OmniStudio Integration Procedure の使用を検討します。 

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

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

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

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

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

Integration Procedure は複数のデータソースを処理する。Salesforce、外部システム (REST (REpresentational State Transfer) や API (Application Programming Interface) を使用)、Apex クラスからデータを読み取ります。このフローを図示すると次のようになります。

Integration Procedure が各種のテクノロジーのデータソースとして機能する。OmniScript や OmniStudio FlexCard からコールされ、そのコール元にデータを返します。また、API や Apex コードのデータソースとしても機能します。図示すると次のようになります。 

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

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

次に例を示します。Integration Procedure が HTTP Action で、API キーを使用してデータをコールします。このデータは JavaScript オブジェクト表記 (JSON) で取り込まれ、余分な情報も含まれています (1)。アクション要素のプロパティを使用して JSON をトリミングし (2)、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 の詳細を学習します。