Authenticate with the ABAP system. Use it to recover a dead session; read-only calls now recover on their own.

Terminate the ABAP session and clear its cookies. WARNING: this client cannot log in again afterwards - the server process has to be restarted. To just release the session use dropSession.

Clear the local session cache (releases held locks server-side; the next call logs on again).

Which transport request a change to this object would go into, and which ones are available for it - what ADT asks before it opens the transport dialog. Worth calling before a write outside $TMP, because a write with no request fails at the last step. Mind the difference the backend does not spell out: a REQUEST is what a write takes, a task inside it is refused with "not a change request".

Create a workbench request. It becomes yours and stays open until it is released, so create one per piece of work rather than per object, and reuse the number for every write that belongs together. Ask first if the user has a request in mind - an unwanted request is visible to the whole team and has to be deleted by hand.

Whether this system has transport configurations at all - the check before offering the organizer tools.

The transport configurations available in the organizer, with their ids - what transportsByConfig takes.

One transport configuration by URI, with everything it defines.

Change a transport configuration - which requests a user sees in the transport organizer. It is shared setup, not a per-call filter.

Create a transport configuration for the organizer. Shared setup; most work needs only createTransport.

List a user's transport requests. Returns a flat, filterable list of requests (number, description, owner, status D=modifiable/R=released, target); pass raw=true for the full ADT payload, which with targets=true can exceed 400k characters. Note that targets=false makes the backend answer with empty lists on some systems, so leave it on unless you know otherwise.

What is inside one transport request: its own header (owner, description, status), its tasks and the objects recorded in it. This is the answer to "what does this request change" - the alternative was a SELECT on E071 through runQuery. Objects are returned as a flat list; pass raw=true for the ADT structure.

Transport requests of one organizer configuration, filtered as that configuration defines. For your own open requests use userTransports, which filters and shortens.

Delete a transport request or a task inside it. Only works while it is still open and empty of anything you want to keep: the objects in it stay as they are, only the request goes. Released requests cannot be deleted at all. Not undoable - ask before doing it to a request you did not create.

Release a request, which sends its objects on to the next system. Not undoable: a released request cannot be reopened, and the only way back is another request. It fails while any task inside it is still open, and while the objects have syntax errors. Ask before releasing anything - this is the step that changes another system.

Hand a request over to another user. The new owner sees it in their list and yours loses it; the objects and tasks inside stay as they are. Only an open request can change hands.

Add a developer task for another user inside a request, so their changes can travel in it. Their objects then sit in their own task under the same request number.

The users of this system, as the transport tools offer them - who a request can be handed to or shared with. Search with filter rather than reading the whole address book of the system.

What a transport reference points at: the object behind one entry of a request.

The metadata of one object: its name, type, package, who changed it when, its master language, and the links ADT offers for it - among them the source URL, which is how the address of an unfamiliar type is found. It does NOT return content: a class answers with its includes, a table with its properties (getStructureSource has the fields), and a message class with the metadata after the messages have been discarded (getMessages has those).

Find objects by name in the repository, with * as a wildcard - the quickest way from a name to a URI, a type and a package. The objType filter is the quick-search filter of the backend and does not take every sub-type: FUGR/FF answers with an empty list while the unfiltered search returns the module. So when a filter comes back empty, search without it and pick the type from the rows.

The workbench path of an object, from the package down to the object itself. That is where the package of an object comes from - its own metadata does not carry it - which is why activation uses this to fill in the parent URI the inactive list leaves empty.

The object types this system knows, as ADT names them. Diagnostic: useful when a type code is in doubt, since a wrong one is refused with a 404 that says nothing.

A single-use ticket for opening SAPGUI on this system without logging on again - what ADT uses when it hands an object to the GUI. It is a credential: it stands for your session, so treat it like one.

The includes a class is made of - definitions, implementations, macros, test classes - with the URL of each. That is how the test class of a class is read or written separately from its main source, and which include names revisions and getTextElements take.

What a class is made of: its methods with their visibility, its attributes, its types and its interfaces - read from the class rather than from its source. This is the cheap answer to "what can this class do"; the source of one method is then found with fragmentMappings or read whole with getObjectSource.

Perform ABAP syntax check. Provide the source in "code", or omit it to reuse the source last read/written for "url" via getObjectSource/setObjectSource (cached this session).

Syntax check for a CDS object, which is addressed differently from ABAP: the DDL source URL goes in as the main URL. For ordinary ABAP use syntaxCheckCode.

Completion proposals for a cursor position: what may be written at line/column of this source. Needs the source and the position, exactly like the editor, so it is worth having when composing a call against an unfamiliar interface; codeCompletionFull adds the insert text and codeCompletionElement the details of one proposal.

Where the symbol under a cursor position is defined - the F3 of ADT. Takes the source URL with a line and column, and answers with the object and position of the declaration, so it needs the source read first to count the position. To go the other way, use usageReferences or impactOf.

Where-used for the symbol at a cursor position, or for the whole object when no position is given. The answer is a flat list that is really a tree - one row per package, per object, and per place inside it - so it is large: a widely used class answers with hundreds of rows and over a hundred thousand characters, past the response cap. Prefer impactOf, which asks this and rolls it up; use whereUsedMethod for one method by name.

Who calls this method. usageReferences needs the line and column of the name inside the source, which means reading the class first and counting characters; here the method name is enough. Returns the callers with the object they sit in, and their source snippets with snippets=true.

Subclasses or superclasses of a class or interface. Pass className or interfaceName and the declaration is located in the source here - the backend resolves a hierarchy from a cursor position rather than from a name, which is why url/body/line/offset are only the escape hatch. Defaults to descendants; set superTypes to walk upwards.

Which syntax-check flavours this system offers, as the check endpoint understands them. Diagnostic; syntaxCheckCode picks the right one itself.

Completion proposals with the text to insert and the position to insert it at, for a cursor position in a source. The fuller form of codeCompletion.

Execute a class that implements IF_OO_ADT_CLASSRUN - the F9 of an ADT editor - and return its console output. The class has to exist and implement that interface; to run a piece of ABAP that does not, use runSnippet, which wraps it in such a class for you. This EXECUTES CODE on the system as the connected user, so it counts as a writing tool and read-only mode refuses it. A runtime error comes back as a bare 500; the reason is in ST22 (runSnippet reads the dump for you).

The details behind one completion proposal: its type, its documentation, where it comes from. Follows codeCompletion for the entry you want to know more about.

The source lines around each usage, for references you already have from usageReferences - pass those rows back in. One more backend call and a much larger answer, so ask for it when the call site itself matters.

Quick-fix proposals the system offers for a position in a source - the same list as the light bulb in ADT (create the missing method, add the missing variable). What comes back is passed to fixEdits to get the actual edits.

Turn one proposal from fixProposals into concrete edits: the ranges and the replacement text. It computes them and does NOT write - apply them with patchObjectSource or editObject.

Locate a named fragment of an object and get the line and column where it starts - the cheap way to find one method in a class of a few thousand lines. type is an ADT fragment type, /: CLAS/OM for a class method, CLAS/OA for an attribute. There is no working fragment type for a FORM of a report; use findInSource for that.

The ABAP keyword or object documentation for a position in a source - the F1 of ADT. Answers with the help text as it is written for that release, which is worth reading before guessing at a statement variant.

Take an edit lock on an object, which every write needs. The handle it returns is what setObjectSource, patchObjectSource and deleteObject take - and it lives and dies with the ADT session, so a lost session voids it and the object has to be locked again. This server remembers the handle per object, so the write tools find it themselves and listLocks shows what is held. The lock must be RELEASED BEFORE ACTIVATING: activation refuses to run while the same session holds it. Prefer editObject, which takes and releases the lock around the change for you.

Release an edit lock. Pass the handle, or leave it out and the one this server recorded for that object is used (see listLocks). Do it before activating - activation refuses while the session still holds the lock - and remember that deleting an object does NOT release its lock, so deleteObject releases it for you.

List the object locks this server currently holds, with their lock handles and when they were taken. Locks are otherwise invisible and outlive the edit that needed them.

Release every lock this server holds. Use it to clean up after an edit that was abandoned; call listLocks first if you want to see what will be released.

Retrieves source code for ABAP objects. ADT serves the INACTIVE version by default, so reading your own edit back proves nothing about what runs - pass version="active" to see the live code. For large objects, use startLine/maxLines to page through the source instead of retrieving it all at once.

Change part of an ABAP object without re-uploading it. Reads the current source, applies the edits, writes the result and returns a unified diff of what changed. Use it instead of setObjectSource for a small change to a large object: setObjectSource replaces the whole object, so it costs the entire source and risks disturbing lines you never meant to touch. Pass dryRun to see the diff without writing.

The whole edit in one call: lock, patch, unlock, activate and verify. This is the sequence a change to an ABAP object needs, and each step has a way to go wrong on its own - the lock must be released BEFORE activating, or activation fails with "user is already processing", and an activation is only believable once the inactive list comes back empty. Nothing is rolled back if a step fails: the source stays written to the inactive version, which is not what the system executes, and the answer says exactly how far it got. Pass dryRun to see the diff without locking anything.

Replace the whole source of an ABAP object. For a small change prefer patchObjectSource, which reads, edits and writes without sending the entire object.

Find text or a regular expression in the source of an ABAP object and get the matching line numbers with context - without pulling the source through the caller. This is how to locate a FORM, a MODULE or any statement in a report: there is no ADT fragment type for those, and asking fragmentMappings for one is answered with 400. For a report, searchIncludes follows its INCLUDE statements too.

Table of contents of an ABAP source: every REPORT, CLASS, METHOD, FORM, MODULE, FUNCTION, INCLUDE and event block with the line it starts on. Read this before paging through a long report or class - it turns "where is that subroutine" into one call. Text scanning, so it works on programs, includes and function groups alike.

Delete an object. It needs an edit lock (this server passes the handle it holds, so lock the object first) and, outside $TMP, a transport request. Deleting does not release the lock - the backend leaves it, pointing at an object that no longer exists - so this releases it and forgets it, and drops the cached source with it. Not undoable from here: the object is gone and only a transport of the deletion travels on.

Activate the objects you name, as rows shaped like the ones inactiveObjects returns. Prefer activateSafe, which activates and then proves it: this call can answer success:true while the object stays inactive, and activating only the class row leaves changed method fragments behind, so the old implementation keeps running under an already-active signature. Every row needs a non-empty adtcore:parentUri, which the inactive list leaves empty for programs.

Activate an ABAP object by name and URL, then check the inactive list to see whether it really happened. The backend call behind this answers success:true for objects that stay inactive - notably a freshly created class - so the answer carries verified/stillInactive as well, and success is lowered to false when anything is left inactive. activateSafe is still the better tool: it activates exactly the rows inactiveObjects reports, including method fragments.

The objects that are written but not activated. Read in the session this server does its writing in, because the sessions disagree: a read from elsewhere can still report an object as inactive after it has been activated. Use it as the proof that an edit went live - an empty list for your object is that proof.

Activate an object and prove it worked. Reads inactiveObjects, activates exactly those entries (class plus its method fragments, sections and test include), then re-reads inactiveObjects and fails if anything is still inactive. Prefer this over activateByName, which can answer success:true without activating anything.

The workbench registration of an object: which transport layer and package it belongs to, and whether it can be changed here. This is what says an object is foreign or read-only before a lock fails on it.

Ask the system whether a new object may be created under this name, in this package, with this description - the check ADT runs before a creation dialog is accepted. It answers with the reason a name is refused (already taken, reserved, wrong namespace). Careful with the answer: some collections reply 200 with an empty body, which the library reads as failure, so a free name can look refused; createObject and createAndWrite handle that themselves.

Create a new ABAP object. Report includes (PROG/I) are the one type this cannot create - it refuses them and points at createInclude.

Create a report include (PROG/I). Use this instead of createObject for includes: abap-adt-api builds the creation body without the reference to the main program, so the backend rejects it (400/500) whatever parameters are passed. This posts the include document together with its context reference.

Create an object and put its source in it, in one call: validate the name, create, lock, write the source, unlock, activate with verification. Creating and writing are separate calls in ADT, and an object created without source is an empty shell that fails activation - this keeps the two halves together. Report includes (PROG/I) are created the way createInclude does it, so they work here too; pass mainProgram. Nothing is rolled back on failure: the answer says which step stopped it.

One level of the repository tree: what is directly inside a package, or inside a function group. Two things to know. Most rows hand back a SAPGUI bridge URI that serves properties and no content, so it is not the way to read sources - packageTree resolves the real source URLs, and listFunctionGroup does it for a group. And an unknown package answers exactly like an empty one, with no nodes at all, so only a repository search tells them apart.

Which programs an include belongs to - the question a report include cannot answer about itself. It is needed to create or syntax-check an include, both of which want the main program, and an include used by several reports answers with all of them.

What one discovery feature offers, by title - the capabilities behind a collection.

What one collection of the discovery document offers: its capabilities, its supported types and its versions.

Which discovery collection serves a given URL - the reverse lookup of adtDiscovery, for when an address is in hand and its capabilities are not.

The object types the creation endpoints accept, with the templates behind them - what a wrong objtype is checked against.

The ADT service document: every collection this system offers, with its URL and the object types it serves. This is where the address of an unfamiliar collection comes from.

The core discovery document of the ADT service - what healthcheck calls to prove the connection is alive.

The ADT compatibility graph of this system: which protocol versions its collections speak. Diagnostic, for a call refused as an unsupported version.

Run ABAP Unit tests for an object. An empty result does not mean the tests passed - it means none ran, and the answer then explains why (inactive object, or an include that does not compile).

Run the ABAP Unit tests of a class and report what happened, activating it first if it has inactive parts. This is what unitTestRun should feel like: tests do not run at all against an inactive object, so a bare run answers with an empty list that reads like success. Returns a summary - how many methods ran, which failed, and each failure with its message - with the full ADT result available on request.

The evaluation behind a unit-test run, for the alerts a run reported. Prefer runTests, which activates first and reports each failure with its assert message.

The markers ADT draws next to code covered by a unit test - which lines a run touched.

Create the test include of a class - the place ABAP Unit tests live, which a new class does not have. It writes an empty include; runTests then runs what is put in it.

How pretty-printing is set for this user: whether keywords go upper or lower case, and how identifiers are treated. Worth reading before formatting a source that is not yours, because the setting decides what the reformat does to every line.

Change the pretty-printer setting for this user - it is a user setting and stays until changed back. It decides what prettyPrinter does to keywords and identifiers, so changing it changes how every later reformat looks.

Reformat a source the way the ADT pretty printer would, following the setting of this user. It answers with the formatted text and writes nothing - the write is yours to make. It does not fix indentation of continuation lines the way a person would: aligning parameters to a column is not something it does.

The abapGit repositories linked on this system, with their packages, branches and state.

Whether an external git repository can be reached with these credentials, and which branches it offers - the check before linking it.

Link a package to an abapGit repository and pull it. This WRITES the objects of that repository into the package - the largest write in this server.

Pull an abapGit repository into its package. This WRITES every object the repository carries, overwriting what is there, and needs a transport outside $TMP.

Disconnect a package from its abapGit repository. The objects stay; the link and its state go, and reconnecting means setting it up again.

Stage the local changes of an abapGit repository for a commit: which objects would go, with their state.

Push staged changes of an abapGit repository to the remote. Outward-facing: it writes to the git remote under the credentials configured there.

Check an abapGit repository before pulling: what would change, and whether anything local stands in the way.

What a remote abapGit repository holds: its branches and their heads, read with the credentials passed in.

Switch an abapGit repository to another branch. It changes what the next pull would write, and a pull after it can rewrite the whole package.

The CDS annotations this system defines, with their value ranges - what may be written in a DDLS source before an activation refuses it.

A dictionary element as the DDIC sees it: a data element, a domain or a type, with its properties. For a table or structure with its fields use getStructureSource.

Read dictionary metadata through the DDIC repository access endpoint - types, fields and domains as the dictionary itself sees them.

Search help for package names, as the input help in ADT offers them - a name check before a creation that would fail on the package.

Read the definition of a DDIC domain: data type, length, decimals, output format, value table and fixed values. Takes the domain name; the object URL is accepted as well.

Change the definition of an existing DDIC domain. The backend PUT replaces the whole definition, so anything not passed here is kept as the system currently has it - read, merge, write happens on this side. The lock is taken and released here unless you pass a handle or this server already holds one; outside $TMP a transport request is needed. Writes the inactive version - pass activate to finish the job, or run activateSafe afterwards.

Read the definition of a DDIC data element: its domain or built-in type, the four field labels, search help and parameter id. Takes the data element name; the object URL is accepted as well.

Change the definition of an existing DDIC data element. The backend PUT replaces the whole definition, so anything not passed is kept as the system has it. The type is either a domain or a built-in ABAP type, not both. The lock is taken and released here unless you pass a handle or this server already holds one; outside $TMP a transport request is needed. Writes the inactive version - pass activate to finish the job, or run activateSafe afterwards.

Create a DDIC domain and give it its definition, in one call: validate the name, create the object, lock it, write the type and output format (and value table or fixed values), unlock, activate. createObject alone leaves a domain with no definition, which cannot be activated. Nothing is rolled back if a step fails - the answer reports each step, and a domain that was created but not written is still there to correct or delete.

Create a DDIC data element and give it its definition, in one call: validate, create, lock, write the type and the four field labels, unlock, activate. The type is either a domain or a built-in ABAP type, not both. createObject alone leaves an element with no type, which cannot be activated. Nothing is rolled back if a step fails - the answer reports each step.

Enhancement implementations active on an ABAP source, with the position each one is injected at and, with includeSource, its code. Read this before drawing conclusions from a standard include: the code that actually runs is the include plus its enhancements, and the source itself does not show them. For a program include, pass contextUri (the main program) - one include can belong to several programs.

Read the text elements of a program, class or function group: text symbols (TEXT-001), selection texts (the labels of PARAMETERS and SELECT-OPTIONS) or list headings. These are stored per language outside the source, so getObjectSource never shows them.

Write the text elements of a program, class or function group. The write replaces the whole set for that category, so pass every element you want to keep - read them first with getTextElements. The lock is taken on the text elements resource - not on the object - and released again, unless you pass a handle or this server already holds one; outside $TMP a transport request is needed. Pass activate to finish the job, or run activateSafe afterwards: a text write leaves both the object and its text pool inactive.

Read the messages of a message class (SE91): number, text, and whether the message is self-explanatory or has a long text. The messages live inside the class document, so this is the only way to see them - objectStructure on the same class shows the metadata alone. Standard classes are large (class 00 has 875 messages), so pass fromNumber/toNumber or numbers to narrow it down.

Read the long text (cause and procedure) of one message, as the HTML the backend serves. The text is stored per language and there is no fallback: a message documented in EN answers nothing in RU. Writing a long text is not possible over ADT - that resource refuses PUT.

Add or change messages of an existing message class. Only the messages passed are touched: the backend upserts by number, so the rest of the class is left alone - and for the same reason a message CANNOT be deleted through ADT. A field left out keeps its current value. The class description is read first and carried over, because the write replaces the class header. The text is capped at 73 characters (what T100 holds) and the answer says what was cut. Takes and releases the lock itself; no activation is needed - the message is in T100 as soon as this returns. Outside $TMP a transport request is required.

Create a message class and fill in its messages in one call: validate the name, create the class, write the messages, read them back. No activation is involved. Nothing is rolled back - the answer says which step stopped and in what state the class was left. Outside $TMP a transport request is required.

Read the definition of a table or structure as ADT serves it: the DDL text plus the parsed field list with types and key flags. Works for TABL/DT and TABL/DS alike - both come from the same endpoint. This is the way to see a table's fields: searchObject answers a table with a SAPGUI bridge URI and objectStructure shows only its metadata.

Create a structure (TABL/DS) and give it its fields in one call: validate the name, create, write the definition, syntax check, activate, verify. Fields are passed as data - the DDL is built here, including the opening keyword, which differs between releases and is taken from the object the backend just created. A quantity or currency field needs its unit annotation or the activation refuses it: pass unitField or currencyField and the reference is built and qualified for you. A transparent table (TABL/DT) cannot be created over ADT at all on a classic ERP system - see the note in getStructureSource. Nothing is rolled back: the answer says which step stopped and in what state the object was left.

List what is in a package, following its sub-packages: every object with its type, the package it sits in and the URL that serves its source where there is one. nodeContents answers one level and gives most objects a SAPGUI bridge URI that serves no content; this resolves the source locations and walks the tree breadth-first, so a limit leaves a complete picture of the upper levels and names the packages it did not open.

Read the source of several objects in one call, by name and type or by source URL. Each object is reported on its own, so one unreadable object does not lose the rest, and the answer stops adding sources once the character budget is used up - it says which objects it did not reach.

Search the sources of a whole package for text or a regular expression, following its sub-packages: one call instead of a package listing plus a read and a search per object. Answers with the matching objects, the line numbers and the lines, and says how far it got - this reads every source it walks, so narrow it with objectTypes and maxObjects on a large package.

Whether the RAP generator (business service generation) answers on this system. False on a classic ERP system, true on a recent S/4 - ask this before assuming a RAP-based approach is possible here. Only the check is wrapped; the generator itself is not.

Publish a service binding, which makes its service reachable on this system. Outward-facing: the endpoint goes live for anyone who can reach the host.

Take a published service offline. Outward-facing and immediate: anything calling that endpoint stops working.

What a service binding exposes: its services, versions and the entities behind them - read before publishing or unpublishing one.

Read rows of one table or view by name, with an optional WHERE clause - the quickest look at data when you know the table. Reading only: ADT serves no write here. For a join, an aggregate or anything over more than one table use runQuery; to see what FIELDS a table has use getStructureSource, because this answers with data and not with a definition. There is no offset in the backend, so paging fetches offset+rowNumber rows and returns the tail - pass an ORDER BY to make the window stable.

Run an Open SQL SELECT and get the rows back - joins, aggregates, GROUP BY, whatever the ABAP SQL console accepts. Reading only, and only SELECT: the endpoint refuses anything that writes, and for logic around the data (call a function module, compute, loop) use runSnippet. Row limits are the ones the backend applies, so ask for what you need with UP TO n ROWS.

The ADT feeds this system publishes (dumps, system messages) with their URLs - the index behind dumps.

Short dumps from ST22, newest first, as the HTML page ST22 itself shows. The header of one carries the runtime error, the exception and the program that died.

Which debug listeners exist for this user and terminal - who would catch a breakpoint right now. Read this before starting one: a second listener for the same user is refused, and an old one left behind is the usual reason a debug session cannot be started. checkConflict is off by default because the backend raises a short dump for it when no listener exists at all - turn it on only once you know one is there.

Start listening for a breakpoint and WAIT until something hits one - the call does not return until a process stops, or the wait times out. That is the shape of the whole debugger here: set breakpoints, start listening, then run the program from somewhere else (SAPGUI, a job, a service call), and this returns when it stops. Nothing in this server can trigger the program for you, so a listener with nothing to trigger it just waits. It occupies the session; delete the listener when you are done.

Stop listening for breakpoints and free the session. Do it when a debug session is over or abandoned - a listener left behind blocks the next one for the same user.

Set breakpoints on lines of a source, or on a statement, for the debug session that follows. They belong to the user and survive until deleted, so they will also stop a colleague running the same code with your user. Set them BEFORE debuggerListen; the ids that come back are what deletes them again.

Remove breakpoints that were set earlier - the ids come from debuggerSetBreakpoints. Worth doing even after a failed session: a forgotten breakpoint stops a productive program the next time it runs.

Attach to the process that has stopped at a breakpoint, which is what debuggerListen reported. Only after this do the stack and the variables mean anything; the attachment holds the stopped process, so let it go (debuggerStep with terminate, or delete the listener) rather than leaving a work process frozen.

Change how the debugger behaves for this user: system debugging, update debugging, how much of a table it reads. They are user settings and stay until changed back.

The call stack of the process stopped at a breakpoint: which programs and methods it came through, with the line each is on. Needs an attached session (debuggerAttach); use debuggerGoToStack to look at variables from a frame further up.

The variables visible in the current stack frame, with their values. Needs an attached session. A structure or a table comes back as a node to open with debuggerChildVariables rather than as its contents.

Open one variable that has parts: the fields of a structure, the rows of an internal table, what a reference points at. Takes the variable id from debuggerVariables.

Step the stopped process: into, over, out, to a line, or terminate it. Each step answers with where it now stands, so the stack and the variables have to be read again. Terminating ends the debugged program - which is how a stopped work process is let go when the session is over.

Move the debugger view to another frame of the stack, so that debuggerVariables shows what is visible THERE. It changes the view, not the position of the program - the process still stands where it stopped.

Change a variable in the stopped process, as the debugger lets you. The program then carries on with the new value, which is a way to reach a branch that the data would not otherwise reach - and a way to make a productive program do something it never would. Only for a session you are deliberately steering.

First of the three steps of a rename: it asks the system what the symbol at this position is and where it is used, so the rename can be planned. Nothing is written. Then renamePreview, then renameExecute.

Second step of a rename: every object and line the rename would touch, from the evaluation you pass back in. Read this before agreeing - a rename reaches objects you did not open, and the preview is the only place that shows how far it goes.

Third step of a rename: apply it. This WRITES every object the preview listed, so all of them must be free of other locks and, outside $TMP, in a transport request. It is not a transaction: a failure part way through leaves the objects already renamed as they are.

How ATC is set up on this system: the check variants and their priorities - what atcCheck runs against by default.

Opens a worklist for an ATC check variant and answers with its id. It reads nothing about the variant, whatever the name suggests: the id it returns is what createAtcRun needs as its worklistId - passing the variant name there is what makes the run answer 500. atcCheck does this and the run and the report in one call.

Starts an ATC run over one object. The first parameter has to be a WORKLIST ID, not a check variant name, whatever it is called here: the backend answers 500 for a variant name. Get the id from atcCheckVariant, or use atcCheck which does the whole sequence.

Run the ATC checks over an object or a whole package and report what they found: for each object, every finding with its priority, the check that raised it, the message, and the source line it points at. This is the whole sequence in one call - the check variant from the system customizing, a worklist, the run, the worklist read back - and getting it wrong is what made a run answer 500 (the run needs a worklist id where the library asks for a variant). Findings are ordered by priority, 1 being the worst.

An existing ATC worklist by id, with the findings it holds. Prefer atcCheck, which opens a worklist, runs the checks and reports them in one call.

The users ATC knows for exemption approval - who can be named as an approver. Search with filter rather than reading the whole address book of the system.

The documentation of one ATC finding: what the check means and what it wants instead. Takes the documentation URI that atcWorklists reports for a finding. Returns the document as it comes from the backend, which is HTML.

The exemption proposal for an ATC finding: what would be requested, before requesting it.

Ask for an ATC finding to be exempted, with a reason - it goes to an approver, it is not granted here.

Whether a message from a check is an ATC proposal rather than a plain finding - which decides whether an exemption can be requested for it.

The contact URI of an ATC finding - who is responsible for it.

Change who is responsible for an ATC finding - it moves the finding into another worklist.

Traces recorded for this user, newest first, with their ids - the way into tracesHitList, tracesStatements and tracesDbAccess. Each run carries how long it took and when its file expires: an expired trace is still listed, but reading it answers "wrong input data".

The recorded requests of a trace - one per unit of work measured. The entry point into a trace before its statements.

The hit list of a trace: what was called how often and for how long - the fastest read of where the time went. The hit list of a single ADT call runs to megabytes, so the answer is capped: pass heaviestFirst for the expensive end of it.

The database accesses of one trace: which tables, how many rows, how long - where a slow run met the database.

The statements of one trace, with their times - where a run spent itself. Takes a trace id from tracesList. The trace has to have been recorded with aggregate false: the backend refuses statements for an aggregated one. One ADT call is some 8000 statements, so the answer is capped - pass heaviestFirst for the expensive end of it.

Set what the next trace records: statements, database access, aggregation. It applies to traces started afterwards, not to one already recorded.

Create a trace configuration: which user and which process to record, and for how long. Recording starts when that user next runs something. Needs parametersId - the URI tracesSetParameters answered with - plus traceUser, traceClient, processType, objectType, expires and maximalExecutions. A bare parameters id and a plain date are accepted here and normalised; sent to the backend as they stand, both answer a flat 400 that names neither field.

Delete a trace configuration, so nothing more is recorded under it.

Delete a recorded trace. Final, and the measurement cannot be taken again from the same run.

What moving an object to another package would involve: the refactoring the backend proposes, with the old and new package and the transport it would be recorded in. Preview only - this server does not execute the move, because the library offers no evaluate step and the payload has to be assembled here, which is not something to run unverified against a real package. Do the move itself in ADT or SE80 once the preview looks right.

First of the three steps that pull a range of lines out into a method: it asks the system whether the range CAN be extracted and what the new method would need - which variables come in, which go out. Nothing is written. Then extractMethodPreview, then extractMethodExecute.

Second step of extract-method: the edits the refactoring would make, from the evaluation you pass back in. Still nothing written - this is where the new signature and the changed call site can be read before agreeing to them.

Third step of extract-method: apply what the preview showed. This WRITES the object, so it needs the object unlocked by anything else and, outside $TMP, a transport request. Nothing is rolled back if the activation afterwards fails.

The version history of an object: who changed it when, and under which transport request. Takes a name (with objectType), or objectUrl for a type it cannot address. Mind what the backend means by "version": that field is the transport request that carried the change, while the version NUMBER is the "revision" field - and that is what compareRevisions takes. A long-lived object has a long history (ZCL_APP answers with 90 versions, most of them copies left by transport releases), so the newest 20 come back unless limit says otherwise, and author/transport/titleContains narrow it down.

What changed between two versions of one object, as a unified diff. Name each side by a revision number from revisions, by a transport request, or by "active" (what the system executes), "inactive" (the working version) or "latest" (newest in the history). With neither side given it compares the two newest versions, which answers "what did the last change do"; "active" against "inactive" shows an edit that is written but not activated. The diff anchors on lines that occur once on each side, so an inserted method reads as an insertion instead of two rewritten methods.

Add a method to a class: the declaration goes into the visibility section, the implementation before the closing ENDCLASS, and the whole lock/write/unlock/activate sequence follows. The signature is passed as data and the ABAP is built here, in the indentation the class already uses. This is otherwise two patchObjectSource edits into two different parts of one source, with line numbers that both have to be right. A method that is already there is refused with the line it is on, rather than declared twice. Pass dryRun to see the diff without writing.

Remove a method from a class - both its declaration and its implementation - and activate. A declaration inside a METHODS: chain is handled: the entry goes, and if it was the last one the chain is closed so it still compiles. What it will not do is guess at a line that declares two methods at once; that is refused and named, because rewriting it wrong takes somebody else's method with it. Pass dryRun to see the diff first, and check usageReferences before removing a method that anything calls.

Add an attribute or a constant to a class - DATA, CLASS-DATA or CONSTANTS - into the section you name, then activate. Defaults to a private DATA, which is what an attribute usually is; a constant needs a value, and READ-ONLY is only accepted on a public one. Pass dryRun to see the diff without writing.

What depends on an object, or on one method of it: the objects that use it, the places inside them, and the package each belongs to. This is usageReferences rolled up into an answer that can be read - that call returns a tree of package, object and member rows, which for a widely used class means hundreds of rows and over a hundred thousand characters for a list of forty objects. Usages in test includes are marked as such, standard SAP objects are left out unless asked for, and depth=2 follows the callers one step further to show what depends on them in turn. A method with no callers looks the same as one reached only dynamically, so an empty answer says so rather than reading as proof.

Whether one object's code reaches another, and through what. Walks usageReferences backwards from "to" through its callers, breadth-first, until it reaches "from" or runs out of budget - the same data impactOf uses, just followed as a chain instead of rolled up one level. Pure ADT data, no ABAP parsing: a call made only dynamically (CALL METHOD (name)) is invisible to it, same as usageReferences itself.

A function module by name alone: which group it lives in, its package, and its signature as data - importing, exporting, changing, tables and exceptions, with types, defaults and which parameters are passed by value. The name is all that is needed; the group is looked up. Without this, reading a module meant knowing its group to build the URL and then reading the interface out of the ABAP by eye, because ADT serves the signature as the first statement of the source (not as the *"-block SE37 shows). Pass includeSource for the body as well - it is often a thousand lines, so it is off by default.

What is in a function group: its modules, its includes, and the global data and types declared in its TOP include. nodeContents answers this, but each row carries a SAPGUI bridge URI padded with spaces to 30 characters, so a group of thirty modules costs about 14,000 characters to list; here it is the names and the source URLs.

Create a function module in an existing group and give it its signature and body in one call: create, write, activate, verify. The signature is passed as data and the ABAP interface is built here - which is how it is set at all, since ADT keeps the interface in the source text. The group has to exist (create one with createAndWrite for FUGR/F) and a group outside $TMP needs a transport request.

Run a piece of ABAP on the system and return what it printed. The snippet is wrapped in a throwaway class implementing IF_OO_ADT_CLASSRUN, created in $TMP, activated, executed with runClass and deleted again - which is the only way ADT executes ABAP at all. Write output with out->write( lv_x ) or out->write_text( ... ); out is the console object the interface hands to main. It answers the questions no read can: what a function module returns for these inputs, what a class method does with this data, what a calculation comes to. It runs code on the target system as your user, so a snippet that writes changes data - it counts as a writing tool and is refused in read-only mode. On a syntax error the activation messages come back with the source, and the class is removed either way.

Call a function module with values and get what it returned, as data. Takes the module name alone - the function group is looked up - reads its signature, generates the call and runs it through a throwaway class in $TMP. The answer carries the exporting, changing and tables parameters by name, sy-subrc turned back into the name of the classic exception it stood for, a class-based exception with its text, and the true row count of every table. Values are checked against the signature before anything is sent: an unknown parameter name and a missing mandatory one are refused with the list of what the module takes. IMPORTANT: this executes the module on the target system as the connected user. Nothing it changed is kept - the call is followed by ROLLBACK WORK - unless commit is set, and a module that commits internally cannot be taken back at all. It counts as a writing tool and is refused in read-only mode.

Call a static method of a class with values and get what it returned, as data. The signature is read from the class source, because classComponents lists methods without their parameters. Returns the returning parameter, the exporting and changing ones by name, and any exception with its text. Static methods only: an instance method needs a constructor call, and runSnippet is the way to do that. IMPORTANT: this executes the method on the target system as the connected user. Nothing it changed is kept - the call is followed by ROLLBACK WORK - unless commit is set. It counts as a writing tool and is refused in read-only mode.

The fields of a table or structure, with the includes spliced in where they sit. Each field carries its position, key and not-null flags, data element, domain, ABAP type, length and decimals, the table its value is checked against, the field holding its unit or currency, and its text in the connection language. This is the answer to "what is in this table": getStructureSource gives the DDL text, where the type of a field is the name of its data element and an .INCLUDE is a line of text rather than the fields it brings - for EKPO, most of them. Reading only, and it executes nothing, so it works on a system where nothing may run.

The secondary indexes of a table, each with the fields it is built on in order, whether it is unique and what it is called in the database. The answer to why a SELECT does or does not have an index to use. Reading only.

The foreign keys of a table: for each field, the table its value is checked against, the fields the two are joined on, the cardinality and whether the check is enforced on input. The answer to "where do the values of this field come from". Reading only.

Check ADT connectivity. Calls the backend and reports which SAP system this server talks to (url, client, language, user), the session state, the active tool profile and the round-trip latency; on failure it reports whether the session is dead.