Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev

bw_update_transformation

Maps source fields to target InfoObjects and converts transformation rules to routines, formulas, constants, or lookups in SAP BW/4HANA modeling.

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.

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.
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. Refused for 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. 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"
      +}
  2. 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."
  3. 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"
      +}
  4. 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, the description carries the full burden and does so well: it discloses that a lock_handle is returned for bw_activate, that the server generates the ABAP class for routines, that an unknown conversion name is refused with the list of valid ones, that operands are auto-registered as sources, and the ASCII 7-bit AMDP limitation.

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 purpose and default behavior are front-loaded in the first sentence, and the rule_type breakdown follows logically. It is dense and repeats some parameter detail already present in the schema, but nearly every sentence carries cross-parameter semantics rather than pure duplication.

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?

For a 13-parameter tool with a nested conversion object and no output schema, the description covers the operational behavior thoroughly enough to invoke it correctly. It omits essentially nothing critical, though some error-handling beyond the conversion-case refusal is undocumented.

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, but the description adds real cross-parameter meaning the schema alone doesn't convey (e.g. source_field being ignored for direct/constant, unit_source_field creating a combined key-figure+unit rule, formula requiring formula/additional_source_fields). It goes beyond restating field docs.

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 opening sentence states a specific verb and resource: mapping a source field to a target InfoObject, or converting a rule to a StepRoutine/StepFormula. The multiple rule_type modes are enumerated precisely. It does not explicitly name siblings (e.g. bw_create_transformation, bw_set_transformation_routine) to route the agent, which keeps it short of a 5.

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 per-mode conditions: direct for StepNoUpdate/StepInitial, routine requires source_field on StepNoUpdate, constant ignores source_field, formula needs the formula param, etc. This is strong in-tool guidance, but there is no explicit when-to-use-this-vs-alternative-tool routing against the transformation siblings.

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