Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev

bw_create_process_chain

Creates a SAP BW/4HANA process chain by defining steps and edges, supporting DTP loads, DSO activation, sub-chains, and collectors.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesProcess chain technical name, uppercase, max 30 characters (e.g. "CHAIN_NAME").
edgesYesDirected edges connecting steps. 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.
stepsYesOrdered list of steps. The TRIGGER (Start) node is implicit at index 0 — do not include it here. Each step has a caller-chosen id used for edge wiring. Step types: DTP_LOAD (requires dtp field), ADSOACT (requires datastores array), CHAIN (requires object = sub-chain name), AND / OR / XOR (collector, no extra fields), or any other BW process type (requires object field).
activateNoIf true, activate the chain immediately after creation. Default false.
infoareaYesInfoArea to file the chain under (e.g. "AREA_NAME").
descriptionYesShort description / label for the process chain.
Behavior5/5

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

Discloses the two-step creation approach, implicit TRIGGER node, default edge statuses, and that generic referenced steps may work but are untested. No annotations are present, so the description fully carries the transparency burden.

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 lengthy but well-structured, starting with the core purpose, then detailing steps, edges, and limitations. It is front-loaded and logically organized, though some sentences could be more concise.

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?

Covers all aspects: creation process, step types, edge behavior, prerequisites (bw_create_dtp), and unsupported types. No output schema exists, but the description sufficiently explains what the tool does and its limitations.

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%, but the description adds significant context: explains the implicit TRIGGER, required fields per step type, and edge status defaults. This goes beyond the parameter descriptions in the schema, providing a richer understanding.

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?

The description clearly states it creates a Process Chain via the BW/4HANA Cockpit REST API, specifying the build process (skeleton then full model) and optional activation. It distinguishes from siblings like bw_activate_process_chain and bw_update_process_chain by describing the full creation workflow.

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?

Explicitly instructs to use bw_create_dtp first for two-step DTP loading, lists supported step types, and highlights unsupported types (e.g., program execution, OS command). Also clarifies edge behavior and that on-error links are not emitted by default.

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