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. Analysis processes (ANPR) are not in the search index — list them with bw_read_metadata_tables instead. 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. Every transformation and DTP hit carries its source and target (type and name) and its direction relative to the object: upstream (feeds it) or downstream (fed from it) — follow upstream hits hop by hop to trace a data flow back to its DataSource. On classic SAP BW the analysis processes that write to or read from a provider (ADSO, ODSO, CUBE, MPRO, IOBJ) are listed too, with direction. On every release the aggregation levels built on a provider are listed as upstream (planned values are written into the provider through them), and object_type=ALVL lists the InfoProvider underneath (downstream) and the planning functions on the level (upstream) next to its queries. 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, or pass activate: true. In a transportable package pass the transport request.

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, the lower case flag, and/or replace the attribute list. Supplying attributes replaces all existing ones (pass an empty array to remove all); omitting them leaves the list untouched. 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": writes the rule as StepFormula whatever step type it has now, including an existing formula rule whose text is to be changed — no ABAP class generated, BW evaluates the formula natively. Every operand of the expression is registered as a source of the rule, so a formula over several source fields works; the operands are read out of the formula and need not be listed. rule_type="constant": sets a fixed constant value on the target field — no source field needed. For routine on StepNoUpdate rules, source_field is required. For routine 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. A rule on a key figure with a currency or unit takes the value over unconverted unless conversion is set. aggregation sets how the rule aggregates into a target key figure (SUM, MOV, MIN, MAX, NOP), alone or with a rule change. 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. Planning sequences ("plsq"), planning filters ("filter") and conversion types ("ctrt", "uomt") are deleted on their active path; a filter still used by a sequence is refused with the sequence named. 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, errors with their long text. Read-only. For a DTP request that did not finish green, the messages of its data packages are added from the step log of the process chain run that executed it — with message variables and the program location of a runtime error. A request run outside a process chain has no such log, and the output says so. 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.

Delete load requests from an InfoProvider, removing the data they brought in along with their entry in the request management. This is the precondition BW demands before several follow-up steps — above all switching a DTP from delta to full extraction, which BW refuses while delta requests remain in the target. NOT the same as selective deletion of records by condition, which removes rows but leaves the request. Handles both kinds of request: a load request in the inbound queue is deleted, an activation request is rolled back instead — a rollback also undoes every later activation and removes the load request underneath it. Use all_requests=true with target to clear a provider completely, which is the regular case before an extraction-mode change. Asynchronous: a successful call starts the deletion; confirm with bw_list_requests. Returns which requests were rolled back and which were deleted.

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.

Read the hierarchies of a characteristic. Without hierarchy_name: the hierarchies the characteristic has, with version, validity, levels and node count. With hierarchy_name: the tree — every node with its type (text node or characteristic value), name, text and node id, indented by level. Use it to find the node to filter on in bw_query_data, and to read a tree before changing it with bw_update_hierarchy.

Create a hierarchy for a characteristic and activate it. The tree is passed nested: a text node { "text_node": "NAME", "text": "...", "children": [...] } groups other nodes; a value node { "value": "..." } is a value of the characteristic (it may have children too). Each node appears once. The characteristic must have hierarchies switched on. Not time-dependent and not version-dependent hierarchies only.

Change a hierarchy: its description and/or its tree, then activate it. The tree is replaced as a whole, not merged — read it with bw_get_hierarchy, change it, and pass the complete new tree in the same nested form bw_create_hierarchy takes. The hierarchy keeps its id, so queries that use it keep working.

Delete a hierarchy of a characteristic. Deletes the active version unless version "M" is given, which discards only a pending revised version. A query that uses the hierarchy no longer finds it.

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. Structure members are reported with their properties: input readiness and disaggregation (the planning settings), decimals, scaling, sign inversion, constant selection, the local calculation (results / single values as), exception aggregation, position, nested child members and the inverse formulas that make an input-ready formula writable. A member that shows a reusable CKF reports the CKF's own exception aggregation separately from the member's. Each variable lists where the query uses it — filter, default value, key date, structure member, formula, CKF/RKF, exception, condition, cell or text — or says that no use was found; the settings carry the key date (system date, a fixed date or a variable). 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, created active and consistent. A characteristic variable (the default) is a filter parameter on a characteristic: processing types UserEntry (manual entry, the default), CustomerExit, Authorization and the current-member flavour of ReplacementPath; it stands for a characteristic value, a hierarchy or hierarchy nodes. A formula variable (variable_type "Formula") stands for a number and is used as a formula operand in bw_update_query_key_figures, bw_create_ckf and bw_update_ckf: no iobj_name, filled by UserEntry or CustomerExit, with a dimension, an optional default value, and a unit (Quantity), a currency (Amount) or either (Price). A text variable (variable_type "Text") is written as &NAME& into a query or member description and replaced at runtime: by replacement path (the default with iobj_name) it shows the key, the external key or the text of that characteristic's value and is never ready for input; filled by CustomerExit or UserEntry it takes no iobj_name. The query tools bind a text variable named in a description when they save the query. To keep a variable out of the user's variable screen, set ready_for_input false.

Read a reusable BW Variable: reference characteristic, description, variable type, processing type, selection type, input type, input readiness, reusability, package and InfoArea. Use it after bw_create_variable to confirm what was stored — the modeling API accepts an enum literal it does not know, saves its default and still reports the object as consistent, so a create alone proves nothing about the processing or selection type. Reading the variable through a query does not answer this: a query resolves the technical name of a variable reference, never its definition.

Change a reusable BW Variable in place: description, input readiness, input type (optional / mandatory), selection type and processing type, and on a formula variable its default value, unit and currency. The UID stays the same, so references from queries, CKFs and structures survive the change — unlike the delete-and-recreate that was the only correction path before, which BW refuses as soon as anything references the variable, and deleting a query does not remove its reusable components either. The reference characteristic and the variable type cannot be changed: BW accepts such a write, reports it as consistent and keeps the old value, so both are rejected here instead of being sent. Read the result back with bw_get_variable.

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 and planning properties (decimals, scaling, hidden, sign inversion, input readiness, disaggregation, constant selection, local calculation) and exception aggregation, nest members and place them at a position, 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").

Manage the cell definitions of an existing BW Query that has two structures (one on each axis): add reference cells (make the value at an intersection of a member of each structure addressable), add formula cells at an intersection, add help cells (formula or selection cells outside the grid, used as reusable operands such as a unit-free denominator), change a cell's formula, description, decimals or scaling, and remove cells. Members and cells are addressed by description or id; bw_get_query lists the existing cells with the member descriptions they sit on. All operations are applied in a single save.

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 their field group (dimension) and, for InfoObject-bound fields, their name usage ("direct" or "unique_name" — a query finds a "unique_name" field only under "-"), the declared field groups, 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. Field groups and name usage: every field the tool creates goes into a field group (CHARACTERISTICS or KEYFIGURES unless dimension names another) and, when it is named after its InfoObject, uses that InfoObject directly by name — the form a query needs to find it. "update_fields" moves existing fields into a group and/or switches their name usage; "update_group" creates a group, changes its label or renames it. 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 from its metadata tables (ADT DataPreview, read-only; needs ADT authorization). The route for objects without a REST resource on this system. object_type → result: TRFN transformation with rules and routine code; DTPA DTP; ODSO classic DSO, CUBE InfoCube, MPRO MultiProvider (parts with their type) — each with load history; ADSO load history only; ANPR analysis process (nodes, field rules, routine code; "Z*" lists them); ISIP InfoPackage (a DataSource name lists its InfoPackages); RSPC process chain definition; RSPCLOG chain runs; PLSE planning function; PLSQ planning sequence; PLCR planning properties; PLDS data slices. Details per type are in the object_type parameter. Prefer the REST tool (bw_get_transformation, bw_get_dtp, …) where the system publishes one.

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 reporting resource of the modeling API is implemented — the REST route to query data, which a classic release publishes without implementing; BICS itself is present there, and InA clients reach it by their own route. 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, the formula both as a rendered string and as a structured tree (formula_tree) that bw_create_ckf and bw_update_ckf take back unchanged, the exception aggregation of the CKF (null for standard aggregation; same shape the write tools take), 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").

Create a reusable Calculated Key Figure (CKF) on an InfoProvider. The formula is passed as an operator/operand tree in the same node syntax bw_update_query_key_figures uses for "add_formula", so a tree read back from bw_get_ckf (field formula_tree) can be written again unchanged. Records to a transport when package and transport_request are given, and reports in "recorded_in" where the entry actually landed.

Change a reusable Calculated Key Figure. Two call forms: pass "formula" to replace the whole expression, or "operations" for targeted edits that leave the rest of the formula untouched — the usual case being "add another summand to a sum" without having to know or rebuild the existing formula. All operations are applied to one document and written in a single save, so a rejected operation leaves the stored formula unchanged rather than half edited.

Change a reusable Restricted Key Figure in place: description, base key figure and/or restrictions. The UID stays the same, so references from CKFs, structures and queries stay intact — unlike the delete-and-recreate that was the only correction path before, which is impossible once the RKF is referenced anywhere and blocked entirely on tiers where deletion is disabled. "restrictions" replaces the full set of characteristic restrictions when given.

Create a reusable key figure structure on an InfoProvider — the object reporting queries embed as an axis, so that one definition drives all of them. Members reference a reusable CKF/RKF or a basic key figure and can carry their own text.

Change a reusable structure: add, remove or re-configure members. The change reaches every query that embeds the structure — which is the point, and the reason this goes at the structure itself rather than through one query that happens to use it. All operations are applied to one document and written in a single save.

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.

Read the BW query statistics (RSDDSTAT) of any frontend, as RSRT statistics and ST03 show them, without SAP GUI. With query_name or provider: the executions in a time window (default the last 24 hours) — count, the last execution and its user, executions per user, min / median / p90 / max runtime (over the latest 5,000 when there are more), plus the breakdown of the slowest ones. With step_uid: one navigation step in full — BW runtime by layer, top events, records read and transferred, the effective "Operations in SAP HANA" setting and the data manager time per provider. Statistics must be switched on for the object (transaction RSDDSTAT). To measure one call of this server, use bw_query_data with_statistics instead.

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. The block characteristics — every characteristic that is not to be changed — are listed separately: the function runs once per combination of their values, so records that differ in one of them never meet in the same call.

Change an existing Planning Function (TLOGO PLSE): the characteristic usage (FIELDS_TO_BE_CHANGED / FIELD_FOR_CONDITIONS / NONE), the conditions, single-value parameter values (constant or variable, including the FOX code of a FORMULA function) and the description. Changes not passed stay as they are. The function is saved straight to the active version — there is no activation step. Before changing the code of a custom exit function, check the block characteristics with bw_get_planning_function: records meant to be combined in one call must not differ in any of them.

Create a Planning Function (TLOGO PLSE) of a given function type on an aggregation level. The server fills in the parameter skeleton of the function type and a usage of NONE for every characteristic; characteristic usage, conditions and parameter values can be passed right away and are applied after the create. Saved active — there is no activation step. Read an existing function of the same type with bw_get_planning_function to see which parameters a type has.

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 kind (planning function, or manual input: an input template that only opens its filter), the aggregation level, the planning function (planning service), and the filter name.

Read a currency translation type (TLOGO CTRT) or a unit conversion type (TLOGO UOMT): source and target (fixed, from the record or chosen when converting, from an InfoObject or a variable), and for a currency the exchange rate type, the exchange rate, the rate type specifics, inverse, and the time reference; for a unit the factor determination and its InfoObject. Without kind both types are tried.

Create a currency translation type (kind "currency", TLOGO CTRT) or a unit conversion type (kind "unit", TLOGO UOMT), saved straight to the active version — there is no activation step. Every option of the modeling tools is available. Source and target: data_dependent (the default; for a source the currency or unit of the record, for a target the one chosen when converting), fixed, infoobject or variable, each with name. Currency: exactly one of rate_type or rate_type_variable; optionally an exchange rate from an InfoObject, rate_specific, inverse, in_transformation_only, via_fi_modules (default true), and the time reference (default the current date). Unit: factors (default T006) and, for the InfoObject-based modes, factors_infoobject. The answer shows the object as stored, because the backend adjusts some combinations on save. A description is limited to 40 characters for a currency type and 60 for a unit type. Delete with bw_delete, object_type "ctrt" or "uomt".

Read a planning filter — the selection a planning sequence step or an input template works on. Returns its aggregation level, InfoArea, package, the restriction per characteristic (fixed values, ranges, exclusions) and the variables it uses with their type, processing and input settings. A sequence step names its filter (bw_get_planning_sequence).

Create a planning sequence with its steps in execution order: planning functions, each with the filter that selects its data, and input templates. Saved active. The InfoArea defaults to that of the aggregation level of the first step, the package to "$TMP".

Change a planning sequence: replace its steps with the list given, in that order, and/or change its description. To add, remove or move one step, read the sequence with bw_get_planning_sequence and pass the whole new list.

Create a planning filter on an aggregation level — the selection a planning sequence step or an input template works on — with its restrictions in the same call: fixed values, ranges and exclusions per characteristic, and characteristic variables. A variable is embedded in the filter as the modeling tools do. Saved active; read it back with bw_get_planning_filter.

Change a planning filter: set the values or the variable of a characteristic (replacing its current restriction), remove a restriction, or change the description. Restrictions not named stay as they are.

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. Errors come with their message number and long text (diagnosis, system response, procedure). For every failed step the step log is read as well: each error with its message variables and, for a runtime error in a routine, the class, method and line it was raised at — the actual cause when a transformation caught the error and left no short dump.

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.

Start a process chain once, now, as the BW/4HANA Cockpit does with "Execute" (asynchronous): the run goes to the background under the technical user of the chain, independent of its start condition, and its scheduling is left unchanged. The chain must be active. Returns the log ID of the run, its status and the messages of the steps reached so far. With wait_seconds the tool waits for the run to finish, checking every 5 seconds; otherwise it answers right after the start. Follow the run with bw_get_process_chain_run_detail (chain_id + the returned log_id) for step-level details and error long texts.

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.