Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev

bw_update_process_chain

Replace the steps and edges of an existing SAP BW/4HANA process chain while preserving its trigger and header, then optionally activate it. Handles stale ETags by reporting conflicts.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesProcess chain technical name (e.g. "CHAIN_NAME"). Case-insensitive.
edgesYesComplete replacement edge list. Use the step id or the literal "TRIGGER" for the start node. Status defaults: "neutral" when the source is "TRIGGER" or a collector (AND/OR/XOR); "positive" otherwise. For a branch edge out of a DECISION node, set sub_status to the branch EVENTNO ("01"/"02"); such edges are forced to "positive".
stepsYesComplete replacement step list. The TRIGGER (Start) node is implicit at index 0 — do not include it here. Same shape as in bw_create_process_chain.
activateNoIf true, activate the chain immediately after the update. Default false.
infoareaNoOptional new InfoArea. If omitted, the existing InfoArea is kept.
descriptionNoOptional new description. If omitted, the existing chain description is kept.
trigger_eventNoOptional event start-condition for the trigger (start type "E"). When omitted, an existing event start-condition is preserved and a non-event trigger stays immediate.
transport_requestNoOptional transport request to record the change into. Only relevant when the chain is in a transportable package (not $TMP). If the chain is transportable and exactly one request is available, it is chosen automatically; pass this to disambiguate when several are available. Ignored for $TMP (local) chains.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changedv1.4.0
    • addedInput schema / properties / steps / items / properties / local
      Added value: +{
      +  "description": "ABAP only. Call location. true (default) runs the program on this system (X_LOCAL). Only the default is verified.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / steps / items / properties / program
      Added value: +{
      +  "description": "ABAP program / report to execute (e.g. \"REPORT_NAME\"). Required when type is \"ABAP\". The call is stored as an inline variant in the chain — no separate variant object is created. Re-specify every existing ABAP step here, otherwise the replacement drops it; read the current program and report variant from bw_get_process_chain.",
      +  "type": "string"
      +}
    • addedInput schema / properties / steps / items / properties / program_description
      Added value: +{
      +  "description": "ABAP only. Optional report description (cosmetic).",
      +  "type": "string"
      +}
    • addedInput schema / properties / steps / items / properties / program_package
      Added value: +{
      +  "description": "ABAP only. Optional package of the report (cosmetic value-help enrichment; the server re-derives it when omitted).",
      +  "type": "string"
      +}
    • addedInput schema / properties / steps / items / properties / program_variant
      Added value: +{
      +  "description": "ABAP only. Optional ABAP report (SE38) selection variant name (e.g. \"VARIANT_NAME\"). Note this is a report variant, not the DECISION variant field above. Omitting it on an existing step silently drops the step's selection variant.",
      +  "type": "string"
      +}
    • addedInput schema / properties / steps / items / properties / synchronous
      Added value: +{
      +  "description": "ABAP only. Call mode. true (default) runs the program synchronously (X_SYNCHRON). Only the default is verified.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / steps / items / properties / type / description
      Previous value: -"Process type: \"DTP_LOAD\", \"ADSOACT\", \"ADSOREM\", \"CHAIN\", \"DECISION\", \"AND\", \"OR\", \"XOR\", or any BW process type string."New value: +"Process type: \"DTP_LOAD\", \"ADSOACT\", \"ADSOREM\", \"ABAP\", \"CHAIN\", \"DECISION\", \"AND\", \"OR\", \"XOR\", or any BW process type string."
    • addedInput schema / properties / steps / items / properties / variant_description
      Added value: +{
      +  "description": "ABAP only. Optional report-variant description (cosmetic).",
      +  "type": "string"
      +}
  2. Changed8 schema fields changedv1.2.0
    • changedInput schema / properties / edges / description
      Previous value: -"Complete replacement edge list. Use the step id or the literal \"TRIGGER\" for the start node. Status defaults: \"neutral\" when the source is \"TRIGGER\" or a collector (AND/OR/XOR); \"positive\" otherwise."New value: +"Complete replacement edge list. Use the step id or the literal \"TRIGGER\" for the start node. Status defaults: \"neutral\" when the source is \"TRIGGER\" or a collector (AND/OR/XOR); \"positive\" otherwise. For a branch edge out of a DECISION node, set sub_status to the branch EVENTNO (\"01\"/\"02\"); such edges are forced to \"positive\"."
    • addedInput schema / properties / edges / items / properties / sub_status
      Added value: +{
      +  "description": "Branch condition (DECISION out-edges only): the branch EVENTNO, e.g. \"01\" (THEN/JA) or \"02\" (ELSE/NEIN). Defaults to \"00\" (normal edge).",
      +  "type": "string"
      +}
    • changedInput schema / properties / steps / items / properties / description / description
      Previous value: -"Step display description (DTP_LOAD, CHAIN, and generic referenced steps)."New value: +"Step display description (DTP_LOAD, CHAIN, DECISION, and generic referenced steps)."
    • addedInput schema / properties / steps / items / properties / remDatastores
      Added value: +{
      +  "description": "Required when type is \"ADSOREM\" (DSO request cleanup). One entry per aDSO whose requests to clean up, each with its own cleanup action and request selection.",
      +  "items": {
      +    "properties": {
      +      "action": {
      +        "description": "Cleanup action code from the cockpit \"Bereinigungsaktion\" dropdown (single character). Observed: \"A\" = activate requests, \"C\" = remove old requests from the change log. The valid action depends on the aDSO type; an unsuitable action is rejected at activation.",
      +        "type": "string"
      +      },
      +      "allRequests": {
      +        "description": "Clean up all requests (ALL_REQUESTS). When true, the count/age selectors are ignored. Default false.",
      +        "type": "boolean"
      +      },
      +      "datastore": {
      +        "description": "aDSO technical name (e.g. \"ADSO_NAME\").",
      +        "type": "string"
      +      },
      +      "numberDays": {
      +        "description": "Remove requests older than N days (NUMBER_DAYS). Default 0.",
      +        "type": "number"
      +      },
      +      "numberRequests": {
      +        "description": "Keep the last N requests (NUMBER_REQUESTS); older ones are removed. Default 0.",
      +        "type": "number"
      +      },
      +      "packageSize": {
      +        "description": "Processing package size (PACKAGE_SIZE); 0 = server default.",
      +        "type": "number"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / steps / items / properties / type / description
      Previous value: -"Process type: \"DTP_LOAD\", \"ADSOACT\", \"CHAIN\", \"AND\", \"OR\", \"XOR\", or any BW process type string."New value: +"Process type: \"DTP_LOAD\", \"ADSOACT\", \"ADSOREM\", \"CHAIN\", \"DECISION\", \"AND\", \"OR\", \"XOR\", or any BW process type string."
    • addedInput schema / properties / steps / items / properties / variant
      Added value: +{
      +  "description": "Decision variant technical name to reference. Required when type is \"DECISION\".",
      +  "type": "string"
      +}
    • addedInput schema / properties / transport_request
      Added value: +{
      +  "description": "Optional transport request to record the change into. Only relevant when the chain is in a transportable package (not $TMP). If the chain is transportable and exactly one request is available, it is chosen automatically; pass this to disambiguate when several are available. Ignored for $TMP (local) chains.",
      +  "type": "string"
      +}
    • addedInput schema / properties / trigger_event
      Added value: +{
      +  "description": "Optional event start-condition for the trigger (start type \"E\"). When omitted, an existing event start-condition is preserved and a non-event trigger stays immediate.",
      +  "properties": {
      +    "event_id": {
      +      "description": "Event id, e.g. \"SAP_TEST\".",
      +      "type": "string"
      +    },
      +    "event_parameter": {
      +      "description": "Event parameter. Defaults to the chain name when omitted.",
      +      "type": "string"
      +    },
      +    "event_type": {
      +      "description": "Event type. Defaults to \"OtherEvent\".",
      +      "type": "string"
      +    },
      +    "only_once": {
      +      "description": "Start only once. Default false.",
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "event_id"
      +  ],
      +  "type": "object"
      +}
  3. Addedv0.9.1

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full disclosure burden and meets it thoroughly: the destructive replacement semantics ('a step left out is deleted'), the stale-ETag 412 behavior with explicit error reporting, preservation of the trigger node and existing event start-condition, the fact that on-error negative links are accepted but not emitted by default, and the support boundary for untested/unsupported step types. No annotation contradicts the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long (~700 words), but the structure is exemplary: purpose first, then the core behavioral contract (read → preserve → replace), the safety-critical warning, named alternatives, then step types and edge semantics. Every sentence carries context-dependent information and there is no tautology or filler; it merely approaches the upper limit of what a single description should hold and would benefit from pushing some step-type detail into the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description carries the entire burden of agent-safe invocation. It covers the destructive edge (dropped steps), transport state ($TMP vs transportable), trigger semantics (implicit vs explicit event start), verified vs. unverified generic types, the ETag conflict path, and the full step-type catalog with required fields. Nothing a calling agent needs to decide whether to call, or what to pass, is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds crucial semantics the schema cannot express: the TRIGGER node is implicit and must be omitted from the step list, default edge statuses derive from source node type ('neutral' for TRIGGER/collector, 'positive' otherwise), re-specifying every existing ABAP step is required or it is dropped, 'program_variant' is an SE38 report variant distinct from the DECISION variant field, and transport_request auto-selection rules when exactly one request is available. These details turn a syntactically correct call into a semantically correct one.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the operation concretely: 'Replace the step model (nodes and edges) of an existing Process Chain (RSPC)'. The verb 'Replace' plus the resource make the action unmistakable, and the description immediately contrasts with the create flow ('Use bw_create_process_chain to create a new chain; use this tool to update an existing one') and with targeted editing tools, so an agent cannot confuse it with any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to and when-not-to guidance. It names the alternative tools for small edits (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) and explains the deciding factor — those tools 'edit the server's own model in place and cannot drop a step they do not model.' This is textbook usage routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dnic-dev/bw-modeling-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server