/adt-api-discovery

name: adt-api-discovery
description: >-
  Investigate SAP ADT REST API endpoints. Use when the user asks about ADT API endpoints,
  request/response XML formats, content types, or how a specific ADT feature works under the hood.
  Teaches how to trace from discovery documents → RES_APP classes → handler classes →
  Simple Transformations → XML schemas. Requires the abapfs_export_adt_discovery tool output files
  and standard ABAP tools (abapfs_get_object_source, abapfs_search_objects, abapfs_search_object_source).
argument-hint: '[what ADT endpoint or feature to investigate]'
user-invocable: true
disable-model-invocation: false

ADT API Discovery — Skill

You are investigating SAP ADT REST API endpoints. Your goal is to determine the full HTTP contract for any endpoint: URL, HTTP methods, request/response XML format, content types, and headers.

Prerequisites

Before using this skill, run the `abapfs_export_adt_discovery` tool with the target `connectionId`. This creates a folder with markdown files containing the raw discovery data. Read these files first.

The ADT Architecture

Every ADT REST endpoint exists because of this chain:

SICF node: /sap/bc/adt
  └── Handler: CL_ADT_WB_RES_APP
        └── BAdI: BADI_ADT_REST_RFC_APPLICATION
              └── RES_APP class (inherits CL_ADT_DISC_RES_APP_BASE or CL_ADT_RES_APP_BASE)
                    └── register_resources() method
                          ├── registry->register_discoverable_resource(url, handler_class, ...)
                          ├── registry->register_resource(template, handler_class)
                          └── collection->register_disc_res_w_template(relation, template, handler_class)
                                └── Handler class (inherits CL_ADT_REST_RESOURCE)
                                      ├── GET/POST/PUT/DELETE method overrides
                                      ├── Content handler factory → get_handler_for_xml_using_st()
                                      └── response->set_body_data() / request->get_body_data()

Step-by-Step Investigation Process

Step 1: Find the endpoint in discovery

Search `workspaces.md` for the URL or keyword. This gives you the collection `href` and any template links (URL templates with parameters, relations, content types).

If the endpoint isn't in discovery, it may be a **hidden resource** — registered via `register_resource()` instead of `register_discoverable_resource()`. You'll find it in Step 2.

Step 2: Find the RES_APP class

The RES_APP class is what registers the endpoint. To find which one:

**Option A — Match by URL pattern**: The discovery URL `/sap/bc/adt/oo/classes` is registered by a RES_APP whose `register_resources()` method contains that URL. Search for it:

Use abapfs_search_object_source on RES_APP classes from res-app-classes.md, searching for the URL segment (e.g., '/oo/classes' or '/datapreview/')

**Option B — Check RES_APP class names**: The `res-app-classes.md` file lists all RES_APP classes with descriptions. Class names often hint at the feature area (e.g., `CL_ADT_DATAPREVIEW_RES_APP` → data preview, `CL_OO_ADT_RES_APP` → OO classes).

**Option C — Use `get_application_title()`**: Each RES_APP has a method `get_application_title()` that returns a title matching the discovery workspace title. Read the method source to match.

Step 3: Read `register_resources()` to find the handler class

Use `abapfs_get_object_source` to read the RES_APP class source. Look for three registration patterns:

" Pattern 1 — Discoverable resource (in /sap/bc/adt/discovery):
registry->register_discoverable_resource(
  url             = '/oo/classes'
  handler_class   = if_oo_adt_res_class_co=>co_class_name
  description     = 'Classes'
  category_scheme = ...
  category_term   = ...
  accepted_types  = ... ).

" Pattern 2 — Hidden resource (NOT in discovery):
registry->register_resource(
  template      = '/oo/classes/{classname}'
  handler_class = if_oo_adt_res_class_co=>co_class_name ).

" Pattern 3 — Template link on a collection:
classrun_col->register_disc_res_w_template(
  relation      = 'http://www.sap.com/adt/relations/oo/classrun'
  template      = '/oo/classrun/{classname}{?profilerId}'
  type          = if_rest_media_type=>gc_text_plain
  handler_class = if_oo_adt_res_classrun_co=>co_class_name ).

Step 4: Resolve the handler class name

The `handler_class` parameter is almost always a **constant reference** like `if_oo_adt_res_class_co=>co_class_name`. You need to resolve it:

1. Identify the interface/class before `=>` (e.g., `IF_OO_ADT_RES_CLASS_CO`) 2. Read that interface's source with `abapfs_get_object_source` 3. Find `CONSTANTS co_class_name TYPE ... VALUE 'CL_OO_ADT_RES_CLASS'`

**Naming convention**: Handler classes typically have a companion `*_CO` interface that holds all constants:

• `IF_OO_ADT_RES_CLASS_CO` → constants for `CL_OO_ADT_RES_CLASS`
• `IF_ADT_DATAPREVIEW_RES_CO` → constants for `CL_ADT_DATAPREVIEW_RES`

These contain: `co_class_name`, `co_accept_header_*`, `co_content_type_*`, `co_st_*`, `co_root_*`, `co_uri_*`

Step 5: Determine HTTP methods

Read the handler class source. The base class `CL_ADT_REST_RESOURCE` defines GET/POST/PUT/DELETE methods that all raise `cx_adt_res_meth_not_supported` by default. A handler **overrides only the methods it supports**:

METHODS get  REDEFINITION.    " → GET is supported
METHODS post REDEFINITION.    " → POST is supported
" PUT and DELETE are NOT redefined → not supported

Search for `REDEFINITION` in the class definition section.

Step 6: Find Simple Transformations (XML schema)

The handler class uses `CL_ADT_REST_CNT_HDL_FACTORY` to create content handlers from Simple Transformations. Search the handler source for:

cl_adt_rest_cnt_hdl_factory=>get_instance( )->get_handler_for_xml_using_st(
  st_name      = co_st_name           " → resolve to e.g. 'ST_DATA_PREVIEW'
  root_name    = co_root_name