SAP Custom Code Remediation with Reviewable ABAP

Decision context

Custom-code remediation begins with coverage. A team needs to know which objects were analyzed, which source was unavailable, what target release and rule version were used, and which dependencies make a local edit unsafe. A list of findings without that boundary encourages false confidence.

Adranum ingests supported ATC and readiness results, ABAP source, abapGit packages, DDIC exports, and requirements. Deterministic rules generate reviewable diffs for supported patterns. The workbench can analyze, document, optimize, and translate code, but unsupported behavior fails closed rather than being represented as a complete transformation.

A generated package includes target artifacts, trace records, ABAP Unit and Gherkin tests, acceptance contracts, import order, and a manifest that binds every file to the package hash. Only the customer SAP runner can record compilation, runtime, and test success.

What the workflow must cover

• Coverage-aware analysis. Hash every supported source line and report parser, file, and object coverage. Keep unsupported or malformed inputs visible in the evidence set.
• Deterministic remediation. Apply versioned rules for supported findings and produce unified diffs. Preserve non-automatable findings for named technical review.
• Grounded ABAP workbench. Use customer requirements, dependencies, DDIC, and retrieved documents when explaining or generating code. Raw ABAP is excluded from third-party Copilot prompts by default.
• Validation-state honesty. Distinguish proposed, reviewed, packaged, installed, compiled, runtime-tested, and accepted states. A model response never advances technical validation.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Ingest ATC, readiness, source, and schema evidence.
2. Review coverage and dependency risk.
3. Generate supported diffs and document unsupported work.
4. Trace requirements and create impacted tests.
5. Package the exact files and validate them through the signed customer runner.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Object and source hashes
• Finding rule and severity
• Dependency consumers
• Unified remediation diff
• Reviewer rationale
• Package manifest
• Compile and runtime result
• Per-test output hash

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• Not every legacy construct can be translated safely.
• The workbench does not replace peer review or SAP transport controls.
• No output is labeled SAP-tested until the customer runner returns a valid signed result.

Buyer checklist

• What percentage of the supplied source was parsed?
• Are remediation rules deterministic and versioned?
• What happens to unsupported behavior?
• Can a reviewer trace each generated file to source and requirement?
• Who controls compile and runtime validation?