bw_append_process_chain_dtp
Add a DTP load step (optionally with DSO activation) to an existing BW process chain, placing it in series before or after a target step or appending it in parallel. Automatically manages edges and chain activation.
Instructions
Add one DTP load step (optionally followed by its own DSO activation step) to an existing Process Chain (RSPC), via the BW/4HANA Cockpit REST API. In-place edit: reads the current model, inserts the node(s)/edge(s)/inline variant, and PUTs it back — the caller does not supply the full model. Positioning: pass "before" to place the block IN SERIES ahead of an existing step (the target's incoming edges are rerouted into the block, then the block links to the target), or "after" to place it in series between a step and its successors. With neither, the block is only APPENDED behind the strand end closest to the trigger (or behind "predecessor") — the target keeps its existing successors, so the block ends up running in PARALLEL to them, not ahead of them. Use before/after whenever the new step must complete before an existing one starts. When adsoact is given, the whole DTP → activation block is placed as one unit. edge_mode defaults to "both", which adds an on-success AND an on-error edge per link ("always continue" — the successor runs even after a failed load). Pass "success_only" for an on-success edge only, which is what a chain whose existing DTP steps have no error edge expects. Idempotent: if the DTP is already a node in the chain, it is skipped without writing. Optionally activates afterwards and then verifies that no collector was inserted and no extra strand appeared. A 412 on the PUT means the ETag was stale (chain modified between read and write); the error reports this explicitly.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| dtp | Yes | DTP variant name to append (e.g. "DTP_NAME"). | |
| name | Yes | Process chain technical name (e.g. "CHAIN_NAME"). Case-insensitive. | |
| after | No | Insert the block IN SERIES AFTER this node — it runs between the target and its former successors. Mutually exclusive with "before". | |
| before | No | Insert the block IN SERIES BEFORE this node: the target's incoming edges are rerouted into the block, then the block links to the target. Node reference — see the note below. Mutually exclusive with "after". | |
| adsoact | No | Optional aDSO name (e.g. "ADSO_NAME"). When given, an ADSOACT step activating this aDSO is added right after the DTP (per-DTP activation) and the two form one block that is placed together. | |
| activate | No | If true, activate the chain immediately after the edit. Default false. | |
| edge_mode | No | "both" (default): add an on-success AND an on-error edge per link, so the successor runs even after a failed load ("always continue"). "success_only": add only the on-success edge. Match whatever the chain's existing steps use — the default adds an error edge that a success-only chain does not have. | |
| predecessor | No | Used only when neither before nor after is given. Node to APPEND behind, or the literal "strand_end_auto" (default = terminal node closest to the trigger, ties → first). An append leaves the target's existing successors untouched, so the new block runs in parallel to them — pass before/after instead when it must run in sequence. Node reference forms (same for before / after / predecessor): a DTP or process-variant name; an aDSO held by an ADSOACT/ADSOREM node; the program of an ABAP step, or "PROGRAM/VARIANT"; "TRIGGER" or a collector type ("AND"/"OR"); or "#<index>" using the step numbers printed by bw_get_process_chain. An ambiguous name is rejected with the candidates listed — use "#<index>" then. | |
| transport_request | No | Optional transport request to record the change into. Only relevant when the chain is in a transportable package (not $TMP). If the chain is transportable and exactly one request is available, it is chosen automatically; pass this to disambiguate when several are available. Ignored for $TMP (local) chains. |