Skip to main content
Glama
bw-modeling-mcp

bw-modeling-mcp

by dnic-dev

bw_append_process_chain_dtp

Add a DTP load step, optionally with its aDSO activation, to an existing process chain and place it before or after a step for correct serial execution.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "dtp": "<dtp>"
    },
    "name": "bw_append_process_chain_dtp"
  }
}

Input Schema

NameRequiredDescriptionDefault
dtpYesDTP variant name to append (e.g. "DTP_NAME").
nameYesProcess chain technical name (e.g. "CHAIN_NAME"). Case-insensitive.
afterNoInsert the block IN SERIES AFTER this node — it runs between the target and its former successors. Mutually exclusive with "before".
beforeNoInsert the block IN SERIES BEFORE this node: the target's incoming edges are rerouted into the block, then the block links to the target. Node reference — see the note below. Mutually exclusive with "after".
adsoactNoOptional aDSO name (e.g. "ADSO_NAME"). When given, an ADSOACT step activating this aDSO is added right after the DTP (per-DTP activation) and the two form one block that is placed together.
activateNoIf true, activate the chain immediately after the edit. Default false.
edge_modeNo"both" (default): add an on-success AND an on-error edge per link, so the successor runs even after a failed load ("always continue"). "success_only": add only the on-success edge. Match whatever the chain's existing steps use — the default adds an error edge that a success-only chain does not have.
predecessorNoUsed only when neither before nor after is given. Node to APPEND behind, or the literal "strand_end_auto" (default = terminal node closest to the trigger, ties → first). An append leaves the target's existing successors untouched, so the new block runs in parallel to them — pass before/after instead when it must run in sequence. Node reference forms (same for before / after / predecessor): a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or "PROGRAM/VARIANT"; a planning mode switch as "PLSWITCHL/ADSO_NAME" or "PLSWITCHP/ADSO_NAME"; "TRIGGER" or a collector type ("AND"/"OR"); or "#<index>" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use "#<index>" then.
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.

  1. Changed1 schema field changedv1.9.0
    • changedInput schema / properties / predecessor / description
      Previous value: -"Used only when neither before nor after is given. Node to APPEND behind, or the literal \"strand_end_auto\" (default = terminal node closest to the trigger, ties → first). An append leaves the target's existing successors untouched, so the new block runs in parallel to them — pass before/after instead when it must run in sequence. Node reference forms (same for before / after / predecessor): a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or \"PROGRAM/VARIANT\"; \"TRIGGER\" or a collector type (\"AND\"/\"OR\"); or \"#<index>\" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use \"#<index>\" then."New value: +"Used only when neither before nor after is given. Node to APPEND behind, or the literal \"strand_end_auto\" (default = terminal node closest to the trigger, ties → first). An append leaves the target's existing successors untouched, so the new block runs in parallel to them — pass before/after instead when it must run in sequence. Node reference forms (same for before / after / predecessor): a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or \"PROGRAM/VARIANT\"; a planning mode switch as \"PLSWITCHL/ADSO_NAME\" or \"PLSWITCHP/ADSO_NAME\"; \"TRIGGER\" or a collector type (\"AND\"/\"OR\"); or \"#<index>\" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use \"#<index>\" then."
  2. Changed5 schema fields changedv1.4.0
    • changedInput schema / properties / adsoact / description
      Previous value: -"Optional aDSO name (e.g. \"ADSO_NAME\"). When given, an ADSOACT step activating this aDSO is added right after the DTP (per-DTP activation)."New value: +"Optional aDSO name (e.g. \"ADSO_NAME\"). When given, an ADSOACT step activating this aDSO is added right after the DTP (per-DTP activation) and the two form one block that is placed together."
    • addedInput schema / properties / after
      Added value: +{
      +  "description": "Insert the block IN SERIES AFTER this node — it runs between the target and its former successors. Mutually exclusive with \"before\".",
      +  "type": "string"
      +}
    • addedInput schema / properties / before
      Added value: +{
      +  "description": "Insert the block IN SERIES BEFORE this node: the target's incoming edges are rerouted into the block, then the block links to the target. Node reference — see the note below. Mutually exclusive with \"after\".",
      +  "type": "string"
      +}
    • changedInput schema / properties / edge_mode / description
      Previous value: -"\"both\" (default): add an on-success and an on-error edge per link. \"success_only\": add only the on-success edge."New value: +"\"both\" (default): add an on-success AND an on-error edge per link, so the successor runs even after a failed load (\"always continue\"). \"success_only\": add only the on-success edge. Match whatever the chain's existing steps use — the default adds an error edge that a success-only chain does not have."
    • changedInput schema / properties / predecessor / description
      Previous value: -"Node to append behind: a DTP variant name, an aDSO whose ADSOACT node holds it, or the literal \"strand_end_auto\" (default). For \"strand_end_auto\" the terminal node closest to the trigger is chosen (ties → first)."New value: +"Used only when neither before nor after is given. Node to APPEND behind, or the literal \"strand_end_auto\" (default = terminal node closest to the trigger, ties → first). An append leaves the target's existing successors untouched, so the new block runs in parallel to them — pass before/after instead when it must run in sequence. Node reference forms (same for before / after / predecessor): a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or \"PROGRAM/VARIANT\"; \"TRIGGER\" or a collector type (\"AND\"/\"OR\"); or \"#<index>\" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use \"#<index>\" then."
  3. Addedv1.2.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: in-place read-modify-PUT semantics, idempotent skip if the DTP already exists, optional post-edit activation and verification, and explicit 412 ETag-stale failure meaning. It also warns that default edge_mode adds an error edge a success-only chain may not expect.

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?

Front-loaded with the core action and edit model, then organized into positioning, edge_mode, idempotency, and failure sections. It is dense but long, and several sentences restate what the schema's parameter descriptions already say (edge_mode, before/after), slightly inflating it.

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?

For a 9-parameter mutation tool with no annotations and no output schema, the description covers the edit model, side effects, idempotency, failure modes, and node-reference conventions enough for an agent to invoke it correctly without opening the schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: the series-vs-parallel semantics of before/after/predecessor, the block-unit behavior of adsoact, and the consequence of edge_mode on chain runtime behavior. Some of this is already in the schema descriptions, hence 4 rather than 5.

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 a specific verb and resource: add one DTP load step (plus an optional ADSO activation) to an existing Process Chain via in-place model edit. It is clearly distinguishable from siblings like bw_add_process_chain_program, bw_add_process_chain_plswitch, and bw_add_process_chain_edge.

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?

Gives explicit routing rules: use before/after when the new step must precede or follow an existing one, otherwise nothing is only appended and runs in parallel. It also names when edge_mode should be success_only (chains whose existing DTP steps have no error edge) versus the default 'both'.

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

Deploy Server

Other Tools