How do I run the report_operations commands from the shell?

Sends trigger_report_instance_request and prints trigger_report_instance_response, so the shape is the protocol's and the meaning is the service's. It reads report_definition_id, tenant_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations trigger-report-instance <report_definition_id> <tenant_id> [--job_instance_id <v>] [--kind <v>] [--covered_date <v>] [--scope_code <v>] [--business_centre_code <v>]

It is addressed at reporting.v1.ops.trigger_report_instance.

report_operations trigger-report-instance 00000000-0000-0000-0000-000000000000 00000000-0000-0000-0000-000000000000

Sends get_run_health_request and prints get_run_health_response, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations get-run-health <report_instance_id>

It is addressed at reporting.v1.ops.get_run_health.

report_operations get-run-health 00000000-0000-0000-0000-000000000000

Sends record_run_pricing_request and prints record_run_pricing_response, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, priced_at, price_note, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations record-run-pricing <report_instance_id> <priced_at> <price_note>

It is addressed at reporting.v1.ops.record_run_pricing.

report_operations record-run-pricing 00000000-0000-0000-0000-000000000000 __none__ __none__

Sends schedule_report_definitions_request and prints schedule_report_definitions_response, so the shape is the protocol's and the meaning is the service's. It reads ids, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations schedule-report-definitions <ids>

It is addressed at reporting.v1.ops.schedule_report_definitions.

report_operations schedule-report-definitions __none__

Sends unschedule_report_definitions_request and prints unschedule_report_definitions_response, so the shape is the protocol's and the meaning is the service's. It reads ids, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations unschedule-report-definitions <ids>

It is addressed at reporting.v1.ops.unschedule_report_definitions.

report_operations unschedule-report-definitions __none__

Sends gather_trades_request and prints gather_trades_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, definition_id, tenant_id, correlation_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations gather-trades <report_instance_id> <definition_id> <tenant_id> <correlation_id>

It is addressed at reporting.v1.ops.gather_trades.

report_operations gather-trades __none__ __none__ __none__ __none__

Sends gather_market_data_request and prints gather_market_data_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, definition_id, tenant_id, correlation_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations gather-market-data <report_instance_id> <definition_id> <tenant_id> <correlation_id>

It is addressed at reporting.v1.ops.gather_market_data.

report_operations gather-market-data __none__ __none__ __none__ __none__

Sends assemble_bundle_request and prints assemble_bundle_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, definition_id, tenant_id, correlation_id, trades_storage_key, market_data_storage_key, fixings_storage_key, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations assemble-bundle <report_instance_id> <definition_id> <tenant_id> <correlation_id> <trades_storage_key> <market_data_storage_key> <fixings_storage_key> [--trade_count <v>] [--trade_versions <v>] [--series_count <v>]

It is addressed at reporting.v1.ops.assemble_bundle.

report_operations assemble-bundle __none__ __none__ __none__ __none__ __none__ __none__ __none__

Sends prepare_ore_package_request and prints prepare_ore_package_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, definition_id, bundle_id, tenant_id, party_id, run_grant_id, correlation_id, trades_storage_key, market_data_storage_key, fixings_storage_key, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations prepare-ore-package <report_instance_id> <definition_id> <bundle_id> <tenant_id> <party_id> <run_grant_id> <correlation_id> <trades_storage_key> <market_data_storage_key> <fixings_storage_key>

It is addressed at ore.v1.ops.prepare_ore_package.

report_operations prepare-ore-package __none__ __none__ __none__ __none__ __none__ __none__ __none__ __none__ __none__ __none__

Sends submit_compute_request and prints submit_compute_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, tenant_id, party_id, run_grant_id, correlation_id, tarball_uris, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations submit-compute <report_instance_id> <tenant_id> <party_id> <run_grant_id> <correlation_id> <tarball_uris>

It is addressed at compute.v1.ops.submit_compute.

report_operations submit-compute __none__ __none__ __none__ __none__ __none__ __none__

Sends collect_compute_results_request and prints collect_compute_results_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, tenant_id, correlation_id, batch_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations collect-compute-results <report_instance_id> <tenant_id> <correlation_id> <batch_id>

It is addressed at reporting.v1.ops.collect_compute_results.

report_operations collect-compute-results __none__ __none__ __none__ __none__

Sends post_process_results_request and prints post_process_results_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, tenant_id, correlation_id, batch_id, skipped_families, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations post-process-results <report_instance_id> <tenant_id> <correlation_id> <batch_id> <skipped_families>

It is addressed at reporting.v1.ops.post_process_results.

report_operations post-process-results __none__ __none__ __none__ __none__ __none__

Sends finalise_report_request and prints finalise_report_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, tenant_id, correlation_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations finalise-report <report_instance_id> <tenant_id> <correlation_id>

It is addressed at reporting.v1.ops.finalise_report.

report_operations finalise-report __none__ __none__ __none__

Sends fail_report_request and prints fail_report_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, tenant_id, correlation_id, error_message, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations fail-report <report_instance_id> <tenant_id> <correlation_id> <error_message>

It is addressed at reporting.v1.ops.fail_report.

report_operations fail-report __none__ __none__ __none__ __none__

Sends resolve_prepared_input_request and prints prepare_ore_package_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, tenant_id, correlation_id, prepared_input_key, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations resolve-prepared-input <report_instance_id> <tenant_id> <correlation_id> <prepared_input_key>

It is addressed at reporting.v1.ops.resolve_prepared_input.

report_operations resolve-prepared-input __none__ __none__ __none__ __none__

Sends ignore_compute_results_request and prints collect_compute_results_result, so the shape is the protocol's and the meaning is the service's. It reads report_instance_id, tenant_id, correlation_id, batch_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations ignore-compute-results <report_instance_id> <tenant_id> <correlation_id> <batch_id>

It is addressed at reporting.v1.ops.ignore_compute_results.

report_operations ignore-compute-results __none__ __none__ __none__ __none__

Sends get_next_fire_request and prints get_next_fire_response, so the shape is the protocol's and the meaning is the service's. It reads definition_ids, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations get-next-fire <definition_ids>

It is addressed at reporting.v1.ops.get_next_fire.

report_operations get-next-fire __none__

Sends resolve_cut_request and prints resolve_cut_response, so the shape is the protocol's and the meaning is the service's. It reads report_definition_id, covered_date, scope_code, business_centre_code, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations resolve-cut <report_definition_id> <covered_date> <scope_code> <business_centre_code> [--preview <v>] [--market_data_snapshot_id <v>] [--deal_population_id <v>] [--reference_data_version <v>] [--engine_version <v>] [--code_version <v>]

It is addressed at reporting.v1.ops.resolve_cut.

report_operations resolve-cut 00000000-0000-0000-0000-000000000000 __none__ __none__ __none__

Sends list_cut_rows_request and prints list_cut_rows_response, so the shape is the protocol's and the meaning is the service's. The caller must have established a session first.

The command is shaped like this:

report_operations list-cut-rows [--kind_code <v>] [--month <v>] [--search <v>] [--state <v>] [--offset <v>] [--limit <v>]

It is addressed at reporting.v1.ops.list_cut_rows.

report_operations list-cut-rows

Sends get_cut_record_request and prints get_cut_record_response, so the shape is the protocol's and the meaning is the service's. It reads cut_id, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations get-cut-record <cut_id>

It is addressed at reporting.v1.ops.get_cut_record.

report_operations get-cut-record 00000000-0000-0000-0000-000000000000

Sends take_cut_request and prints take_cut_response, so the shape is the protocol's and the meaning is the service's. It reads kind_code, scope_code, business_centre_code, timepoint, timepoint_timezone, reason, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations take-cut <kind_code> <scope_code> <business_centre_code> <timepoint> <timepoint_timezone> <reason> [--cut_time_code <v>] [--preview <v>]

It is addressed at reporting.v1.ops.take_cut.

report_operations take-cut __none__ __none__ __none__ __none__ __none__ __none__

Sends list_cut_authorisation_subjects_request and prints list_cut_authorisation_subjects_response, so the shape is the protocol's and the meaning is the service's. It reads request_ids, in that order. The caller must have established a session first.

The command is shaped like this:

report_operations list-cut-authorisation-subjects <request_ids>

It is addressed at reporting.v1.ops.list_cut_authorisation_subjects.

report_operations list-cut-authorisation-subjects __none__