Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev

bw_create_process_chain

Create SAP BW/4HANA process chains by specifying steps and edges, including DTP loads, DSO activation, decisions, and collectors, with optional activation after creation.

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

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. For a branch edge out of a DECISION node, set sub_status to the branch EVENTNO ("01"/"02"); such edges are forced to "positive".
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), ADSOREM (requires remDatastores array), CHAIN (requires object = sub-chain name), DECISION (requires variant = decision variant 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.
trigger_eventNoOptional event start-condition for the trigger (start type "E"). Omit for the default immediate start (start type "I").
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses important behaviors: the TRIGGER node is implicit (index 0), edge status defaults, collectors require no extra fields, and supported step types. It also mentions what is not supported and prerequisites. However, it does not describe return values or error handling, which is a minor gap given the lack of an output schema.

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 but dense with necessary information. It is front-loaded with the main action and then provides details on step types, edges, and prerequisites. While it could be more structured, every sentence adds value for a complex tool with many parameters and nested objects.

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 the tool's complexity (7 parameters, 5 required, nested objects) and 100% schema coverage, the description is remarkably complete. It covers step type definitions, edge defaults, the implicit TRIGGER, prerequisites, unsupported types, and event-based triggers. The agent has sufficient information to construct the process chain correctly.

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. The description adds value beyond the schema by explaining the implicit TRIGGER, edge default rules, step type requirements (e.g., collectors need no extra fields), and prerequisites like creating DTPs and decision variants first. These details help the agent construct valid parameters correctly.

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 the tool's purpose: 'Create a Process Chain (RSPC) via the BW/4HANA Cockpit REST API.' It details the construction from steps and edges, and activation option. It differentiates from siblings like bw_create_dtp and bw_activate_process_chain by explaining that DTPs must be created first and that this tool builds the chain around them.

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?

The description provides explicit guidance on when to use this tool versus alternatives. It states 'For two-step DTP loading always use bw_create_dtp first; this tool builds the process chain around existing DTPs.' It also advises creating decision variants with bw_create_decision_variant before use. It notes unsupported types and untested paths, giving clear when-not guidance.

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