リソース: TransferRun
実行されるデータ転送を表します。
JSON 表現 | |
---|---|
{ "name": string, "labels": { string: string, ... }, "scheduleTime": string, "runTime": string, "errorStatus": { object( |
フィールド | |
---|---|
name |
転送実行のリソース名。転送実行名の形式は |
labels |
ユーザーラベル。
|
scheduleTime |
転送実行が開始するまでの最小時間。 RFC3339 UTC「Zulu」形式のタイムスタンプ。精度はナノ秒。例: |
runTime |
バッチ転送実行の場合、データが取り込まれる日時を指定します。 RFC3339 UTC「Zulu」形式のタイムスタンプ。精度はナノ秒。例: |
errorStatus |
転送実行のステータス。 |
startTime |
出力のみ。転送実行の開始時間。入力リクエストでは、パラメータが無視されます。 RFC3339 UTC「Zulu」形式のタイムスタンプ。精度はナノ秒。例: |
endTime |
出力のみ。転送実行の終了時間。入力リクエストでは、パラメータが無視されます。 RFC3339 UTC「Zulu」形式のタイムスタンプ。精度はナノ秒。例: |
updateTime |
出力のみ。データ転送実行状態が最後に更新された時間。 RFC3339 UTC「Zulu」形式のタイムスタンプ。精度はナノ秒。例: |
params |
出力のみ。データ転送固有のパラメータ。 |
destinationDatasetId |
出力のみ。BigQuery ターゲット データセット ID。 |
dataSourceId |
出力のみ。データソースの ID。 |
state |
データ転送の実行状態。入力リクエストでは無視されます。 |
userId |
非推奨。転送が代行されたユーザーの一意の ID。 |
schedule |
出力のみ。定期的なスケジュールの一部として転送ジョブが作成されている場合には、この転送ジョブのスケジュールが入ります。手動でスケジュールされたバッチ転送実行の場合、このフィールドは空になります。注: 現在の負荷状態に応じて、システムがスケジュールの延期を選択する場合があります。このため、この値と |
partnerToken |
出力のみ。これは、TransferConfig から初期化されたトークンと同じものです。パートナー トークンは、外部パートナー側に保存されている転送設定の識別に使用される一意の識別子です。トークンは DTS から見えず、パートナーのみが解釈できます。パートナー データソースでは、転送構成(実行)の正当性を検証するため、構成 ID とトークンのマッピングが作成されます。 |
ステータス
Status
型は、REST API や RPC API など、さまざまなプログラミング環境に適した論理エラーモデルを定義します。gRPC により使用されます。エラーモデルは次の属性を付与するように設計されています。
- 多くのユーザーにとって使いやすく、わかりやすいこと。
- 柔軟で予期しないニーズに対応できる。
概要
Status
メッセージには、エラーコード、エラー メッセージ、エラーの詳細の 3 種類のデータが含まれます。エラーコードは、google.rpc.Code
の列挙値であることが必要ですが、必要に応じて追加のエラーコードを受け入れることもできます。エラー メッセージは、デベロッパーがエラーを理解して解決できるよう、デベロッパー向けの英語によるメッセージにする必要があります。ユーザー向けのローカライズされたエラー メッセージが必要な場合は、エラーの詳細にローカライズされたメッセージを入れるか、クライアントでローカライズします。オプションのエラーの詳細には、エラーに関する任意の情報を含めることができます。パッケージ google.rpc
には、一般的なエラー条件に使用できる事前定義されたエラー詳細タイプのセットがあります。
言語マッピング
Status
メッセージはエラーモデルの論理表現ですが、必ずしも実際の送信形式ではありません。Status
メッセージが別のクライアント ライブラリと別のワイヤ プロトコルで公開されている場合は、異なる方法でマッピングできます。たとえば、Java では例外にマッピングされるものが、C ではエラーコードにマッピングされる可能性が高くなります。
他の使用例
エラーモデルと Status
メッセージは、API の有無にかかわらず、さまざまな環境で使用でき、異なる環境で一貫したデベロッパー エクスペリエンスを提供します。
このエラーモデルの使用例には、次のようなものがあります。
部分的エラー。サービスがクライアントに部分的なエラーを返す必要がある場合は、部分的なエラーを示すために通常のレスポンスに
Status
を埋め込むことができます。ワークフロー エラー。通常のワークフローには複数のステップがあります。各ステップに、エラー報告用の
Status
メッセージを含めることができます。一括オペレーション。クライアントで一括リクエストと一括レスポンスを使用する場合は、各エラーのサブレスポンスに 1 つずつ、一括レスポンスの中で
Status
メッセージを直接使用する必要があります。非同期操作。API 呼び出しでレスポンスに非同期オペレーションの結果を埋め込む場合、オペレーションのステータスは
Status
メッセージを使用して直接表す必要があります。ロギング。一部の API エラーがログに保存されている場合、メッセージ
Status
はセキュリティやプライバシー上の理由で必要とされる除去を行った後に、直接使用できます。
JSON 表現 | |
---|---|
{ "code": number, "message": string, "details": [ { "@type": string, field1: ..., ... } ] } |
フィールド | |
---|---|
code |
ステータス コード。 |
message |
デベロッパー向けのエラー メッセージ。英語で記述します。ユーザー向けのエラー メッセージは、ローカライズして |
details[] |
エラーの詳細を保持するメッセージのリスト。API が使用する共通のメッセージ タイプのセットがあります。 任意のデータ型のフィールドを含むオブジェクト。タイプを識別する URI を含むフィールド |
メソッド |
|
---|---|
|
指定した転送実行を削除します。 |
|
データソースが実行の処理を完了したことを Data Transfer Service に通知します。 |
|
実行された特定の転送に関する情報を返します。 |
|
実行中のジョブと完了したジョブの情報を返します。 |
|
転送実行に関するメッセージをログに記録します。 |
|
転送実行を更新します。 |
|
データの読み込み準備が完了したことを Data Transfer Service に通知します。 |