1. Business problem

ABAP Cloud deployment is not only a code-generation problem. Enterprise teams need a reliable way to move from an AI or coding-agent instruction to a SAP ABAP Cloud outcome while preserving authentication boundaries, target-system constraints, activation evidence and recovery options.

2. Why ABAP Cloud deployment is more than code generation

Generated source is only one part of the delivery chain. A useful deployment architecture must address repository discovery, object creation, activation, diagnostics, semantic correctness, bounded retry and evidence preservation.

3. Shared target outcome

Both architectures target the same outcome: controlled ABAP Cloud delivery into SAP with evidence that can be reviewed after execution.

4. Architecture 1 overview

ABAP4C Cloud Deployment Pipeline — Architecture 1 uses a standards-led route:

AI or Coding Agent → VS Code / Cline / Python → Standard ADT MCP Server in Eclipse → SAP ADT tools → ABAP Cloud → audit and execution evidence.

Its architecture name is Standard ADT MCP.

5. Architecture 2 overview

ABAP4C Cloud Deployment Pipeline — Architecture 2: Capella uses a governed bridge route:

AI or Coding Agent → VS Code / Cline / Python → Capella Control Plane → Local Eclipse Bridge → ADT / RIS / DDIC execution → SAP ABAP Cloud → receipts, evidence and rollback controls.

Its architecture name is Capella Governed Bridge.

6. Side-by-side flow

Concern Architecture 1 — Standard ADT MCP Architecture 2 — Capella Governed Bridge
Primary route Direct MCP provider route through Eclipse ADT Dedicated control plane plus local Eclipse bridge
Governance Provider/tool contract and external release discipline Built-in plan, receipt, approval and bounded recovery model
Session model Uses the Eclipse/ADT provider context Uses authenticated Eclipse workspace through a governed local bridge
Evidence Tool results and audit evidence Immutable receipts, manifests, recovery references and deployment evidence
Best fit Standards-led exploration and direct provider capability validation Bounded live execution, recovery-sensitive workflows and stricter release control

7. AI-agent relationship

In both architectures, the AI or coding agent is not the authority for SAP correctness. The agent proposes or orchestrates work; deterministic validation, SAP responses and evidence remain authoritative.

8. Cline / VS Code / Python relationship

Cline, VS Code and Python can act as the operator and automation layer. They do not remove the need for target-system verification, source review or human approval where a governed write is involved.

9. Eclipse and ADT relationship

Both architectures depend on Eclipse ADT as a trusted SAP development context. Architecture 1 reaches SAP through the Standard ADT MCP provider. Architecture 2 places a governed bridge and control plane in front of Eclipse/ADT execution.

10. Authentication basis

Authentication remains anchored in the approved Eclipse ADT context. The website description does not expose credentials, tokens, tenant secrets or private runtime data.

11. Session handling

Architecture 1 depends on the provider and Eclipse context. Architecture 2 adds explicit session-state handling in the bridge and separates bridge readiness from SAP write success.

12. Object discovery

Architecture 1 uses provider-exposed discovery and ADT tooling. Architecture 2 can combine ADT repository discovery, RIS search and DDIC-oriented evidence where those routes are live-verified.

13. Creation flow

Architecture 1 focuses on provider-exposed creation paths such as abap_creation where supported. Architecture 2 creates only through reviewed, governed plans and bounded bridge execution.

14. Activation flow

Architecture 1 can use provider activation routes such as abap_activate_objects where verified. Architecture 2 treats activation as a governed stage with receipt and recovery context.

15. Error handling

Architecture 1 surfaces tool, provider and ADT errors. Architecture 2 adds orchestration state, correction boundaries and read-only reconciliation after uncertain mutation.

16. Retry and recovery

Architecture 1 should avoid unsupported retries and distinguish protocol success from semantic correctness. Architecture 2 is designed around controlled retry, bounded recovery and rollback references.

17. Evidence and auditability

Both architectures must preserve evidence. Architecture 2 places more emphasis on immutable receipts, plan hashes, approval boundaries and recovery evidence.

18. Target-system variation

Neither architecture should claim universal object support. Verified object types, provider-schema constraints, activation-path constraints and target-system limitations must remain visible.

19. Governance model

Architecture 1 is lightweight and standards-led. Architecture 2 adds a control plane for review, policy, approval, execution receipts and recovery.

20. Strengths of Architecture 1

  • Direct standards-led path.
  • Lower orchestration overhead.
  • Useful for provider capability discovery.
  • Good fit where the Standard ADT MCP provider exposes the required operations.

21. Strengths of Architecture 2

  • Stronger execution governance.
  • Explicit evidence receipts.
  • Bounded recovery model.
  • Better fit where session handling, reconciliation or controlled write boundaries matter.

22. Constraints of Architecture 1

  • Provider schema can limit available operations.
  • Activation paths must be verified.
  • Generated-object discovery is not the same as activated-object proof.
  • Protocol success does not prove semantic correctness.

23. Constraints of Architecture 2

  • Additional control plane and bridge complexity.
  • Bridge readiness does not guarantee SAP write success.
  • Live-verified and unverified object types must remain separate.
  • It should not be presented as universally superior.

24. Selection guidance

Choose Architecture 1 when the direct Standard ADT MCP provider path is verified for the target operation and lightweight standards-led execution is sufficient. Choose Architecture 2 when governance, recovery, receipts, bounded retry and target-system variation require a dedicated control plane.

25. Why both architectures matter

Same SAP outcome. Different execution architecture. Different governance and recovery model. Both are valuable depending on target-system and provider constraints.

26. Verification boundaries

This comparison does not claim universal ABAP object support, universal testing intelligence or provider-independent SAP write success. It separates mock, controlled, integrated and live evidence.

The MCP/SAP Testing publication has a verified LinkedIn source. ABAP4C-specific LinkedIn relationships remain LINK_PENDING until an exact public URL is approved.

Related YouTube actions remain LINK_PENDING until exact public video URLs are verified. The website does not render broken video actions for pending links.

30. Detailed future direction

Future work should expand verified object coverage, compare provider and bridge behaviour across target systems, improve recovery evidence and keep Architecture 1 and Architecture 2 clearly named so Capella remains Architecture 2 rather than a separate unrelated fourth pipeline.