Universal search for BW objects by name or description. Use this whenever the user wants to find, list, or look up any BW object — aDSOs, queries (ELEM), transformations (TRFN), DTPs (DTPA), InfoObjects (IOBJ), InfoSources (TRCS), CompositeProviders (HCPR), DataSources (RSDS), InfoAreas (AREA), process chains (RSPC), and any other TLOGO type. Supports wildcards (e.g. "Z*" to find all objects starting with Z). Pass object_type to restrict results to a single type; omit it to search across all types. Prefer this tool over type-specific get/list tools whenever the object name is unknown or a pattern is given.

Find where-used / dependencies for a BW object. Returns all objects that reference the given object. Use this to find the Transformation and DTPs that reference an aDSO, or to find which DTPs depend on a Transformation. Use object_type=DTPA to find the process chain(s) a DTP belongs to — this is preferred over bw_get_dtp when only the process chain is needed.

Read an aDSO (Advanced DataStore Object) structure — fields, settings, version.

Create a new aDSO shell. action "from_template" (default): proposes fields/keys/settings from a template object — pass template_name. Without template_name creates an empty standard shell. The template can be an existing aDSO (template_type "ADSO", default) or a DataSource (template_type "RSDS"); for RSDS, source_system is required and the server proposes the DataSource fields. action "empty": creates a minimal empty aDSO with the given adso_type preset (no fields). After creation the aDSO is inactive — add fields with bw_update_adso, then call bw_activate.

Add/remove fields, change aDSO type/settings, manage key fields, or update individual field properties. action "add_field" (default): add one or more InfoObject-backed fields — infoobject_name required. action "remove_field": removes the field from the aDSO (and from the key if it was a key field). action "add_pure_field": add one or more pure (non-InfoObject) fields — pass fields array with name, label, data_type, optional length/precision/scale/aggregation_behavior/is_key. action "update_settings": change aDSO type preset and/or individual boolean flags — no infoobject_name needed. action "manage_keys": replace the complete key field list — pass key_fields array (empty = no key fields). action "update_field_properties": modify sidDeterminationMode, aggregationBehavior, fixedCurrency/Unit, a unit/currency field reference (unit_currency_field), the field group (dimension), or descriptions of a single field — pass field_name and properties. Field groups: pass "dimension" on add_field/add_pure_field to place new fields in the right group straight away — a field added without it lands in the catch-all group and moving it afterwards costs a second activation. Returns a lock_handle that must be passed to bw_activate to complete the operation. Sequence: bw_update_adso → bw_activate (adso) → bw_activate (trfn) → bw_activate (each dtpa).

Create a new InfoObject — Characteristic (CHA) or Key Figure (KYF) — inactive. Sequence: lock → POST create → unlock. After creation call bw_activate with object_type "iobj" to activate.

Create a new InfoArea. The InfoArea is immediately active after creation — no activation step needed.

Create a new Transformation between two BW objects (aDSO, DataSource, InfoSource, etc.). The Transformation name is server-generated (32-char UUID-like key). Created inactive — call bw_activate with object_type "trfn" afterwards.

Move a BW object (aDSO, InfoObject, InfoArea, …) to a different InfoArea. Single POST operation — no lock/unlock needed.

Assign an existing BW object to a different package (Development Class) and record the change on a transport request. Single write, no activation and no version change: this is a pure TADIR/transport assignment, so an active object stays active and no re-activation is required (verified for ADSO, TRFN, DTPA). Do not re-activate a TRFN afterwards — an activation with a stale lock can regenerate the AMDP method body. For object_type "RSDS" (DataSource) source_system is mandatory — the key is compound and the package change is verified by re-reading the DataSource. Verified for TRFN and RSDS; other TLOGO types use the same mechanism but are not trace-verified.

List transport requests and their tasks via the BW transport state (cto/check). Defaults to the caller's modifiable requests. Use this to find an open request to assign an object to.

Read an InfoObject definition (must already exist in the system). Returns the full XML including data type, length, conversion routine, and descriptions.

Update a Characteristic InfoObject: change description and/or replace the attribute list. Replaces all existing attributes with the supplied list (pass an empty array to remove all). Also supports Key Figure (KYF) updates: set fixed_unit or fixed_currency. Sequence: lock → GET → PUT → activate → unlock — all in one call.

Read a Transformation structure — source/target segments, mapping rules. Transformation names are UUID-like generated keys (e.g. "TRFN_UUID_KEY"). Use bw_xref on the aDSO to find the transformation name.

Map a source field to a target InfoObject in a Transformation, or convert an existing rule to a field routine (StepRoutine) or formula rule (StepFormula). rule_type="direct" (default): changes a StepNoUpdate/StepInitial rule to StepDirect. rule_type="routine": converts an existing StepDirect, StepInitial, or StepNoUpdate rule to StepRoutine (AMDP field routine). rule_type="formula": converts an existing rule to StepFormula — no ABAP class generated, BW evaluates the formula natively. rule_type="constant": sets a fixed constant value on the target field — no source field needed. For routine/formula on StepNoUpdate rules, source_field is required. For routine/formula on StepDirect/StepInitial rules, source_field is ignored (field is already mapped). source_field is always ignored for rule_type="constant". rule_type="direct" with unit_source_field set: creates a COMBINED key-figure + unit/currency direct rule (multi-source/target) — maps a quantity together with its unit (or an amount with its currency) in one rule, as the Eclipse rule editor shows it. Returns a lock_handle for bw_activate.

Remove a Start, End, or Expert routine from a Transformation. Removes the matching routine rule from the transformation's global routine group. If no rules remain, removes the entire group. Returns lock_handle for bw_activate.

Add a Start, End, or Expert routine to a Transformation. Creates the global routine group (group id="0") and ABAP/AMDP method stub. Returns lock_handle for bw_activate.

Write the CODE of an existing Start/End/Expert routine into the Transformation MASTER so it survives TLOGO regeneration — a full bw_activate(trfn) AND a transport import — then activate. Use this instead of abap-adt WriteSource on the generated /BIC/_M class: WriteSource updates only the generated class body, which BW re-generates from the old master on the next trfn activation or transport import (symptom: "return type mismatch … OUTTAB[…]"). This tool replicates the Eclipse editor: it writes the class, then re-saves the transformation master and runs a TLOGO activation via the BW modeling endpoints. The routine must already exist (create it first with bw_set_transformation_routine). Activates automatically — no separate bw_activate needed.

Edit the list of target fields the global END routine writes ("Felder setzen" in SAP GUI). Requires an existing END routine — use bw_set_transformation_routine to create one first. Provide exactly one of: fields (explicit complete set of target fields the END routine should write) or exclude_fields (all target fields minus these). Rejected if neither or both are given, if any field name does not exist in the target segment, or if the resolved field set is empty. Does not activate. Returns lock_handle for bw_activate.

Switch a Transformation between HANA and ABAP runtime. Only changes the HANARuntime attribute — no rule changes. The current runtime is read from the active version; if it already matches, returns early. Activates automatically and verifies the change landed in the active version — no separate bw_activate needed. Returns an error (not success) if the switch does not persist, e.g. when the server refuses HANA runtime for this transformation.

Activate one BW object (aDSO, Transformation, DTP, InfoObject, InfoSource, DataSource, CompositeProvider, or Aggregation Level). Pass the lock_handle from bw_update_adso or bw_update_transformation. For DTP and DataSource (rsds) activation use lock_handle="" (no lock needed — standalone activation). For object_type "rsds" also pass source_system (a DataSource is identified by DataSource name plus source system). Unlock is sent automatically after activation (not for DTPs or DataSources). The response lists any DTPs deactivated by impact analysis — these must be re-activated.

Delete a BW object permanently (aDSO, InfoObject, Transformation, DTP, Query, etc.). Sequence: lock (with /m) → DELETE → unlock. No activation needed — deletion is immediate. Queries (object_type "query", alias "elem") use a dedicated delete sequence; deleting a query does NOT delete the reusable components (variables, CKFs, RKFs) it references — only the query itself. Dependency note: delete aDSOs before their InfoObjects, not the other way around.

Release a lock on a BW object without activating it. Use this to discard changes and free the lock, e.g. after an aborted create or update. For DTPs (dtpa) this releases the DTP framework enqueue lock (SM12: RSBKDTP) that can otherwise linger and block the next run or edit of the same DTP.

Read an InfoSource (TRCS) structure — fields, key fields, label, InfoArea, version status.

Read an InfoArea definition — name, label, parent area, object status.

Create a new InfoSource (TRCS) shell. Optionally copy fields from an existing aDSO, CompositeProvider, DataSource, or InfoObject via copy_from_* parameters. Created inactive — call bw_activate with object_type "trcs" afterwards. To add fields after creation use bw_update_infosource.

Update an InfoSource — change description, add/remove fields, and update labels. Provide fields as an array of the fields to add, and remove_fields as an array of field names to delete; other existing fields are always preserved verbatim. Each field can reference an InfoObject (set infoobject_name) or be a local field (omit infoobject_name). Returns a lock_handle for bw_activate.

List DTPs (Data Transfer Processes) that depend on a BW object. Uses the xref endpoint filtered to DTPA object type. Use object_type=TRFN and the transformation name to find DTPs after activating a transformation.

Read a DTP (Data Transfer Process) definition — source, target, transformation, extraction settings, and filter fields (selections and routines). Use bw_xref on an aDSO to find the DTP name first. To find only the process chain a DTP belongs to, use bw_xref with object_type=DTPA instead — it is faster and avoids loading the full DTP definition.

Read a Process Chain (RSPC) definition — header metadata, scheduling and monitoring settings, all steps (nodes) with type, variant, and last execution status, step dependencies (edges) with branch conditions for DECISION nodes, and inline variant details. By default (include_variant_details=true), automatically fetches and embeds the full variant configuration for each step that has detail available. Steps without variant detail (DTP_LOAD, OR, AND, EXOR, CHAIN) are shown without extra detail — for DTP_LOAD use bw_get_dtp, for CHAIN use bw_get_process_chain recursively. Set include_variant_details=false for a faster structural overview without variant detail. Use bw_search with object_type=RSPC to find chain names first.

Read the detail configuration of a single Process Variant from a Process Chain step. Covers all process types: ABAP (report name + selection variant), ADSOACT (aDSO activation), ADSOREM (request cleanup), PLSWITCHL/PLSWITCHP (planning mode switch), DTP_LOAD, DECISION, and any other type — oDetail is returned as indented JSON for unknown types. Get process_type and variant_name from bw_get_process_chain output (sProcessType and sProcessVariant fields). Use format="raw" to see the full unformatted JSON.

List the recent load requests of an InfoProvider from the runtime request monitor, with decoded request status, record counts and timestamps. Returns one entry per request including the internal request TSN, which is the input for bw_get_request. Read-only. Use bw_search to find the target technical name first. Performance: listing cost scales with the number of returned rows because each row is enriched on the backend (a per-row cross-reference read). top bounds the result set; created_from and status only help by returning fewer rows, not by making a row cheaper. For providers with long load histories, use a narrow created_from window or a small top.

Full status analysis of one load request in a single call, bundling the request header, DTP information (including start, finish and duration), the process step chain and the message log. Read-only. The request TSN comes from bw_list_requests output.

Activate loaded data (DSO request activation): move a finished load from the Inbound Table into the active data table and change log. This is the runtime request activation, NOT the modeling-object activation done by bw_activate. Only applies to aDSOs that have an activation step (not inbound-only staging aDSOs). Activates all previous loads up to the given request. Asynchronous: a successful call starts activation; monitor completion via bw_list_requests / bw_get_request.

List remodeling requests from the remodeling monitor, with decoded status, last run and creator. Remodeling changes the structure of an existing InfoProvider (e.g. adding, deleting or reassigning a field of an aDSO) and converts the data it already holds. Read-only. Rules are not created by this tool family — BW creates one automatically when an aDSO holding data is activated after a change that cannot be applied to the existing data in place (changing the key definition, deleting a field, changing a data type). Merely appending a field does not trigger one: the column is added and old records keep the initial value. The activation reports "remodeling rule created instead of the activation"; that ID is the remodeling_rule of the resulting request.

Full status of one remodeling request: header, the five processing steps (CHECK, SAVE, CONVERT, ACTIVATE, CLEANUP) with their individual status, and the application log messages. Read-only. This is the tool to diagnose a failed remodeling — the log carries the reason. A "running" status is never reported on the monitor service alone: it is buffered and keeps reporting Running after a run has finished, so the status is cross-checked against the runtime tables and the batch job. A corrected status names its source; if the run is demonstrably over but the header still lags, the output warns about it. Poll this tool to wait for a run to finish.

Start, restart or reset a remodeling request. WRITE OPERATION WITH DATA IMPACT: executing a remodeling rule restructures the InfoProvider and converts its existing data — it is not a plain reload and cannot simply be undone. Asynchronous: the call schedules the run; monitor completion with bw_get_remodeling_request. Actions: "execute" starts a request that has not run, "restart" resumes a failed one, "reset" resets the whole request, "reset_step" resets only the current step.

Create a new DTP (Data Transfer Process) for an existing Transformation and activate it. The DTP name is server-generated. Optionally set a filter on one source field (Equal operator). After creation the DTP is activated automatically. IMPORTANT: Before calling this tool, always check the full transformation chain. Single-step chain (e.g. ADSO->ADSO): use trfn_name only. Two-step chain (e.g. ADSO->TRCS->ADSO): use trfn_name for the first transformation and trfn_name_2 for the second; source_name/source_type = the start object, target_name/target_type = the end object. Omitting trfn_name_2 in a two-step chain causes a persistent HTTP 500 error. Use bw_get_transformation or bw_xref to determine the chain before creating the DTP. DataSource source: set source_type "RSDS" and pass source_system (the DataSource source system). source_name is then the plain DataSource name; the tool builds the RSDS compound source key internally.

Start (execute) a run of an existing, active DTP. Triggers the load with a single request and returns the new run request id. The returned request_id is the RSPM request TSN: pass it straight into bw_get_request (as request_tsn) to monitor load status — no bw_list_requests lookup needed.

Set an ABAP filter routine on a DTP filter field. Use this only when custom ABAP code is needed for the filter logic; for value sets, ranges and patterns use the filter parameters of bw_update_dtp. Repeatable on the same field: the routine replaces the previous one, existing value selections on the field are kept, and a failed attempt leaves neither a routine nor a generated report behind.

Update DTP properties: description, the value selection of one filter field, extraction mode (Full vs Delta), and/or the semantic group. Use this for setting filter values on existing filter fields. A filter is written per field as a complete selection — a second call on the same field replaces the first, it does not add to it, so pass the whole value set at once. Note: switching extraction mode between Delta and Full (and back) has BW delta-init implications — a later delta load may require re-initialization of the delta on the source.

Fetch the JSON schema for an aDSO write interface. Returns field names, data types, and required fields. Use this before bw_push_data to know what fields to include in records.

Push data records directly into an aDSO inbound table via the SAP BW/4HANA write interface. The aDSO must have write_interface enabled (pushMode="true"). Use bw_get_push_schema first to verify field names and types. Success = HTTP 204 (SAP returns empty body). DATS fields must be formatted as YYYYMMDD strings. INT4 fields as JSON integers.

Read a BW Query definition — variables, filter, layout (rows/columns/free characteristics), calculated and restricted measures, exceptions, and cell definitions. Tries the active version first; falls back to the inactive version if not found. format="text" (default): compact human-readable output. format="raw": full parsed JSON.

Create a new BW Query (TLOGO ELEM) on an InfoProvider in package $TMP. Without copy_from the query is created empty and consistent (no rows, columns, or key figures yet). With copy_from the new query is created as a full copy of an existing query (layout, filter, variables, key figures); the description parameter still applies to the copy, and infoprovider may be omitted (it is derived from the source query). Support for transportable packages is not yet available; only package $TMP is supported.

Create a reusable BW Variable on a characteristic, for use as a filter parameter in queries. The variable is created active and consistent. Covers processing types UserEntry (manual entry, the default), CustomerExit, Authorization and the current-member flavour of ReplacementPath, and stands for a characteristic value, a hierarchy or hierarchy nodes. Text and formula variables are not supported. To keep a variable out of the user's variable screen, set ready_for_input false.

Modify an existing BW Query layout: add or remove characteristics in the rows, columns, or free-characteristics area, and add or remove references to reusable structures (a structure is a layout container). All operations are applied in a single save. All names must be technical names (e.g. "IOBJ_NAME", "STRUCTURE_NAME", "QUERY_NAME").

Modify an existing BW Query filter. Supported restrictions: fixed values — single values, intervals (via "high"), and exclusions (via "exclude") — and reusable variable references (via "set_variable"). All operations are applied in a single save. Key figure members are not yet supported. All names must be technical names (e.g. "IOBJ_NAME", "QUERY_NAME", "VAR_NAME").

Manage the key figure structure of an existing BW Query: add basic key figures, add references to reusable CKFs/RKFs (with optional local restrictions), add local formula members (recursive operator/operand tree), set member display properties (decimals, hidden, sign inversion) and exception aggregation, and remove members. All operations are applied in a single save. Member operations also apply to a reusable key figure structure referenced via bw_update_query_layout add_structure. All names must be technical names (e.g. "IOBJ_NAME", "CKF_NAME", "QUERY_NAME").

Change query-level display and behaviour settings of an existing BW Query (description, zero suppression, result position, sign presentation, zero presentation, universal display hierarchy, document links, and related flags). Only the provided settings are applied in a single save. The InfoProvider, technical name, and package cannot be changed. All names must be technical names (e.g. "QUERY_NAME").

Set the display and access properties of the characteristics in an existing BW Query - the per-characteristic settings of the rows, columns, and free-characteristics areas: display of result rows, display as key/text, access type for result values (read mode), sorting, cumulation, display level, and the hierarchy assignment with its display options. Pass "*" as infoobject to apply one set of properties to every characteristic in the layout. Every property also accepts "default", which drops the explicit value and falls back to the InfoObject/query default. All specs are applied in a single save. Characteristics must already be in the layout - add them with bw_update_query_layout first. All names must be technical names (e.g. "QUERY_NAME", "CHAR_NAME").

Read a CompositeProvider (HCPR) structure — general info, view node type (Union/Join), source providers (inputs) with mapping counts, fields with dimension classification, join condition, and temporal join details. Returns the inactive version.

Change a CompositeProvider (HCPR): its fields, its source providers, their field mappings, the join condition, or root settings. Every action returns a lock_handle that must be passed to bw_activate (object type hcpr) — an HCPR cannot be activated without it. Fields: "add_field" (default) adds an element plus a mapping in every part provider supplying it, taking the field metadata from there; "remove_field" removes the element and all mappings referencing it. Sources: "add_input" attaches a source provider, creates the target elements it needs and returns the generated alias; "remove_input" strips one by alias, leaving its elements and any join reference behind. Mappings: "update_mapping" replaces the complete mapping list of one input; pass no mappings to map every field of its source one to one. This is also how an input attached at creation time gets its mappings. Joins: "update_join" sets the condition between one pair of inputs — call it once per pair to build an N-way join — and "remove_join" drops one pair. Note that both sides of a join key must be mapped onto the SAME target field, otherwise activation fails with "join fields need at least one common target field"; auto-mapping does not do this, so map the second side's key fields explicitly. Settings: "update_settings" edits label, stackable, default node and aggregation behaviour.

Create a CompositeProvider (HCPR). Without copy_from it creates a view node of the given type with the listed source providers attached — entity only, so give them their mappings afterwards with bw_update_composite_provider action "update_mapping". A Union node may be created empty; a JOIN node must be created WITH its sources, since a join node without inputs makes the server dump. With copy_from the server copies view node, inputs and mappings from an existing CompositeProvider. The result is inactive — activate it with bw_activate (object type hcpr).

Read the direct children of any node in the BW repository tree. The path parameter maps to the navigation hierarchy: use "/" or "" for all InfoAreas, "area/{name}" for InfoArea contents (object type folders), "area/{name}/{folder}" for objects within a folder (e.g. "area/MYAREA/adso"), "{type}/{name}" to expand an object (e.g. "hcpr/CP_NAME" → sub-folders), "{type}/{name}/{subfolder}" for objects within a sub-folder (e.g. "adso/ADSO_NAME/trfn"). Returns name, description, object_type, object_subtype, status, has_children, self_url, fiori_only, and children_path (pass directly to bw_list_contents to drill down).

Read a BW object definition directly from its metadata tables (via the ADT DataPreview service). Read-only fallback for object types the connected system does not publish as a REST resource — on classic SAP BW (7.5) that is typically transformations and DTPs, and the classic providers, for which no release ships a REST resource. Use bw_system_profile to see which endpoints a system publishes. Supported object_type: TRFN (transformation incl. start/end/expert and field routine source code), DTPA (data transfer process), ODSO (classic DataStore Object), CUBE (InfoCube), MPRO (MultiProvider) and RSPC (process chain: steps with their variant parameters, in execution order — every step follows its predecessors, but branches that run in parallel have no order among themselves, so read the "After" line of each step for the actual dependency). Requires ADT authorization for the calling user. Prefer bw_get_transformation where the REST endpoint exists.

Find out what the connected BW system is and which of this server's tools will work on it. Distinguishes SAP BW/4HANA from classic SAP BW (7.5) via the system's own b4hanamode flag, lists which REST endpoint groups the system publishes, and verifies three preconditions: Accept-header handling (a broken one makes almost every call fail with HTTP 406 on BW 7.5), access to the ADT DataPreview service, and whether the BICS reporting resource is implemented. Call it before planning work on a system whose release you do not already know: the answer says which tool groups are available and which route to take where they are not — on classic BW, for instance, transformations, DTPs and the classic providers have no REST resource and are read with bw_read_metadata_tables instead. One call beats inferring the release from failed ones.

List logical source systems (LSYS) registered in the BW datasource structure. If source_system_type is provided, lists only source systems of that type (e.g. "ODP_SAP", "ODP_BW", "FILE"). If omitted, lists all source systems across all types. Returns each LSYS with name, description, source_system_type, status, self_url, and children_path (pass children_path directly to bw_list_datasources as the source_system argument).

List all DataSources (RSDS) available under a logical source system. Recursively traverses the full application component (APCO) hierarchy — may take time for large systems. Returns each DataSource with name, source_system, description, status, self_url, and apco_path (ordered list of application component titles from root to the DataSource). Optional apco_path_filter restricts the result to a hierarchy subtree and also prunes traversal.

Read the metadata of a single logical source system (LSYS) — type, description, connection details, and maintenance properties.

Read the full structure of a DataSource (RSDS) — metadata, all fields with types and properties, and adapter configuration.

Change the delta process of a DataSource (RSDS deltaProperties). Full read-modify-write; the requested value is validated against the DataSource's admissible delta values. Leaves the DataSource inactive — activate separately with bw_activate (object_type "rsds"). Pass delta_process as an empty string to remove the delta process.

Set the transfer flag of one or more DataSource fields (fieldProperties@transfer) and/or the segment language field designation. Full read-modify-write; only the field transfer flags and/or the segment languageField change. Fields marked transferNotAllowed are skipped when enabling transfer. At least one of fields / language_field must be given. Leaves the DataSource inactive — activate separately with bw_activate (object_type "rsds"). Pass transport for a transportable DataSource so the change is recorded on that request.

Fetch a live data preview / sample rows from a DataSource (RSDS) — reads the first N rows directly from the source system and returns them as a formatted table with field names as column headers. Use this when the user wants to see, sample, preview, or inspect the actual data behind a DataSource (e.g. "show me data from DS_X", "preview 50 rows", "what does DS_X look like"). For data from an aDSO, CompositeProvider, or BEx query, use bw_query_data instead.

List the remote entities (HANA views / virtual tables) a source system exposes as a DataSource basis — read-only discovery (the value help Eclipse shows on the DataSource proposal page). Each entity's technical_name is exactly what binds into bw_create_datasource as the HANA entity. Use this to find a valid hana_entity before creating a DataSource.

Create a DataSource (RSDS) on top of a remote entity from the server's field proposal, leaving it inactive. The server derives the complete field/segment structure from the remote entity — no field, key, or partitioning editing is supported (v1). Local objects only (Development-Class $TMP); no transport handling. The HANA entity binds via the adapter externalObject attribute, not by name equality — use bw_list_remote_entities to find a valid hana_entity. After creation, activate separately with bw_activate (object_type "rsds", the same source_system, lock_handle "").

Read a global Calculated Key Figure (CKF) defined at CompositeProvider level. Returns technical name, description, formula (recursively resolved), metadata, and the full dependency graph of referenced CKF/RKF sub-components.

Read a global Restricted Key Figure (RKF) defined at CompositeProvider level. Returns technical name, description, base measure, characteristic filters, metadata, and the full dependency graph of referenced CKF/RKF sub-components.

Read a global Structure defined at CompositeProvider level. Returns the ordered member list with type (Selection/Formula), referenced component or IOBJ name, characteristic filters, and the full dependency graph.

Create one reusable Restricted Key Figure (RKF, TLOGO ELEM) on an InfoProvider. Built for mass creation: one RKF per call — the agent loops. The RKF is created from a base key figure plus one or more characteristic restrictions; each restriction value is validated against the InfoProvider and mapped to its internal key before the write. The RKF is written consistent (no separate activation step). All names must be technical names (e.g. "PROVIDER_NAME", "RKF_NAME", "KYF_NAME", "IOBJ_NAME").

Execute a BW query or preview data from a provider (CompositeProvider, aDSO, etc.) via the BICS reporting endpoint. ALWAYS call the appropriate read tool first before querying data: bw_get_composite_provider for a CompositeProvider (is_provider=true), bw_get_adso for an aDSO (is_provider=true), bw_get_query for a BEx Query — this gives you the available fields, key figures, and the query structure before you attempt a data call. Then perform a GET (no state/variables) first to discover the current axis layout, characteristic ids, variables, and background filters before sending any POST. IMPORTANT — always call bw_get_filter_values before applying any filter or variable value. This is the only way to know the correct internal key format for a characteristic (e.g. date/time characteristics like 0CALMONTH, 0CALYEAR, 0CALDAY may use non-obvious formats). Never guess or assume filter value formats — always look them up first. If the GET response shows inputRequired="true", variables must be filled via POST before data is available. If unsure whether a BEx Query exists for the desired analysis, use bw_search or bw_list_contents first before falling back to a direct provider call (is_provider=true). Result is rendered as a formatted table with hierarchy indentation. KEY FIGURE STRUCTURE FILTER: to restrict which key figures appear in the result, apply filterValues directly on the structure dimension (isStructure=true) in state.infoObjects — use the technical name of the calculated or restricted key figure as the low value (e.g. "CKF_NAME" or "RKF_NAME"). Hierarchical children of the filtered member are included automatically. This is the correct approach because ad-hoc threshold filters on key figure values are not supported via the state mechanism; only structure-member selection is possible this way. CRITICAL: variable id and name values in the variablesContainer are session-specific and change between GET calls. Always extract variable id and name exactly from the variablesContainer in the GET response and use them immediately in the next POST — never reuse IDs from a previous GET call or from bw_get_query output. The variable name includes trailing spaces and a 4-digit suffix (e.g. "VARNAME 0004") that must be copied verbatim from the GET response. format="raw" returns XML.

Look up valid characteristic values for use in query filters or variable inputs. Returns CHAVL_INT (internal key) — always use this value when setting filter selectValues or variable inputs; CHAVL_EXT and CHAVL_INT often differ for date-type characteristics. Supports wildcard search: use "" to return all values, "2022" for prefix match. Optionally scope results to a specific InfoProvider (recommended when values differ by provider).

Load the complete BW query role hierarchy as shown in the "Publish to Role" dialog. Returns all roles (ROLE nodes) and their folder structure (FOLDER nodes) with nodeids. Use this to discover role names and folder names needed for bw_set_query_roles. Optionally filter to roles whose name starts with a given prefix.

Get all roles and folders where a specific BW query is currently published. Returns the role name, description, and folder for each assignment. If the query is not published anywhere, returns a clear message.

Publish or unpublish a BW query in a role or folder. action "add": assigns the query to the given role or folder. action "remove": removes the query from the given role or folder. Use bw_get_roles to discover role/folder names and bw_get_query_roles to see current assignments.

List all BW queries published in BW roles (via the "Publish to Role" mechanism). Returns each role with its assigned queries, including technical name, description, object type, and InfoProvider. Note: only SAP_BW_QUERY objects are returned; PFCG menu entries of other types (e.g. AFO workbooks added as transactions) are not included. Use role_name to filter to a specific role; omit it to see all roles with published queries.

Trace the data flow graph for a BW object. Returns a tree (≤ 30 nodes) or flat table (> 30 nodes) showing all connected objects (ADSO, RSDS, TRFN, DTPA, TRCS, IOBJ, HCPR, LSYS, ELEM) with their type, name, description, and status. BW direction convention: "upwards" traverses towards BW target objects (ADSO, TRFN, TRCS, IOBJ); "downwards" traverses towards source systems (LSYS, RSDS). Use this to understand the full lineage of an object without navigating each connection manually. IMPORTANT: Always print the complete tool result verbatim as a fenced code block in your chat response — never omit or summarize it.

Read an Open Hub Destination (TLOGO DEST) definition — destination type, source, DB table, InfoArea, package, status, the complete output field list with type/length, InfoObject binding, conversion routine, compounding, and key flag, plus file properties when the destination type is FILE.

Read an Aggregation Level (TLOGO ALVL) definition — the planning-enabled view on top of an InfoProvider (aDSO or CompositeProvider) used for Integrated Planning / embedded BPC. Returns name, description, status, InfoArea, package, the underlying InfoProvider, and the full element list split into characteristics and key figures. Characteristics include type, length, conversion routine, base InfoObject, compounding, and dimension group. Key figures additionally include aggregation behavior, semantics (AMO/QUA/NUM), and the unit/currency reference (unit characteristic, fixed unit, or fixed currency).

Create a new Aggregation Level (TLOGO ALVL) on top of a planning-enabled InfoProvider (aDSO or CompositeProvider), for Integrated Planning / embedded BPC. Sequence: lock → POST the shell → unlock → lock → PUT the field list → unlock. The Aggregation Level is created inactive — activate it with bw_activate using object_type "alvl" and lock_handle "". By default every characteristic and key figure of the InfoProvider is exposed; pass fields to restrict the selection. A selection needs at least one characteristic and one key figure, and it must contain every key field of the underlying provider, otherwise activation reports the missing ones. The InfoProvider must be planning-enabled, otherwise the create fails with a message saying it cannot serve as the basis of an aggregation level.

Add fields to or remove fields from an existing Aggregation Level (TLOGO ALVL). action "add_fields" exposes further characteristics or key figures of the underlying InfoProvider; action "remove_fields" drops them from the Aggregation Level. Fields already exposed (add) or not exposed at all (remove) are reported as skipped, not treated as errors. The Aggregation Level becomes inactive — activate it with bw_activate using object_type "alvl" and lock_handle "". A removal that would leave no characteristic or no key figure is refused before writing. On a CompositeProvider both the prefixed field name and the bare name are accepted.

Read a Planning Function (TLOGO PLSE) definition — a planning operation (formula/FOX, copy, delete, repost, distribution, currency translation, custom exit, …) tied to an aggregation level for Integrated Planning / embedded BPC. Returns name, description, function type (planningServiceType), aggregation level, documentation, status, InfoArea, package, the characteristic usage list (role of each characteristic in the function), and the full parameter tree with nested structure and values. For FORMULA functions the FOX code surfaces as the value of the FLINE parameter.

Read a Planning Sequence (TLOGO PLSQ) definition — an ordered list of planning steps for Integrated Planning / embedded BPC. Returns name, description, InfoArea, package, status, and the ordered step list. Each step shows its type code, the aggregation level, the planning function (planning service), and the filter name.

Read the Planning Properties (TLOGO PLCR) of a plan-enabled InfoProvider (real-time aDSO or CompositeProvider). Returns the provider name, underlying provider resource and media type, InfoArea, package, status, and the general planning settings: key-date mode, maximum number of characteristic combinations, and the save strategy (planning sequence and delta-read flag). The PLCR shares its technical name with the InfoProvider it belongs to.

List execution runs of one or all process chains from the process chain monitoring log. Each row represents one chain run with overall status, runtime deviation, start/end timestamps, and duration. Optionally filter by chain technical name, start date range, and status code. Returns the log_id of each run — pass chain_id + log_id into bw_get_process_chain_run_detail for step-level details. Ordered by start time descending. Default limit 20 runs.

Read the execution detail of one process chain run — all process steps with type, variant, status, timestamps, and parent/child relationships (predecessor graph edges), plus the full message log. chain_id and log_id come from bw_list_process_chain_runs or bw_list_process_chain_last_status output. Use this to diagnose a failed run: the message log contains the actual error messages.

Read the latest execution status and scheduling state for every process chain in the system — one row per chain. Includes last run status, runtime deviation, scheduling status, next scheduled start, and the log_id of the most recent run (pass into bw_get_process_chain_run_detail to drill down). Chains that have never run appear here too. Optionally filter to chains whose last run has a specific status or whose last start date falls in a range.

Create a Process Chain (RSPC) via the BW/4HANA Cockpit REST API. Builds the chain model from a list of steps and edges, creates it with a trigger-only skeleton, then updates it with the full model in a single operation. Optionally activates after creation. The TRIGGER (Start) node is implicit (node index 0) and must not be listed in steps. DTP_LOAD and generic referenced steps use bIsReference=true; ADSOACT and ADSOREM use inline variants. Collectors (AND, OR, XOR) require no extra fields beyond their type. Edge status defaults: neutral for edges whose source is TRIGGER or a collector; positive for all others. For two-step DTP loading always use bw_create_dtp first; this tool builds the process chain around existing DTPs. Supported step types: DTP_LOAD (DTP load), ADSOACT (DSO data activation), ADSOREM (DSO request cleanup), ABAP (execute an ABAP program, optionally with an SE38 selection variant), CHAIN (start a local sub-chain, verified), DECISION (branch on a decision variant, requires the variant field), and collectors AND / OR / XOR; the start trigger is implicit. A generic referenced-step path (any process type string plus an object name, bIsReference=true) is available and verified for DTP_LOAD and CHAIN; for other types it may work but is untested. Other inline-configuration process types (for example OS command, attribute change run) are not supported in this version. Edges support on-success (positive) and unconditional (neutral) links; on-error (negative) links are accepted in the schema but not emitted by default. DECISION branch edges: set sub_status to the branch EVENTNO ("01"=THEN/JA, "02"=ELSE/NEIN) — such edges are always positive. Create the referenced decision variant first with bw_create_decision_variant. To start the chain on an event instead of immediately, pass trigger_event (start type "E").

Replace the step model (nodes and edges) of an existing Process Chain (RSPC) via the BW/4HANA Cockpit REST API. Reads the current chain to obtain the ETag and preserve the existing trigger node (with its scheduling configuration) and the current header. Replaces only the steps and edges; the trigger is always preserved as-is. Optionally overrides description and infoarea in the header. Optionally activates after the update. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly. Use bw_create_process_chain to create a new chain; use this tool to update an existing one. This tool REPLACES the whole step model, so every step that should survive must be listed — a step left out is deleted. For a small change to a big chain prefer the targeted tools (bw_append_process_chain_dtp, bw_add_process_chain_program, bw_add_process_chain_edge, bw_remove_process_chain_edge, bw_remove_process_chain_step), which edit the server's own model in place and cannot drop a step they do not model. Supported step types: DTP_LOAD (DTP load), ADSOACT (DSO data activation), ADSOREM (DSO request cleanup), ABAP (execute an ABAP program, optionally with an SE38 selection variant), CHAIN (start a local sub-chain, verified), DECISION (branch on a decision variant, requires the variant field), and collectors AND / OR / XOR; the start trigger is implicit. A generic referenced-step path (any process type string plus an object name, bIsReference=true) is available and verified for DTP_LOAD and CHAIN; for other types it may work but is untested. Other inline-configuration process types (for example OS command, attribute change run) are not supported in this version — a chain containing one cannot be rewritten with this tool without losing that step. Edges support on-success (positive) and unconditional (neutral) links; on-error (negative) links are accepted in the schema but not emitted by default. DECISION branch edges: set sub_status to the branch EVENTNO ("01"/"02"); such edges are always positive. The trigger is preserved as-is unless trigger_event is passed (which sets an event start-condition); an existing event start-condition is preserved across updates.

Activate an existing Process Chain (RSPC) via the BW/4HANA Cockpit REST API. Use this after bw_create_process_chain (with activate=false) or to re-activate a modified chain. Returns the top-level activation message, severity, and full log entries. Surfaces any log entries with severity "error" in a dedicated errors field.

Create a DECISION process variant (a standalone TLOGO object) for use as a branch/decision step in a Process Chain, via the BW/4HANA Cockpit REST API. The variant holds two branches indexed by position: THEN/first (EVENTNO "01" by default, label "JA") and ELSE/second (EVENTNO "02", label "NEIN"). The formula is the branch condition (e.g. "GET_SEGMENT( ) = ' 3'"); it is evaluated for the THEN branch, the ELSE branch is its complement. The variant is created AND activated (activation is mandatory — an inactive variant is not selectable in the chain variant picker). After creation, reference the variant from a DECISION step in bw_create_process_chain / bw_update_process_chain (variant=), and branch its out-edges with sub_status "01"/"02". Package/transport: $TMP is fine for visibility and picker selection; pass a transportable package (NOT $TMP) only if you need to transport the variant. For a transportable package a transport_request is used (auto-selected when exactly one changeable request is available; pass it to disambiguate).

Add on-error (negative) links to an existing Process Chain (RSPC) by mirroring the existing on-success (positive) out-edges of its DTP load steps, via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, appends the negative edges (skipping any that already exist), and PUTs it back. Optionally activates afterwards. Use dtps to restrict to specific steps; omit it to apply to every DTP load step. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

Swap one DTP load variant for another in an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, replaces the matching DTP_LOAD node's variant, and PUTs it back — edges and all other nodes are preserved unchanged. Prefer this over bw_update_process_chain for a single-variant swap, since it does not require re-specifying the whole chain. Optionally activates afterwards. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

Add one DTP load step (optionally followed by its own DSO activation step) to an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, inserts the node(s)/edge(s)/inline variant, and PUTs it back — the caller does not supply the full model. Positioning: pass "before" to place the block IN SERIES ahead of an existing step (the target's incoming edges are rerouted into the block, then the block links to the target), or "after" to place it in series between a step and its successors. With neither, the block is only APPENDED behind the strand end closest to the trigger (or behind "predecessor") — the target keeps its existing successors, so the block ends up running in PARALLEL to them, not ahead of them. Use before/after whenever the new step must complete before an existing one starts. When adsoact is given, the whole DTP → activation block is placed as one unit. edge_mode defaults to "both", which adds an on-success AND an on-error edge per link ("always continue" — the successor runs even after a failed load). Pass "success_only" for an on-success edge only, which is what a chain whose existing DTP steps have no error edge expects. Idempotent: if the DTP is already a node in the chain, it is skipped without writing. Optionally activates afterwards and then verifies that no collector was inserted and no extra strand appeared. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

Add an "Execute ABAP Program" step (RSPC process type ABAP, "Programm ausführen") to an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API. Runs an ABAP report, optionally with a named SE38 selection variant. In-place edit: reads the current model, inserts the node + its INLINE process variant (the program call is stored inline in the chain — there is no separate variant object), and PUTs it back. Positioning: pass "before" to run the program ahead of an existing step (the target's incoming edges are rerouted through the new step, e.g. Start → PROGRAM → DTP); pass "after" to run it between a step and its successors; pass neither (optionally with predecessor) to append behind the strand end closest to the trigger. edge_mode "both" (default) adds an on-success and an on-error edge per new link; "success_only" adds only the on-success edge. Idempotent: if an ABAP step already calls the same program (and variant), it is skipped without writing. Only the synchronous/local/program call configuration is verified; keep the defaults. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

Add one dependency (edge) between two existing steps of a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, appends the edge, and PUTs it back. Use this to repair the wiring of a chain — for example to connect the end of a newly inserted block to the step that must run after it. Note that an "always continue" dependency is TWO edges (one on-success, one on-error): call this twice, once with status "positive" and once with "negative". Idempotent: an identical edge is skipped without writing. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

Remove the dependency (edge) between two existing steps of a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, drops the matching edge(s), and PUTs it back. By default every edge between the two steps is removed, which is what an "always continue" dependency needs (it is stored as an on-success plus an on-error edge); pass status to remove just one of them. Use this together with bw_add_process_chain_edge to re-route a mis-wired chain. Removing an edge can leave a step unreachable from the start — the chain will not activate until every step has a path from the trigger. Reports a skip when no matching edge exists. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

Remove one step (node) from a Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, drops the node together with every edge touching it and its inline process variant, and PUTs it back. By default the gap is bridged — every predecessor of the removed step takes over every successor, keeping the condition of the edge that ran into the removed step — so the strand stays connected. Pass reconnect=false to leave the successors disconnected. Use this to roll back a step that was inserted in the wrong place. The TRIGGER (Start) step cannot be removed. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.

Add a task (sub-request) for a user to an existing workbench transport request. Single ADT call, no lock or activation. The parent request must be modifiable. Returns the created task number.