サードパーティー 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 から生データ自体にアクセスしたりできます。