Turbo Integrator, Workato, and Task Scheduler#

The automation API is the substrate under three ready-made ways to launch a job from outside Reportworq: an IBM Planning Analytics Turbo Integrator (TI) process, a Workato recipe, and a Windows Task Scheduler task. This page covers each, and the one PowerShell setting that keeps a script-launched job from appearing to hang.

When to use it. Launch a job this way when the trigger is another system's event rather than a clock, for example a TI process that has just finished loading actuals and should regenerate the reporting pack on data-ready. If you previously used Cube Monitoring to launch jobs from Planning Analytics, note that Cube Monitoring is deprecated, and the REST-API Turbo Integrator described here is its replacement, it now also reaches IBM Planning Analytics Cloud through the Cloud Connector relay.

Before you begin#

• The target job is authored and listable through the API.
• You have the right token for the delivery model: a workspace access token for the Local API, or the Cloud Connector token for the Cloud API. See The automation API.
• For a Cloud call from Planning Analytics Cloud, the on-prem instance is registered with CloudHub (the Cloud Connector is enabled), and you have the workspace name for ?workspace=.

Launch a job from IBM Planning Analytics Turbo Integrator#

Reportworq ships sample TI processes you adapt rather than write from scratch. They live in the TM1 plugin's TI_Scripts folder and include:

• Rest API Run Job Sample, and a Cloud variant that reaches Planning Analytics Cloud through the Cloud Connector relay.
• Add Queued Job Sample and Add Queued Job For Workspace Sample, for queued execution.
• A PowerShell prolog variant used by the Cloud sample.

To use one:

1. Import the sample TI process that matches your delivery model (Local or Cloud) into your Planning Analytics model.
2. Set the Reportworq server address (or the CloudHub base URL), the token, and the target job name.
3. For a Cloud call on a multi-workspace instance, set the ?workspace={name} querystring.
4. Call the process where your model's data load finishes, so the reporting pack regenerates on data-ready.

The TI process calls the REST run command described in Run a job by API, so the same parameter and distribution overrides are available from TI.

Launch a job from Workato#

The Reportworq Workato connector wraps the same command set as recipe actions:

• Check Server Status, returns true or false.
• List Jobs.
• Run Asynchronous, starts a job and returns its job id.
• Run Synchronous, starts a job and polls to completion, up to a Timeout in seconds.
• Get Job Status and Cancel Job.

The connector authenticates with the Cloud API token. Its Parameters and Notification inputs are semicolon-delimited. A typical recipe runs a job synchronously, waits for completion, then routes the result downstream to an approval, a ticket, or a notification.

Launch a job from Windows Task Scheduler#

An OS task can issue a REST run on a schedule the native scheduler does not cover, most simply by having the task run a small PowerShell script that calls the API. If you script it in PowerShell, apply the fix below.

The PowerShell and TI hang fix#

A job launched from a PowerShell script (including a Turbo Integrator PowerShell prolog) delivers its reports correctly, but the script itself never returns, it stalls after a successful run. The reports are never the problem, only the script's completion is. The cause is Windows Invoke-WebRequest trying to parse the server's HTML response.

Add this line near the top of the script:

$PSDefaultParameterValues['Invoke-WebRequest:UseBasicParsing'] = $true

This is now shipped by default in the generated Cloud TI PowerShell prolog, so newer generated scripts are already immune. It remains the fix for hand-rolled or older PowerShell scripts and older self-hosted run scripts. If a script-launched job delivers output but the launching script hangs, this is the setting to add.

Notes and limits#

• Cube Monitoring is deprecated. Migrate job launches from Planning Analytics to the REST-API Turbo Integrator here.
• The Cloud path needs only outbound 443. A Planning Analytics Cloud model reaches your on-prem instance through the Cloud Connector relay with no inbound exposure. See The automation API.
• Cloud calls are subject to short maintenance windows. Build retries into an unattended caller.

Going deeper. For the command surface these integrations call, parameter overrides, and filtering a run to a specific output type and destination, see Run a job by API. For choosing an authentication type when connecting to Planning Analytics, see Connect IBM Planning Analytics.