グローバルサービスオプションの構成

サービスのグローバルオプションは、そのすべてのエンティティに適用されます。 オプションは次のとおりです。

• 依存性インジェクター
• パッケージパス
• マルチバージョン同時実行制御
• ネームスペースオプション
• 作成者

依存性インジェクター

デフォルトの依存性注入は、OSGi宣言型サービスです。 これにより、Service Builder は他のモジュールと同様に一貫して動作するようになります。 DXP/Portal 7.2 より前では、Service Builder は Spring 依存性注入を使用していました。 唯一の違いは、サービスを使用するときにサービスをどのように挿入するかです。 両方のインジェクター設定を以下に示します。 詳細については、 コア フレームワーク の 依存性注入 を参照してください。

宣言型サービス依存性インジェクター：

<service-builder dependency-injector="ds">

Spring依存性インジェクター：

<service-builder dependency-injector="spring">

Service Builder テンプレートを使用してプロジェクトを作成すると、宣言型サービスの依存関係インジェクターとその依存関係がプロジェクトに対してデフォルトで構成されます。 代わりに Spring 依存性インジェクタを使用するには、 Blade CLIの Service Builder テンプレートと --dependency-injector spring オプションを使用してプロジェクトを作成します。

注

Liferay DXP/Portal 7.2 より前は、Spring が唯一の依存性インジェクターでした。 サービスはSpring Beanでした。 LiferayのSpring Beanフレームワークは、相互に参照するSpring Beanに対応しています。たとえば、Spring Bean AにはSpring Bean Bフィールドがあり、その逆も同様です。 Spring を依存性インジェクターとして使用する場合、Service Builder は、service.xml で定義されているすべてのエンティティのローカル サービスと永続性フィールドを含む基本サービスを生成します。 これにより、循環参照が発生します。 OSGi 宣言型サービスは循環参照に対応していないため、DS が依存性インジェクターである場合、サービス ビルダーは基本クラスにこれらのフィールドを作成しません。 詳細については、 生成されたクラスの理解と拡張を参照してください。

パッケージパス

パッケージパスは、サービスクラスと永続性クラスが生成されるパッケージを指定します。 たとえば、ゲストブックのパッケージパスは次のとおりです。

<service-builder dependency-injector="ds"
        package-path="com.acme.guestbook">

上記のパッケージパスは、*-apiモジュールのサービスクラスがcom.acme.guestbookパッケージで生成されることを保証します。 永続性クラスは、*-serviceモジュール内の同じ名前のパッケージで生成されます。 生成されたクラスの詳細については、 「生成されたクラスの理解と拡張」を参照してください。

マルチバージョン同時実行制御（MVCC）

service-builder要素のmvcc-enabled属性は、デフォルトではfalseです。 mvcc-enabled="true" を設定すると、すべてのエンティティに対して マルチバージョン同時実行制御 (MVCC) が有効になります。 システムでは、同時更新が一般的です。 MVCC がないと、無効な状態からデータが読み取られたり、上書きされたりする可能性があります。 MVCCでは、各変更は特定の基本バージョン番号に基づいて行われます。 Hibernate永続レイヤーは更新を受信すると、update SQLステートメントを生成します。このステートメントでは、where句を使用して現在のデータバージョンが期待するバージョンであることを確認します。

現在のデータバージョンが

• 予想されるバージョンと一致する場合、データ操作は最新のデータに基づいており、受け入れられます。

• 期待されるバージョンと一致しない場合、操作しているデータが古くなっています。 DXP/Portalはデータ操作を拒否し、例外をスローします。例外をキャッチすると、ユーザーが例外を処理するのに役立ちます（操作の再試行を提案するなど）。

<service-builder/> 要素で mvcc-enabled="true" を設定することで、すべてのサービスに対して MVCC を有効にします。 サービスエンティティの更新（例：fooService.update(object)）を呼び出すときは、必ずトランザクションで呼び出してください。 ユーザーが処理できるように、UIで拒否されたトランザクションを公開してください。

<service-builder dependency-injector="ds"
        package-path="com.acme.guestbook"
        mvcc-enabled="true">

ネームスペースオプション

サービスビルダーは、サービスのネームスペースを使用してデータベーステーブルに名前を付けます。 たとえば、GBはゲストブックアプリケーションサービスのネームスペースとして機能できます。

<service-builder dependency-injector="ds"
   package-path="com.acme.guestbook"
   mvcc-enabled="true">
    <namespace>GB</namespace>
    <author>Liferay</author>

サービスビルダーは、src/main/resources/sqlフォルダに生成される次のSQLスクリプトのネームスペースを使用します。

• indexes.sql
• sequences.sql
• tables.sql

注

生成されたSQLスクリプトのフォルダ場所は設定可能です。 たとえば、Gradle を使用している場合は、以下の例で適用されている databaseNameMaxLength 設定のように、プロジェクトの Gradle build.gradle ファイルで sqlDir 設定を定義できます。

サービスビルダーは、SQLスクリプトを使用して、service.xmlが定義するすべてのエンティティのデータベーステーブルを作成します。 データベーステーブル名には、作成時にネームスペースが付加されます。 この例のネームスペースの値はGBであるため、エンティティ用に作成されたデータベーステーブル名はプレフィックスとしてGB__で始まります。 各サービスビルダープロジェクトのネームスペースは一意である必要があります。 個別のプラグインは個別のネームスペースを使用する必要があり、Liferayエンティティ（UsersやGroupsなど）ですでに使用されているネームスペースを使用しないでください。 Liferayのデータベースのテーブル名をチェックして、すでに使用されているネームスペースを確認してください。

名前空間の値は慎重に割り当ててください。 一部のデータベースには、データベーステーブルと列名の長さに強い制限があります。 Service Builder Gradle プラグイン パラメータ databaseNameMaxLength は、テーブル名と列名に使用できる最大長を設定します。 以下に、ビルドファイルでdatabaseNameMaxLengthを設定する例をいくつか示します。

Gradle build.gradle

buildService {
    ...
    databaseNameMaxLength = 64
    ...
}

作成者

グローバル情報の最後の部分として、service.xmlファイルにサービスの作成者としての名前を入力します。 サービスビルダーは、生成するすべてのJavaクラスとインターフフェイスに指定された名前の@authorアノテーションを追加します。 service.xml ファイルを保存します。 次に、サービスのエンティティを追加します。

<service-builder dependency-injector="ds"
   package-path="com.acme.guestbook"
   mvcc-enabled="true">
    <namespace>GB</namespace>
    <author>Liferay</author>

関連トピック

• コアフレームワーク
• 生成されたクラスの理解と拡張