パターンを生成した後に完了する必要があるタスクです。
このパターンは、操作 (作成、読み取り、更新、および削除) ごとにサブフローを作成します。サブフローの実装は、バックエンド・アプリケーションの呼び出しで完了します。このパターンは、サブフロー内の CRUD 操作ごとに参照実装を生成します。参照実装は、例として提供されます。これを使用すると、生成されるアプリケーションを作業用のソリューションとして Message Broker にデプロイすることができるので、パターンの働きを理解するのに役立ちます。
このパターンによって生成される Worklight アダプターは、データに変換を適用せず、モバイル・アプリケーションから Message Broker にそのまま渡します。この設計は、モバイル・アプリケーションと Message Broker 内のサブフローとの間で渡される JSON データのフォーマットについて、合意が必要であることを意味します。モバイル・アプリケーションと Message Broker との間で渡されるアプリケーション・データは、単一の JSON オブジェクトです。モバイル・アプリケーションは、WL.Client.InvokeProcedure
を起動してバックエンド・アプリケーションを呼び出す際にこの JSON オブジェクトを提供します。
Worklight やモバイル・アプリケーションとは別個に Message Broker アプリケーションをテストできます。例えば、FireFox Poster プラグインは HTTP/JSON 要求を Message Broker との間で送受信できます。Worklight Studio を用いて Message Broker アプリケーションをテストすることもできます。Worklight Studio は、モバイル・アプリケーションからの HTTP/JSON 要求をシミュレートして、このパターンによって生成されたアダプターを呼び出すことができます。
セキュリティーを有効にした場合は、モバイル・アプリケーションは認証と許可のためにユーザー資格情報も提供しなければなりません。
セキュリティーを有効にした場合、このパターンは追加の構成可能サービス・ファイルを生成します。このファイルは、Message Broker 内でのセキュリティー処理を構成します。1 つ目のファイル (AuthenticationSecurityProfile.configurableservice
) は、HTTPInput ノードによって実行される認証を構成します。2 つ目のファイル (AuthorisationSecurityProfileReaders.configurableservice
) は、リーダーの許可を構成します。3 つ目のファイル (AuthorisationSecurityProfileWriters.configurableservice
) は、1 つ以上の書き込み操作 (作成、更新、または削除) を選択した場合にのみ生成されます。このファイルは、ライターの許可を構成します。
Message Broker Toolkit または Message Broker Explorer でこの構成可能サービス・ファイルを Message Broker にデプロイしてください。詳しくは、Message Broker のヘルプ内にある「構成可能サービス」のトピックを参照してください。
デプロイメント時に、mqsisetdbparms
を使用して LDAP ユーザー ID とパスワードを設定することをお勧めします。Message Broker は、これらの資格情報を使用して LDAP サーバーにログインし、認証を実行します。ユーザー ID とパスワードが構成されていない場合、Message Broker は、匿名で LDAP サーバーにバインドします。詳しくは、Message Broker のヘルプ内にある「LDAP を使用した認証の構成」のトピックを参照してください。
キャッシュを使用可能にした場合は、Message Broker でグローバル・キャッシュを構成しなければなりません。Message Broker Explorer でデフォルトのグローバル・キャッシュを簡単に構成できます。詳しくは、Message Broker のヘルプ内にある「グローバル・キャッシュの管理」のトピックを参照してください。
グローバル・キャッシュには、データの自動満了 (強制削除) はありません。したがって、このパターンによって生成されるアプリケーションはデータを無期限にキャッシュに入れます。この状況は、他のチャネルによってバックエンド・アプリケーションに変更が加えられる場合 (Message Broker を介さず直接バックエンド・アプリケーションに変更が加えられる場合など) には適切でない可能性があります。
このパターンで提供されるキャッシュを改良する方法は複数あります。1 つ目のオプションは、バックエンド・アプリケーションで変更を listen し、これらのイベントをトリガーとして使用して、キャッシュから項目を削除することです。この方法の好例としては、DatabaseInput ノードがあります。DatabaseInput ノードは、1 つ以上のデータベース表をモニターし、アプリケーション・データに対する変更を探すことができます。変更が検出されると、削除する必要がある項目をメッセージ・フローがキャッシュから削除できます。モバイル・アプリケーションから行われる次の読み取り要求は、キャッシュ内でこのデータを検出しないので、バックエンド・アプリケーションを照会して変更を収集します。
2 つ目のオプションは、キャッシュ全体に対して定期的に消去作業を行うことです。この方法には、mqsicacheadmin
コマンドを使用して簡単に実装できるという利点があります。このコマンドに -c clearGrid
オプションを指定して定期的に実行するシェル・スクリプトは、キャッシュからすべての項目を削除します。この方法により、キャッシュが無制限に大きくならずに済み、データがキャッシュに残る最大時間も確定します。詳しくは、Message Broker のヘルプ内にある「mqsicacheadmin」のトピックを参照してください。
値の変更によってパターン・インスタンスの動作が影響を受けないことを確認する必要があります。