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, or descriptions of a single field — pass field_name and properties. 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. Afterwards the object is inactive and must be re-activated with bw_activate (pass the same transport). 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.

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". Returns a lock_handle for bw_activate.

Remove a Start, End, or Expert routine from a Transformation. Deletes the matching rule from group id="0". 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.

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. If the runtime already matches the target value, returns early without a PUT. Returns a lock_handle for bw_activate.

Activate one BW object (aDSO, Transformation, DTP, InfoObject, InfoSource, DataSource, or CompositeProvider). 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, etc.). Sequence: lock (with /m) → DELETE → unlock. No activation needed — deletion is immediate. 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. DTPs do not need unlocking.

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 and/or replace the complete field list. Provide fields as an array; the entire existing field list is replaced. 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.

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, not for simple value filters.

Update DTP properties: description, simple value filter (e.g. field = value), and/or extraction mode (Full vs Delta). Use this for setting filter values on existing filter fields. 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.

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.

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).

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.

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.

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).

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 uses 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), CHAIN (start a local sub-chain, verified), 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 program execution, 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.

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. Supported step types: DTP_LOAD (DTP load), ADSOACT (DSO data activation), CHAIN (start a local sub-chain, verified), 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 program execution, 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.

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.