Tricentis Tosca

Choose the Tosca system in Connections, then select the deployment variant and credentials appropriate to it:

Tosca Cloud uses OAuth2 client credentials.
Tosca On-Prem uses the configured server and Basic authentication, with a workspace selected for relevant operations.

Test a read before authoring or triggering changes. DataMaker permissions and the Tosca account's permissions both apply.

Read test designs

Ask the agent to list test cases and inspect one test-case design. Use its configuration parameters, steps and value ranges to identify the data the test needs. Confirm the exact test case and environment before creating a template or scenario from it.

Cloud tools can inspect playlists, playlist runs, test-case runs and run steps. These provide test execution evidence; reading them does not start a new execution.

Build native Cloud tests

DataMaker can search and read native Cloud modules, inspect standard-module packages, and create new custom modules. Name the target workspace explicitly, for example: “In SAP Demo, find the browser login module and show its controls.”

For a migration, inspect compatible modules first. DataMaker can author new modules from known control identification properties and use the returned module and attribute references to create native test cases. Keep browser and desktop SAP controls separate, and preserve frame context, input values, selected dropdown entries, assertions and waits.

Module creation adds a new artifact. If Tosca times out after a creation request, check the named workspace for the module before retrying. A created module or test case is not execution evidence: run and inspect the native test before treating the migration as verified.

Change an existing module

Changing a native Cloud module in place, for example to point an API module at a new endpoint, is an API operation: PATCH /integrations/{id}/tosca/modules/{moduleId}. The body is an object, not a bare patch: {"space": "<workspace>", "operations": [ ... ]}, where operations is a JSON Patch (RFC 6902) document of one to a hundred operations and space names the workspace. The agent cannot do it. Its module tools list modules, inspect standard-module packages, read one module and create a new one, so asking the agent in chat to change a module will not work: call the route, or make the edit in Tosca.

DataMaker reads the module, applies the patch itself and writes the whole module back, because Tosca's own PATCH answers 204 and silently drops nested and array changes such as a base URL. The change keeps the module's identity and its attributes' identities, so the test steps that use the module keep working. An operation on an id is refused, and so is a patch that would replace an attribute or parameter rather than change or remove it, since the steps bound to the old one would break: change the attribute's fields instead, or remove it on purpose. To make sure you change what you expect, add a test operation: if the module holds something else the call answers 409 and nothing is written. A patch that changes nothing is not written at all. Tosca turns off rescanning for a module written this way, so a later rescan does not undo the change.

Changing a module is a write, so it needs the integration:write permission and a connection saved with Read & write permissions in Connections. On a read-only connection it is refused with 403. A module that is not in the named workspace answers 404, and a patch Tosca itself rejects answers 400 and changes nothing. On success the module is read back and returned, so the response shows what Tosca stored.

A 502 is the one answer you cannot read as "nothing happened". Tosca may have taken the whole module before the connection failed, and it may also accept the write and then fail the read back, which is reported as applied. So read the module in that workspace before retrying rather than repeating the call blind: sending the same patch again is harmless for a plain value change, but a patch that adds to an array would add a second time.

On-premises authoring

The on-premises tool surface can list workspaces, query objects with TQL, create supported objects, add execution entries, inspect objects and check in changes. Read the announced tool schema and verify the parent object before making a change.

Checking in or adding an execution entry is a separate action from reading a design. Review the intended workspace and scope rather than inferring authorization from a successful connection test.

Pull input set rows into a test

A Tosca test case can read the rows the business filled in, so the test runs against data someone signed off rather than data it invented. In this setup Tosca asks DataMaker for the rows at run time. To copy the rows into Tosca's own test data instead, see Push rows into Tosca test data.

To make one, press New input set under Inputs and choose how to start: a Blank sheet with columns you name, From a template in the project, whose fields become the columns, or Upload Excel or CSV, which previews how each column of the file maps before anything is saved. Each opens an editable draft. Add test cases with the sheet's Test cases button.

To find one again, search Inputs by input set or template name, narrow it to one Template, and Sort by when each was updated or created, by name, or by row count. Switch between cards and a list with the view buttons at the end of the toolbar, as on Templates. Select all and the bulk delete act only on the input sets shown.

To seed a sheet, press Generate data, say how many rows to add and, if you like, what the data should look like. The agent fills every column except Derived and Mapped ones, which DataMaker still computes, and adds the rows below the ones already there, assigning each to one of the sheet's test cases when it has them. The rows appear when the agent finishes, are checked against the target system like any row you type, and nothing is frozen until you press Create dataset. A sheet holds at most 500 rows.

Open the input set under Inputs, link its test cases to Tosca, and press Create dataset (Save dataset for a business user) to freeze a version. A cell left blank in a field marked Supplied by the business stays blank in the version: DataMaker generates only the template's other fields. In a template with no marked fields, where every field is a column, a blank cell is still generated, so Derived and Mapped columns compute as before. The Tosca panel then offers Set up in Tosca. Choose Read rows in a test step to build an OpenAPI specification for one test case: the request that fetches its rows, with the endpoint and the test case already filled in. Pick the test case, pin a version or follow the latest, then either download the specification or copy its URL. The same button also sets up a pull into Tosca test data, described under Let a Tosca test case pull the data set.

In Tosca Cloud, create an API message and choose Use an API specification. Paste the URL, or upload the downloaded file. Tosca creates the request and response modules from it. The URL needs no API key, so Tosca can fetch it, and it stops working after seven days. It describes the request only: it never carries row values or a key.

The specification leaves the API key out. After importing, set the X-API-Key header on the request module to a read-only DataMaker API key scoped to the project, and treat the key as exposed once it is in Tosca: Tosca stores a request header in clear text and shows it to anyone who can read the space. Rotate it on a schedule.

Then buffer the columns the test needs from the response. Rows are under rows, counted from zero, so rows[0].Customer is the first row's Customer value.

See whether Tosca has pulled the rows

The same Tosca panel answers whether anything has actually read the rows. Before the first read it says the input set has not been pulled yet. After one it shows when the read happened, which version it took, how many rows came back and whether it succeeded, with a line per test case so you can see which of them a run has reached.

Every read of an existing version's rows is recorded, so a pull stays attributable afterwards even though the key that made it is long lived. A read of a version that does not exist is refused with 404 before anything is recorded, so it does not appear in the panel. Who made the read is shown only to people who may read the audit trail; everyone else sees whether it was a person or an API key. A read that returned no rows is shown as a failure, which is usually a test case that does not match or a version whose dataset was deleted. The specification asks for rows by the test case's Tosca id (testCase=<id>), so a test case linked to a different Tosca test case after the version was frozen returns none. A call written by hand may pass the test case's name instead, but either value is matched exactly, so a difference in case returns no rows.

Push rows into Tosca test data

Tosca Cloud keeps its own test data under Prepare > Test data, and a test step reads it with an expression such as {TDM[Orders][Material]}. DataMaker can create or refresh one of those data sets from a locked set, an input set version, a dataset, or rows a scenario produces. Test cases then read the data the way they read any other Tosca test data, with no API key stored in Tosca.

Ask for it by name and source, for example: "Push the Q3 regression set to Tosca as Orders." A scenario does the same through the Python SDK (datamaker-py; the scenario runner image installs the version pinned in its lockfile, 0.12.0, which also offers append):

from datamaker import DataMaker

dm = DataMaker()
result = dm.push_tosca_dataset(
    "<Tosca connection id>",
    "Orders",
    input_set_id="<input set id>",
    on_existing="overwrite",
)
print(result.outcome, result.rows_count, result.example)

Any other API client calls POST /integrations/{id}/tosca/datasets:

{
  "name": "Orders",
  "source": {
    "kind": "inputSet",
    "inputSetId": "<input set id>",
    "version": "latest"
  },
  "onExisting": "overwrite"
}

Sources. set needs a locked set, so the rows cannot change under Tosca. Pass allowUnlocked: true to push one that is not locked. inputSet takes a version number or latest. dataset takes a ready dataset. rows takes the rows themselves. DataMaker reads a set, input set or dataset with your own access to it.
No square brackets in names. A test step reads the data with {TDM[...]}, which uses [ and ] as delimiters. A data set name containing them is refused. A test case or other subset value containing them is listed under subsets.unaddressable and gets no subset, and such a column is listed under unaddressableColumns. Its data is still pushed, but a test step cannot read it by name until it is renamed.
Values keep their type. Text such as a material number 0012 stays text. Tosca makes date-like text a date column.
One subset per test case. An input set gets a subset for each of its test cases, so a test case reads only its own rows: {TDM[Orders][<test case name>][Material]}. Set subsetsBy to another column, or to false to turn this off. An input set made without test cases is pushed as its own columns only, with no subsets.
Running it again. By default a push refuses a name that already exists. overwrite replaces the rows and keeps the data set's subsets; new columns are added for you. A push that would drop a column is refused unless you also pass onSchemaChange: "recreate", which deletes and recreates the data set: test steps keep working because they refer to it by name, but its subsets are rebuilt and anything else attached to it is lost. new lets Tosca create a copy beside the existing data set.
Very large spaces. DataMaker finds an existing data set by reading the space's list, up to a limit, and confirms a name it did not find with Tosca's own check at upload. In the rare case that the list ends early and Tosca does not answer that check, the push stops with listingIncomplete rather than risk a second data set of the same name. Push with new if a copy is acceptable.
Retrying a recreate. A recreate can take a few minutes, so a slow connection may time out while it carries on in Tosca. If you retry, DataMaker checks with Tosca before creating anything: when the first attempt has already recreated the data set, the retry is refused with recreatedConcurrently (or createdConcurrently) instead of making a second one. Retries are best left until the first attempt has had a few minutes to finish, then push again with overwrite if needed.
Used rows start over. Tosca marks a row used when a test consumes it. Replacing the rows clears that, which is usually what you want for regression data.

Add rows for tests that consume them

When tests use up the rows they read, a scenario that feeds fresh rows on every run should push with onExisting: "append" (on_existing="append" in a scenario). Each run adds its rows to the same data set. Use overwrite instead only for data every run reads again, and never new for a scenario that runs repeatedly: it leaves another data set behind on every run.

The first push creates the data set.
Later pushes add their rows and leave every row already there as it is, including the rows Tosca has marked as used. The data set keeps its id and subsets.
A column the new rows bring is added to the data set. A column the data set has but the new rows lack is left empty on them.
With subsets, a value seen for the first time gets its own subset; existing subsets pick up the new rows on their own.
One append adds up to 1,000 rows, since Tosca takes appended rows one at a time.
A column keeps the type Tosca gave it when the data set was created. An append writes "44" into a number column as 44, "true" into a true/false column as true, and an empty cell in either as no value. A date column takes ISO dates such as 1990-08-17 or 1990-08-17T10:30:00. A value the column cannot hold, such as "n/a" in a number column or 16.07.1989 in a date column, refuses the whole append with typeMismatch, naming the column and the rows, before anything is added. Push those rows to a new data set name, or send values of the column's type.
An append is not undone or deduplicated: pushing the same rows twice adds them twice. If an append stops part way, the error says how many rows were added (appendedRows) and which of the pushed rows were not (notAppendedRows, by position), so push only those.
A data set locked in Tosca is refused with locked, as for overwrite.

result = dm.push_tosca_dataset(
    "<Tosca connection id>",
    "Orders",
    rows=new_orders,
    on_existing="append",
)
print(result.outcome, result.appended_rows, result.rows_count)

Keep an input set in step with Tosca

For an input set the business keeps editing, push with onExisting: "sync", or use Push version in the Tosca test data panel under the input set's versions. To push an earlier version, press Push to Tosca beside that version's View rows. The first push creates the data set. Each later push of the latest version changes only what changed, and never a row a test has already used:

A row whose values are unchanged is left as it is.
A changed row is updated in place while no test has used it. Once a test has used it, the change is added as a new row and the used row is kept as the record of what that run read.
A new row is added.
A row removed from the input set is deleted in Tosca unless a test used it.
A row added in Tosca by hand is never touched.

DataMaker matches the rows through a DataMakerRow column, which holds each row's id in the input set and a fingerprint of the values the business typed in. Values DataMaker generates are not part of that fingerprint, so a new version that only regenerates them changes nothing in Tosca. Versions made before blank cells were kept blank hold generated values in those cells. Create a new version and push it: each row that had a blank cell is rewritten once to clear them, and a row a test has already used gets a clean copy beside it. Pushing a version made before then does not clear them, since it still holds the generated values. Test steps read the other columns as usual and can ignore this one. A column added to the sheet is added in Tosca and filled on every row a test has not used. The input set owns the data set's columns: a column removed from the sheet stays in the data set but is emptied on the rows the sync writes, and so is a column someone added in Tosca by hand, since DataMaker cannot tell the two apart. Keep extra data in a separate data set. onSchemaChange does not apply to a sync. A sync refuses a data set of that name that it did not create, since it could not tell which rows are whose: push to a new name instead. Each row also carries a DataMakerInputSet column naming the input set it came from, and a sync refuses a data set synced from a different input set, which it would otherwise empty of that input set's rows: push to a new name instead. A data set synced before DataMaker recorded the input set has no owner on its rows, so only someone with integration:write can sync into it. Their next push records the input set on every row a test has not used, and from then on business users can sync it again. The panel remembers the connection and name you pushed to, so the next push updates the same data set.

Pushing writes into Tosca, so it needs a connection saved with Read & write permissions. Syncing an input set version needs the integration:run permission, which business users hold, so the people filling in the sheet can push it themselves. Any other source, or any other onExisting mode, needs integration:write. Pushing an older version brings the data set back to that version, so the dialog warns before it does. Every push is recorded in the audit trail with its source and row count, never the values. Pushes are rate limited, and one push may write up to 100,000 rows.

Bind a test case to the data set

After a push, a test step still has to say which column it reads, and typing {TDM[<data set>][<test case>][<column>]} into every value of a test case is slow and easy to get wrong. DataMaker can write those expressions for you.

Push from the Tosca test data panel, then, under Bind a test case, pick one of the input set's test cases that is linked to Tosca and press Preview bindings. DataMaker reads the test case from Tosca and matches each step value to a column by its attribute name: exactly first, then ignoring case, then ignoring spaces and punctuation, and only when exactly one column fits. The preview lists every value it would write and what the value holds now. Nothing changes in Tosca until you press Write bindings.

Empty values are bound.
Values that already read a {TDM[...]} expression, for example one pointing at an older data set, are rebound to this one. The preview shows the expression they held.
Values typed by hand are kept, since they may be deliberate. Tick Replace on one to bind it too.
Values whose name differs from the column, such as Partner name reading Name, are listed under the values no column matched. Choose the column there, or choose Don't bind. The panel remembers your choice for the input set.
Buffer and output values are never touched: their value is not test data.

The step reads the subset for its own test case, so it gets only that test case's rows. Only the values in the preview change: steps, modules and everything else in the test case stay as they are. If someone saves the test case in Tosca between your preview and the write, DataMaker writes nothing and asks you to preview again.

Binding writes into a Tosca test case, so it needs a Read & write connection and the integration:write permission. Every write is recorded in the audit trail with the values and columns it bound, never their data. An API caller does the same with POST /integrations/{id}/tosca/testcases/{testCaseId}/bind: send datasetId, and subset to read one, with dryRun: true to get the plan, then send the plan's version as expectedVersion to write it.

Let a Tosca test case pull the data set

The push can also be started from Tosca. A test case runs one API message that asks DataMaker to create or refresh the data set, and the test steps after it read the rows with {TDM[...]}. Tosca then always tests against the newest data without anyone pushing it first.

To get the message, press Set up in Tosca in the input set's Tosca panel and choose Pull into Tosca test data. Pick the connection and data set name (it starts from the ones you last pushed to), follow the latest version or pin one, and download the specification. It is an OpenAPI file for the one request the message makes. In Tosca Cloud, create an API message, choose Use an API specification and upload the file. Then set the X-API-Key header on the request module (see below) and add a check that the response's name is the data set name.

For a set or a dataset there is no button yet. The API returns the same setup as a DataMaker manifest, which describes the message field by field for building it by hand or with the Tosca MCP server:

GET /integrations/{id}/tosca/dataset-pull-setup?name=Orders&inputSetId=<input set id>&version=latest

Pass exactly one of inputSetId, setId or datasetId. onExisting defaults to sync for an input set and overwrite for a set or dataset, so running the test again refreshes the same data set. new is not offered: Tosca gives the copy a different name, so every later run would fail its check and leave another copy behind. DataMaker checks the source when it builds the setup, the same way a push does, so a setup for an unlocked set, a dataset that is not ready or a version that does not exist is refused straight away instead of failing on every run.

The message is a POST to /integrations/{id}/tosca/datasets, the same call a push makes, so everything above applies to it: the name and column rules, subsets, sync, rate limits and the audit trail. Check that the response names the data set: a refused pull fails that check, so the test case stops before reading data that was not refreshed. The response also carries the data set id, row count, outcome and an example {TDM[...]} expression (datasetId, rowsCount, outcome, example) to buffer if a later step needs them. The manifest lists that check and those buffers (DM_DataSetId, DM_DataSetRows, DM_DataSetOutcome, DM_DataSetExample).

The key needs write access. DataMaker writes to Tosca with the connection's own credentials. The DataMaker API key in the message only lets Tosca ask, but because the pull writes through the connection it must be a read-write key that can read the source and use the connection: a key scoped to their project, or a team key if they are in different projects. A read-only key is refused. The specification declares the header with no value and the manifest holds a placeholder, so neither carries a key: type it into the request module in Tosca, and treat it as exposed once it is there, since Tosca stores request headers in clear text.
One pull per playlist. Pulls share the push rate limit of the key that makes them. Run the message once, in a setup test case at the start of the playlist, rather than in every test case that reads the data.
Spell the name as Tosca does. Tosca matches an existing data set regardless of case and answers with its own spelling, which the message checks. Use the name exactly as it appears under Prepare > Test data.
Read-only connections. A connection saved without Read & write permissions cannot be used for a pull, and DataMaker refuses to build the setup for it.
The audit trail says who asked. A pull is recorded like any push, under the API key that made it, and is marked as started by a Tosca API message.
What Tosca imports. Tosca Cloud imports the downloaded OpenAPI specification. It cannot import the manifest from dataset-pull-setup, and DataMaker does not apply a manifest to Tosca for you: build the message from it by hand or with the Tosca MCP server.

Tricentis does not publish an API for Tosca Cloud test data. DataMaker uses the one the Tosca portal itself uses, so a change on Tricentis' side can break pushes until DataMaker is updated. Pulling input set rows does not depend on it.

The Hub can provide starter assets where the catalogue is enabled. Imported scenarios remain drafts and skills disabled until reviewed. Configure the actual Tosca connection and verify the imported workflow against a small test case.

On this page