abap-transport-review

abap-transport-review

Reviewed, traceable and controlled transports for SAP ABAP development.

This project connects the SAP transport system with GitHub pull requests. Releasing a task commits its objects to a review branch and opens a pull request. A request cannot be released until a colleague has approved that pull request, and the release of the request merges it. Exceptions are explicit and visible: the marker #NOREVIEW in the request text, the switch ZTR_DISABLED, and a failure of the check itself, which never stops a release. See docs/WORKFLOW.md.

Everything runs inside the SAP development system, in ABAP, on top of abapGit. The tools are local objects of the development system and are not transported.

Why use it

The purpose is clean code and controlled releases. A change leaves the development system only after another person has reviewed it, and everything about the change is recorded: when it was released, what changed, who made it, who approved it, and why.

In many landscapes these questions are hard to answer after the fact. With this project the answers are in Git and on GitHub:

The second approval and the rule on conversations come from the branch rules of the repository (docs/GITHUB-REPOSITORY-SETUP.md).

What you gain:

• Quality through a second approval. Every task becomes a pull request under the developer's own GitHub account, and the request cannot be released until its pull request is approved by somebody else: GitHub does not count the approval of the author. You decide when and how a transport can leave the development system, and a change that nobody else has looked at does not get out.
• Clean code that is checked where everybody can see it. abaplint can run on GitHub on every pull request (the syntax of your target release and the Clean ABAP rules; the workflows are in github-templates/), and you can turn on GitHub Copilot code review for the repository (it needs a Copilot licence). Copilot reviews the diff automatically, guided by the instructions in .github/copilot-instructions.md. A colleague therefore starts from a diff that has already been checked, and nobody has to spend an AI session on their own machine for it. The review by Copilot is a comment, not the required approval; the approval comes from a person. How to turn it on: docs/GITHUB-REPOSITORY-SETUP.md.
• Everybody can see what changes, without logging in to SAP. Product owners, functional consultants, development leads, testers and auditors open the pull request on GitHub, or the issue in the issue tracker, and see which transports are in development, what changed, who made the change, who reviewed it and when it was released. They need no SAP user, no SAP GUI and no knowledge of SE09. The transport is no longer a black box for anyone except the developer.
• Review on a diff. The review uses a diff with inline comments, the history and the blame of Git, not a list of the objects of a transport.
• Linked to the issue tracker. Start the request text with the issue key and Jira, Linear, Azure Boards or GitHub Issues show the pull request and its merge on the issue (below).
• Works on older systems. SAP NetWeaver 7.40 SP08 and newer, on-premise or private cloud. The classic transport request still moves the change between systems; nothing in your landscape changes.
• Developers keep their way of working. They release in SAP GUI or in Eclipse ADT as before and log in to GitHub once. The push, the pull request and the merge run as background jobs.
• Exceptions are controlled and auditable. The tools can be switched off for a system (ZTR_DISABLED). One request can be released without review with #NOREVIEW; the marker stays in the description of the request, where it can be listed. A failure of the check itself never stops a release.

It is not meant for the cloud editions of S/4HANA or the BTP ABAP environment, and it does not replace the delivery of transports to other systems; see gCTS and this project and the roadmap.

How it works

1. Work as usual. A developer changes objects in a request with tasks, in SAP GUI or in Eclipse ADT. The short text of the request starts with the issue key (below).
2. Release a task. The release check makes sure the developer is logged in to GitHub (a popup in SAP GUI the first time). A background job then commits the objects of that task to the branch review/<request>, opens a pull request from it, if there is none yet, and sends the link to the developer's SAP inbox. What abapGit cannot write, such as table rows, report variants and authorization profiles, goes along as JSON files under content/ in the same commit, so it is reviewed too (below).
3. Review on GitHub. The checks of the repository run on the pull request (abaplint, and Copilot if you turned it on). A colleague reads the diff, comments and approves. The reviewer approves; the reviewer does not merge. The author cannot approve their own pull request. By default a colleague who pushed a later commit can still approve; the ruleset option "require approval of the most recent reviewable push" closes that.
4. Rework, if the review asks for changes. The developer does not touch the pull request. They create a new task in the same request, make the changes and release that task. The job adds a new commit to the same branch, so the same pull request shows the new change. A new commit dismisses the approvals given before (with the ruleset of this project), so the reviewer looks again. This repeats until the pull request is approved and all conversations are resolved.
5. Release the request. The release check compares the objects of the request with the approved pull request. If it is approved and nothing changed since, the release goes on. If it is not approved, or an object changed after the last push, the release is refused with the reason, and a changed object is pushed to the same pull request so that it can be reviewed again.
6. The merge happens from SAP, never on GitHub. When the request is released in SAP, a job squashes and merges the pull request into the base branch, through the GitHub App. Nobody merges on GitHub, and a rule on the repository enforces it: only the release in SAP, or an administrator, can update the base branch (github-templates/github-restrict-merge.sh). The reason is that the base branch must contain only what has been released. Without the rule, somebody could merge an approved pull request while the request is still open, and then a new task in that request, with a change that was never reviewed, would be released after the merge; Git would no longer show what was reviewed and what the transport delivers. The commit title is the request text followed by the number of the pull request, so the issue tracker shows the merge. The rule is a ruleset of GitHub, not part of the ABAP code: set it up as described in docs/GITHUB-REPOSITORY-SETUP.md, and test it on your repository first, because whether GitHub accepts the merge of the App for a developer without administrator rights is not proven by this project.
7. Transport as before. The transport request moves to the other systems in the way your landscape does it today. Git holds the reviewed copy; it does not deploy. If a change reaches another system through Git instead, abapGit brings the objects and the report ZTR_APPLY_CONTENT brings the content/ files.

Who sees what: the developer works in SAP and reads refusals as a popup (SAP GUI) or an error message (ADT); the reviewer works only on GitHub; the administrator sets the branch rules once and can merge by hand in an emergency. Details: docs/WORKFLOW.md.

Quick start

Full checklist with what to do when a step fails: docs/INSTALL.md.

What to look at: one line per check, no red line.

The flow

Details of every step, the results of the release check and the limits: docs/WORKFLOW.md.

Everything on GitHub happens under the account of the developer who releases. There is no shared technical user and no token in SM59. Each developer logs in once (GitHub device flow); the token is kept per SAP user, encrypted.

Linking issues, pull requests and merges

The tools do not talk to your issue tracker. They write the short text of the transport request into the commit message, the pull request title, the pull request description and, at the merge, the squash commit. Start the request text with the issue key, and the integration between GitHub and your tracker does the rest:

ABC-123 Fix posting date check

Other trackers that read issue keys from pull request titles and descriptions work the same way; read their documentation for the exact format. These are the standard behaviours of the integrations, which read the title, the commit message and the description. Only Jira has been used with these tools.

Two things to know:

• The branch name is review/<request>, with the request number and not the issue key. A tracker that links only by branch name will not find the issue; the title and the commit message have the key.
• Nothing checks the key. A request without a key is reviewed like every other. docs/JIRA.md shows exactly what is written where, and how a check for the key could be added.

Releasing without review: #NOREVIEW

Write #NOREVIEW anywhere in the short text of a request, upper or lower case, for example #NOREVIEW ABC-123 Fix posting run. The release of that request then skips the check: no login check, no review check and no merge job. Use it for an emergency, not to save time.

• What still happens. The tasks of the request were pushed when they were released and have their pull requests as usual. Those pull requests stay open. An admin merges or closes them on GitHub; nothing merges them automatically, and the rules of the base branch on GitHub still apply.
• It is visible. The marker stays in the description of the request. To list the requests that used it, read table E07T for descriptions containing #NOREVIEW (SE16).
• It only affects the release of the request. Tasks are not affected.
• Nobody checks who writes it. Anyone who may change the request text can use it. If that is a problem for you, review the list of requests with the marker regularly, and write the reason into the documentation of the request.

Objects that abapGit cannot write: the content/ folder

abapGit turns repository objects (classes, interfaces, tables, programs and so on) into files under src/. A transport carries more than that: table rows, report variants, authorization profiles, old OTR texts, ALV layouts and SAP Note entries. This project writes them as JSON files under content/, in the same commit and the same pull request as the objects, so a reviewer sees them too.

If you find an object that should be supported and is not, please tell us: give the object type, your abapGit version and your SAP release.

Also: a transport of copies is never pushed; an object that is deleted in the transport removes its files; some entries are outside Git by nature, for example client-specific customizing that travels in customizing requests and is not a repository object; check those on the system.

Bringing it into another system. abapGit pulls only src/. The report ZTR_APPLY_CONTENT does the rest:

1. Create the request for the change and pull the objects with abapGit into it.
2. Run the report as a test run. For each file it lists the rows and variants that are new, different, equal and only on this system. Nothing is changed.
3. Run it with "Write" and that request. The keys are recorded in the request first, then the rows are written. The request travels on like any other.

The report writes only what the tools themselves write to Git: tables of packages under Git that SAP delivers as content (delivery class E, S or G) or that you list, and variants of reports of those packages. Each write needs the authorization S_TABU_NAM for the table. Credential fields are never taken from Git. SAP Note entries are only reported; you implement the note in SNOTE.

Set ZTR_REQUIRE_COMPLETE to refuse a request that holds something that cannot be written to Git. All details, the file formats and the limits: docs/NOT-IN-GIT.md.

Eclipse ADT and Claude Code

The release itself works in SAP GUI and in Eclipse ADT. Only two things need a person to run something: the check of a system and the one-time login of each developer. In ADT, without SAP GUI, there are two optional console classes in the sub-package $ZTR_REVIEW_CONSOLE. Open the class and run it with F9 (Run As, ABAP Application (Console)).

Writing the settings needs input and stays in report ZTR_SETUP. The same classes can be started from a script or from Claude Code through the ADT HTTP interface, because they only write text.

The console interface IF_OO_ADT_CLASSRUN exists on 7.40 SP25 and on S/4HANA 2023. On another release check it in SE24; if it is missing, leave the sub-package out of the pull (step 4 of docs/INSTALL.md). Everything else works without it.

Why no Fiori app: the tool is used by developers on development systems, and a Fiori app would need Gateway, a Launchpad and a deployed UI5 application on a system that may be 7.40. The logic is in classes (ZCL_TR_SETUP, ZCL_TR_AUTH) without a screen, so a UI can be put on top later.

Prerequisites

gCTS and this project

gCTS (Git-enabled Change and Transport System) is SAP's own integration of Git with the transport system: a released transport request is committed to a Git repository, and other systems get the change by pulling it (SAP: gCTS and the transport system, SAP: merging into the main branch).

What gCTS does not give you, as far as SAP's documentation shows:

• A gate at the release. gCTS commits when the request is released. A review can sit on the merge into the branch that other systems pull, but nothing holds back the release itself until a pull request is approved. This project refuses the release of the request until the pull request is approved, and opens a pull request for every task.
• Systems before S/4HANA 1909/2020. gCTS is not available on SAP NetWeaver 7.40 and similar releases. This project is written for 7.40 SP08 and newer.
• The abapGit file layout. gCTS keeps the content of a transport in its own layout. abaplint on GitHub, and a pull of the code into another ABAP system with abapGit, read the abapGit layout, which this project writes.

What this project does not give you that gCTS does: delivery of released transports to other systems by pulling from Git, support from SAP, and use in the cloud editions.

gCTS and this project must not write to the same repository. Running both on the same package, each with its own repository, may be possible; this has not been tried. Check the current SAP documentation for your release before you decide.

Supported systems

The tools are classic ABAP on an on-premise or private-cloud system. They use the classic transport check (BAdI CTS_REQUEST_CHECK), background jobs, report variants and the cluster table INDX, none of which is part of ABAP Cloud.

abapGit has to be the developer version of a release that matches your system; the tools call its classes.

The ABAP objects

Not in here, on purpose: abapGit itself (package $ABAPGIT) and the abaplint client (package $ABAPLINT). Both are installed from their own public repositories.

What is in the repository

Guides

Troubleshooting

The messages are the ones the tools write. Where a release is refused you see them in a popup (SAP GUI, release in the dialog), in the error message (Eclipse ADT), or in the log of the job RELEASE OF <request> in SM37 (release in the background).

Security notes

• The token of a developer is only as safe as the developers on that system. It is encrypted with AES-256, but the key is kept in the same cluster table, and anybody who can run ABAP on the system can read both. The separation between author and reviewer on GitHub therefore holds only if every developer of that system is trusted. Use the tools on development systems only. No class of these tools returns the token of another user.
• Authorizations. Changing the settings (ZTR_SETUP with "Write the settings") needs S_TABU_NAM activity 02 for the tables it writes. Applying content from Git (ZTR_APPLY_CONTENT) writes only tables that the tools themselves write to Git (delivery class E, S or G in a package under Git, or listed in ZTR_CONTENT_TABLES) and only variants of reports of the packages under Git or of the variant settings; it needs S_TABU_NAM activity 02 for each table (and S_TABU_CLI for a client-independent table). A rule it cannot check is refused, not allowed. Restrict who may run these reports with S_PROGRAM or a transaction code.
• The release check never stops a system that is not set up. It does nothing until ZTR_CLIENT_ID is written, and nothing when the STVARV parameter ZTR_DISABLED is X. Settings and logins are per client, because STVARV and the cluster table are client-dependent.
• If the release check cannot be loaded at all (for example after an abapGit upgrade that makes ZCL_TR_AUTH inactive), every release in that system fails with a short dump. Deactivate the implementation ZTR_RELEASE_CHECK in SE19; ZTR_DISABLED cannot help in that case.
• Content files are written with credential-looking fields blanked, by field, data element and domain name. That is best effort, not a guarantee; review content/ before you make a repository public.

Status and limits

• Written for SAP NetWeaver 7.40 SP08 and newer with abapGit (developer version); see Supported systems. The sources are ABAP 7.40 syntax.
• Checked: the classes and the five reports compile without errors on 7.40 SP25, and all but the translation report also on S/4HANA 2023; 35 unit tests of the setup, content, content-apply and login classes and 35 unit tests of the translation classes pass on S/4HANA 2023. scripts/syntax-check.py compiles a source on a system without creating anything.
• One working copy per system: abapGit keeps one selected branch per repository for all users, and the push job switches it while it runs. Do not work in the abapGit screen of a repository during a push.
• The token of a developer is encrypted, but anyone who can run ABAP on that system can read it with their own code. Use it on development systems only.
• Pushes run one after the other.
• More in docs/WORKFLOW.md, section "Limits".

Roadmap

Ideas, not promises. There is no date.

• ABAP Cloud (S/4HANA Cloud Public Edition, SAP BTP ABAP environment). Not a port of this tool: the classic transport check, the report and job calls, the cluster table and the abapGit developer classes are not available there. SAP's own answer there is gCTS, so the plan is gCTS together with a branch rule on GitHub, so that only an approved pull request reaches the branch the other systems pull. What is still to be investigated is whether a review can also be required at the release of a transport request in the cloud, and what a small helper on released APIs would have to do for that.
• A user interface for the setup and the login, for systems that run Fiori, on top of the classes ZCL_TR_SETUP and ZCL_TR_AUTH, which already work without a screen. The report and the ADT console classes stay for 7.40.
• A first import that publishes the last released version of objects that are in an open task, so that the first pull request shows a diff.
• More unit tests for the push report and the release check, and the Clean ABAP rules on the whole code base.
• Pinned versions for the abaplint server in the Docker file.

Feedback and contributions

Everybody is welcome to use this project, to report what does not work and to improve it.

• Report a problem, an object that is not supported, or an idea: new issue. Reports from other SAP releases than the ones in Supported systems are especially useful.
• Change something: fork the repository, make the change in a branch and open a pull request. CONTRIBUTING.md says how to check a change and what a pull request needs. A maintainer reviews every pull request, and the check abaplint 7.40 runs on it.
• Security problems: report them privately, see SECURITY.md.

Licence

This project is licensed under MIT. abapGit and abaplint are separate projects that the tools use; they are not included here and keep their own licences. The Clean ABAP skill in claude/ derives from SAP's Clean ABAP style guide; the attribution is in claude/README.md.