Red Hat Mobile Application Platform ホスト型 (RHMAP) の中心的なコンセプトの 1 つはクラウドアプリです。クラウドアプリは、モバイルデバイスにデプロイされたクライアントアプリとビジネスロジックおよびデータが含まれるバックエンドシステム間の通信を処理するサーバーサイドアプリケーションです。

クラウドアプリは Node.js を使用して開発されます。 Node.js は、高速でスケーラブルなネットワークアプリケーションを簡単に構築できるようにする、Chrome の JavaScript ランタイムに基づいて構築されたプラットフォームです。Node.js は軽量さと効率性を実現するイベント駆動の非ブロッキング I/O モデルを使用し、分散されたデバイスで実行するデータ集約型リアルタイムアプリケーションに最適です。

Node.js 開発に精通していない場合は、Node Beginner Website を参照することをお勧めします。

クラウドアプリが RHMAP で作成された場合、その新しく作成されたクラウドアプリは実質的には事前設定された Node.js アプリケーションです。事前設定された対応するクライアントアプリも生成された場合、クラウドアプリにはすべての基本的な設定 (ルート) が含まれるため、クライアントアプリとクラウドアプリは同期されます。また、クラウドアプリをホストするインフラストラクチャーもインプレース状態 (MBaaS) にあり、簡単にアクセスできます。

設定とインフラストラクチャーがすべてインプレース状態にあるため、クラウドアプリは MBaaS にデプロイできます。また、追加コードを必要とせずにクライアントアプリの要求をルーティングできます。上級 Node.js 開発者がサーバーを再設計したり、独自のサーバーを実装したりする場合、これは、application.js ファイル内のコードを操作することによって可能になります。

クラウドアプリでは次のファイルがデフォルトで提供されます。

クラウドアプリは非常に簡単に準備できます。Studio で新しいプロジェクトを作成するときに Hello World Project テンプレートを試したり、GitHub (feedhenry-templates/helloworld-cloud) でテンプレートのソースコードを探したりすることにより単純なサンプルを使用できます。以下にテンプレートの簡単な概要を示します。

最初の手順は application.js でカスタムルートを設定することです。

app.use('/hello', require('./lib/hello.js')());

参照される hello.js ファイルでは、特定のルートのロジックを定義します。

var express = require('express');
var bodyParser = require('body-parser');
var cors = require('cors');

function helloRoute() {
  var hello = new express.Router();
  hello.use(cors()); // enables cross-origin access from all domains
  hello.use(bodyParser()); // parses POST request data into a JS object

  hello.post('/', function(req, res) {
    res.json({msg: 'Hello ' + req.body.hello});
  });
  return hello;
}
module.exports = helloRoute;

$fh.cloud を使用したこのエンドポイントへのクライアントサイド呼び出しは以下のようになります。

$fh.cloud({
    path: 'hello',
    data: {
      hello: 'World'
    }
  },
  function (res) {
    // response handler
  },
  function (code, errorprops, params) {
    // error handler
  }
);

環境は、プロジェクト、サービス、フォーム、およびアプリの開発サイクルを個別のステージに論理的に分離する方法です。環境はライフサイクル管理の重要な要素です。

たとえば、プロジェクトには Dev、UAT、および Production の 3 つのステージが含まれることがあります。各ステージは環境により表されます。環境の数と種類はプラットフォームで設定可能であり、ドメインごとに変更できます。

App Studio で環境が使用される領域は以下のとおりです。

環境にアクセスせずにこれらの領域にアクセスすると、以下のような警告が表示されます。

App Studio でプロジェクト、サービス、フォーム、およびアプリに関連するほとんどのアクションを実行するには、1 つまたは複数の環境にアクセスできる必要があります。

現在環境にアクセスできない場合は、以下の理由が考えられます。

本書では、Node.js モジュールをクラウドアプリに含め、使用する方法について説明します。Red Hat Mobile Application Platform (RHMAP) では、クラウドアプリを開発するためにレジストリーで利用可能な Node.js パッケージのモジュールを使用できます。パブリックレジストリー (npmjs.com) では、フレームワーク、コネクター、およびさまざまなツールを含む数千のパッケージを見つけることができます。

RHMAP 自体の機能の一部はノードモジュールとして公開されます。たとえば、プラットフォームで新しいクラウドアプリを作成する場合、デフォルトでは package.json に Mobile Backend As A Service (MBaaS) の基盤となる fh-mbaas-api という名前のモードモジュールが含まれます。

アプリにある機能が必要であり、一から作成したくない場合は、npmjs.com で既存のモジュールを探すことをお勧めします。

たとえば、Mongoose ODM フレームワークを使用する場合は、レジストリーの mongoose パッケージの公式ページ (npmjs.com/package/mongoose) を参照してください。

プロジェクトでパッケージの最新バージョンを使用する場合は、クラウドアプリのディレクトリーで以下のコマンドを実行してパッケージをローカルにインストールし、依存関係としてクラウドアプリの package.json ファイルに追加します。

npm install --save mongoose

または、以下の例のように、dependencies オブジェクトの最後で依存関係を追加することにより依存関係を package.json に手動で追加します。

{
    "name": "my-fh-app",
    "version": "0.2.0",
    "dependencies": {
        "body-parser": "~1.0.2",
        "cors": "~2.2.0",
        "express": "~4.0.0",
        "fh-mbaas-api": "~4.9.0",
        "mocha": "^2.1.0",
        "request": "~2.40.0",
        "mongoose": "~4.1.12" // added mongoose dependency
    }
}

この時点で、パッケージで提供されるモジュールを使用できます。多くの場合、npmjs.com のパッケージページには、使用方法とドキュメンテーションへのリンクが含まれます。すべてのモジュールで共通な次の手順では、コードでモジュールを必須にして使用できるようにします。

var mongoose = require('mongoose');
mongoose.connect('mongodb://localhost/my_database');
...

この例では、データベース URL はソースでハードコーディングされます。ただし、より一般的なシナリオでは開発ライフサイクルの異なるステージ (開発、テスト、本番稼働) に応じて異なるデータベースを使用します。これは、環境変数で設定値を定義することにより実現できます。

ホスト名、ユーザー名、パスワードなどのクラウドアプリの設定の部分がライフサイクルステージで異なる場合は、環境変数を使用してこのような設定値を設定できます。これにより、コードを変更せずに設定を変更できるようになります。Studio において各クラウドアプリには Environment Variables セクションがあり、変数を作成または削除したり、値を設定したり、アプリの実行中インスタンスに変数をプッシュしたりできます。

環境変数は、異なる値を異なる環境にプッシュする機能と組み合わせると特に有用です。たとえば、テスト用と本番稼働用に異なるデータベースホストを使用できます。他の利点は、 機密性がある設定情報をアプリケーションのコードベース外に格納できることです。

クラウドアプリでは、環境変数は process.env オブジェクトを介してアクセスできます。環境変数を使用するよう変更された Mongoose 接続呼び出しの前の例は以下のようになります。

mongoose.connect('mongodb://' + process.env.MONGO_HOST + '/' + process.env.MONGO_DB);

npm (ノードパッケージマネージャー) は Node.js 用の依存関係管理ツールであり、Node.js アプリケーションを開発するために必要になります。原則として、npm は Maven、Cocoapods、NuGet などの他の依存関係管理システムに似ています。

クラウドアプリでの Node.js モジュールの使用については、クラウドアプリでの Node.js モジュールの使用を参照してください。

クラウドアプリをデプロイする場合は、アプリの環境で npm コマンドが実行され、アプリの依存関係がダウンロードおよびインストールされます。以下のことに注意してください。

npm を使用した基本的なベストプラクティスは、ノードモジュールでバージョン管理がどのように機能するかを理解し (The semantic versioner for npm を参照)、package.json の依存関係に対して * を使用しないことです。

ローカルで開発する場合に役に立つヒントは、npm (npm install request --save など) を使用してモジュールをインストールするときに --save フラグを使用することです。--save フラグを使用すると、インストールされたバージョンの package.json の依存関係セクションに新しいモジュールが追加されます。また、shrinkwrap ファイルの使用もお勧めします。

npm shrinkwrap

RHMAP では、node_modules ディレクトリーをコミットし、クラウドアプリで使用できます (ただし、これは推奨される方法ではありません)。この場合、アプリがステージングされても npm はまったく実行されず (clean オプションが指定されている場合であっても)、アップロードしたモジュールはアプリを実行するために使用されます。ただし、ネイティブのノードモジュールは実行するのと同じアーキテクチャー (RHMAP のインスタンスによって異なる可能性があります) でコンパイルする必要があります。

最初に、fhc の最新バージョンを用意します。

npm install -g fh-fhc

次に fhc ランタイムコマンドを使用して、環境で利用可能なランタイムを確認します。

fhc runtimes --env=dev

このコマンドを実行すると、4.4.7 などのバージョンが出力されます。

左側にはランタイムの名前が示され、右側には特定のバージョンが示されます。

fhc app stage --app=<APP_GUID> --runtime=<node version>

ステージ中にアプリのランタイムを設定するには、<node version> (4.4.7 など) を追加します。

これにより、ノードのアプリのランタイムが v4.4.7 に設定されます。

別のランタイムに変更するには、ランタイムの引数をステージコマンドに再び追加します。

Studio のデプロイ画面では、アプリが設定された現在のランタイムを確認できます。また、ここで新しいランタイムを設定し、アプリをデプロイすることもできます。

サードパーティー API からデータをアクセスするときは、多くの場合、アプリケーションの受信データの構造または形式を変更する必要があります。たとえば、値を異なる形式に変換し、データを事前処理して、新しい値を派生させたり、アプリケーションのモデルを適合させるためにフィールドの名前変更または削除を行ったりします。

RHMAP には、データ変換ロジックをカプセル化し、主要なアプリケーションロジックから抽象化することを可能にする API Mapper という名前の視覚的なツールが含まれます。API Mapper を使用すると、以下のことを行って JSON API の応答を簡単に変換できるようになります。

API Mapper はクラウドサービステンプレートとして提供されます。API Mapper の 1 つのインスタンスは複数のクラウドアプリとクラウドサービスで使用でき、複数の異なる API を変換するためにも使用できます。ただし、必要な場合は、任意の数の API Mapper インスタンスをデプロイできます。

API Mapper を使用するには以下の手順に従ってください。

この時点で、サービスの Preview セクションから API Mapper の管理インターフェースにアクセスできます。

データベースのアップグレードが完了したら、プレフィックス fhsync_ の付いた新たなコレクションが作成され、同期機能が有効になります。Red Hat では、同期機能を使う予定がない場合でも、これらのコレクションを保持しておくことを推奨しています。

この例は、要求、マッピング、およびカスタム変換を作成する方法を示しています。デモのために、この手順では変換するソース API の例としてパブリックな Github API を使用します。

組み込みのフィールド変換以外に、カスタムの変換関数を作成することもできます。

app.use('/', require('./lib/api')({
  transformations : {
    <transformation name> : {
      type: <'array' | 'number' | 'string' | 'boolean'>,
      transform: <unary function>
    }
  }
}));

組み込みの UnifiedPush Server (UPS) から Google のプッシュ通知ネットワークにアクセスできるようにするには、最初にサーバーキーを取得し、Firebase コンソールでプロジェクトを確立する必要があります。クレデンシャルを取得する詳細な手順については、Obtaining Firebase Cloud Messaging Credentials を参照してください。これらの手順はネイティブ Android アプリ向けであり、すべてのプロセスを完了する必要はありません。セットアップを正常に完了するには、以下の 3 つのアイテムを取得する必要があります。

他のプッシュネットワークについては、Obtaining Credentials for Push Networks を参照してください。

プッシュサポートは、各クライアントアプリに対して明示的に有効にする必要があります。また、最初の手順 (Firebase Cloud Messaging クレデンシャルの取得と google-services.json ファイルのダウンロード) で取得したプッシュネットワーククレデンシャルを提供する必要もあります。

Firebase コンソールで定義されたパッケージ名に合わせて config.xml ファイルの widget id 設定を変更します。

特別なセットアップなしで簡単にビルドできる Debug タイプの Android バイナリーをビルドします。

フォームビルダーで、フォームフィールドのデータソースとして MBaaS サービスのエンドポイントを使用できます。本書では、MBaaS サービスの作成、データソースの定義、およびデータソースを使用したフォームフィールドへのデータの入力を実行する方法について説明します。

フォームのデータソースの詳細については、Using Data Sources を参照してください。

データソースを定義するには、データソースの有効な JSON 応答を提供する MBaaS サービスエンドポイントを提供する必要があります。この例では、JSON ファイルから静的なデータを提供する新しい MBaaS サービスを作成します。

データを提供する MBaaS サービスを作成したら、データソースで使用できます。

この時点で、フォームフィールドにデータを入力するためにフォームビルダーでデータソースを使用できます。

データソースの定義後に、フォームビルダーでそのデータソースを使用できるようになります。

Dashboard に移動すると、プレビューの右側にあるデータソースからデータが入力されたフィールドを確認できます。

プラットフォームには、ユーザーがアクセスできるカウンターとタイマーが保持されます。一部はプラットフォームにより提供され、一部はアプリケーションの開発者が指定できます。

カウンターは、特定の機能の使用を追跡するために使用でき、増分または減分できます。プラットフォームでは、現在アクティブなサーバーサイドアクションを示すカウンター (つまり、現在実行中のモバイルアプリケーションにより呼び出されたサーバーサイド機能の数) が提供されます。

タイマーは、指定されたアクションを実行するのにかかった時間を追跡するために使用できます。プラットフォームでは、サーバーサイドアクションの実行時間を追跡するタイマーが提供されます。定期的 (プラットフォームで設定された間隔) に、現在のカウンターとタイマーが履歴にプッシュされ、ゼロに設定されます。

プラットフォームから統計を要求するときは、データを返す最近の間隔の数と破棄の間隔の長さ (ミリ秒単位) がデータとともに返されます。

タイマーデータは、間隔で発生したタイミングイベントの数 (上限値とか下限値を含む) として返されます。また、90 パーセンタイルの上限値と平均値もあります。

アプリ開発者は以下のコードを使用して独自のカウンターとタイマーを作成できます。

$fh.stats.inc('COUNTERNAME'); // Increments a counter
$fh.stats.dec('COUNTERNAME'); // Decrements a counter
$fh.stats.timing('TIMERNAME', timeInMillis); // Store a timer value

クラウドアプリの統計 API の詳細については、以下のドキュメントを参照してください。

"app” の統計タイプを指定することにより、開発者のカウンターとタイマーはプラットフォームから要求できます。

カウンターのキー名はフォーム DOMAIN_APPID_app_COUNTERNAME に基づきます。ここで、DOMAIN_APPID はドメインの名前であり、APPID はアプリの ID であり、COUNTERNAME はカウンターに開発者が付けた名前です。

タイマーのキー名はフォーム DOMAIN_APPID_app_TIMERNAME に基づきます。ここで、DOMAIN_APPID はドメインの名前であり、APPID はアプリの ID であり、TIMERNAME はタイマーに開発者が付けた名前です。

ユーザーは、Studio から統計データにアクセスしたり、コマンドラインクライアントである FHC から生データ自体にアクセスしたりできます。

同期フレームワークは、クライアントアプリと Node.js クラウドアプリ API のセットで構成されます。

クライアントアプリは、バックエンドデータに直接アクセスしません。代わりに、同期クライアント API を使用して、デバイスに格納されたデータの読み取りと一覧表示を行い、変更 (作成、更新、および削除) をクラウドアプリに送信します。データにローカルで行われた変更は、クラウドアプリに送信される前にローカルの同期データキャッシュに格納されます。クライアントアプリは、同期クライアント API からリモートデータセットへの変更の通知を受け取ります。

クライアントアプリはクライアント同期サービスを使用して、リモートデータセットに行われた変更 (デルタ) をクラウドアプリから受け取り、同期データキャッシュに格納します。また、クライアントアプリはクライアント同期サービスを使用してローカルで行われた更新をクラウドアプリに送信します。クライアントアプリがオフラインのときは、キャッシュされた更新がデバイス上のローカルストレージにフラッシュされ、ネットワーク接続が再確立される前にクライアントアプリが閉じられる場合に変更を永続化できます。変更は、クライアントアプリが次回オフラインになったときにクラウドアプリにプッシュされます。

クラウドアプリはバックエンドデータに直接アクセスせず、同期クラウド API を介してのみアクセスします。クラウドアプリは、クライアント同期サービスを使用してクライアントアプリからアップデートを受け取るために同期クラウド API を使用します。これらのアップデートはクラウドアプリ同期データキャッシュに格納されます。クラウドアプリは、標準的な CRUDL (create, read, update, delete and list) および collisionHandler 関数を使用して、ホストされたストレージでバックエンドデータを管理するために同期クラウド API を使用します。

標準的なデータハンドラー関数以外に、クラウドアプリにはユーザー定義データアクセス関数も使用できます。

同期用のクライアントおよび Node.js API 呼び出しは、以下のガイドで文書化されています。

アプリで同期フレームワークを使用するには、以下の手順を実行します。

同期フレームワークは、アプリ開発者がデータセットのソースデータを定義することを可能にするフックを提供します。通常、ソースデータは外部のデータベース (MySql、Oracle、MongoDB など) ですが、これは要件ではありません。データセットのソースデータはどんな種類でもかまいません (csv ファイル、FTP メタデータ、複数のデータベーステーブルから取得されたデータなど)。同期フレームワークの唯一の要件は、ソースデータの各レコードが一意の ID を持ち、データが同期フレームワークに JSON オブジェクトとして提供されることです。

バックエンドデータソースと同期するために、アプリ開発者は同期のコードを実装できます。

たとえば、データベースからデータをロードする代わりにバックエンドからデータをリストするときに、ハードコーディングされたデータを返すことができます。

興味がある場合は、同期フレームワークを理解するのに役に立つ以下の情報をお読みください。

{
  record_uid_1 : {<JSON Object of data>},
  record_uid_2 : {<JSON Object of data>},
  record_uid_3 : {<JSON Object of data>},
  ...
}

同期クライアントと同期サーバー間の通信用プロトコル。
詳細については、同期プロトコルを参照してください。

同期サーバーは、同期プロトコルのサーバー部分であり、fh-mbaas-api モジュールに含まれます。以下のことを行います。

同期クライアントは、同期プロトコルのクライアント部分です。3 つの同期クライアント実装があります。

同期クライアント:

同期サーバーループは、同期サーバーで継続的に実行される機能です (各実行の間に 500ms の待機が発生)。
各実行中は、すべてのデータセットクライアントに対して反復処理が行われ、データセットをデータセットバックエンドから同期する必要があるかどうかを確認できます。

同期クライアントループは、同期クライアントで継続的に実行される機能です (各実行の間に 500ms の待機が発生)。
各実行中は、すべてのデータセットクライアントに対して反復処理が行われ、データセットを同期サーバーと同期する必要があるかどうかを確認できます。

同期クライアントでは、これは特定のデータセット用の同期サーバーからのアップデートをチェックする間隔です。
同期サーバーでは、これは特定のデータセット用データセットバックエンドからのアップデートをチェックする間隔です。

詳細については、同期周期の設定を参照してください。

データセットは、1 つ以上の同期クライアント、同期サーバー、および データセットバックエンド間で同期されるレコードのコレクションです。

同期クライアントと同期サーバー間で同期されたデータ用レコードのシステム。
API を提供する任意のシステムであり、同期サーバーから mysql データベースや SOAP サービスなどと統合できます。
同期サーバーは、データセットバックエンドと統合するためにデータセットハンドラーを使用して同期サーバー API を公開します。

データセットハンドラーは、同期サーバーをデータセットバックエンドに統合する機能です。
データセットに対して CRUDL アクションを実行したり、データセットレコード間で競合を管理したりする多くのハンドラーがあります。
これらのハンドラーのデフォルトの実装では fh.db (RHMAP MBaaS で支援される MongoDB) を使用します。
これらの各ハンドラーはオーバーライドできます。詳細については、Sync Server API を参照してください。

重要: ハンドラーをオーバーライドする場合、Red Hat は、デフォルトの実装を使用している一部のハンドラーとオーバーライドされた実装を使用している他のハンドラーでの異常な動作を回避するために、すべてのハンドラーをオーバーライドすることをお勧めします。

データセットクライアントは、クライアントとサーバー間で積極的に同期されている各データセットに対する同期クライアントと同期サーバーに格納された設定です。
以下のようなデータが含まれます。

データセットレコードはデータセット内の個別レコードです。
以下のものが含まれます。

同期プロトコルで使用されるハッシュには 2 つの種類があります。

同期サーバーアーキテクチャーに含まれるもの: * HTTP ハンドラー * キューおよびプロセッサー * 同期スケジューラー

これらの各コンポーネントによりデータは MongoDB で永続化されます。˙

同期周期は、システムが 2 つの同期プロセスの間に待機する期間です。

重要: クライアントとサーバーで別々に周期を設定できます。ただし、Red Hat は以下のシナリオを回避するために同じ設定を使用することをお勧めします。

サーバーの同期周期の値により、同期プロセッサーが実行される頻度が決定されます。同期プロセッサーが実行されるたびに、データセットバックエンドに対してリスト操作が実行され、データとローカルコピーが同期されます。使用しているアプリケーション向けの同期周期の最適な値を決定するために、以下のセクションをお読みください。

同期周期値を使用して、サーバーがバックエンドに生成する要求の数を制御できます。この値は、バックエンドが負荷を処理でき、サーバー自体が過負荷の状態でない限り、0ms に設定できます。

同期アーキテクチャーで説明されているように、同期データを格納するために使用するさまざまなキューがあります。データを処理するために、各キューに対応するワーカーが作成されます。この唯一のタスクは、キューからジョブを一度に 1 つずつ取得し、処理することです。ただし、あるジョブを完了してから利用可能な次のジョブを取得するまでの時間を表す間隔値があります。この値は、ワーカーのパフォーマンスを最大化するために設定できます。

本項では以下のことを行う開発者を対象とします。

fh-mbaas-api@>=7.0.0 をすでに使用している場合は、本項のどの手順も実行しないでください。

7.0.0 より前は、同期サーバーが fh.db API を使用して同期操作データを MongoDB に格納していました。fh.db は、中間 http API (fh-ditch) を介することがある MongoDB のラッパーです。この結果、同期操作データに対して実行できるアクションは制限されます。また、MongoDB に直接接続されるモジュールの使用も制限されます。fh-mbaas-api@7.0.0 では、同期サーバーで MongoDB への直接接続が必要です。

条件は以下のとおりです。

同期データハンドラー向けのメソッド署名は、新しい同期フレームワークでは異なります。データハンドラーを実装した場合は、パラメーターの順序を変更する必要があります。これらの変更は、javascript のパラメーター順序規則 (つまり、コールバックが最後のパラメーター) に準拠します。

重要 パラメーターとして各ハンドラーに渡されたコールバック関数が各呼び出しに対して実行されるようにします。これにより、ハンドラーの完了後もワーカーを維持できます。

7.0.0 よりも前のバージョンとそのバージョンのデータハンドラーおよび署名は以下のとおりです。

// <7.0.0
sync.handleList(dataset_id, function(dataset_id, params, callback, meta_data) {});
sync.globalHandleList(function(dataset_id, params, callback, meta_data) {});
// >=7.0.0
sync.handleList(dataset_id, function(dataset_id, params, meta_data, callback) {});
sync.globalHandleList(function(dataset_id, params, meta_data, callback) {});


// <7.0.0
sync.handleCreate(dataset_id, function(dataset_id, data, callback, meta_data) {});
sync.globalHandleCreate(function(dataset_id, data, callback, meta_data) {});
// >=7.0.0
sync.handleCreate(dataset_id, function(dataset_id, data, meta_data, callback) {});
sync.globalHandleCreate(function(dataset_id, data, meta_data, callback) {});


// <7.0.0
sync.handleRead(dataset_id, function(dataset_id, uid, callback, meta_data) {});
sync.globalHandleRead(function(dataset_id, uid, callback, meta_data) {});
// >=7.0.0
sync.handleRead(dataset_id, function(dataset_id, uid, meta_data, callback) {});
sync.globalHandleRead(function(dataset_id, uid, meta_data, callback) {});


// <7.0.0
sync.handleUpdate(dataset_id, function(dataset_id, uid, data, callback, meta_data) {});
sync.globalHandleUpdate(function(dataset_id, uid, data, callback, meta_data) {});
// >=7.0.0
sync.handleUpdate(dataset_id, function(dataset_id, uid, data, meta_data, callback) {});
sync.globalHandleUpdate(function(dataset_id, uid, data, meta_data, callback) {});


// <7.0.0
sync.handleDelete(dataset_id, function(dataset_id, uid, callback, meta_data) {});
sync.globalHandleDelete(function(dataset_id, uid, callback, meta_data) {});
// >=7.0.0
sync.handleDelete(dataset_id, function(dataset_id, uid, meta_data, callback) {});
sync.globalHandleDelete(function(dataset_id, uid, meta_data, callback) {});


// <7.0.0
sync.listCollisions(dataset_id, function(dataset_id, callback, meta_data) {});
sync.globalListCollisions(function(dataset_id, callback, meta_data) {});
// >=7.0.0
sync.listCollisions(dataset_id, function(dataset_id, meta_data, callback) {});
sync.globalListCollisions(function(dataset_id, meta_data, callback) {});


// <7.0.0
sync.removeCollision(dataset_id, function(dataset_id, collision_hash, callback, meta_data) {});
sync.globalRemoveCollision(function(dataset_id, collision_hash, callback, meta_data) {});
// >=7.0.0
sync.removeCollision(dataset_id, function(dataset_id, collision_hash, meta_data, callback) {});
sync.globalRemoveCollision(function(dataset_id, collision_hash, meta_data, callback) {});

同期サーバーが MongoDB に直接接続するようになったため、起動時にセットアップ時間が必要です。sync.init() を現在使用している場合は、これらの呼び出しを sync:ready イベントハンドラーでラップします。たとえば、以下のコードを使用する場合は、

fh.sync.init('mydataset', options, callback);

イベントハンドラーに配置するよう変更します。

fh.events.on('sync:ready', function syncReady() {
  sync.init('mydataset', options, callback);
});

または、同期 API からイベントエミッターを使用できます。

fh.sync.getEventEmitter().on('sync:ready', function syncReady() {
  sync.init('mydataset', options, callback);
});
[source,json]

fh.sync.init() に渡された logLevel オプションは利用できなくなりました。デフォルトでは、新しい同期サーバーは何もログに記録しません。すべてのロギングでは [debug](https://www.npmjs.com/package/debug) モジュールが使用されます。同期サーバーからの出力をログに記録する場合は、以下のように DEBUG 環境変数を設定できます。

DEBUG=fh-mbaas-api:sync

SDK 全体からすべてのログを参照する場合は、以下のように設定します。

DEBUG=fh-mbaas-api:*

debug モジュールの他のすべての環境変数と動作機能が利用可能です。

同期サーバーはスケーラブルとして設計されています。

本項では、同期サーバーのパフォーマンスとスケーリングのオプションについて説明します。

同期サーバーのパフォーマンスを検査するには 2 つのオプションがあります。

同期サーバーのパフォーマンスを理解するために確認する必要がある主要なメトリクスは以下のとおりです。

同期サーバーをスケールする場合は、以下のことを検討します。

同期サーバーは、実行中にさまざまなコレクションを MongoDB に保持します。

本書では、同期サーバーが作成するコレクションとその目的について説明します。

同期サーバーにより作成されたすべてのコレクションには接頭辞 fhsync が付けられます。

各キューコレクションに対して、ドキュメントは処理後すぐに削除されません。代わりに、ドキュメントは deleted と示されます。これにより、開発者はドキュメントを監査ログとして使用し、デバッグに役立てたりすることができるようになります。

これらのキューが容量を使用しすぎないようにするために、これらのメッセージには TTL (time to live) を設定できます。TTL 値に到達すると、これらのメッセージはデータベースから削除されます。

詳細については、$fh.sync.setConfig の「queueMessagesTTL」オプションを参照してください。

この問題のデバッグを容易に行うために、以下の質問に回答してください。

クライアントはサーバーに変更を送信しましたか?

クライアントが変更を行った後に同期要求の要求本文を確認して変更が送信されたかどうかを調べます。変更は pending アレイにある必要があります。以下に例を示します。

{
  "fn":"sync",
  "dataset_id":"myShoppingList",
  /*...*/
  "pending":[{
    "inFlight":true,
    "action":"update",
    "post":{
      "name":"Modified Name",
      "created":1495123790928
    },
    "postHash":"2e90b858164184b9ff31e0937cef8ddf4a959ac5",
    "timestamp":1495799747404,
    "uid":"591dc768a95300322eee1d1f",
    "pre":{
      "name":"Original Name",
      "created":1495123790928
    },
    "preHash":"421932b23f05f8aef528d73fff3cbf5aa00786a4",
    "hash":"f98f595974f7e7e1f07aed6220fab04446f459c9",
    "inFlightDate":1495799747850
  }]
}

変更が保留中のアレイにない場合は、デバイスがオンラインであることを検証します。クライアントアプリにエラーがないか確認し、該当する同期アクションを呼び出していることを検証します (たとえば、更新の場合は sync.doUpdate())。クライアントアプリで、変更を行うコードの周辺でデバッグしたり、ロギングを追加したりすると役に立ちます。

この変更のレコードが fhsync_pending_queue コレクションにありますか?

「いいえ」の場合は、サーバーが変更を受け取っていないか、受け取るときにエラーが発生しました。

レコードが fhsync_pending_queue コレクションに存在したが、レコードに対するキューの Time To Live (TTL) 期間が経過したため、レコードが削除された可能性があります。これに該当する場合は、TTL を増やすと、デバッグが有効になります。

レコードの deleted フィールドにタイムスタンプがありますか?

「いいえ」の場合は、そのアイテムがまだ処理されていません。

この更新のレコードが fhsync_pending_queue コレクションにありますか?

「いいえ」の場合は、更新の処理中にエラーが発生した可能性があります。

レコードの type フィールドが failed または collision に設定されていますか?

「はい」の場合は、更新をデータセットバックエンドに適用できない可能性があります。

「いいえ」であり、タイプが applied の場合は、作成または更新ハンドラーをデバッグして、なぜそのハンドラーで変更がデータセットバックエンドに適用されたと見なされたのかを確認する必要があります。

type フィールドは、collision、failed、または applied のいずれかである必要があります。

変更がデータセットバックエンドからクライアントに同期されるまでに十分な時間が経過しましたか?

変更がデータセットバックエンドに適用され、他のクライアントがその変更を取得する前に、以下の 2 つのことが起こる必要があります。

十分な時間が経過したら、データセットバックエンドとの同期中のエラーをサーバーログで確認してください。

データセット向けの fhsync_queue コレクションに最近のレコードがありますか?

「いいえ」の場合は、レコードの TTL 値が経過し、レコードが削除された可能性があります。この場合は、TTL 値を増やしてさらにデバッグすることができます。

別の可能性としては、同期スケジューラーでそのデータセットの同期がスケジュールされなかったことが挙げられます。この理由としては、そのデータセットに対して現在アクティブなクライアントがなく、そのデータセットに対してクライアントが最後にアクティブであったときから clientSyncTimeout が経過したことが考えられます。

レコードの deleted フィールドにタイムスタンプがありますか?

「いいえ」の場合は、同期がまだ処理されていないことを意味します。

fhsync_<datasetid>_records キャッシュ内のレコードは最新ですか?

リストハンドラーが呼び出され、結果がレコードキャッシュに追加されている必要があります。レコードキャッシュが更新されたことを検証するには、更新されたレコードの fhsync_<datasetid>_records コレクションを確認します。このレコード内のデータはデータセットバックエンドのデータに一致する必要があります。一致しない場合は、サーバーログでリストハンドラーのエラーと動作を確認します。リストハンドラーにロギングを追加すると役に立つことがあります。

クライアント同期呼び出しが正常に実行されましたか?

クライアントが同期呼び出しを行う場合に、サーバーからの有効な応答があることを確認します。呼び出しが正常に行われた場合は、クライアントが更新済みレコードを取得していることを検証します。サーバーキャッシュに更新済みレコードが含まれるのにクライアントが更新済みレコードを受け取らない場合は、クエリーパラメーターとサーバーに送信されたメタデータが正しいことを確認します。デバッグログを有効にすると、正しくないデータがどのようにクライアントに送信されたのかを簡単に調べることができる場合があります。

デバッグのために同期ログを有効にするには、サーバーで以下の環境変数を設定します。

DEBUG=fh-mbaas-api:sync

この処理により、大量のログが生成されます。各ログエントリーには、そのログメッセージのコンテキストでアクションを実行する特定のデータセット ID がタグ付けされます (可能な場合)。これらのログは理解しにくいことがありますが、クライアントからの更新とそれらの更新のさまざまな段階を追跡できます。成功したシナリオのログと不成功のシナリオのログを比較し、障害が発生した段階を特定すると役に立つことがあります。

この問題の原因は、(特にエッジケースに関連する) カスタムハンドラー実装にあることが考えられます。カスタムハンドラーにログを追加すると役に立つことがあります。

データセットバックエンド接続の問題 (特に断続的な問題) はデバッグおよび特定が困難なことがあります。データセットバックエンドを外部的に監視または確認すると、役に立つことがあります。

このチュートリアルでは、モバイルアプリケーションで SAML 認証を使用する例を示します。SAML は現在 Red Hat Mobile Application Platform ホスト型 (RHMAP) では認証ポリシーとして利用できませんが、ユーザーの独自のソリューションの土台として使用できるテンプレートが提供されます。

SAML 認証の同じソリューションは、サーバーサイドロジックとクライアントアプリの両方で構成されます。

以下の各プラットフォーム向けのクライアントアプリが提供されます。

提供されたテンプレートの構造について説明するために、最初に SAML のコンセプトを簡単に説明します。SAML 認証シナリオには以下の 3 つの要素があります。

これらの要素は、複数の前提に基づいて認証の処理で対話します。

最初に、提供されたテンプレートから SAML Service クラウドサービスを作成します。このサービスはソリューションの中心的なコンポーネントであり、サービスプロバイダーとして機能します。この例で提供される実際のサービスでは、エンドポイント /session/valid でユーザーの詳細が表示されています。SAML 認証プロセスをサポートするエンドポイントは他に複数あります。

サービスは IdP として Active Directory Federation Services 2.0 (ADFS) を使用するよう設定されていますが、少しだけ調整して他の任意の SAML 2.0 準拠 IdP を使用するよう設定できます。

認証プロセス中に起こったことを見ていきます。

Sign In ボタンをクリックすると、クライアントアプリが sso/session/login_host エンドポイントを呼び出し IdP のログイン画面の URL を取得します。この URL はアプリ内ブラウザーで開き、IdP と認証できます。

$('.sign-in-button').on('click', function(e) {
  $fh.cloud({
    path: 'sso/session/login_host',
    method: "POST",
    data: {
      "token": $fh._getDeviceId()
    }
  },
  function(res) {
    console.log('sso host:' + res.sso);
    var browser = cordova.InAppBrowser.open(res.sso, '_blank', 'location=yes');
...

JSONObject params = new JSONObject();
params.put(TOKEN, Device.getDeviceId(getApplicationContext()));

FHCloudRequest request = FH.buildCloudRequest(
  "sso/session/login_host", "POST", null, params);
request.executeAsync(new FHActCallback() {
  @Override
  public void success(FHResponse res) {
    Log.d(TAG, "FHCloudRequest (login_host) - success");
    String ssoStringURL = res.getJson().getString("sso");
    Log.d(TAG, "SSO URL = " + ssoStringURL);
    SAMLActivity.this.displayWebView(ssoStringURL);
  }
...

NSString* deviceID = [[FHConfig getSharedInstance] uuid];
NSMutableDictionary __params = [NSMutableDictionary dictionary];
params[@"token"] = deviceID;
FHCloudRequest __cloudReq = [FH buildCloudRequest:@"sso/session/login_host" WithMethod:@"POST" AndHeaders:nil AndArgs: params];

// Initiate the SSO call to the cloud
[cloudReq execWithSuccess:^(FHResponse _success) {
  NSLog(@"EXEC SUCCESS =%@", success);
  NSDictionary_ response = [success parsedResponse];
  NSString* urlString = response[@"sso"];
  NSURL* loginUrl = [[NSURL alloc] initWithString:urlString];
  // Display WebView
  FHSAMLViewController *controller = [[FHSAMLViewController alloc] initWithURL:loginUrl];
  [[[[UIApplication sharedApplication] keyWindow] rootViewController] presentViewController:controller animated:YES completion:nil];
...

private async void Button_Click(object sender, RoutedEventArgs e)
{
    var response = await FHClient.GetCloudRequest("sso/session/login_host", "POST", null, GetRequestParams()).ExecAsync();

    var resData = response.GetResponseAsJObject();
    var sso = (string)resData["sso"];
    if (!string.IsNullOrEmpty(sso))
    {
        webView.Visibility = Visibility.Visible;
        webView.Navigate(new Uri(sso));
  }
}

IdP で必要なクレデンシャルを入力し、ログインフォームを送信したら、IdP は ID アサーションを SAML サービスの /login/callback エンドポイントにポストし直します。

SAML サービスは以下のことを行います。

ユーザーが正常にログインしたら、アプリ内ブラウザーが閉じられ、クライアントアプリはサービスプロバイダーにより提供されたサービスを使用できます (sso/session/valid を呼び出しユーザーの詳細を取得します) 。

$fh.cloud({
  path: 'sso/session/valid',
  method: "POST",
  data: {
    "token": $fh._getDeviceId()
  }
},
function(details) {
  $('.first_name').text(details.first_name);
  $('.last_name').text(details.last_name);
  $('.email').text(details.email);
  $('.expires').text(details.expires);
},
...

JSONObject params = new JSONObject();
params.put(TOKEN, Device.getDeviceId(getApplicationContext()));

FHCloudRequest request = FH.buildCloudRequest(
  "sso/session/valid", "POST", null, params);
  request.executeAsync(new FHActCallback() {
    @Override
    public void success(FHResponse res) {
      Log.d(TAG, "FHCloudRequest (valid) - success");
      User user = new User();
      user.setFirstName(res.getJson().getString("first_name"));
      user.setLastName(res.getJson().getString("last_name"));
      user.setEmail(res.getJson().getString("email"));
      user.setExpires(res.getJson().getString("expires"));

      Log.d(TAG, user.toString());

      SAMLActivity.this.displayUserData(user);
...

NSString* deviceID = [[FHConfig getSharedInstance] uuid];
NSMutableDictionary __params = [NSMutableDictionary dictionary];
params[@"token"] = deviceID;
FHCloudRequest __cloudReq = [FH buildCloudRequest:@"sso/session/valid" WithMethod:@"POST" AndHeaders:nil AndArgs: params];

// Initiate the SSO call to the cloud
[cloudReq execWithSuccess:^(FHResponse _success) {
  NSDictionary_ response = [success parsedResponse];
  // Manage next UI view controller
  [ self performSegueWithIdentifier: @"showLoggedIn" sender: response];
} AndFailure:^(FHResponse *failed) {
  NSLog(@"Request name failure =%@", failed);
}];

var response = await FHClient.GetCloudRequest("sso/session/valid", "POST", null, GetRequestParams()).ExecAsync();
if (response.Error == null)
{
  var data = response.GetResponseAsDictionary();
  name.Text = string.Format("{0} {1}", data["first_name"], data["last_name"]);
  email.Text = (string) data["email"];
  expires.Text = ((DateTime) data["expires"]).ToString();
}
else
{
  await new MessageDialog(response.Error.ToString()).ShowAsync();
}

OpenShift Online は、アプリケーションのプロビジョニング、管理、およびスケーリングを自動化する、Red Hat のパブリッククラウドアプリケーションの開発およびホスティングプラットフォームです。

最初に必要なものは OpenShift Online アカウントです。既存のアカウントを使用するか、新しいアカウントを作成することができます。

{
  "action": {},
  "cacheKey": "CloudAppdevelnat-openshiftdeploy",
  "error": "",
  "log": [],
  "status": "complete"
}

RHMAP は、OpenShift Online ギアを MBaaS ターゲットとして扱うために、最初に OpenShift Online への接続を確立する必要があります。この接続は OpenShift Online クレデンシャルを使用して RHMAP に初めてログインする場合にセットアップされます。RHMAP はユーザーのクレデンシャルを使用してユーザーの代わりに OpenShift Online にログインし、承認トークンを交換して、RHMAP と OpenShift Online 間の今後の通信を可能にする SSH キーをセットアップします。次に、RHMAP は自動的に OpenShift Online を MBaaS ターゲットとして設定し、プロジェクトで利用できるようにします。

初期設定が完了し、RHMAP プロジェクトで OpenShift MBaaS ターゲットを使用できるようになったら、RHMAP クラウドアプリを OpenShift Online にデプロイできます。これらのアプリは他の OpenShift Online アプリケーションと同様に扱われ、特別な利点として RHMAP に統合されます。たとえば、デプロイメント、アプリケーションロギング、および他の操作は引き続き RHMAP から実行できますが、OpenShift Online で実行されているアプリケーションに SSH 経由で直接接続することもできます。また、アプリケーションが OpenShift Online コンソールから直接デプロイされた場合は、そのアプリケーションの詳細を表示することもできます。

アプリのユーザーの認証を Google の OAuth サービスに対して実行するには、最初に複数の手順を実行する必要があります。

以下の図では、Google のコンソールでこれらの項目が赤で示されています。

承認パネルには 2 つのオプションがあります。

これらいずれかのオプションを選択しない場合は、適切な Google アカウントを持つすべてのユーザーがアプリにアクセスすることを許可すると見なされます。

既存のユーザーを認証ポリシーに追加するには、check if user is approved for Auth オプションをクリックします。スワップ選択が、利用可能なユーザーが入力された状態で表示されます。これらいずれかのユーザーをポリシーに追加するには、ユーザーを選択し、承認済み列の方向を向いた矢印を押します。ユーザーを削除するには、承認済み列でユーザーを選択し、利用可能な列の方向を向いた矢印をクリックします。

認証ポリシーの設定が完了したら、"Update Policy" ボタンをクリックします。

App Studio の Data Browser セクションでは、開発者は以下のことを行えます。

$fh.db API で提供されるもの以外のデータベース操作を実行する必要がある場合は、MongoDB ドライバーを直接使用してデータベースにアクセスできます。データベースへの直接アクセスを有効にするには、最初にデータベースをアップグレードし、専用インスタンスに移行する必要があります。

アプリのデータベースをアップグレードするには、データブラウザー画面の右上隅にある Upgrade Database ボタンをクリックします。

アップグレード中にプラットフォームにより以下の手順が実行されます。

データベースにすでにデータが含まれる場合は、以下の手順が実行されます。

注記: application.js ファイルと package.json ファイルの内容を更新する必要がある場合もあります。この場合は、移行画面で通知されます。

すべてのデータ移行手順が完了したら、アプリを再デプロイする必要があります。

データベースのアップグレードが完了したら、プレフィックス fhsync_ の付いた新たなコレクションが作成され、同期機能が有効になります。Red Hat では、同期機能を使う予定がない場合でも、これらのコレクションを保持しておくことを推奨しています。

クラウドアプリまたはサービスに関連するすべてのコレクションは、単一の tar アーカイブにエクスポートされ、圧縮されたバイナリー JSON (BSON) ファイルとして個別のコレクションから構成されます。各 BSON ファイルの名前は元のコレクションの名前と一致します。

例:

    export.tar
    |__ <COLLECTION_1_NAME>.bson.gz
    |__ <COLLECTION_2_NAME>.bson.gz

BSON ファイルは、標準的な MongoDB バックアップおよび復元ツールと互換性があります。 詳細については、Back Up and Restore with MongoDB Tools を参照してください。

アプリケーションデータのエクスポートプロセスは、主に以下の 3 つの手順から構成されます。

アプリケーションデータのインポートプロセスは、主に以下の 2 つの手順から構成されます。

"www" ディレクトリーのみが公開された標準的な Cordova 3.x アプリ。 これらのアプリでは、標準的な Web テクノロジー (HTML5、CSS、JavaScript) を使用します。ネイティブコードは使用しません。

これらは、プラットフォームの使用方法を学ぶための最も単純なアプリですが、開発者は標準的な Cordova プラグインのみを使用するよう制限されます。これは、config.json ファイルを使用して実現されます (Cordova プラグイン)。

標準的な Cordova 3.x モバイルアプリケーション。これらのアプリは Web テクノロジーとネイティブコードの組み合わせで構成されます。基礎となるネイティブプロジェクトと Cordova ライブラリーは開発者に公開され、アプリ (Cordova プラグインとサードパーティー製 SDK を含む) の完全なカスタマイズが可能になります。

通常、これらのアプリのネイティブコードを記述または変更するのにかかる時間は比較的短く、小規模な開発チームのみがネイティブコードを扱う必要があります。開発チームはネイティブコードを開発、設定、および管理し、標準的な Cordova プラグインの手法を使用して追加のプラグインまたは SDK を Web 層に公開できる必要があります。

開発チームは、ネイティブコードについてほとんど心配する必要がありません。開発チームは、引き続き純粋な Web 技術を使用して開発を行えますが、ネイティブ層から公開された追加の機能も利用できます。

Node.js + Express Web アプリケーション。これらのアプリは、高度なモバイル Web サイトとデスクトップブラウザー Web ポータルを提供します。この場合、非常に強力な Node.js (Jade などのテンプレートエンジンを使用したサーバーサイドテンプレートなどの機能を含む) を使用して Web アプリ開発を行えます。また、標準的な HTML5、CSS、および JavaScript 向けの静的ファイルの提供もサポートされます。

ネイティブの Android アプリ。

ネイティブ iOS アプリケーション。

ネイティブ Windows Phone 8 アプリ。

Xamarin アプリ。

v2 Studio では、アプリはハイブリッドアプリ、Web アプリ、クラウドアプリ、および場合によってはネイティブ iOS または Android アプリすべてを表します。v3 Studio では、アプリはこれらのコンセプトの 1 つを表します。アプリはクラウドアプリまたはネイティブ iOS アプリのいずれかであり、両方ではありません。v3 Studio では、機能とプラットフォームを分けるためにさまざまなアプリの種類が提供されます (ただし、これらのアプリはプロジェクトでグループ化できます)。

v2 から v3 の Studio に移行する最大の利点は、新しい複数の機能を利用できることです。プロジェクトワークフローにより、開発ライフサイクル全体でプロジェクト内の複数のアプリを簡単に管理できるようになります。v3 の各アプリは、ホストされた git リポジトリーによって支持されます。これらのアプリは、SSH キーをアップロードするだけで使用できます。

v2 Studio は引き続きサポートされますが、v2 Studio では新しいプラットフォームの機能は使用できません。

v2 アプリを個別に v3 プロジェクトに移行するために、v2 Studio では自動移行機能が利用できます。この移行プロセスの詳細を知りたい場合、またはアプリを手動で移行する場合は、詳細なアプリ移行ガイドを参照してください。

Studio アプリ移行機能はドメイン内のすべてのアプリで利用可能です。ただし、アプリによっては移行が簡単でない場合があります。Studio は、検証チェックを実行して自動移行がアプリに適しているかどうかを判断しようとします。このチェックは非破壊的であり、アプリにはまったく変更が加えられません。この機能を実行して移行しないことを決定することができます。

アプリのサイズに応じて、検証チェックには数秒から最大 1 分かかります。検証チェック後に、移行を自動的に行えるかどうかを通知する視覚的なレポートが生成されます。このレポートには、アプリで検出されたことと移行で注意する必要がある潜在的な問題 (警告) に関する情報が示されます。作業を円滑に進めるために、移行前にすべての問題を解決する (または問題の解決を計画する) ことが重要です。

検証チェックが何らかの理由で失敗した場合は、エラーが表示されます。可能な場合は、移行のためにアプリを再び検証しようとする前にエラーを修正する必要があります。手動による移行が唯一の選択肢となることもあります。不確かな移行の問題またはサポートが必要な移行の問題は、https://access.redhat.com から報告できます。

検証チェックが成功した場合は、Migrate ボタンが表示されます。このボタンを押すと、移行が開始され、進捗のフィードバックがリアルタイムで提供されます。移行が成功すると、小さなレポートが作業途中で検出されたすべての潜在的な問題とともに表示されます。 強調表示された問題は、v3 Studio を最大に活用するのに重要である場合があるため、完全に理解することをお勧めします。

移行中に問題が発生した場合は、プラットフォームにより、すべての変更がロールバックされ、アプリが移行前の状態に復元されます。繰り返しますが、この移行ステージで発生したすべての問題は、https://access.redhat.com で報告できます。

複数のアプリを移行する場合は、移行をスクリプト化すると便利です。これは、fhc migrate コマンドを使用して行えます。以下に例を示します。

fhc migrate <appid>

migrate コマンドにより、最初に検証チェックが実行され、問題がない場合に、続行するか尋ねられます。

ドメイン内のすべてのアプリを自動的に移行する場合は、以下のスクリプトを土台として使用できます。

#!/usr/bin/env node
var fh = require('fh-fhc');
var async = require('async');

// Init fhc
fh.fhc.load(function (err) {
  if (err) return console.error(err);
  // Target my domain and login
  fh.target(['https://testing.feedhenry.me','testing@example.com','password'], function(err, ok) {
    if (err) return console.error(err);
    console.log('ok:', ok);
    // List all apps
    fh.apps([], function(err, apps) {
      if (err) return console.error(err);
      console.log('apps:', apps);
      // Iterate over apps, calling migrate for each
      async.mapSeries(apps.list, function(app, cb) {
        // Passing 'silent' here will bypass prompt after validation check if check is ok
        fh.migrate([app.id, 'silent'], function(err, data) {
          if (err) return cb(err);
          console.log('data:', data);
          return cb(null, data);
        });
      }, function(err, results) {
        if (err) return console.error(err);
        // all done
        console.log('results:', results);
      });
    });
  });
});

この例は、gist (package.json を含む) としても利用できます。

v2 アプリは v2 Studio でのみ確認できるアプリです。Web アプリとしてホストし、デバイスに対してビルドおよびデプロイして、実行されているサーバーサイドコンポーネントを Node.js (または従来の Rhino) 環境にデプロイできます。

これらすべての機能は、一意の ID である GUID (Globally Unique Identifier) を持つ単一のアプリに割り当てられます。単一のコードベースはプラットフォームに格納できます (Studio と API を介してのみアクセスできます)。また、git リポジトリー (パブリックまたはプライベート) に格納して、Studio からリンクすることもできます。上記の各機能を単一のコードベースからサポートすると、厳密なディレクトリー構造が強制されます。この構造は以下のとおりです。

すべての機能は単一のアプリ guid に割り当てられるため、このアプリにより表されるさまざまな Web アプリまたは Cordova アプリはクラウドコードに密接に結合されます。つまり、このアプリの実行中のクラウドコードとのみ対話します。

v3 アプリは v3 Studio でのみ確認できるアプリです。すべての v3 アプリはプロジェクトの一部です。v3 アプリの機能はアプリの種類 (Cordova アプリ、クラウドアプリ、ネイティブ iOS など) によって異なります。一般的に v2 アプリの個別機能は v3 アプリタイプにマップされます。たとえば、v3 アプリタイプがクラウドアプリの場合は、Node.js コードをクラウド環境にデプロイできます。タイプが Cordova Light の場合は、Web コンテンツ (html、css、js) を使用してさまざまなプラットフォーム用のネイティブアプリバイナリーをビルドできます。各アプリタイプは特定の機能を考慮して設計されているため、特にチームで開発を容易に管理できます (懸念事項の切り分けが可能)。

v3 Studio では、確認するアプリタイプで利用できる機能のみが表示されます。たとえば、確認するアプリが Cordova Light アプリタイプである場合は、Build オプションが表示されますが、Deploy オプションは表示されません。(新しい) ネイティブ iOS アプリを確認する場合は、Build オプションが表示されますが、Config オプションと Push オプションは表示されません (これらは Cordova と類似したアプリであるため)。

各 v3 アプリには、独自の git リポジトリー (プラットフォームでホストされる) により支持された独自のコードベースがあります。つまり、厳密なディレクトリー構造はありません。たとえば、クラウドアプリの場合は、git リポジトリーのルートにファイル package.json と application.js があります。一般的に、ルートにコードを配置することが適切な場合、プラットフォームはビルド時またはデプロイ時にその場所でコードを探します。この唯一の例外は Cordova Light アプリです。このアプリでは、すべての Web コンテンツ (HTML、CSS、JS) を /www フォルダーに保持する Cordova の規則に従います。これにより、ビルドスクリプトと他の非本番稼働コンテンツをビルドされるアプリに含めずに保守することが簡単になります。

v3 Studio では、プロジェクトはアプリの論理的なグループです。プロジェクトのクライアントアプリが (接続を介して) 同じプロジェクトのクラウドアプリまたはデプロイ済みアプリに API 呼び出しを行うよう設定できます。プラットフォームの一部の機能 (フォーム、接続、レポートなど) はプロジェクトに関連付けられます。また、プロジェクトにはサービスも関連付けられます。サービスは、サードパーティー製システムとの事前定義された統合です。プロジェクトにはコードベースと独自の特別な機能がないため、プロジェクトをビルドまたはデプロイすることはできません。

v3 Studio では、アプリは独自に存在することはできません。アプリはプロジェクトに属する必要があります。v2 アプリを v3 Studio に移行する場合は、ベアプロジェクトを選択することをお勧めします。これにより、アプリがない状態で新しいプロジェクトが作成されます。

package.json を更新するには、以下の手順に従ってください。

グローバルの $fh は使用されなくなりました。必要な場合は作成できますが、代わりに fh に置き換えることが推奨されます。

fh-mbaas-api/fh-mbaas-express の場合、application.js ファイルは大幅に異なります。既存の application.js を Hello World テンプレートアプリの最新の application.js ファイルに置き換えることが推奨されます。

これはオプションですが、使用することを強く推奨します。新しい FeedHenry テンプレートは、ローカル開発とテスト向けのベストプラクティスの支援のために Grunt を頻繁に使用します。

アプリで Grunt を使用するには、Hello World Cloud テンプレートの該当する Grunt 部分をコピーすることをお勧めします。

FeedHenry v2 では、Embed 宛先を使用して、プラットフォームでクライアントコードを Web アプリとしてホストできました。これは既存のクライアントアプリの単純な HTML ベース Web ポータルを作成する場合に便利でした。

RHMAP Studio では、組み込みアプリが非推奨になり、基本的な Web アプリに置き換えられました。基本的な Web アプリは、アプリを組み込む以前の FeedHenry v2 オプションと同じ機能を提供します。また、ライフサイクル管理のために index.html 、アプリの実行方法と実行場所、および個別の Git リポジトリーを完全に制御することもできます。

アプリを RHMAP プロジェクトに移行した後で、組み込みアプリは引き続き実行されますが、既存の組み込みアプリを再デプロイすることはできなくなります。本書では、RHMAP プロジェクトで既存の組み込みアプリを新しい基本的な Web アプリに移行する手順について説明します。

移行を開始するために、既存の FeedHenry v2 アプリを RHMAP プロジェクトにすでに移行したことを前提とします。まだ移行していない場合は、ここにあるガイドを参照してください。

ロールベースのパーミッションシステムでは、ロールは以下の 3 つのレベルのユーザーに割り当てられます。

チームに割り当てられる以下のパーミッションにより、アナリィティクスへの同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、フォームへの同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、フォームへの同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、フォームへの同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、フォームへの同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、同等のアクセスが許可されます。

チームに割り当てられる以下のパーミッションにより、同等のアクセスが許可されます。