Skip to main content
Glama
bw-modeling-mcp

bw-modeling-mcp

by dnic-dev

bw_update_transformation

Maps source fields to target InfoObjects in SAP BW/4HANA transformations and updates rule types, formulas, constants, lookups, aggregation, or currency/unit conversion.

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. A rule on a key figure with a currency or unit takes the value over unconverted unless conversion is set. aggregation sets how the rule aggregates into a target key figure (SUM, MOV, MIN, MAX, NOP), alone or with a rule change. Returns a lock_handle for bw_activate.

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": {
      "transformation_name": "<transformation_name>",
      "target_infoobject": "<target_infoobject>"
    },
    "name": "bw_update_transformation"
  }
}

Input 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.
conversionNoCurrency or unit conversion for a direct rule on a key figure with a currency or unit (rule_type="direct"). Omitted or type "none": no conversion — the value is taken over as it is, which is also what direct, formula and constant rules on such a key figure get by default. Type "currency": convert with a currency translation type; type "unit": convert with a unit conversion type. The name is checked against the types defined on the system, and an unknown name is refused with the list of available ones. The source currency/unit comes from source_unit_field, else from the source key figure's own unit reference; a conversion type with a fixed source needs neither. The transformation's currency/unit handling is switched on.
aggregationNoAggregation type of the rule on a target key figure: "SUM" (summation), "MOV" (overwrite), "MIN", "MAX" or "NOP" (no aggregation). It decides what happens when several source records end up in one target record. Given alone (with transformation_name and target_infoobject only), it changes the aggregation and leaves the rule as it is; given with a rule change, both are saved together. Possible are MOV, NOP and the key figure's own aggregation (SUM for one without aggregation); MIN or MAX only for a key figure that aggregates that way, and MOV not into a data mart DataStore object. Anything else is refused with the possible values, as is a target field whose aggregation the target does not let a transformation override.
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. Changed1 schema field changedv1.10.0
    • changedInput schema / properties / aggregation / description
      Previous value: -"Aggregation type of the rule on a target key figure: \"SUM\" (summation), \"MOV\" (overwrite), \"MIN\", \"MAX\" or \"NOP\" (no aggregation). It decides what happens when several source records end up in one target record. Given alone (with transformation_name and target_infoobject only), it changes the aggregation and leaves the rule as it is; given with a rule change, both are saved together. Refused for a target field whose aggregation the target does not let a transformation override."New value: +"Aggregation type of the rule on a target key figure: \"SUM\" (summation), \"MOV\" (overwrite), \"MIN\", \"MAX\" or \"NOP\" (no aggregation). It decides what happens when several source records end up in one target record. Given alone (with transformation_name and target_infoobject only), it changes the aggregation and leaves the rule as it is; given with a rule change, both are saved together. Possible are MOV, NOP and the key figure's own aggregation (SUM for one without aggregation); MIN or MAX only for a key figure that aggregates that way, and MOV not into a data mart DataStore object. Anything else is refused with the possible values, as is a target field whose aggregation the target does not let a transformation override."
  2. Changed2 schema fields changedv1.7.1
    • addedInput schema / properties / aggregation
      Added value: +{
      +  "description": "Aggregation type of the rule on a target key figure: \"SUM\" (summation), \"MOV\" (overwrite), \"MIN\", \"MAX\" or \"NOP\" (no aggregation). It decides what happens when several source records end up in one target record. Given alone (with transformation_name and target_infoobject only), it changes the aggregation and leaves the rule as it is; given with a rule change, both are saved together. Refused for a target field whose aggregation the target does not let a transformation override.",
      +  "enum": [
      +    "SUM",
      +    "MOV",
      +    "MIN",
      +    "MAX",
      +    "NOP"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / conversion
      Added value: +{
      +  "description": "Currency or unit conversion for a direct rule on a key figure with a currency or unit (rule_type=\"direct\"). Omitted or type \"none\": no conversion — the value is taken over as it is, which is also what direct, formula and constant rules on such a key figure get by default. Type \"currency\": convert with a currency translation type; type \"unit\": convert with a unit conversion type. The name is checked against the types defined on the system, and an unknown name is refused with the list of available ones. The source currency/unit comes from source_unit_field, else from the source key figure's own unit reference; a conversion type with a fixed source needs neither. The transformation's currency/unit handling is switched on.",
      +  "properties": {
      +    "name": {
      +      "description": "Currency translation type or unit conversion type (e.g. \"CONV_TYPE\").",
      +      "type": "string"
      +    },
      +    "source_unit_field": {
      +      "description": "Source field holding the source currency or unit (e.g. \"CURRENCY_FIELD\").",
      +      "type": "string"
      +    },
      +    "type": {
      +      "enum": [
      +        "none",
      +        "currency",
      +        "unit"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "type"
      +  ],
      +  "type": "object"
      +}
  3. 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."
  4. 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"
      +}
  5. First observedv0.7.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and mostly delivers: it discloses that the server generates an ABAP class for routines, that formula rules generate no class and are evaluated natively, that unknown conversion or aggregation values are refused with the list of valid options, that currency/unit handling is switched on, that existing rules are overwritten, and that a lock_handle is returned for bw_activate. It does not address permissions, concurrency beyond the lock handle, or reversibility of the mode conversion.

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

Conciseness3/5

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

The opening sentence usefully front-loads the purpose, but the remainder is a dense run-on block of rule_type clauses with no list structure, mixing usage rules, side effects, and schema commentary in one paragraph. Content largely earns its place, but formatting makes it harder to scan than it needs to be.

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

Completeness3/5

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

For a 13-parameter mutation tool with no annotations or output schema, the description is substantial and covers the tricky interactions (formula, aggregation, conversion, unit_source_field). However it never explains transport behavior beyond the schema, nor the lookup_object parameters it exposes in the enum, leaving one of six enum branches undocumented in prose.

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 the baseline is 3; the description earns more by adding conditional semantics the schema lacks, notably that source_field is ignored for routine on StepDirect/StepInitial and for constant, that formula operands are auto-registered as sources, and that unit_source_field creates a combined key-figure plus unit rule with the target unit derived automatically.

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?

Opens with a specific verb and resource: 'Map a source field to a target InfoObject in a Transformation', and then enumerates the four rule_type modes it performs. It clearly delimits its own operational modes but never mentions the closely named siblings bw_set_transformation_routine, bw_set_transformation_expert_routine, or bw_delete_transformation_routine, so an agent cannot tell from the text whether routine editing belongs here or there.

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?

Gives explicit when-to-use conditions for each rule_type: routine requires source_field on StepNoUpdate but ignores it on StepDirect/StepInitial, constant ignores source_field, aggregation may be given alone or with a rule change. It also states defaults (rule_type=direct, no conversion). What is missing is guidance versus sibling tools that also manipulate transformation rules.

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