Oracle® Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイド 11g リリース1 (11.1.1) B72429-01 |
|
前 |
インライン・サービス・メタデータのローカライズにより、ルール・エディタおよびデシジョン・センターのレポートに表示されるローカル言語名を変更できます。ローカライズできるインライン・サービスのメタデータ要素は、エンティティ、エンティティ属性、選択肢属性およびアプリケーション・パラメータです。
注意: この付録では、ローカライズの主用途である、エンティティ名とエンティティ属性名のローカライズを中心に説明します。 |
この付録には次のトピックが含まれます:
ローカライズは、1つの関数によって実現されます。この関数により、インライン・サービス・メタデータ値のソース名とターゲット名(メッセージとも呼ばれます)を検索する場所が指定されます。ソース名とターゲット名は、この関数自体の中でも記述できますが、通常はテキスト・ファイルまたはデータベース表に格納します。この関数名を「メッセージ関数」アプリケーション・パラメータの値として選択します。インライン・サービスを再デプロイすると、ローカライズされたテキストをルール・エディタの画面やデシジョン・センターのレポートに表示できるようになります。
要約すると、ローカライズの設定で必要な主な要素は次の3つです。
ローカライズ・メッセージのソース(インライン・サービス内のテキスト・ファイルまたはデータベースに格納できます)
ローカライズ・メッセージを検索するローカライズ関数
ローカライズ関数はアプリケーションの「メッセージ関数」パラメータとして設定する必要がある
インライン・サービスをデシジョン・スタジオで編集して、アプリケーション・サーバーにデプロイする必要があります。ユーザーがデシジョン・センターにログインすると、ローカライズされたメッセージが検索されます。
ローカライズ・データの標準的な2つの設定方法の例と、Decision Managerのレポートにおけるローカライズの効果を図D-1に示します。
注意: この付録では、主にデシジョン・センターのレポートにおけるローカライズの効果について説明しますが、ルール・エディタの画面でも同様の効果があります。ルール・エディタの画面では、ローカライズされたエンティティ名およびエンティティ属性名も表示されます。 |
ローカライズ関数自体、テキスト・ファイルまたはデータベース表のいずれで指定するかを問わず、ローカライズ・データは、対応するソース・テキスト文字列とターゲット・テキスト文字列の組で構成されます。
ソース・テキスト文字列
ソース・テキスト文字列は、インライン・サービス要素の内部IDに由来します(通常、インライン・サービスの各画面にデフォルトで表示されるラベルではありません)。
エンティティIDは、デフォルトでは大文字で始まります(例: Address)。 属性IDおよびパラメータIDは、デフォルトでは小文字で始まります(例: houseNumber)。これらのIDはデシジョン・スタジオで変更できます。そのため、「トグル」アイコンをクリックしてID値を表示することが重要です。このアイコンをクリックすると、オブジェクト名の表示がラベルとオブジェクトIDの間で切り替わります。
エンティティのうち、別のエンティティの属性でもあるエンティティには、エンティティID(明示的なエンティティ要素として参照される場合)と属性ID(上位エンティティの属性として参照される場合)の両方があります。たとえば、AddressエンティティがCustomerの属性である場合、Addressとしてのデフォルトの明示的エンティティIDはAddress
であり、Customer内のAddressとしてのデフォルト属性IDはCustomer.address
です。
この項の以降の例では、Customerエンティティの属性の1つにAddressエンティティがあり、AddressエンティティにはstreetとhouseNumberという属性があると仮定します。
インライン・サービスの一般的な要素(エンティティなど)の場合、ソース・テキスト文字列の形式は次のとおりです。
<element_ID>
例: Customer
, Address, Offers
インライン・サービスの一般的な要素(エンティティなど)の属性またはパラメータの場合、ソース・テキスト文字列の形式は次のとおりです。
<element_ID>.<element_attribute_or_parameter_ID>
例: Customer.address
, Address.street, Offers
.profitMargin
Applicationのパラメータの場合、ソース・テキスト文字列の形式は次のとおりです。
Application.
<parameter_ID>
例: Application.serviceTest
Sessionの属性の場合、ソース・テキスト文字列の形式は次のとおりです。
ApplicationSession.
<attribute_ID>
例: ApplicationSession.customer
インライン・サービスの特殊要素であるApplicationとSessionは、単独のソース・テキスト文字列としてローカライズで必要になることはありません。この2つはOracle RTDで内部的に処理されます。
注意: ソース・テキスト文字列で使用できるドット区切りの構成要素は2つまでです。 たとえば、次のソース・テキスト文字列はいずれも無効です。
|
ターゲット・テキスト文字列
ターゲット・テキスト文字列は自由形式のテキスト文字列です。通常はローカル言語で記述しますが、必ずしもその必要はありません。ターゲット・テキスト文字列には空白文字を含めることができます。
ローカライズの設定後、ルール・エディタ(値リストと条件)およびデシジョン・センターのレポートにターゲット・テキスト文字列が表示されます。
ルール・エディタの例
ソース・テキスト文字列とターゲット・テキスト文字列は次のとおりです。
ApplicationSession.ball=[BALL]
Ball=[BALL]
Ball.color=[COLOUR]
Ball.size=[SIZE]
この場合、ルール・エディタでは、次の例のようにローカライズされたメタデータが条件に表示されます。
ローカライズ関数は、入力パラメータjava.util.Locale
をとり、java.util.Map
またはそのサブクラス(java.util.Properties
など)を返すインライン・サービス関数です。
ソース・テキスト文字列とターゲット・テキスト文字列の詳細は、第D.2項「ローカライズのソース・テキスト文字列とターゲット・テキスト文字列」を参照してください。
返されたマップには、ソース・テキスト文字列とターゲット・テキスト文字列の組が含まれています。マップ・キーはソース・テキスト文字列(Customer.address
など)で、ターゲット・テキスト文字列(indirizzo
など)の検索に使用されます。
この項には次のトピックが含まれます:
このシナリオでは、ユーザーのブラウザの言語をローカライズ・メッセージ・テキスト・ファイルのキーとして使用する方法について説明します。たとえば、ユーザーのブラウザの言語が英語に設定されている場合は、対応するサーバー・ロケールがen_US
(米国の場合)またはen_CA
(カナダの場合)に設定されている可能性があります。国固有の翻訳が不要であれば、対応するファイル名はmessages_en_US.properties
またはmessages_en.properties
になります。
該当するファイルを検索するロジックは次のとおりです。
まず、完全なロケールが使用されます。たとえば、pt-BR (ポルトガル語 - ブラジル)です。対応するファイル名はmessages_pt_BR.properties
です。
このファイルが見つからない場合、ロケールの言語部分のみが使用されます。ファイル名はmessages_pt.properties
です。
このファイルが見つからない場合、検索ロジックはサーバーのデフォルト・ロケール(en-USなど)に戻り、前述の2つのステップが繰り返されます。
このフォールバック・ロケールに対応するファイルが見つからない場合、デフォルト・ファイルが使用されます。ファイル名はmessages.properties
です。
最後の手段として、空のマップが返されます。これは、ローカライズが用意されていない場合に、Oracle RTDがローカライズされたメッセージを絶えず要求しないようにするためです。
インライン・サービス・メタデータのローカライズを実装するには、次の手順を実行します:
インライン・サービスはアプリケーション・サーバーにデプロイされるため、すべてのメッセージ・ファイルをアプリケーション・サーバーのファイル・システムに伝播させる必要があります。つまり、インライン・サービスと一緒にデプロイする必要があります。このため、すべてのメッセージ・ファイルをインライン・サービスのdc/jsp
フォルダに格納する必要があります。
このフォルダが存在しない場合は、デシジョン・スタジオで次の例のように作成します。
このフォルダに、図D-1のテキスト・ファイルの例にあるエントリのような、ソース・テキスト文字列とターゲット・テキスト文字列を記述したファイルを作成します。
ローカライズ関数を作成します。
この例では、ローカライズ関数の名前をGet Messages From Propertiesとします。
ローカライズ関数に対して、次の操作を行います。
戻り値を指定します。
「データ型」で「その他」を選択し、「Javaクラス名」にPropertiesと入力します。
[インライン・サービス関数でjava.util.*パッケージがすでにインポートされているので、戻り型の完全名(java.util.Properties)を指定する必要はありません。]
同様に、関数の入力パラメータをjava.util.Locale型で追加します。
次のようなコードを関数ロジックに追加します。
String language = locale.getLanguage(); String country = locale.getCountry(); Properties props = new Properties(); java.io.File appDir = com.sigmadynamics.sdo.loading.AppFactory.getInstance().getAppLocation( Application.getApp().getName(), Application.getApp().getDeploymentState()); java.io.File dcDir = new java.io.File(appDir, "dc/jsp"); Locale fallbackLocale = Locale.getDefault(); String fbLanguage = fallbackLocale.getLanguage(); String fbCountry = fallbackLocale.getCountry(); String fileName = "resources_" + language; if (!country.isEmpty()) fileName += "_" + country; fileName += ".properties"; java.io.File propFile = new java.io.File(dcDir, fileName); if (!propFile.exists()) { fileName = "resources_" + language + ".properties"; propFile = new java.io.File(dcDir, fileName); } if (!propFile.exists()) { fileName = "resources_" + fbLanguage; if (!fbCountry.isEmpty()) fileName += "_" + fbCountry; fileName += ".properties"; propFile = new java.io.File(dcDir, fileName); } if (!propFile.exists()) { fileName = "resources_" + fbLanguage + ".properties"; propFile = new java.io.File(dcDir, fileName); } if (!propFile.exists()) { fileName = "resources.properties"; propFile = new java.io.File(dcDir, fileName); } if (propFile.exists()) { try { props.load(new java.io.FileInputStream(propFile)); } catch (Exception e) { logError("Error retrieving localized messages from properties (locale [" +locale.toString()+"], file ["+propFile.getName()+"])", e); } } return props;
この関数をアプリケーションのメッセージ関数として割り当てます。
インライン・サービスを再デプロイします。
ブラウザ(次の例のブラウザはInternet Explorerです)を起動し、目的の言語を追加します。
追加した言語をブラウザの「言語の優先順位」リストの先頭に移動します。
デシジョン・センターにログインすると、図D-1のようにローカライズされたレポートを表示できます。
このシナリオでは、ローカライズ・データおよびローカライズ情報をデータベース表に格納します。表と列には任意の名前を使用できます。
この例では、表名をLOCALIZATIONとします。この表にはLOCALE列、SELECTOR列(ソース・テキスト文字列)、MESSAGE列(ターゲット・テキスト文字列)があります。また、データベースはOracle RTDデータベースであり、データソースにはSDDSを使用すると仮定します。
インライン・サービス・メタデータのローカライズを実装するには、次の手順を実行します:
データベースで次のコマンドを実行して表を作成します。
CREATE TABLE LOCALIZATION ( LOCALE VARCHAR2(8) NOT NULL, SELECTOR VARCHAR2(200) NOT NULL, MESSAGE NVARCHAR2(2000) )
ターゲット・テキストにはあらゆる文字セットが使用される可能性があるため、ターゲット・テキスト列はNVARCHAR2型にすることが重要です。
データベース表にデータを入力します。
[この手順は、ここで行っても後で行っても構いません。]
ローカライズ関数(Get Messages From Databaseなど)を作成します。
ローカライズ関数に対して、次の操作を行います。
戻り値を指定します。
「データ型」で「その他」を選択し、「Javaクラス名」にPropertiesと入力します。
戻り型をMapに設定します。
同様に、関数の入力パラメータをjava.util.Locale型で追加します。
次のようなコードを関数ロジックに追加します。
java.sql.Connection conn = null; java.sql.PreparedStatement pst = null; java.sql.ResultSet rs = null; Map<String, String> strings = new HashMap<String, String>(); try { conn = com.sigmadynamics.server.SDDataSource.getDataSource("SDDS").getConnection(); pst = conn.prepareStatement("select * from Localization where locale=?"); pst.setString(1, locale.getLanguage() + (locale.getCountry().isEmpty() ? "" : "_" + locale.getCountry())); rs = pst.executeQuery(); if (!rs.next()) { rs.close(); pst.setString(1, locale.getLanguage()); rs = pst.executeQuery(); } else { strings.put(rs.getString(2), rs.getString(3)); // selector + message } while (rs.next()) { strings.put(rs.getString(2), rs.getString(3)); // selector + message } } catch (Exception e) { logError("Error retrieving localized messages from database (locale ["+locale.toString()+"])", e); } finally { try { rs.close(); pst.close(); conn.close(); } catch (Exception e) {} } return strings;
この関数をアプリケーションのメッセージ関数として割り当てます。
インライン・サービスを再デプロイします。
ブラウザの言語設定(第D.3.1項「ローカライズ・データをテキスト・ファイルに格納する場合の設定例」の手順9と10)を行います。
デシジョン・センターにログインすると、図D-1のようにローカライズされたレポートを表示できます。