v5.3.0

Bedrock 5.3 – Release Notes

New Processes Added

This release introduces two powerful new Bedrock processes:

• }bedrock.cube.view.create.from_json
• }bedrock.process.multi-thread

These processes expand view generation flexibility and enable controlled multi‑threaded execution of TurboIntegrator workloads.

✅ New Process: }bedrock.cube.view.create.from_json

Overview

This process creates a cube view based on a JSON‑defined specification. The resulting view can be used for exporting data, copying data, or zeroing out values.

It provides a structured and highly flexible alternative to traditional TI view‑building logic by allowing dimension selections to be defined using JSON Objects or JSON Arrays.

Key Capabilities

• Define cube views using a JSON Object or JSON Array
• Support for elements, subsets, MDX expressions, or combinations of these
• Explicit inclusion and exclusion logic
• Automatic handling of unspecified dimensions using configurable default MDX

Documentation:

Description:

This process creates a view that can be used for exporting, copying or zeroing out numbers.

How to Use:

pFilter defines which elements should be in the view, for each dimension. It must be either a JSON Array or Object.
If pFilter is a JSON Object, then the keys are the dimension name, and the values which elements you want included in the view.
If pFilter is a JSON Array, then the items in the array are which elements you want included in the view, and the index of the item corresponds to the index of the dimension you want that item to apply to.

The items that you specify must be one of the following: an element, a subset name, an MDX, or a JSON array of any number of the previous three.
When determining which of these an item is, the order of priority is: Element ➡️ Subset ➡️ MDX. So, if a subset has the same name as an element, it will be interpreted as an element.

Note

JSON Arrays use 0-based indexing, but Cubes use 1-based indexing. To rectify this difference, relative positioning is used. In other words, the first item in the array will be applied to the first dimension in the cube, the second item to the second dimension, etc.

To specify a subset that has the same name as an element you can use the MDX function TM1SubsetToSet.

Given the cube "plan_BudgetPlan" which has dimensions: plan_version, plan_business_unit, plan_department, plan_chart_of_accounts, plan_exchange_rates, plan_source, plan_time, here is a JSON Object to pass to pFilter:

{
  "plan_version": "{[plan_version].[plan_version].[FY 2003 Budget]}",
  "plan_time": "2026 Forecast Periods",
  "plan_department": ["405", "{TM1FILTERBYPATTERN({TM1FILTERBYLEVEL({TM1SUBSETALL([plan_department].[plan_department])}, 0)},'11*')}"]
}

In this example, "2026 Forecast Periods" is the name of a subset in the "plan_time" dimension, so the view will have all the elements within that subset.
For "plan_department", the view will have element "405", as well as all elements specified by the MDX (All N-Level elements that match the pattern '11*').

Here is an example which will create the same view using a JSON Array instead of Object:

[
  "{[plan_version].[plan_version].[FY 2003 Budget]}",
  null,
  ["405", "{TM1FILTERBYPATTERN({TM1FILTERBYLEVEL({TM1SUBSETALL([plan_department].[plan_department])}, 0)},'11*')}"],
  null,
  null,
  null,
  "2026 Forecast Periods"
]

The important difference between the two is that in a JSON Array, you need to use null as a spacer so that your specification lines up with it's intended dimension.
In this example, there is a null as the second element in the array, so that the "plan_department" specification will be the third element in the array, lining it up with the cube's dimension order.

• pFilter - See above.
• pExcept - Interpreted in the same way as pFilter, but any element specified by this parameter will be excluded from the view.
• pDefaultMDX - MDX string to use when a dimension is not specified in pFilter. Will replace the pDimensionSubstitution value with the dimension's name. The default value will get all N-Level elements of the dimension through MDX ({TM1FILTERBYLEVEL({TM1SUBSETALL([???].[???])}, 0)}).
• pDimensionSubstitution - The substring in pDefaultMDX which will be replaced with the dimension's name. The default value is ???.

✅ New Process: }bedrock.process.multi-thread

Overview

This process manages the multi‑threaded execution of TI processes using a JSON‑defined task list. It enables controlled parallelism, dependency management, and flexible success handling.

Key Capabilities

• Execute multiple TI processes concurrently
• Define explicit task dependencies
• Control execution flow based on predecessor success or failure
• Limit concurrency with a maximum thread count
• Customize acceptable return codes for successful execution

Description:

This process manages the multi-threaded execution of tasks

How to Use:

• pTaskList defines the tasks that the process will execute.
  The parameter must be a JSON Array of JSON Objects, e.g. [{...}, {...}, ..., {...}].
  The JSON Objects within pTaskList can have the following key-values:

{
  "process": <string, REQUIRED>,
  "parameters": <JSON Object, OPTIONAL>,
  "id": <string, OPTIONAL>,
  "predecessors": <JSON Array, OPTIONAL>,
  "require_predecessor_success": <boolean, OPTIONAL>
}

How to use each key-value pair:

• process: REQUIRED: the name of the process.
• parameters: OPTIONAL: A JSON Object specifying the parameter values of the process. (It is not required to list all the parameters of the process).
• id: OPTIONAL: an ID string that other tasks can use to reference this task.
• predecessors: OPTIONAL: A JSON Array of task ID strings.
• require_predecessor_success: OPTIONAL: JSON boolean, if true the task will not be executed if any of it's predecessors failed (default = false).

Here is an example pTaskList:

[
  {
    "process": "}bedrock.server.wait"
  },
  {
    "process": "}bedrock.server.wait",
    "parameters": {
      "pWaitSec": 10,
      "pLogOutput": 1
    },
    "id": "second_task"
  },
  {
    "process": "}bedrock.server.wait",
    "parameters": {
      "pWaitSec": 15
    },
    "predecessors": ["second_task"],
    "require_predecessor_success": true
  }
]

This task list has three tasks, and each task is the process "}bedrock.server.wait".
If this task list is executed with pMaxThreads = 1, given the predecessors specified, the order of execution will be: the first or second task will execute first, but the third will not execute until the second task finishes executing.

• pMaxThreads defines the maximum number of threads allowed to run concurrently.
• pRefreshRate defines the number of milliseconds to wait in between checking the statuses of the created threads.
• pSuccessReturnCodes is a JSON array with either the numeric value of a return code (e.g. 0, 5, 7, 8) or the strings of the return code function (e.g. "ProcessExitNormal", "ProcessExitByBreak", "ProcessExitMinorError").
  You can also shorten the strings by removing the "ProcessExit" prefix (e.g. "Normal", ByBreak", "MinorError").

Important

The executor ignores the order of the tasks in the list. So if you want a specific task to execute before another, only way to gaurantee that behavior is to use "predecessors".

Summary

This Bedrock 5 update adds:

• A JSON‑driven, highly flexible cube view creation process
• A robust multi‑threaded execution framework with explicit dependency control

Together, these processes improve scalability, readability, and orchestration of complex TurboIntegrator workloads while aligning with Bedrock 5’s standardized, modern architecture.

Full Changelog: v5.2.0...v5.3.0

Release v5.2.0

Bedrock 5 – Release Notes for v5.2.0

Overview

This update focuses on standardizing the bedrock parameters, as well as introducing a new way to pass parameters to bedrock processes: pJson.

---

Key Changes

1. Parameter Descriptions and Values

• Parameter Descriptions: Standardised description layout, and descriptions for parameters that are used across multiple processes for consistency.
• Parameter Values: Where applicable, put the default value in the Value box for greater clarity

2. pLogOutput, pStrictErrorHandling, and pJson

• Parameters for All Processes: pLogOutput and pStrictErrorHandling are parameters in all processes.
• pJson: Process parameter values can now be passed as a JSON object, with the parameter name as the keys, and the values as the parameter value.

---

Full Changelog: v5.1.0...v5.2.0

v5.1.0

This is the official first release of Bedrock 5 for IBM Planning Analytics TM1 Database 12.4+. If you are using IBM Planning Analytics TM1 Database 12.4+ you must use Bedrock 5.

What's Changed

• created initial set of github templates by @nicolasbisurgi in #1
• Refactored documentation by @nicolasbisurgi in #5
• changed github repo url and bedrock version on all TI processes by @nicolasbisurgi in #6

New Contributors

• @nicolasbisurgi made their first contribution in #1

Full Changelog: v5.0.0...v5.1.0

v5.0.0

This is the pre-release version of Bedrock 5 for IBM Planning Analytics TM1 Database 12.4+. If you are using IBM Planning Analytics TM1 Database 12.4+ you must use Bedrock 5.