これに使用したアプローチは、データテーブルを持たないが、いくつかのJSONWSメソッドを公開する独自のサービスを作成することです。これは、リモートサービスを作成するためのサービスビルダーのオプションを使用するプラグインプロジェクトで行います（アプリにポートレットが含まれているため、ポートレットプラグインを使用しましたが、フックプラグインでも実行できると思います）。
service.xmlからの簡単な抜粋：
<entity name="UserNotification" local-service="true"
remote-service="true">
</entity>
フィールドもファインダーもありません...エンティティ名だけです。
次に、プラグインプロジェクトのUserNotificationServiceImplで、公開するメソッドを作成し、問題のLiferayサービスに対して定期的にサービス呼び出しを行います（権限チェッカーを使用する責任があります。ここではセキュリティについて自動的に行うことはできません）。サービスを再構築すると、ServiceBuilderリバースエンジニアがメソッドを作成し、リモートサービスAPIを作成します。
トリッキーな点は、カスタムAPIを呼び出すことです。これは、組み込みAPIに対して行う呼び出しとは異なる形式になります。サービスに認証を要求し、メソッドにパーミッションチェッカーで使用するユーザーコンテキストを与えると仮定すると、次の形式で呼び出しを行います。
https://user:passwd@example.com/api/secure/jsonws/plugin-name.entity-name/method? ...parameters
他の呼び出し形式もありますが、重要なのは、Liferayに直接アドレス指定し、そのドット付き表記を使用してプラグインとエンティティを識別することです。プラグインを独自のアプリケーションコンテキストでアドレス指定する場合
https://user:passwd@example.com/plugin-name/api/secure/jsonws/entity-name/method? ...parameters
認証コンテキストを取得できないため、権限チェッカーを使用できません。残念ながら、Liferayサイトの周りには、この方法で電話をかけるように指示するかなりの量の資料があります。しないでください。
すべての詳細（構成設定、呼び出しのニュアンスなど）については説明していませんが、開発者ガイドの新しいドキュメントでは、現在かなりうまく対処しています。ですから、必ずそれを研究してください。
また、 ServiceBuilderについても読む必要があります。
ただし、注意が必要です。おそらく、ポータルが提供するAPIページをサービスのリファレンスとして使用することに慣れているでしょう。これは組み込みのサービスには問題ありませんが、プラグインによって提供されるサービスの場合、このページは誤った例を示しているため、信頼できません。ドキュメントを参照してください。