Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_update_transformation

Update a BW transformation's mapping: assign source fields to target InfoObjects and change existing rules to direct, routine, formula, constant, or lookup, with combined quantity/currency support.

Instructions

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. Returns a lock_handle for bw_activate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formulaNoFormula expression for rule_type="formula" (required). Source fields are referenced by their technical field name: use /BIC/FIELDNAME for custom InfoObjects (e.g. "/BIC/FIELD_NAME + 10"), or the direct field name for standard InfoObjects. Operators: +, -, *, /. Functions: IF, ABS, CONCATENATE, DATE_YEAR, etc. Comparison operators < > <= >= <> are supported (escaping is handled automatically, in either spelling). Every operand of the expression is wired up as a source of the rule; operands that name a source-segment field are recognised in the expression itself, so a multi-operand formula works without listing them.
rule_typeNoRule type to assign. "direct" (default): maps source field directly (StepDirect). "routine": converts the rule to an AMDP field routine (StepRoutine) — the server generates the ABAP class automatically. "formula": writes the rule as a formula rule (StepFormula) — requires the formula parameter; also used to change the formula text of an existing formula rule. "constant": sets a fixed constant value (StepConstant) — requires the constant_value parameter, source_field is ignored. "lookup": converts the rule to a StepRead (Lookup) rule — requires lookup_object and lookup_object_type. "no_update": reverts any existing mapping back to StepNoUpdate (no mapping, field stays empty). IMPORTANT: AMDP SQLSCRIPT methods only allow ASCII 7-bit characters — no German umlauts or special symbols in code or comments.
transportNoTransport request number (e.g. DEVK900123). Only required if the BW system requires transport assignment.
source_fieldNoSource field name in the source segment (e.g. "FIELD_NAME"). Required for rule_type="direct" if the existing rule has no source mapping. Also required for routine/formula when the target has no source mapping yet (StepNoUpdate). Required for rule_type="lookup".
lookup_objectNoName of the InfoObject or aDSO to read from (Nachlese-Objekt). Required for rule_type="lookup".
constant_valueNoConstant value for rule_type="constant" (required). The value is written as-is into the target field during data loading. Example: "X" for a flag field, "USD" for a currency field.
target_infoobjectYesTarget InfoObject name in the target segment (e.g. "IOBJ_NAME").
unit_source_fieldNoSource unit/currency field for a COMBINED key-figure + unit/currency direct rule (rule_type="direct"). When set, target_infoobject is the key figure and this is the source field that fills its unit or currency. The target unit/currency field is derived automatically from the key figure's unit reference in the aDSO (the target key figure must reference a unit/currency field). The standalone unit/currency rule is folded into the combined rule and the transformation's currency/unit handling is switched on. Example: target_infoobject="QUANTITY", unit_source_field="QUANTITYUNIT".
lookup_object_typeNoType of the lookup object. "IOBJ" for InfoObject, "ADSO" for aDSO. Required for rule_type="lookup".
transformation_nameYesTransformation name (UUID-like key).
additional_source_fieldsNoAdditional source fields for rule_type="formula" when the formula references more than one source field. Combined with source_field, all listed fields are registered as inputs on the StepFormula rule — alongside the operands read out of the formula itself, so this is only needed for a field the expression does not name under its source-segment name. Example: ["QUANTITY_SOLD", "COST_PER_UNIT"].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.0
    • changedInput schema / properties / additional_source_fields / description
      Previous value: -"Additional source fields for rule_type=\"formula\" when the formula references more than one source field. Combined with source_field, all listed fields are registered as inputs on the StepFormula rule. Example: [\"QUANTITY_SOLD\", \"COST_PER_UNIT\"]."New value: +"Additional source fields for rule_type=\"formula\" when the formula references more than one source field. Combined with source_field, all listed fields are registered as inputs on the StepFormula rule — alongside the operands read out of the formula itself, so this is only needed for a field the expression does not name under its source-segment name. Example: [\"QUANTITY_SOLD\", \"COST_PER_UNIT\"]."
    • changedInput schema / properties / formula / description
      Previous value: -"Formula expression for rule_type=\"formula\" (required). Source fields are referenced by their technical field name: use /BIC/FIELDNAME for custom InfoObjects (e.g. \"/BIC/FIELD_NAME + 10\"), or the direct field name for standard InfoObjects. Operators: +, -, *, /. Functions: IF, ABS, CONCATENATE, DATE_YEAR, etc. Comparison operators < > <= >= <> are supported (will be XML-escaped automatically)."New value: +"Formula expression for rule_type=\"formula\" (required). Source fields are referenced by their technical field name: use /BIC/FIELDNAME for custom InfoObjects (e.g. \"/BIC/FIELD_NAME + 10\"), or the direct field name for standard InfoObjects. Operators: +, -, *, /. Functions: IF, ABS, CONCATENATE, DATE_YEAR, etc. Comparison operators < > <= >= <> are supported (escaping is handled automatically, in either spelling). Every operand of the expression is wired up as a source of the rule; operands that name a source-segment field are recognised in the expression itself, so a multi-operand formula works without listing them."
    • changedInput schema / properties / rule_type / description
      Previous value: -"Rule type to assign. \"direct\" (default): maps source field directly (StepDirect). \"routine\": converts the rule to an AMDP field routine (StepRoutine) — the server generates the ABAP class automatically. \"formula\": converts the rule to a formula rule (StepFormula) — requires the formula parameter. \"constant\": sets a fixed constant value (StepConstant) — requires the constant_value parameter, source_field is ignored. \"lookup\": converts the rule to a StepRead (Lookup) rule — requires lookup_object and lookup_object_type. \"no_update\": reverts any existing mapping back to StepNoUpdate (no mapping, field stays empty). IMPORTANT: AMDP SQLSCRIPT methods only allow ASCII 7-bit characters — no German umlauts or special symbols in code or comments."New value: +"Rule type to assign. \"direct\" (default): maps source field directly (StepDirect). \"routine\": converts the rule to an AMDP field routine (StepRoutine) — the server generates the ABAP class automatically. \"formula\": writes the rule as a formula rule (StepFormula) — requires the formula parameter; also used to change the formula text of an existing formula rule. \"constant\": sets a fixed constant value (StepConstant) — requires the constant_value parameter, source_field is ignored. \"lookup\": converts the rule to a StepRead (Lookup) rule — requires lookup_object and lookup_object_type. \"no_update\": reverts any existing mapping back to StepNoUpdate (no mapping, field stays empty). IMPORTANT: AMDP SQLSCRIPT methods only allow ASCII 7-bit characters — no German umlauts or special symbols in code or comments."
  2. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / unit_source_field
      Added value: +{
+  "description": "Source unit/currency field for a COMBINED key-figure + unit/currency direct rule (rule_type=\"direct\"). When set, target_infoobject is the key figure and this is the source field that fills its unit or currency. The target unit/currency field is derived automatically from the key figure's unit reference in the aDSO (the target key figure must reference a unit/currency field). The standalone unit/currency rule is folded into the combined rule and the transformation's currency/unit handling is switched on. Example: target_infoobject=\"QUANTITY\", unit_source_field=\"QUANTITYUNIT\".",
+  "type": "string"
+}
  3. First observedv0.7.0

TDQS

A4.2/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 burden of behavioral disclosure, and it does so comprehensively. It explains that direct changes rule types, formula rules are evaluated natively with no ABAP class generated, operands are auto-registered as sources, source_field may be ignored depending on rule_type, and unit_source_field creates a combined key-figure/unit rule. It also discloses the returned lock_handle for bw_activate, which is valuable behavioral context.

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 densely informative, which is justified given the tool has 11 parameters and multiple rule types. It is front-loaded with the primary purpose, then expands into rule_type-specific behavior and important caveats. It could be improved with bullet structure or shorter sentences, but every sentence contributes meaningful information.

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

Completeness4/5

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

Given the complexity of the tool and the absence of an output schema, the description covers most essential behavior: rule conversions, parameter dependencies, combined unit/currency rules, and the activation lock_handle. The schema fills in lookup and no_update details, so the total tool definition is nearly complete. Minor gaps remain around transport/activation prerequisites and explicit alternatives to sibling tools.

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 description coverage is 100%, so the schema already documents all parameters well. The description adds meaningful cross-parameter semantics such as when source_field is required versus ignored, how formula operands are auto-wired, and how unit_source_field folds a unit rule into a combined rule. It does not substantially cover lookup and no_update in the main narrative, though the schema does, so there is some reliance on the schema.

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

Purpose4/5

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

The description begins with a specific action: map a source field to a target InfoObject in a Transformation or convert existing rules to routine/formula/constant rules. This clearly identifies the resource and the operation, and the rule_type breakdown makes the tool's scope concrete. It does not explicitly distinguish itself from closely named sibling tools like bw_set_transformation_routine, so it stops short of full sibling differentiation.

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

Usage Guidelines4/5

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

The description gives clear context for when each rule_type applies and which parameters are required, ignored, or conditionally relevant. It also explains side-behavior like returning a lock_handle for later activation. However, it does not explicitly say when to prefer this tool over related siblings such as bw_set_transformation_routine or bw_delete_transformation_routine.

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