Executes the provided SAS code in the Viya environment and returns information about the completed Job. This will create a job definition for the SAS code, execute it, and then retrieve the results.

IMPORTANT — state persists between calls: the code runs in a reusable compute session that is kept warm and shared across calls (per user), so SAS state — WORK tables, macro variables, and assigned librefs — survives between successive execute_sas_code calls. A re-run can therefore see leftovers from earlier calls (e.g. a check that counts results twice). Pass fresh_session=True (or call reset_compute_session) when the code must start from a clean slate.

Tip: to reach CAS data, prefer libname casuser cas; (or a targeted caslib statement) over caslib _all_ assign; — on tenants with many caslibs the latter floods the log with assignment NOTEs.

List available compute contexts on the Viya environment.

Reset (delete) the cached compute session for a compute context.

The server keeps one reusable SAS compute session per user and compute context so repeat calls skip the slow session spin-up; SAS state (WORK tables, macro variables, assigned librefs) therefore persists across execute_sas_code and list_compute_* calls. Call this to discard that state — the next compute tool call transparently creates a fresh session.

Search the SAS Information Catalog for assets (tables, columns, reports, ...).

The catalog is a metadata index across the whole Viya environment, so this finds assets without needing to know their server/library first. Each hit includes the asset's resource_uri — the URI you can hand to the matching tool (e.g. get_report, get_castable_data) to act on the live asset — and an attributes map with whatever metadata the catalog holds for it (commonly library, rowCount, columnCount, completenessPercent, reviewStatus, informationPrivacy, and analysisTimeStamp).

The query uses the SAS catalog search grammar:

• Free text matches names, with wildcards * (0+ chars) and ? (1 char): cust*.

• Facets constrain fields, e.g. AssetType:Report, Name:sales, Library.name:PUBLIC, Column.informationPrivacy:Sensitive.

• Ranges DateModified:[2024-01-01 TO 2024-12-31] and + to require a term. Combine freely: AssetType:"CAS Table" +Name:cust*. Use catalog_search_helper to discover valid facet names and values.

Discover how to search the catalog: list facets, or values for one facet.

Call with no facet to list the available facets — the fields you can constrain in a catalog_search query. Call with a facet name to get the suggested/valid values for that facet (e.g. the asset types or review statuses that actually exist). Use the results to build precise catalog_search queries.

Resolve the catalog instance for a source-asset URI.

catalog_search finds assets by free text and facets, but the profiling and download tools key off a catalog instance id. When you already hold a resource URI — the resource_uri from a search hit, or a CAS table path — this looks the instance up directly by resourceId (the same filter the profiling workflow uses) and returns its id plus the key profile attributes. Use it to tell at a glance whether the asset has been profiled (analysisTimeStamp) and what semantic metadata it carries (informationPrivacy, nlpTerms, nlpTags, mostImportantFields) before calling catalog_download_table_profile.

List SAS Information Catalog discovery agents.

Agents crawl a data source (server/library) to discover assets and collect their metadata into the catalog. Use catalog_run_agent to start one and catalog_get_agent_history to see what a run produced.

Start a catalog discovery agent run (asynchronous).

Triggers the agent to crawl its data source and populate/refresh catalog metadata. The run is asynchronous — results are applied to the catalog in the background; poll catalog_get_agent_history to track completion. Note: the Catalog API can only start an agent, not stop one already running.

Get the execution history of a catalog agent's runs.

Each record reports a run's status and how much metadata it populated (tables enumerated/added/updated/removed), so you can confirm a run started by catalog_run_agent finished and what it changed.

Submit an ad-hoc analysis (profiling) job for a table in the catalog.

Profiles the table — computing the data dictionary, column statistics, and data-quality metrics that catalog_download_table_profile returns. The job runs asynchronously and may take a while; poll catalog_get_adhoc_analysis with the returned job id until the profile is ready.

The three NLP job parameters are enabled by default — they drive the semantic enrichment that populates an asset's informationPrivacy, nlpTerms, nlpTags, and mostImportantFields (the privacy and keyword signals the catalog is most useful for). Leave them on unless you only need a plain column profile and want the job to finish faster.

Get the status of an ad-hoc analysis job, and whether its profile is ready.

The job reaching a terminal status is not sufficient: the profile attributes are written onto the asset a little later, so a download fired the instant the job completes can come back empty. To close that gap, when the job carries a resource this also resolves the target catalog instance and reports profile_ready (the asset's analysisTimeStamp is populated — the same gate catalog_download_table_profile uses) and information_privacy (non-empty once the NLP semantic enrichment has landed). Poll until profile_ready is true, then download.

Download a catalog table's data dictionary and profile as CSV.

Returns the table's column metadata plus, by default, its profile (column statistics and data-quality metrics). If the table has not been profiled yet, this returns a recommendation to run catalog_run_adhoc_analysis (pre-filled with the table's URI and type) instead of an empty profile.

Identify the table by either instance_id or resource_uri (give one). Passing resource_uri lets you run search → profile → download without ever handling an instance id: the asset is resolved by resourceId the same way catalog_find_instance does. instance_id takes precedence if both are given.

List the SAS libraries (librefs) assigned in a compute context.

Runs in the reusable per-user compute session for the context, so it also sees libraries created by prior execute_sas_code calls.

List the tables in a SAS library within a compute context.

These are SAS/Compute tables (e.g. WORK or an assigned libref), distinct from in-memory CAS tables (see list_castables). Runs in the reusable per-user compute session for the context.

List the columns of a table in a SAS library within a compute context.

Runs in the reusable per-user compute session for the context.

List available CAS servers on the Viya environment.

List CAS libraries (caslibs) available on a CAS server.

List tables in a CAS library.

List source tables that are NOT yet loaded into memory in a CAS library.

These are the candidates for promote_table_to_memory — tables that exist on the caslib's data source but are not in CAS memory yet.

Get metadata for a CAS table (row count, column count, size, etc.).

Get column metadata for a CAS table (names, types, labels, formats).

A missing table returns a structured not_found with the two usual causes (unloaded source table vs session-scoped table) instead of a raw HTTP error.

Fetch rows from a CAS table with column names.

Run a FedSQL SELECT against CAS or compute data and return the rows.

One SQL surface over both storage tiers, so exploring a caslib table and a SAS library table use the same tool and the same dialect. The query runs in the reusable compute session; nothing is persisted — the result is materialised into session scratch, read back, and dropped.

Pick the tier with target — it selects the namespace, and the two cannot be mixed in one statement (a caslib table and a libref table cannot be joined; stage one side first with execute_sas_code):

• target='cas' (default) — qualify as caslib.table (e.g. Public.HMEQ); see list_caslibs / list_castables.

• target='compute' — qualify as libref.table (e.g. WORK.SALES); see list_compute_libraries / list_compute_tables. Concatenated librefs — several directories under one name, which is what SASHELP and MAPS are — are invisible to FedSQL, because its BASE driver maps one schema to one directory. Copy such a table into WORK first (data work.cars; set sashelp.cars; run;) and query WORK.CARS.

Dialect notes (FedSQL, not PROC SQL): joins (inner/left/right/full/ cross), subqueries, UNION, GROUP BY/HAVING/ORDER BY, and scalar functions work. There is no WITH/CTE — use a derived table (select ...) "t" — and no MERGE; express a merge as a join (a full join with COALESCE gives upsert semantics). Double-quote identifiers that are reserved words or contain spaces; SAS name literals ('x'n) are not FedSQL.

Row capping is done by this tool, not by your SQL: any LIMIT you write is ignored in favour of limit (a malformed LIMIT is silently discarded by CAS and would return the whole table). Add ORDER BY for stable paging.

Upload a data file into a CAS table — read by the server, not the model.

Provide the data by reference through exactly one of:

• file_path — the server reads the file off its own disk (in stdio mode that's your machine). Disable with ALLOW_LOCAL_FILE_UPLOAD=false.

• url — the server fetches it over HTTP.

Either way the bytes are read server-side and never pass through the calling model's context window. To create a small table you are building inline (no file or URL), use the upload_inline_data tool instead.

The casManagement uploadTable endpoint only accepts an uploaded file (multipart form-data) and has no URL parameter, so url is fetched and sent on as the multipart file part.

Formats. Per the uploadTable API: csv, xls, xlsx (single sheet), sas7bdat, sashdat; tsv is csv with a tab delimiter. parquet is not accepted and is rejected up front with guidance (load via a path-based caslib + promote_table_to_memory, or convert to csv/sas7bdat). The format is auto-detected from the file_path/url extension; pass data_format to override (needed for URLs with no clean suffix).

Create a small CAS table from inline delimited text passed as a string.

Use this only for tiny, hand-built tables — a lookup/mapping table the model constructs on the fly, or a quick test table — because the whole payload travels through the model's context as a tool argument. For anything larger, or any file you already have, use upload_data (file_path/url), which reads the bytes server-side instead.

Text formats only: csv (default) or tsv (tab-separated). For binary formats (Excel, sas7bdat, sashdat) use upload_data.

Load a source table into CAS memory at global scope (visible to all sessions).

Loads the table from its caslib data source and promotes it to global scope via the casManagement updateTableState API. Idempotent: if the table is already loaded in global scope it is left untouched. Use list_source_tables to discover unloaded tables that can be promoted.

List files in the Viya Files Service.

Upload a file to the Viya Files Service, optionally into a Content folder.

Provide the file content through exactly one of:

• content — inline text (the original behaviour; text files only).

• file_path — a path the server reads directly from its own disk (in stdio mode that's your machine). Handles binary files (xlsx, zip, images) untouched. Disable with ALLOW_LOCAL_FILE_UPLOAD=false.

• url — an HTTP(S) URL the server fetches the file from. Also binary-safe.

parent_folder_uri files the upload into a Content folder (e.g. /folders/folders/{folderId}) — the location %include/filesrvc ingestion and other folder-scoped consumers need. Without it the file lands unfiled under the caller's user context.

Download file content from the Viya Files Service.

List Visual Analytics reports.

Get a Visual Analytics report's metadata and definition.

Export a Visual Analytics report (or specific report objects) in any format the VA service exposes, via its synchronous export endpoints.

Formats (export_format):

• package — full report bundle as a .zip (source files, query results, and rendered content); whole report or selected objects.

• pdf — rendered PDF; whole report or selected objects. Pass rendering overrides (e.g. orientation, paperSize, margin, includeCoverPage) via options.

• png / svg — image of the report or a single object; image_size is required, e.g. "1200px,800px".

• csv / tsv / xlsx — the data behind a single report object; exactly one object label is required.

• summary — the report's text summary.

Discover what a Visual Analytics report can contain — operations and objects.

Call this to learn how to build a report before calling apply_report_operations. It reads a bundled catalog (no network), so it is the cheap way to look up an object's data roles instead of guessing.

Create a Visual Analytics report and return its id for further edits.

Creates an empty report shell, or — if you pass operations — builds the whole report in one atomic call (bind data, add pages, add objects). Building at creation avoids leaving an empty report behind if a later edit fails. Returns {"status": "created", "id": ..., "name": ...} plus a created summary whose object names/labels are what follow-up placement and exports target; feed the id to apply_report_operations to keep editing. Note: VA prepends an empty default "Page 1" before any pages your operations add, so verify page-by-page with export_report (see the result's verify_hint) rather than a whole-report export.

Apply an ordered batch of operations to a report — the authoring workhorse.

This is how you add pages, add objects (any of the ~60 VA visual, control, and content types), set parameters, and swap data sources. operations is the native SAS Visual Analytics operations array; the whole batch is applied atomically (all succeed or nothing changes).

Operation keys (one per array element): addData, addPage, addObject, updateObject, setParameterValue, updateData, changeData, applyDataView. Call describe_report_objects for each operation's shape (operation="addData" covers formats, aggregations, and geography via dataItems) and each object's data roles, and get_castable_columns to map columns onto those roles.

Layout & titles (see describe_report_objects → placement / layout_recipes for details):

• Page title — give addPage a title (e.g. {"addPage": {"pageName": "Overview", "title": "Sales Overview"}}); it becomes a text band at the top of that page's body. Page/report headers accept ONLY control objects — never text or visuals.

• Chart titles — pass {"options": {"object": {"title": "..."}}} inside the object spec at add time (all types except standardContainer, which takes no options at add time).

• One-batch multi-page — create pages inline with placement {"report": {"context": "new_page", "pageName": "Trends", "pagePosition": 1}} (numeric position) and target that pageName from later operations in the same batch.

• Grids/columns — relativeToObject with left/right/top/bottom (geometric) or before/after (flow order) against an EXISTING object's name; same-batch forward references fail, so chain across calls using the names each result returns. Objects are auto-named and auto-sized; placement and dataRoles are write-once (updateObject changes options only).

• Read structure back anytime with get_report_outline; verify visually with export_report page-by-page (see verify_hint in the result).

The tool validates every operation against the object catalog before any HTTP call (unknown/typo'd object type, non-addable object, bad data-role names or arity, disallowed object/placement keys) and reports ALL invalid operations at once. It also handles the ETag optimistic-concurrency handshake for you, retrying once transparently on a concurrent edit.

Read a report's structure: pages → objects with the handles other tools need.

Reduces the stored report definition to a compact outline — per page its internal name and label, per object its name (ve*), label, type, and any text content. Use it to edit an existing report, to recover object names after an apply, or to check what a batch actually produced:

• object name → the target for relativeToObject/container placement and updateObject;

• object label → what export_report report_objects takes;

• page label → the page placement target.

Returns {"status": "ok", "pages": [...], "hint": ...} (or not_found / outline_failed).

Copy a Visual Analytics report to a new report, returning the copy's id.

Useful for tailoring a report to a new audience or for the copy-and-replace pattern — copy, then apply_report_operations with a changeData op to point the copy at a different table. Returns {"status": "copied", "id": ..., "name": ..., "source_report_id": ...}.

Delete a Visual Analytics report and its content.

There is no per-object undo in the report API, so deleting and rebuilding (or copying first) is how you discard an unwanted report. Returns {"status": "deleted", "report_id": ...} (or not_found / delete_failed).

Submit a SAS job for asynchronous execution via the Job Execution service.

Check the status of a submitted job.

List recent jobs from the Job Execution service.

Cancel a running job.

Retrieve the log of a completed job.

List AutoML pipeline automation projects.

Create a new AutoML pipeline automation project from a CAS table.

The training table must already be loaded into CAS memory at global scope. This tool verifies that first and returns an actionable error otherwise (use promote_table_to_memory to load + promote a source table, and list_source_tables to find one). The data-table URI is built from server_id/caslib_name/table_name.

Register the champion model from an AutoML pipeline automation project to the Model Repository.

Publish the champion model from an AutoML pipeline automation project to the Model Repository.

Run an AutoML pipeline automation project.

List models in the Model Repository.

List available publishing destinations.

List published scoring models and decisions (MAS modules).

Fetch a MAS module step's input/output variable signature.

Call before score_data to know the exact variable names, types, and order to pass as inputs, and what outputs to expect.

Score data against a published model or decision (MAS module).

Create a new SAS Business Rules rule set.

A rule set with no rules cannot be used in a decision flow — follow up with create_business_rule to populate it.

Update an existing SAS Business Rules rule set's name/description/signature.

Changing the signature can invalidate existing rules that reference removed variables — check with get_business_ruleset first if unsure.

Fetch a single SAS Business Rules rule set by ID.

List SAS Business Rules rule sets, optionally filtered by name substring.

Permanently delete a SAS Business Rules rule set.

Only call this once the rule set is confirmed unused by any decision flow — deleting a rule set still referenced by a decision fails.

Lock the current state of a rule set as an immutable revision.

Decision steps reference a specific rule set revision (versionId), not the live working copy, so a revision must exist before wiring a rule set into a decision flow — call again after editing rules if a decision needs to pick up the changes.

The revision-creation request replaces the rule set's full content from the body sent, so this fetches the rule set with its rules included (application/vnd.sas.business.rule.set.integral+json) and resends them — omitting them would wipe the live rule set's rules, not just the new revision.

List all locked revisions of a rule set.

Create a new rule inside an existing SAS Business Rules rule set.

A rule set can hold multiple rules, each evaluated per its conditional type. Condition/action expressions must include the variable name directly (e.g. "credit_score < 650", not just "< 650") — the API accepts the latter as valid but generates DS2 code with a missing left-hand operand. Boolean signature variables must be compared with = 0/= 1 in expressions, not = false/= true.

Update an existing rule inside a SAS Business Rules rule set.

Fetch a single rule's definition from a SAS Business Rules rule set.

List all rules inside a SAS Business Rules rule set.

Permanently delete a rule from a SAS Business Rules rule set.

Create a new SAS Intelligent Decisioning flow chaining rule set steps.

Update an existing SAS Intelligent Decisioning flow.

Pass ALL rule set steps (existing + new) — the full flow is replaced on update, it is not a partial patch.

Fetch the current state of a SAS Intelligent Decisioning flow.

List SAS Intelligent Decisioning flows, optionally filtered by name substring.

Permanently delete a SAS Intelligent Decisioning flow.

Retrieve the generated DS2 execution code for a decision flow.

Lock the current state of a decision flow as an immutable revision.

Call after a successful create/update to freeze the approved state as a point-in-time snapshot referenceable by publish_decision_flow.

List all locked revisions of a decision flow.

Fetch the content of a specific locked decision revision.

Publish a locked decision revision to a Micro Analytic Score (MAS) destination.

Required before score_data can execute the decision — MAS runs published modules, not decision flows directly. Requires the DS2 code generation service to be healthy for this decision's rule sets; an error mentioning rule set code generation is an environment-level issue, not a bad payload.

Publishing is asynchronous and the resulting MAS module ID is server-generated — it is NOT publish_name. This polls the publish job (properties.masModules[0].jobUri) until it reaches a terminal state and returns the real moduleId alongside the publish record, so the result is directly usable with get_mas_module_step_signature/score_data without a separate lookup via list_mas_modules.