| Oracle® Fusion Middleware Oracle WebCenter Sitesでの開発 12c (12.2.1.2.0) E82734-02 |
|
 前 |
 次 |
Oracle WebCenter Sites: Visitor Servicesは、訪問者プロファイル情報をフェッチしてコンパイルします。マーケティング担当者は、この情報を使用して、訪問者のニーズに応じたWebサイト・コンテンツ(製品情報やマーケティング・キャンペーンなど)を提供します。
注意:
Visitor Services固有の用語の詳細は、Visitor Servicesの「用語集」を参照してください。
訪問者のプロファイル情報は、一般に顧客のオンライン・プレゼンス内の様々なシステムで取得されます。ある訪問者が最近、Eloqua電子メールの閲覧、CRMホワイト・ペーパーのダウンロード、またはFacebookやGoogleを介したログインなどを実行した場合が考えられます。各オンライン・アクティビティでは、一連の異なる訪問者属性が収集されます。Visitor Servicesは、これらの訪問者属性を収集し、集計テンプレートを介してその情報を提供します。
Visitor Servicesコンポーネントは、ターゲット設定に使用可能な検出、集計、問合せの各機能を備えています。選択対象の属性を様々な訪問者プロファイルから選択すると、マーケティング担当者が必要とする数の集計テンプレートを作成できます。マーケティング担当者は、訪問者情報を使用して、WebCenter Sitesが提供するページでコンテンツをターゲット設定します。
開発者用のVisitor Servicesタスク
Visitor Services構成では、次に示すように、Adminインタフェース「訪問者の管理」ノードで構成される開発者のタスクが主に含まれます。マーケティング担当者の観点から見たVisitor Servicesの詳細は、『Oracle Fusion Middleware Oracle WebCenter Sitesの使用』のWebCenter Sites: Visitor Servicesの理解に関する項を参照してください。
開発者タスクは次のとおりです。
Visitor Services URLを構成する(「Visitor Services URLの構成」を参照)。
WebCenter SitesでVisitor Servicesを構成するには、インストール時に構成されるVisitor Services URLを識別する必要があります。『Oracle Fusion Middleware Oracle WebCenter Sitesのインストールと構成』のVisitor Services URLの構成に関する項およびVisitor Servicesのデプロイに関する項を参照してください。
シングル・サインオン(SSO)システム用のアイデンティティ・プロバイダを実装および構成し、Visitor Servicesへのサイト訪問者を認証する。「アイデンティティ・プロバイダの構成」を参照してください。
Visitor Servicesには、Oracle Access Managerと統合できるようにOracle Access Managerアイデンティティ・プロバイダが同梱されています。「カスタム・アイデンティティ・プロバイダの作成: 例」で説明されているように、カスタム・アイデンティティ・プロバイダを作成することもできます。
プロファイル情報リクエストを認証するようにアクセス・プロバイダを構成する。「アクセス・プロバイダの構成」を参照してください。
アクセス・プロバイダは、アプリケーションとVisitor Services間で行われたRESTコールを認証します。Visitor ServicesとWebCenter Sites間でセキュアな接続を保持するためのアクセス・プロバイダを使用することをお薦めします。
プロファイル・プロバイダを作成して、訪問者プロバイダをコンパイルおよびエンリッチする。
プロファイル・プロバイダを使用すると、訪問者アイデンティティを訪問者プロファイルに関連付けることができます。Visitor Services内の特定のリポジトリ用のプロファイル・プロバイダを実装および構成し、すべてのプロファイル・プロバイダから訪問者情報を収集するためのエンリッチメント・ルールを作成します。Visitor Servicesには、Eloqua Cloud Marketing Serviceと統合するためのEloquaプロファイル・プロバイダ、Oracle Access Managerと統合するためのOracle Access Managerプロファイル・プロバイダ、およびFacebookプロファイル・プロバイダが同梱されています。「1つ以上のプロファイル・プロバイダの構成」および「プロファイル・プロバイダおよびエンリッチメント・サービスについて」を参照してください。
訪問者プロファイルに基づいてサイト訪問者に返されるデータを決定する集計テンプレートを作成する。「1つ以上の集計テンプレートの作成」および「アイデンティティ・プロバイダについて」を参照してください。
集計テンプレートにより、訪問者プロファイルがリンクされ、様々な訪問者プロファイルからの情報を結合できるようになります。開発者は、訪問者プロファイルからのプロファイル情報を欠落する集計ルールおよびタイプを作成します。
Visitor Servicesからの訪問者プロファイルがどのようにリクエストおよび使用されるかを構成する。
訪問者プロファイルを使用するには、実行時にWebCenter SitesコンポーネントによってVisitor Services API (REST、JAVAまたはJavaScript)を介してこれらがリクエストされる必要があります。Visitor Servicesは、次と統合されます。
Engage: 訪問者プロファイルを使用して、Engageセグメントを決定し、推奨を提供します。たとえば、マーケティング担当者は、年齢や収入などの訪問者プロファイル属性を使用して、セグメントを作成し、推奨を提供できます。匿名ユーザーについては、サイトへのアクセスに使用されたデバイス、タイムゾーン、ロケール、ブラウザ、リファラ(Facebook、Twitter、Bing)またはIPアドレスなどの属性に基づいてこれらのユーザー用のセグメントを作成します。Oracle Fusion Middleware Oracle WebCenter Sitesの使用のEngageアセットの使用を参照してください。
A/B Testing: セグメントを決定するための訪問者プロファイルを使用し、これらのセグメントを使用してA/Bテスト用の訪問者をターゲット設定します。『Oracle Fusion Middleware Oracle WebCenter Sitesの使用』のA/Bテストの使用に関する項を参照してください。
Visitor Services APIリファレンス
Visitor Services Java API: Visitor Servicesのクライアント開発者がカスタム・アイデンティティ・プロバイダ、アクセス・プロバイダ、およびプロファイル・プロバイダ・インタフェース実装を記述するためのJava APIドキュメントを提供します。
Visitor Services Client Java API: Oracle WebCenter SitesやEngageなど、Visitor Servicesと通信して訪問者プロファイル情報を取得するアプリケーションの開発者向けのJava APIドキュメントを提供します。
Visitor Servicesを使用するには、WebCenter Sitesでそのインスタンスを構成する必要があります。Adminインタフェースに用意されているプロパティ管理ツールを使用すると、Visitor Servicesインスタンスを速やかに構成できます。
http://<visitorserviceshost>:<visitorservicesport>/visitors-webappの書式で入力します。Visitor Servicesインスタンスが構成されました。
アイデンティティ・プロバイダは、Visitor Servicesへの訪問者認証のステータスを検索します。OSGiバンドルを使用してアイデンティティ・プロバイダを構成したり、独自のアイデンティティ・プロバイダをOSGiバンドルとして開発できます。
Visitor Servicesで提供されているOracle Access Managerアイデンティティ・プロバイダ(OSGiバンドル)を使用して、Oracle Access Manager (OAM)とVisitor Servicesを統合する。「アイデンティティ・プロバイダ設定の構成」および「Oracle Access Manager (OAM)とVisitor Servicesの統合」を参照してください。
独自のカスタム・アイデンティティ・プロバイダをOSGiバンドルとして開発して、Visitor Servicesに構成する。「カスタム・アイデンティティ・プロバイダの作成: 例」を参照してください。
認証済訪問者: これらの訪問者は、アイデンティティ・プロバイダで認証されます。たとえば、有効なOAMユーザーは、リクエスト・コールでVisitor Servicesに到達するOAMユーザーを識別するために作成された、アイデンティティ・プロバイダによって認証できます。
未認証/匿名の訪問者: このタイプの訪問者はサインインしないため、Visitor Servicesには、このユーザーの属性がありません。Visitor Servicesは匿名の訪問者を識別できませんが、クライアント・アプリケーション(WebCenter Sitesなど)がそれらの登録を明示的に決定すると。これらの訪問者は、登録後に認証済訪問者になります。クライアント・アプリケーションは、後で登録できるように属性を保存できます。Webサイトでは、Visitor Servicesが生成した訪問者IDをCookieに格納して、ユーザー・セッションの関連付けに使用します。
デフォルトのアイデンティティ・プロバイダを使用するか、独自のプロバイダを作成するかに関係なく、このトピックで説明されているアイデンティティ・プロバイダの設定をAdminインタフェースで設定する必要があります。
アイデンティティ・プロバイダを構成する手順:
訪問者アイデンティティ・ヘッダー名: oam.headers.dn=OAM_REMOTE_USER
アイデンティティ記憶域ヘッダー名: oam.headers.identityStorage=OAM_IDENTITY_DOMAIN
匿名訪問者アイデンティティ・ヘッダー値: oam.guest=Anonymous
OAMに埋込みのLDAPが停止し、OAM経由のリクエストがVisitor Servicesに到達しない場合、Visitor Servicesアプリケーションは、LDAPが使用不可である旨のレスポンスを返しません。
この項で説明する手順を実行する前に、Visitor Servicesで提供されているOAMIdentityProviderを構成していることを確認します。OAMアイデンティティ・プロバイダでは、Visitor ServicesがOAMと通信できるようにします。このプロバイダの構成手順は、「アイデンティティ・プロバイダの実装および構成」を参照してください。
この項で説明するOAMとVisitor Servicesの統合後:
Visitor ServicesでOAMプロファイル・プロバイダを構成します。このプロファイル・プロバイダは、実際のデータをOAM記憶域から取得します。プロファイル・プロバイダを構成する手順は、「プロファイル・プロバイダおよびエンリッチメント・ルールの実装および構成」で説明しています。
統合が成功したことを確認します。
注意:
OAMとVisitor Servicesの統合は、標準の実装である必要があります。
OAM Mobile & SocialとVisitor Servicesを統合する手順:
OAM管理コンソール(http://host:port/oamconsole)にアクセスします。
「アプリケーション・ドメイン」タブをクリックし、アプリケーション・ドメインを作成します。
図53-4 アプリケーション・ドメイン
保護ポリシーを作成するには、次のようにします。
「アプリケーション・ドメイン」ページの「認証ポリシー」タブで、「認証ポリシーの作成」をクリックします。
図53-5 認証ポリシー
「認証ポリシー」ページの「認証スキーム」ドロップダウン・リストから、「OICSchema」を選択してoicpolicyをコールします。
リソース用に追加をクリックし、/index.htmlを追加し、「適用」をクリックします。
図53-6 「認証ポリシー」 - 「認証スキーム」
「認証ポリシー」ページで、リソース・ポリシーの保護をクリックします。
「認証スキーム」ドロップダウン・リストから、「LDAPSchema」を選択して、OAMがLDAPを認証モジュールとして使用するようにします。
リソース用に追加をクリックし、/sites/avi/home.html , /**を追加し、「適用」をクリックします。
「起動パッド」から、「認証モジュール」を開きます。次に、LDAPモジュールに使用されるアイデンティティ記憶域を確認します(Oracle Acceses Managerの管理者ガイドを参照)。この記憶域は、LDAPプロファイル・プロバイダの構成時に使用されます。
「検索」で、「リソース・タイプ」ドロップダウン・リストから「HTTP」を選択して、「検索」をクリックします。次のリソースが検索結果で返されない場合は、それらを追加します。
/index.html
/visitor-webapp/rest/*/visitor/**
/visitors-webapp/rest/*
/visitors-webapp/rest/*/visitor/current/**
/sites/avi/*.*
/visitors-webapp/**
/sites/avi/home.html
/**
/visitors-webapp/rest/*/visitor/**の場合は、保護レベルとして「除外」を選択します。
/visitors-webapp/rest/*/visitor/**の場合は、保護レベルとして「非保護」を選択します。
図53-7 HTTPリソース・タイプ
SSOエージェントを作成します。
「起動パッド」で、「SSOエージェント登録」をクリックします。
「11g Webゲート」を選択します。
フォームに入力します。
図53-8 svsSSOAgent
Oracle HTTP Server (OHS)を構成します。
Enterprise Manager (http://host:port/em)にアクセスします。
ナビゲーション・ツリーで「Web層」を開いてから、OHSインスタンスを選択します。
新しい仮想ホストを作成するには、「管理」を選択して、「Oracle HTTP Server」ドロップダウン・メニューから「mod_wl_ohs構成」を選択します。
図53-9 mod_wl_ohs構成
mod_wl_ohs.confファイルを編集します。
WebLogicClusterディレクティブを含むセクションで、DynamicServerListをOFFに設定します。
mod_wl_ohs.confファイルを保存して、OHSを再起動します。
Mobile and Socialを構成します。:
「起動パッド」から、「ソーシャル・アイデンティティ」を開きます。
アプリケーション・ドメインの作成中に指定したものと同じ名前でアプリケーション・プロファイルを作成します。
アプリケーション・ユーザー属性とインターネット・アイデンティティ・プロバイダ・ユーザー属性をマップします。
図53-10 アプリケーション・ユーザー属性とインターネット・アイデンティティ・プロバイダ・ユーザー属性のマッピング
「プロファイル・プロバイダおよびエンリッチメント・ルールの実装および構成」の説明に従い、プロファイル・プロバイダを構成します。
参考のため、次にOAMでJavaScriptクライアントを使用できるようにするサンプル・コードを示します。
<html>
<head>
<title>Sample Page</title>
//Assuming OAM is at 'http://<host>:<port>',(Actual Visitor Service application may be deployed somewhere else. Its location must be registered with OAM),
//use OAM server in URLs for Visitor Services to go to the Visitor Services application via OAM so that the identity token set by OAM is available to Visitor Services.
<script src="<host>:<port>/visitors-webapp/js/client.js"></script>
</head>
<body>
<script type="text/javascript">
var handleSuccess = function( visitorId )
{
// Got visitorId
console.log("visitor id received from visitor Services = "+visitorId);
};
var handleError = function(error)
{
conole.log(error.errorCode);
};
var client = new com.oracle.sites.visitors.Client("<host>:<port>/visitors-webapp"); //URL having OAM instance as server part
client.getVisitorId(handleSuccess,handleError);
</script>
</body>
</html>
OAMとVisitor Servicesの統合の確認
Visitor Services JavaScriptクライアントを使用して訪問者IDを取得します。この場合、WebCenter Sitesのページはポリシー'protected'によりOAMで保護され、OHS経由でコールできます(これにより、ユーザー・ログインがOAMから要求されます)。ユーザーは、各自の資格証明を指定し、JavaScriptクライアント・コードが存在するページにランディングできます。JavaScriptクライアントによって受信される訪問者IDは、OAM認証済の訪問者IDです。Visitor Servicesのホストとポートではなく、OHS仮想ホストとポートを使用します。OAMIdentityProviderによってリクエストから取得されるため、外部IDは指定しないでください。コールごとに訪問者IDを生成します。
外部ユーザーを使用してVisitor Servicesにログインします。
手順1の説明に従い、訪問者IDを取得します。ユーザーIDは、最初のコールで生成し、コールごとに同じにならないようにする必要があります。
手順3で生成したユーザーに対して、Visitor Services REST APIを使用して、訪問者のリンク済プロファイルの取得を試みます。
OAMアイデンティティ・プロバイダは、デフォルトでVisitor Servicesで提供されます。この項では、例を利用したカスタム・アイデンティティ・プロバイダの実装について説明します。
次のポイントでは、サンプル・アイデンティティ・プロバイダの実装について説明します。
すべてのアイデンティティ・プロバイダはOSGiバンドルである必要があり、プロバイダをFelixランタイムに登録するには、このバンドルをプロバイダ実装とアクティベータで構成する必要があります。
実装クラスでは、最初にアイデンティティ・プロバイダ・インタフェースを実装してから、プロファイル・プロバイダ・インタフェースを実装する必要があります。アイデンティティ・プロバイダ・インタフェースは、完全に実装された次のメソッドの少なくとも1つを使用して実装する必要があります。
getVisitorIdentity(String externalId);を特定します
getVisitorIdentity(HttpServletRequest request);を特定します
次の例に示すメソッドでは、アイデンティティ(識別名(dn)のみ)を返し、このアイデンティティは、プロファイル情報をフェッチするためにプロファイル・プロバイダに渡されます。
package com.oracle.sites.visitors.api.providers;
import ...
public interface IdentityProvider
{
String getProviderName();
void setProviderConfig(Properties config);
Identity getVisitorIdentity(HTTPServletRequest request);
}
アイデンティティ・プロバイダを実装するサンプル・コードを次に示します。この実装では、プロバイダ名およびユーザーdnで構成される外部IDを使用します。
public class SampleIdentityProvider implements IdentityProvider
{
private static final String PARAMETER_EXTERNAL_ID_NAME = "parameter.external_id";
private static final String COOKIE_NAME_ATTRIBUTE_NAME = "cookie.external_id";
@override
public Identity getVisitorIdentity)HttpServletRequest request)
{
String externalId = getExternalIdFromCookie(request);
if (null ==externalId || externalId.isEmpty())
{
externalId = getExternalIdFromParams(request);
}
//Returns an identity object based on external id
return getVisitorIdentity(externalId);
}
システムは、前述で返されたアイデンティティ・オブジェクトでプロファイル・プロバイダをコールします。ユーザーが訪問者IDをリクエストするたびに、将来使用できるように、外部ID (プロバイダおよびdn)がCookieに格納されます。
OSGiバンドルでは、バンドルに含まれるコードのアクティブ化にアクティベータ・クラスが必要です。サンプル・アイデンティティ・プロバイダを登録できるアクティベータ・クラスを記述します。
public class Activator implements BundleActivator {
/**
* Implements BundleActivator.start(). Prints
* a message and adds itself to the bundle context as a service listener.
* @param context the framework context for the bundle.
**/
public void start(BundleContext context)
{
context.registerService (ProfileProvider.class.getName(),
new SampleProfileProvider(context.getBundle().getLocation()), null);
}
/**
*Implements BundleActivator.stop().Prints a message
*and removes itself from the bundle context as a service listener.
*@param context the framework context for the bundle.
**/
public void stop(BundleContext context)
{
}
}
「アイデンティティ・プロバイダの構成」で説明されている次の手順に従い、アイデンティティ・プロバイダを構成します。
アクセス・プロバイダは、訪問者プロファイル情報に対するアプリケーションのアクセスを制御します。アクセス・プロバイダ・サービスは、RESTクライアントと組み合せて機能します。たとえば、コンテナ保護認証の場合、Visitor Servicesの基本認証設定でアクセス・プロバイダ・バンドルをアップロードし、同じ認証タイプをRESTクライアントで設定する必要があります。
アクセス・プロバイダ・リファレンスを参照してください。
Visitor Servicesには、LDAPディレクトリに対する認証を行うために基本的なLDAPアクセス・プロバイダが同梱されています。
この項の手順に従い、アクセス・プロバイダとVisitor Servicesを一緒に使用できるようにします。
訪問者アクセス・プロバイダ・フォームが表示されます。
プロファイル・プロバイダを使用すると、訪問者アイデンティティを訪問者プロファイルに関連付けることができます。Visitor Servicesには、Eloquaと統合するためのEloquaプロファイル・プロバイダ、Oracle Access Manager用のOracle Access Managerプロファイル・プロバイダ、およびサンプル・プロファイル・プロバイダが同梱されています。
プロファイル・プロバイダ・リファレンスを参照してください。
Visitor Servicesで提供されているEloquaを使用する。「Eloquaプロファイル・プロバイダの構成について」を参照してください。
Visitor Servicesで提供されているOracle Access Managerプロファイル・プロバイダ(OSGiバンドル)を使用する。「プロファイル・プロバイダ設定およびエンリッチメント・ルールの構成」を参照してください。
独自のカスタム・プロファイル・プロバイダをOSGiバンドルとして開発して、Visitor Servicesに構成する。「カスタム・プロファイル・プロバイダの作成: 例」を参照してください。
注意:
プロファイル・プロバイダの属性を設定したら、その名前を変更しないでください。プロファイル・プロバイダおよびエンリッチメント・ルールを構成する手順:
「プロファイル・プロバイダ・リスト」ページが表示されます。
表53-3 LDAPプロファイル・プロバイダの構成パラメータ
| パラメータ | 値 |
|---|---|
LDAPアドレス |
書式: |
ユーザーの基本識別名 |
|
管理者(admin)の識別名 |
|
パスワード |
管理者(admin)のパスワード。 |
ユーザー・ログイン名として使用されるLDAP属性 |
デフォルトは |
サポートされているLDAP objectClasses |
|
LDAPプロファイル属性 |
|
Eloquaプロファイル・プロバイダを使用するには、次を実行する必要があります。
Eloquaプロバイダ・インスタンスの詳細を「構成」ボックスに入力していることを確認します。
例:################################################################################################### #### ELOQUA SETTINGS ################################################################################################### ## Auth Settings ####################################### # # Client's Company name # company = OraclePOC # # Client's user name # user = username # # Client's user password # password = password ## Proxy Settings ####################################### # # Use proxy in provider # useProxy = true # # Proxy server host # proxyHost = www-proxy.us.oracle.com # # Proxy server port # proxyPort = 80 # # Proxy server type # This can be "DIRECT", "HTTP", or "SOCKS" # proxyType = HTTP ## Search Settings ####################################### # # Eloqua REST URL # restUrl = https://secure.eloqua.com/API/REST/1.0 # # Depth or level of visitor detail returned. # This can be "minimal", "partial", or "complete". # searchDepth = partial
Eloquaプロファイル・プロバイダを有効にするには、最初に、左側のAdminツリーの 「プロファイル・プロバイダ」ノードをダブルクリックして、「プロファイル・プロバイダ・リスト」に移動します。次に、Eloquaプロファイル・プロバイダの「有効化」チェック・ボックスを選択します。
注意:
Eloquaでは、電子メール・ベースの検索をサポートしていません。したがって、Eloquaの電子メール・フィールドに基づいたエンリッチメント・ルールは機能しません。サポートされるのは、IDベースの検索のみです。EloquaのユーザーIDが識別され、プロファイル・プロバイダが訪問者プロファイルの詳細をフェッチできるように、アイデンティティ・プロバイダが構成されていることを確認します。Visitor Servicesには、LDAPプロファイル・プロバイダ、Eloquaプロファイル・プロバイダおよびサンプル・プロファイル・プロバイダがパッケージされています。次のポイントでは、カスタムCSVプロファイル・プロバイダの実装について説明します。
すべてのプロバイダはOSGiバンドルである必要があり、プロバイダをFelixランタイムに登録するには、このバンドルをプロバイダ実装とアクティベータで構成する必要があります。
実装クラスでは、最初にアイデンティティ・プロバイダ・インタフェースを実装してから、プロファイル・プロバイダ・インタフェースを実装する必要があります。
次の例に示すプロファイル・プロバイダ・メソッドは、プロファイル情報をフェッチします。
public interface ProfileProvider
{
String getProviderName();
RawProfile getProfile(String dn);
List<RawProfile> search(String attribute, String value);
void setProviderConfig(Properties config);
サンプル・プロファイル・プロバイダを登録できるアクティベータ・クラスを記述します。
public class Activator implements BundleActivator {
/**
* Implements BundleActivator.start(). Prints
* a message and adds itself to the bundle context as a service listener.
* @param context the framework context for the bundle.
**/
public void start(BundleContext context)
{
context.registerService (ProfileProvider.class.getName(),
new SampleProfileProvider(context.getBundle().getLocation()), null);
}
/**
*Implements BundleActivator.stop().Prints a message
*and removes itself from the bundle context as a service listener.
*@param context the framework context for the bundle.
**/
public void stop(BundleContext context)
{
}
}
次のサンプル実装では、アイデンティティ・オブジェクトに渡されるdnを使用して、未加工のプロファイル情報を取得できます。プロファイルは*.csvファイルからロードされます。
ID,Name,Email,Address,Country,City
1,Alek,Alek.Z@mycompany.com,Kyiv,Ukraine,Kyiv
2,Avi,avi.n@mycompany.com,Gachibowli,India,Hyderabad
3,Joe,Joe.d@mycompany.com,Miyapur,India,Hyderabad
4,Reva,reva.p@mycompany.com,Kukatpally,India,Hyderabad
@Override
public RawProfile getProfile(String dn) {
List<CSVProfile> profiles = csvManager.getProfiles();
CSVProfile selected = null;
for (CSVProfile p : profiles) {
if (p.getName().equalsIgnoreCase(dn)) {
selected = p;
break;
}
}
if (selected == null)
return null;
RawProfile rawProfile = new RawProfile();
rawProfile.setUserId(selected.getId());
rawProfile.setProviderId(getProviderName());
rawProfile.setAttributes (getAttributes (selected));
return rawProfile;
}
private JsonObject getAttributes(CSVProfile csvProfile)
{
JsonObject attributes = new JsonObject();
attributes.addProperty("email", csvProfile.getEmail());
attributes.addProperty("address", csvProfile.getAddress());
attributes.addProperty("country", csvProfile.getCountry());
attributes.addProperty("city", csvProfile.getCity());
return attributes;
}
サンプル・プロファイル・プロバイダを登録できるアクティベータ・クラスを記述します。
public class Activator implements BundleActivator {
@Override
public void start(BundleContext bundleContext) throws Exception {
bundleContext.registerService(ProfileProvider.class.getName(),
new CSVProfileProvider(bundleContext.getBundle().getLocation()), null);
}
@Override
public void stop(BundleContext bundleContext) throws Exception {
}
}
「1つ以上のプロファイル・プロバイダの構成」で説明されている手順に従い、プロファイル・プロバイダを構成します。
集計テンプレートを利用すると、訪問者プロファイルに基づいて、どの情報をサイトの訪問者に送信するかを決定できます。たとえば、集計テンプレートをEngageからコールして、推奨に使用する属性を特定できます。集計テンプレートは、VelocityまたはJavaScriptを使用して作成できます。
集計テンプレート・リファレンスを参照してください。
「集計テンプレート・リスト」ページが表示されます。
集計テンプレートを作成するためのサンプルのVelocityコード
#set( $sn ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).sn} != "null")
#set( $sn = ${profiles.LDAPProfileProvider.get(0).sn.getAsString()})
#end
#set( $displayName ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).displayName} != "null")
#set( $displayName = ${profiles.LDAPProfileProvider.get(0).displayName.getAsString()})
#end
#set( $mail ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).mail} != "null")
#set( $mail = ${profiles.LDAPProfileProvider.get(0).mail.getAsString()})
#end
#set( $homePhone ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).homePhone} != "null")
#set( $homePhone = ${profiles.LDAPProfileProvider.get(0).homePhone.getAsString()})
#end
#set( $name ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).name} != "null")
#set( $name = ${profiles.LDAPProfileProvider.get(0).name.getAsString()})
#end
#set( $description ="Not Provided")
#if(${profiles.LDAPProfileProvider.get(0).description} != "null")
#set( $description = ${profiles.LDAPProfileProvider.get(0).description.getAsString()})
#end
#else
#set( $otherProvider = "other profile provider used.")
#end
#if (${profiles.has("LDAPProfileProvider")})
{
"Name ": "$name",
"displayName ": "$displayName",
"description ": "$description",
"sn ": "$sn",
"mail ": "$mail",
"homePhone ": "$homePhone"
}
#else
{
"otherProvider ": "$otherProvider"
}
#end
次の例に、複数のプロファイル記憶域から訪問者情報をまとめたサンプルの集計テンプレートを示します。このサンプルは、前述のVelocityコードと同じように機能するJavaScriptコードです。
function aggregate()
{
var result={};
if(profiles.get("LDAPProfileProvider"))
{
var NOT_PROVIDED_LABEL = "Not Provided";
var internalAttrs = JSON.parse(profiles.get("LDAPProfileProvider").get(0).getAttributes());
result.Name = internalAttrs.name || NOT_PROVIDED_LABEL;
result.displayName = internalAttrs.displayName || NOT_PROVIDED_LABEL;
result.description = internalAttrs.description || NOT_PROVIDED_LABEL;
result.sn = internalAttrs.sn || NOT_PROVIDED_LABEL;
result.mail =internalAttrs.mail || NOT_PROVIDED_LABEL;
result.homePhone = internalAttrs.homePhone || NOT_PROVIDED_LABEL;
}
else
{
result.otherProvider = "other profile provider used.";
}
return result;
}
訪問者の経験を最適化できるように、拡張属性およびアクティビティは訪問者の複数のプロファイルから訪問者情報を収集します。また、Visitor ServicesをEngageと統合することもできます。WebCenter Sitesでは、ページ作成者がこの情報を使用して、セグメントと推奨を設計し、関連するコンテンツを対象ユーザーに表示します。マーケティング担当者は、Visitor Servicesデータをターゲット設定、テストおよび分析に使用します。
訪問者IDをリクエストする。
指定した集計テンプレートを使用して、訪問者プロファイルをリクエストする。
集計済テンプレートと指定した属性を返します。
この項には次のトピックが含まれます:
Visitor ServicesとWebCenter Sitesなどのクライアント・アプリケーション間の通信を有効にするために、Visitor Servicesでは、Visitor Servicesをヒットするためにクライアント・アプリケーションで実行されるクライアントAPI (JavaおよびJavaScript)を提供しています。Visitor Servicesでは、サーバー側およびクライアント側のJavaScript用のJavaクライアントをデフォルトで提供しています。Javaクライアントは、Visitor Servicesおよびアプリケーションがサーバー側からプロファイル情報にアクセスしようとした場合に使用されます。JavaScriptクライアントAPIは、訪問者がブラウザからアプリケーションを使用して、Visitor Servicesと通信しようとした場合に使用されます。JavaクライアントAPIとJavaScriptクライアントAPIの違いは、JavaクライアントAPIが、WebCenter Sitesのサーバー側コードなど、信頼できるアプリケーション内部で実行することを想定していることです。したがって、これらのアプリケーションには、訪問者データに対する一部の機密操作(更新操作)を処理する前に、訪問者自身の認証に使用可能な資格証明が含まれます。JavaScriptクライアントはブラウザの内部で実行されるため、十分にセキュリティ保護されません。したがって、現在の訪問者の情報の読取りしかできないようになっています。Visitor Servicesでは、信頼できるアプリケーションにすべての訪問者のプロファイルの情報を提供します。訪問者には、自身の情報のみが提供されます。
JavaおよびJavaScriptクライアントAPIには、これらの関数が共通して含まれます。ただし、JavaScriptの場合、この関数は現在/ログインしている訪問者を対象にします。
GetVisitorId: SSOソリューションに格納されている外部IDを使用して、訪問者のIDをVisitor Servicesから取得します。JavaScript APIでは、この関数はGetCurrentVisitorIdと呼ばれます。現在のユーザーの訪問者IDをVisitor Servicesから取得します。
GetAggregatedProfile: 既存の訪問者のIDを使用して、集計済プロファイルをVisitor Servicesから取得します。JavaScript APIでは、この関数はGetCurrentAggregatedProfileと呼ばれます。現在のユーザーの集計済プロファイルをVisitor Servicesから取得します。
0日から任意の正数(1 = 1日)でプロファイルの有効期間を設定できます。有効期間により、外部記憶域からフェッチしたプロファイル情報リフレッシュされるまで、この情報がVisitor Services内に保持される日数が決定されます。有効期間を指定しない場合、プロファイル情報はリフレッシュされません。「一般構成」ページ(「訪問者の管理」ノードの「一般構成」ノードからアクセス)には、プロファイル更新期間構成が表示されます。この情報を編集して、有効期間を設定します。
IsExists: 訪問者IDがデータベースに存在するかどうかを確認します。ゲストまたは一部のプロファイルが登録されたユーザーが存在しているかどうかに関係なく、訪問者IDがデータベースに存在している場合は、レスポンスがtrueになります。JavaScript APIでは、この関数はIsCurrentExistsと呼ばれます。訪問者IDがデータベースに存在するかどうかを確認します。ゲストまたは一部のプロファイルが登録されたユーザーがデータベースに存在しているかどうかに関係なく、訪問者IDがデータベースに存在している場合は、レスポンスがtrueになります。
IsGuest: 訪問者のプロファイルがデータベースにないことを確認します。訪問者情報が存在するかどうかに関係なく、いずれの場合も、レスポンスがtrueになります。JavaScript APIでは、この関数はIsCurrentGuestと呼ばれます。このゲスト訪問者の訪問者プロファイルがデータベースに存在しないことを確認します。ゲスト訪問者がデータベースに格納されているかどうかに関係なく、いずれの場合も、レスポンスがtrueになります。
Javaクライアントはサーバーで実行されますが、JavaScriptはWebブラウザから実行されます。両方のURLは、構造が異なります。例:
信頼できるアプリケーションに対するJava REST関数: http://visitorserviceshost:visitorservicesport/visitors-webapp/rest/v1/visitor/id/690b507b-efb6-4c35-9e6e-0c9f2a28b37d/profile/aggregated/arrg
このURLでは、id/690b507b-efb6-4c35-9e6e-0c9f2a28b37dになることに注意してください。これは、指定した訪問者ID (次のポイントに示すように、ログインしている訪問者のcurrentがその場所で使用されます)。
信頼できない訪問者に対するJavaScript REST関数: http://visitorserviceshost:visitorservicesport/visitors-webapp/rest/v1/visitor/current/profile/aggregated/arrg
前述のURLでは、訪問者IDパスがcurrentコンテキスト(信頼できない訪問者は自身の情報しか参照できないことを示す)で置き換えられます。信頼できない顧客に対するすべてのRESTコールには、currentコンテキストが含まれます。
すべてのアプリケーションがOAMにデプロイされると、Oracle HTTP Protectionが「除外」セキュリティ・タイプに設定されます。データがすでに準備されているプロファイル情報をクライアント・アプリケーションがリクエストすると、Visitor Services JavaクライアントAPIの送信リクエスト(準備済のデータがこれらのアプリケーションに提供されます)をVisitor Servicesの独自の保護によって保護できます。
コンテナ保護: ユーザーに関するすべての情報はコンテナ記憶域に格納され、Visitor Servicesはユーザーのロールのみをチェックします。クライアントのWebサーバーで基本認証が可能な場合は、コンテナ保護を使用することをお薦めします。
Visitor Services保護: クライアントのWebサーバーが基本認証メカニズムをサポートしていない場合は、Visitor Services保護を使用します。
Visitor Services APIを使用して独自のアクセス・プロバイダを実装して、Adminインタフェースでプロバイダをアップロードすることもできます。
注意:
updatedパラメータ・セットをfalseに設定して、集計済またはリンク済プロファイルのリクエストが処理されると、期限切れのプロファイルに対するVisitor Servicesの動作は次のようになります。 Visitor Services用に構成されたJMS: 現在のリクエストで古いプロファイル・データが返され、その間にVisitor Servicesがプロファイルをバックグラウンドで更新して、プロファイル・データを随時リフレッシュします。
Visitor Services用に更新されていないJMS: バックグランド処理機能はJMSに依存しているため、更新されたプロファイルをリクエスト・コールで返します。
各アプリケーションには、REST APIにアクセスするための独自の資格証明をそれぞれ含めることをお薦めします。Visitor Servicesは、このアクセスを自身で確認します。信頼できないアプリケーションのVisitor Services REST APIは、SSOによってセキュリティ保護され、OAMでは、保護レベルが「非保護」に設定されます。Visitor Servicesには、保護されているRESTリソースはありません。コンテナ保護を使用することをお薦めします。
Oracle Fusion Middleware Oracle WebCenter Sites: Visitor Services Java APIリファレンスを参照してください。
Visitor ServicesとEngageを統合し、セグメントと推奨に使用できるように、訪問者情報を収集してEngageに提供できます。WebCenter Sitesでは、ページ作成者がこの情報を使用して、セグメントと推奨を設計し、関連するコンテンツを対象ユーザーに表示します。Visitor Servicesからプロファイル情報を取得するために、開発者またはページ作成者は、訪問者情報を収集して属性として格納されるように設計された、訪問者属性フォームの「値ソース」フィールドを使用します。
oracle.fatwire.integrations.svs.VisitorServiceHelperクラスを使用して、現在の訪問者のプロファイル情報を取得し、訪問者のCookieライフ・サイクルを管理できます。
Webサイトに「ホーム」ページと「マイ・アカウント」ページがあるとします。訪問者が、Visitor Servicesアイデンティティ・プロバイダ・サービスを使用して「ホーム」ページにログインしていない場合、ページ内部のヘルパーAPIコード(helper.getProfile(ics,aggregationTemplateName,..))がブラウザのゲストIDをCookieとして設定します。(ゲストIDにはプロファイル情報がないことに注意してください。)「マイ・アカウント」ページへのリンクが認証メカニズムで保護されており、「マイ・アカウント」ページにアクセスする前に、アイデンティティ・プロバイダ・サービスを使用して訪問者がログインしている場合、その訪問者は認証済訪問者になります。ただし、ヘルパーAPIは「ホーム」ページのブラウザCookieにすでにゲストIDを設定しているため、「マイ・アカウント」ページ・コード内でupdateNowパラメータをtrue (helper.getProfile(ics,aggregationTemplateName,true))として渡すことで、ブラウザのCookieを更新する必要があります。Cookieが更新されていない場合、「マイ・アカウント」ページは認証済訪問者IDと関連のプロファイル情報を受け取らず、Cookieからゲスト訪問者IDを使用し続けます。
この例では、「マイ・アカウント」ページで次のコードを使用します。
VisitorServiceHelper helper = VisitorServiceHelper.getInstance(); Helper. getProfile(ics,<someAggregationTemplateName>,true);
ブラウザCookieからの訪問者IDがNULLの場合、訪問者が認証済ページに直接ランディングしたことを示します。それ以外の場合は、ゲストIDになり、IDがVisitor Servicesに存在せず、ローカル・ブラウザのみにキャッシュされたことを示します。この場合は、新しい訪問者IDを生成して、Cookieの値を置き換えます。
Cookieからの訪問者IDがVisitor Servicesに存在する場合は、Cookieが2つのIDをリンクするため、このIDを使用し続けます。これは、CookieのゲストIDが「マイ・アカウント」ページで使用される前に、明示的に登録されると発生します。「ホーム」ページのコードは、このAPIをコールするか(ブール・パラメータをfalseとして渡す)か、2つのパラメータ(ヘルパー、getProfile(ics,<someAggregationTemplateName>)、このパラメータはデフォルトでfalseと想定)のみを指定する別のメソッドをコールします。
この項では、拡張属性およびアクティビティと、それらがVisitor Servicesでどのように機能するかについて説明します。この項には、次の項目が含まれます。
拡張属性は、言語、ロケール、性別などの訪問者の特性に基づきます。拡張属性は、訪問者ID別に訪問者に関連付けられ、名前および値が含まれます。これらの属性は、アプリケーションに固有です。アプリケーションの承認により、これらの属性はVisitor Servicesに格納され、他のアプリケーションによって使用されます。たとえば、Engageからの拡張属性が承認されると、他のアプリケーションで使用できます。
拡張アクティビティは、Webサイト上での訪問者のアクティビティに基づきます。たとえば、ページを開く、検索の実行、入札など、アクティビティは訪問者ID別に関連付けられ、タイプ、データ、タイムスタンプおよび評価が含まれます。これらのアクティビティは、アプリケーションに固有です。アプリケーションの承認により、これらのアクティビティはVisitor Servicesに格納され、他のアプリケーションによって使用されます。
拡張アクティビティおよび属性は、訪問者のすべてのプロファイルから収集されます。つまり、訪問者に複数のリンク済プロファイルがある場合、get rated(latest)関数はすべてのプロファイルで同じ結果を返します。
Javaクライアントを使用したRESTでのアクティビティの追加: 例
VisitorsClient client = new VisitorsClient(..);
Map<String,String> acts = new HashMap<>();
acts.put("product", " dell v560"); // type,data
acts.put("catalog", " laptops");
acts.put("web_page", "http://online.store.com/dell/v560");
client.addActivity("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", acts);
Javaクライアントを使用したRESTでのアクティビティの取得: 例
can get activities using two types:
getRated: fetches most rated activities
getLatest: fetches latest activities
getRated Method:
VisitorsClient client = new VisitorsClient(..);
List<Activity> res = client.getRated("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", "product", 5);
getLatest Method:
VisitorsClient client = new VisitorsClient(..);
List <Activity>res = client.getLatest("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", "product", 5);
5 - count. How many activities are needed
Javaクライアントを使用したRESTでの拡張属性の追加: 例
VisitorsClient client = new VisitorsClient(..);
Map<String,String> attrs = new HashMap<>();
attrs.put("language", "en"); // name,value
attrs.put("gender", "male");
client. saveExtendedAttributes ("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", attrs);
拡張属性は、Visitor Servicesで集計およびエンリッチメントに使用できます。
集計: リンクされたプロファイルには、extendedという名前の追加のプロファイルがあり、訪問者のすべての拡張属性が含まれます。
エンリッチメント: 拡張属性構成の値として、拡張属性のエンリッチメント・ルールを追加できます。Visitor Servicesでは、これらのエンリッチメント・ルールを使用して、訪問者プロファイルをエンリッチします。拡張属性の例は、訪問者がWebサイトでコールバック用に残す電話番号です。この番号は、訪問者のプロファイルを他のプロファイル・ストアから検索するために、訪問者の拡張属性としてVisitor Servicesで使用できます。したがって、この例のエンリッチメント・ルールは、callback_phone=LDAP:Personal_Phoneになります。
次のプロセス・フローには、サンプルのオンライン・ストア、訪問者およびVisitor Servicesアクティビティ機能が含まれます。
訪問者がブラウザを開き、http://online.store.com/dell/v560にアクセスしてDell v560ラップトップを選択します。
URLがhttp://online.store.com/dell/v560のページのリクエストをブラウザがWebサーバーに送信します
必要なデータをWebサーバーが計算し、次の操作を実行します。
(オプション)データベースからデータをフェッチします。
(オプション)Visitor Servicesに訪問者の興味をリクエストし、最も関連性のある/関心(評価)のある商品に関する広告を表示できるようにします。
サンプル・コード: List<Activity> res = client.getRated("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", "product", 5);
この訪問者はLenovoラップトップに関心があることをVisitor Servicesが返します(この情報は前のアクティビティに基づきます)。
Lenovoラップトップに関連する広告を表示します。
(オプション)訪問者の最近のアクティビティを保存し、アクティビティを追加するようにVisitor Servicesにリクエストします。
最初: visited page = 'http://online.store.com/dell/v560'
2番目: product = 'dell v560'
サンプル・コード:
Map<String,String> acts = new HashMap<>();
acts.put("product", " dell v560'");
acts.put("web_page", "http://online.store.com/dell/v560");
client.addActivity("c11e123e-7fd0-4e55-9f6f-ef581e30d86a", acts);
次に、Visitor Servicesアーキテクチャ、データ・モデル、集計テンプレートおよびプロバイダ(アイデンティティ、プロファイル、アクセスなど)に関する情報を示します。
Visitor Servicesは、様々なプロファイル記憶域から訪問者のプロファイルをフェッチし、開発者が訪問者プロファイル情報(都市、教育、興味、ジョブ・プロファイルなど)を様々なプロファイル属性としてリポジトリに格納します。Visitor Servicesでは、使用状況の追跡および効果的なコンテンツ・ターゲット設定のための訪問者プロファイルの問合せ、エンリッチ、格納およびリンクを開発者が行うこことができます。
Visitor Servicesは、アプリケーションによってリクエストされたユーザー・データを収集するプロファイル・プロバイダ経由でプロファイル記憶域と通信します。ユーザー情報にアクセスするために、Visitor Servicesは顧客のシングル・サインオン(SSO)ソリューションを利用します。Visitor Servicesでは、アイデンティティ・プロバイダを使用して、SSOソリューションと通信します。
この図は、Visitor Servicesアーキテクチャを示しています。Visitor Servicesには、次の統合レイヤーが含まれます。
プロファイル・プロバイダ: Visitor Servicesとプロファイル記憶域間の通信を可能にします。
アイデンティティ・プロバイダ: Visitor ServicesとSSOソリューション間の通信を可能にします。
RESTサービス: Visitor ServicesとそのクライアントAPI間の通信を可能にします。
図53-16 Visitor Servicesアーキテクチャ
これらの統合レイヤーは、Visitor Servicesでカスタムのアイデンティティ・プロバイダおよびプロファイル・プロバイダをサポートするように設計されています。
このリファレンスの内容は次のとおりです。
アイデンティティ・プロバイダ・サービスでは、Visitor Servicesと顧客のSSOシステムの統合を可能にし、Visitor ServicesとSSOシステム間の通信メカニズムを提供します。ブラウザがRESTサービスに訪問者のプロファイルをリクエストすると、RESTサービスはアイデンティティ・プロバイダからアイデンティティ・オブジェクトを要求します。アイデンティティ・プロバイダは、アイデンティティ・オブジェクト(DNとプロバイダで構成)をプロファイル・プロバイダに渡します。ユーザーが記憶域に存在する場合、プロファイル・プロバイダは一意のIDを返します。それ以外の場合、ユーザーはゲスト・ユーザーとして扱われるため、新しい一意のIDが返されます。次に、RESTサービスが訪問者IDをブラウザに返します。
アイデンティティ・プロバイダは、ブラウザCookieチケットなどの一部の識別子を使用して、リクエストされた訪問者に関する次の情報(Visitor Servicesのアイデンティティと呼ばれます)を提供します。
訪問者のログイン名(記憶域の一意の名前)。
訪問者情報が格納される記憶域の名前。
アイデンティティ・プロバイダ機能は、Visitor Servicesアプリケーションの不可欠な部分であり、直接アクセスすることはできません。したがって、訪問者のIDの取得に関するすべてのリクエストは、RESTサービスを介してアイデンティティ・プロバイダに送信されます。一部のSSOソリューションは、Cookieチケットなどの外部IDと連動しますが、HTTPリクエストを入力パラメータとして受け入れるSSOソリューションもあります。アイデンティティ・プロバイダ実装では両方の状況をサポートする必要があることに注意してください。
Visitor Servicesでは、それぞれに一意の訪問者IDを提供することで、Webサイトを識別できます。訪問者は、次のいずれかのタイプとして識別されます。
認証済: Webサイトに登録され、Oracle Access Manager (OAM)やSiteMinderなどのSSOソリューションで自身を認証できる訪問者をVisitor Servicesで識別します。
未認証/匿名: このタイプの訪問者はサインインしないため、Visitor Servicesには、このユーザーの属性がありません。Visitor Servicesは匿名の訪問者を識別できませんが、クライアント・アプリケーション(WebCenter Sitesなど)がそれらの登録を明示的に決定すると。これらの訪問者は、登録後に認証済訪問者になります。クライアント・アプリケーションは、後で登録できるように属性を保存できます。Webサイトでは、Visitor Servicesが生成した訪問者IDをCookieに格納して、ユーザー・セッションの関連付けに使用します。
認証済訪問者プロファイルを処理するために、Visitor Servicesは、OAM MobileやSocialを含む、Oracle Access Manager (OAM)とデフォルトで統合します。他のSSOソリューションの場合、開発者は拡張機能を作成して、カスタム・アイデンティティ・プロバイダを構成できます。
「アイデンティティ・プロバイダの構成」を参照してください。
このサービスは、Visitor Servicesとアプリケーション間の接続の保護に使用されます。Visitor Servicesと対話するクライアントの認証性を確認できるように、基本認証、LDAPベースの認証、その他の認証を構成できます。アクセス・プロバイダ・サービスで認証が構成されていない場合、すべてのリソースはパブリックとみなされ、だれもアクセスできなくなります。本番システムではアクセス・プロバイダを設定することを強くお薦めします。
注意:
クライアント側でアプリケーションとVisitor Servicesの接続に使用されるJavaScript APIは、パブリックAPIとみなされ、アクセス・プロバイダ・サービスではサポートされません。
アクセス・プロバイダ・サービスでは、次のタイプの保護が提供されます。
コンテナ保護: ユーザーに関するすべての情報はコンテナ記憶域に格納され、Visitor Servicesはユーザーのロールのみをチェックします。クライアントのWebサーバーで基本認証の構成が可能な場合は、コンテナ保護を使用することをお薦めします。基本認証では次が必要です。
Webサーバー: user = "username", password="pass", role="svsclient"
アクセス・プロバイダ: access-provider-container-basic.jarバンドルをアップロードします。構成: role= svsclient
RESTクライアント: new HttpAuthentication("username "," pass ")でクライアントを初期化します
Visitor Services保護: ユーザーに関する情報はLDAPやデータベースなどに格納できます。クライアントのWebサーバーで基本認証メカニズムがサポートされていない場合は、Visitor Services保護を使用します。
Visitor Servicesからの基本LDAP保護では、次が必要です。
アクセス・プロバイダ: access-provider-ldap-basic.jarバンドルをアップロードします。
構成:
LDAP接続設定はLDAPプロファイル・プロバイダと同じです。
認可タイプの設定: HeaderName=Visitors-AuthorizationおよびAuthAlias=Visitors-Basic
ユーザーのusernameとpasswordがともにあるLDAP。
RESTクライアント: new VisitorsHttpAuthentication("username","pass")でクライアントを初期化します
クライアントがプロファイル情報リクエストをVisitor Servicesに送信します。このリクエストには、必要な認証(認証ヘッダーの認証トークン)が含まれます。
Webサーバーがこのリクエストを停止し、認証ヘッダーをチェックします。
ユーザーを認証できない場合、Webサーバーは401エラーを返します。
ユーザーが正常に認証されると、Webサーバーがユーザー・ロールをリクエストに追加します。
リクエストがアクセス・プロバイダに到達します。
関数boolean check(HttpServletRequest request)がリクエストをチェックして、必要なロールを確認します。
ロール・チェックが成功すると、Visitor Servicesがリクエストを処理します。
このリファレンスの内容は次のとおりです。
プロファイル・プロバイダでは、Visitor Servicesが訪問者情報をそれぞれのリポジトリからフェッチできます。エンリッチメント・サービスでは、プロファイル・プロバイダが存在するすべてのリポジトリから、訪問者のプロファイル情報をVisitor Servicesでフェッチできます。
Visitor Servicesの主要タスクは、訪問者情報を外部記憶域から取得することです。これらの記憶域は、構造化データ、LDAP、または一部のデータベース上に構築されている外部Webサービスが含まれるテキスト・ファイルにできます。訪問者データをプロファイル記憶域からフェッチするために、開発者はカスタム・プロファイル・プロバイダを実装して、それらをVisitor Servicesに接続できます。プロファイル記憶域ごとに、1つのプロファイル・プロバイダが可能です。
LDAPおよびEloquaを使用する顧客の場合、プロファイル・プロバイダをデフォルトで使用できます。これらのプロファイル・プロバイダは、Adminインタフェースを使用してインストールされるOSGiバンドルとして使用可能です。これらのOSGiバンドルは、目的の記憶域で必要となる通信の実際のJavaベースの実装です。
注意:
Eloquaプロファイル・プロバイダを使用して訪問者IDを取得するには、-DUseSunHttpHandler=true パラメータをVisitor Services管理対象サーバーに設定する必要があります(使用中のアプリケーション・サーバーがWebLogicサーバーの場合)。
エンリッチメント・サービスでは、プロファイル・プロバイダを使用する様々なプロファイル記憶域で、訪問者情報をVisitor Servicesで検索できます。各プロファイル・プロバイダは、すべてのプロファイル・プロバイダが検索する情報をVisitor Servicesで検索できるようにする単一のルール・セットで構成できます。したがって、エンリッチメント・ルールでは、訪問者情報をすべてのプロファイル・プロバイダから収集します。これらのルールには、AttributeNameInCurrentProfileProvider=DifferentProfileProviderName:AttributeNameInThatProfileProviderの構造が含まれます。
Visitor Servicesがリクエストを受信して、訪問者のプロファイルをLDAPから取得すると、Visitor Servicesは、バックグラウンドで、対応するプロファイルに指定したエンリッチメント・ルールに従い、この訪問者のプロファイルをCRMで検索します。訪問者プロファイルがCRMに見つかると、電子メール・アドレスを検索基準として使用して、Eloquaを検索します。エンリッチメント・プロセスには時間がかかります。したがって、プロファイル・プロバイダを使用して、訪問者のプロファイルが記憶域から初めて取得されると、プロセスが個別のフローとしてバックグラウンドで実行されます。
Visitor Servicesが訪問者情報を複数の記憶域から収集した場合、Engageなどのアプリケーション用に、(集計テンプレートに基づいて)それらをコンパイルします。
次の図に、未加工のプロファイルをプロファイル記憶域から取得して、エンリッチメント・ルールをプロファイルに適用するために、Visitor Servicesがプロファイル・プロバイダとどのように通信するかを示します。
図53-17 Visitor Servicesとプロファイル・プロバイダ間のプロセス・フロー
前述の図に示すプロセス・フローに基づく手順:
訪問者がFacebookにログインを試みます。
ログイン・リクエストがSSOソリューション経由でFacebookログイン・ページに渡されます。
訪問者の資格証明がSSOソリューションに渡されます。
セッションが起動します。
WebサイトがVisitor Servicesに訪問者IDをリクエストします。
SSOソリューションが訪問者のIDをVisitor Servicesに渡します。
Visitor ServicesがFacebookプロファイル・プロバイダに訪問者のFacebookプロファイルをリクエストします。
Facebookプロファイル・プロバイダが訪問者のFacebookプロファイルをFacebookプロファイル記憶域から取得します。
Facebookプロファイル・プロバイダが未加工のFacebookプロファイルをVisitor Servicesに返します。
未加工のFacebookプロファイルがVisitor Servicesデータベースに保存されます。
Visitor ServicesがFacebookプロファイル・プロバイダのエンリッチメント・ルールを取得します。
Visitor ServicesがGoogleプロファイル・プロバイダにGoogleプロファイルをリクエストします。
Googleプロファイル・プロバイダが訪問者のGoogleプロファイルをGoogleプロファイル記憶域から取得します。
Googleプロファイル・プロバイダが未加工のGoogleプロファイルをVisitor Servicesに返します。
GoogleプロファイルおよびFacebookプロファイルがリンクされ、Visitor Servicesデータベースに保存されます。
Visitor ServicesがGoogleプロファイル・プロバイダのエンリッチメント・ルールを取得します。
Visitor Servicesが訪問者IDをWebサイトに送信します。
Visitor Servicesは、プロファイル・プロバイダを使用して、LDAP、Facebook、Eloqua、CRMなどの複数のプロファイル・ストアから訪問者データを検索してフェッチします。LDAPおよびEloquaのプロファイル・プロバイダが提供されます。他のプロファイル・ストアの場合、開発者はカスタム・プロファイル・プロバイダを作成および構成できます。
Visitor Servicesは、プロファイル・プロバイダが検索する訪問者ごとに、検索された訪問者IDと属性で未加工の訪問者プロファイルを作成します。たとえば、訪問者の名前と電子メールがLDAPプロファイル・プロバイダから、その配送先住所がCRMプロバイダから取得される場合があります。
包括的な訪問者ビューを構築するために、Visitor Servicesでは、プロファイル・プロバイダからプロファイル・エンリッチメントを介して訪問者の属性を検索および収集し、訪問者プロファイルをリンクできます。たとえば、OAM経由でログインしている訪問者の場合、Visitor Servicesは電子メール・アドレスをLDAPプロバイダ・プロファイルで検索して、一致する電子メール・アドレスをEloquaプロファイルで検索できます。
1つ以上のプロファイル・プロバイダの構成を参照してください。
このリファレンスの内容は次のとおりです。
集計テンプレートは、Visitor Servicesで定義されている1つ以上のプロファイル・プロバイダからプロファイル属性を集計するのに使用されます。たとえば、同じ属性でプロファイル記憶域ごとに異なる名前が使用されます。訪問者の名前および電子メールIDがGoogle+とFacebookで異なる場合があります。Visitor Services集計サービスでは、様々なプロファイルでの命名方法に関係なく、同じタイプの属性を識別するために、次のパラメータを含む集計テンプレートが用意されています。
プロファイルのメタデータ(属性のリスト)
様々なプロファイルからの情報を結合するためのルールのセット
集計サービスへのリクエストは、クライアントが訪問者IDと集計テンプレートを送信するVisitor Services APIを経由します。各クライアントには、Visitor Servicesで現在使用可能な訪問者プロファイルに関係なく、それぞれ独自のプロファイル構造があります。集計サービスは、アプリケーションのテンプレートを使用してプロファイルを構築します。集計テンプレートは、必要な属性のセットで、未加工の様々なプロファイルからどの属性を収集してコンパイルするかというルールが使用されます。集計済プロファイルの構造は、その訪問者がVisitor Servicesで使用可能なプロファイルのリストに関係なく常に同じであり、様々なプロファイル・プロバイダからの未加工のプロファイルの構造に関係ありません。
次の図に、リンクされているすべてのプロファイルとリクエスト時に必要なテンプレートを集計サービスがどのように取得するかを示します。
図53-18 プロセス・フロー: 集計サービスの仕組み
図53-18に示すプロセス・フローに基づく手順:
特定の属性の訪問者の集計済プロファイルを取得するために、Webサイトが訪問者IDおよび集計テンプレート名をRESTサービスに提供します。
RESTサービスが訪問者IDと襲名テンプレート名を集計サービスに送信します。
訪問者IDに使用可能なすべてのリンク済プロファイルを集計サービスがVisitor Servicesデータベースから取得します。
RESTサービスによって提供された集計テンプレート名の集計テンプレートを集計サービスが取得します。
集計済テンプレートに基づいて、集計済プロファイルを集計サービスがRESTサービスに送信します。
RESTサービスが集計済プロファイルをWebサイトに送信します。
プロファイル集計では、集計テンプレートを使用して、複数の訪問者プロファイルから集計済プロファイルに訪問者属性を統合します。(未加工の訪問者プロファイルは分離されたままです。)ビジネス・ニーズに応じて様々な集計テンプレートを作成できます。たとえば、マーケティング部門が、名前と電子メール・アドレスをLDAPから、電話番号をCRMから提供するテンプレートをリクエストしたり、名前をLDAPから、メーリング・アドレス・データをCRMプロファイルから提供するテンプレートをリクエストしたりできます。
集計テンプレートを使用すると、様々なソースからの訪問者プロファイルを結合するだけでなく、格納済のプロファイル情報を使用する、検索された値を計算する(例: 前年の注文数の合計)、および計算された値をプロファイル属性として追加することもできます。
「1つ以上の集計テンプレートの作成」を参照してください。
Visitor Servicesでは、属性を収集してリンクし、集計済訪問者プロファイルに格納します。プロファイルを使用するには、実行時にVisitor Services API (JavaクライアントおよびJavaScript)を介して、WebCenter Sitesコンポーネントでそれらをリクエストする必要があります。
マーケティング担当者は、訪問者プロファイルをVisitor Servicesから使用して、Engageセグメントを決定および作成できます。たとえば、マーケティング担当者は、年齢や収入などの訪問者プロファイル属性をVisitor Servicesから使用し、セグメントを作成して推奨を提供することができます。
未認証および不明の訪問者の場合、マーケティング担当者は、サイトへのアクセスに使用されたデバイス、タイム・ゾーン、ロケール、ブラウザ、リファラ(Facebook、Twitter、Bing)、IPアドレスなどの属性に基づいて、それらのセグメントを作成できます。
アイデンティティ・プロバイダ、プロファイル・プロバイダおよびアクセス・プロバイダの構成は、WebCenter Sitesデータベースに格納され、Sites REST APIを介してVisitor Servicesによって取得されます。訪問者の未加工のプロファイル、属性およびアクティビティは、ローカルのVisitor Servicesデータベースに格納されます。
WebCenter Sitesデータベースには、次の表で説明されている表が含まれます。これらの表は、WebCenter Sitesのインストール中に作成されます。
表53-4 WebCenter Sitesデータベースの表
| 表名 | 説明 |
|---|---|
WCS_ProfileProviders |
プロファイル・プロバイダの実装、構成およびエンリッチメント・ルールが含まれます。 |
WCS_IdentityProviders |
アイデンティティ・プロバイダの実装および構成が含まれます。 |
WCS_AccessPrividers |
アクセス・プロバイダの実装および構成が含まれます。 |
WCS_AggregatedTemplates |
集計テンプレートが含まれます。 |
WCS_VisitorsConfig |
Visitor Servicesの一般構成が含まれます。 |
ローカルVisitor Servicesデータベースには、次の表で説明されている表が含まれます。
表53-5 ローカルVisitor Servicesデータベースの表
| 表名 | 説明 |
|---|---|
WCS_VIS_Profiles |
プロファイル記憶域からの未加工のプロファイルが含まれ、プロファイル・プロバイダによって提供されます。 |
WCS_VIS_Attributes |
アプリケーションによって登録されたアクティビティが含まれます。 |
WCS_VIS_Activity |
アプリケーションによって保存された拡張属性が含まれます。 |
次の図に、Visitor Servicesデータ・モデルおよび各データベースに含まれる表を示します。
集計
Visitor Servicesで定義されている集計ルールに基づいて、未加工のプロファイルから集計済プロファイルを取得するプロセス。
集計済プロファイル
リンクされている訪問者の様々なプロファイルからVisitor Servicesによってコンパイルされる一意のプロファイル属性。
集計テンプレート
集計済プロファイルを作成するために、未加工のプロファイルからプロファイル属性を取得するための構成。
エンリッチメント
Visitor Servicesで定義されているエンリッチメント・ルールに基づいて、すべてのプロファイル記憶域から訪問者の未加工のプロファイルを取得するプロセス。
外部ID
SSOソリューションによって提供される外部ユーザー識別子。
アイデンティティ
値のペア: 訪問者のプロファイル・プロバイダ名と識別名(DN)。このペアはアイデンティティ・プロバイダからのものです。
アイデンティティ・プロバイダ
プロファイル・プロバイダ名とユーザーDNのペアを対応するアイデンティティ・ストアからVisitor Servicesに提供するために、externalIDを受け入れる開発者によって実装されるエンティティ。
アイデンティティ・ストア
訪問者の情報を含む記憶域。LDAPまたはデータベースになります。
リンクされているプロファイル
リンクされている未加工のすべてのプロファイルを数行の形式でVisitor Servicesデータベースに格納し、Visitor Servicesによって提供されるデータ。
プロファイル・プロバイダ
特定のプロファイル・ストアから訪問者プロファイルを受け取るために、開発者によって実装されるエンティティ。一般には、プロファイル・ストアごとに1つのプロバイダが実装されます。
プロファイル記憶域
訪問者のプロファイルの情報が含まれる外部記憶域。
未加工のプロファイル
プロファイル・プロバイダによって、そのプロファイル・ストアから提供される訪問者データ。
格納済プロファイル
RawProfile、ID、LinkId、およびVisitorIdの形式の処理済プロファイル・データを含む内部Visitor Servicesエンティティ。
SSOソリューション
Visitor Servicesとアプリケーション間のシングル・サインオンを提供する認証システム。Visitor Servicesには、OAM SSOシステムがパッケージされています。
Visitor Servicesデータベース
集計ルールやマッピング・ルールなど、訪問者のプロファイル・データと設定を格納するために、Visitor Servicesによって使用されるローカル・データベース。
