Enable "Brick-Level Update" in a Script

Cloudbridge supports both a full refresh and a partial refresh of data gathered from a data source (a cloud service or an on premises server).

Performing a full refresh has been available from the beginning, and is very straightforward: you simply re-run your script node to retrieve the latest data that is available. 

Partial refresh is a new addition to Cloudbridge, and it allows you to refresh one or more records in a data set by either:

• Selecting the rows you want to refresh, right-clicking on those rows, and selecting “Refresh Rows”. This is known as a manual refresh.

• Using Start-CbJob in an action script to launch the script to which the action was bound as a refresh invocation. This is an automated refresh.

Both of these refresh methods have the same set of requirements that must be met before they can be supported. These requirements are as follows:

1. The node script can only produce a single default dataset (view).
   As many derived views as you like may be included on the node, but only one default view is allowed. If you want refresh support on a node with a script that produces multiple default views, you will have to first break that script node apart into multiple script nodes that return single datasets.

2. The node script must contain one parameter of type CBDataRefresh.
   CBDataRefresh is a Cloudbridge-specific type that identifies a parameter that will receive a collection of unique key assignments that will be used by the script to refresh specific data records. Inside of a script, a CBDataRefresh parameter resolves as an array of PSObjects. CBDataRefresh parameters do not appear in UI when you run an action – they are a special case, and only used to refresh data.

3. Change monitoring must be enabled in the default view.
   Change monitoring configuration identifies the properties that are required to refresh rows in the dataset.

4. At least one property must be identified as a unique key in the change monitoring configuration.
   These are the properties that will be used when you invoke a refresh of a script.

5. All unique keys must be assigned in each dictionary passed into the -ArgumentList parameter.
   Unique keys are like mandatory parameters when it comes to refresh. If you leave any out, the refresh will fail.

The easiest way to learn how this works is by an example. Imagine you have a script to gather users from Microsoft 365. The script itself may be very simple, and look something like this: 

If you want to configure this script to support manual refresh (right-clicking one or more rows and refreshing those rows), you would modify it as follows:

1. Run the script to get the data.

2. Enable Change Monitoring, and set the ObjectId as the unique key.

3. Add a parameter of type CBDataRefresh to the script. Typically this would be called $RefreshRows.

4. Update the script to use $RefreshRows to identify the specific rows to refresh, and retrieve only those rows from the data source.

Here is what your script might look like after you have made those changes:

The key differences here are the new parameter and the logic internally to retrieve some records vs all records when that parameter is part of the invocation. Note that if you run this script from the script node, you’ll still get a full run, with no prompting for parameters, but now, with Change Monitoring enabled and the script updated accordingly, you can right-click on one or more selected rows and refresh those rows.

With this, you may configure a task script to automatically refresh rows in your dataset. To allow this, you must allow “execution from Cloudbridge script”

Open

Then you can use the Remote Command Builder to generate the syntax required to invoke the script for data refresh using Start-CbJob.

Open

To learn more about Start-CbJob, see https://ucclearly.atlassian.net/wiki/spaces/CK/pages/324567140/Start-CbJob%2BRun%2BOne%2BScript%2BFrom%2BAnother .