In the ABAP development world, efficiency, reliability, and innovation are key.
Today, we introduce TRM (Transport Request Manager), a new open-source project set to transform the way developments are delivered across the SAP landscape.
This is part 1 of 5 TRM related blog articles:
TRM (Transport Request Manager) is a software built on top of CTS, designed to make transports across your SAP ECC/S4 OnPremise systems landscape easier.
The software is fully open-source, and it’s composed of two main components and a registry.
The components are a client-side Node.js CLI application that communicates with a server-side package installed on your SAP development system.
There’s also a registry, where packages are stored and retrieved when needed.
Other prerequisites are the installation of the SAP NW RFC SDK and a local copy of R3Trans on your pc.
Depending on when you’re reading this, the latest releases of the software might implement new capabilities: it’s best to keep yourself updated by reading the roadmap, and having a look at the open issues on Github.
But TRM is more than just a CLI software for transports.
With TRM, manifests are introduced into transports.
If you aren’t new with tools like npm or pip, you’ll find some similarities, because TRM is inspired by them.
This means commands like install, publish, view are now available in the SAP world.
The possibilities with TRM are many, such as:
TRM has many use cases, some of which may adapt to your development environment.
The best use case is modularizing your packages.
This practice can be used when dealing with many systems and, to avoid re-writing the same code, modules are built as standalone packages.
A simpler use case might be package versioning. Even if you are not modularizing your packages, assigning them a version and making a release is one of the steps needed to keep your development organized.
TRM also enables you to clearly see what dependencies are needed in a package: this is useful when you have multiple packages and you are not sure which ones should be transported to avoid errors.
TRM might also be used to install third party modules (libraries, SDKs…) on your systems with ease (this topic will be discussed later, with security and risk considerations).
Continuous deployment means setting up a way to automatically deploy a development once it’s ready to be released, and ideally tested beforehand.
This is a common task in any development environment and it is usually very easy to set up… but with ABAP it’s a whole different story.
Up until now there was no easy way to set up a CD pipeline so this is where TRM comes into place.
TRM is heavily inspired by other programming language package managers, such as npm or pip - easy to understand install and publish commands, easy pipeline setup.
It’s also worth mentioning that CI (to achieve the final CI/CD pipeline) is already available through other open source/official projects (some listed below).
Take a look at the typical CI/CD pipeline and see how TRM will fit in:
A tutorial on setting up a pipeline with these tools will be published in the upcoming days.
Before even getting started, you might be wondering why you should use TRM instead of other similar solutions.
abapGit might be considered one, however it is not actually intended for releasing a development.
The benefits of abapGit are all in the code stage (see the CI/CD pipeline above), but when it comes to releasing and distributing you’ll struggle to get it working (or atleast, I did 😛).
abapGit is very different from TRM: you could consider TRM the build of a package and the serialized files of abapGit the source code.
For these reasons, it can be used for releases, but it’s not designed for it.
gCTS is SAP official solution and it will, of course, work, but from personal experience I think the setup is somewhat complex and not user friendly and, most importantly, it doesn’t rely on a registry (this will be explained later) and has no manifest definition for packages.
If you want to take a look at TRM source code, you’ll soon find it isn’t actually magic: as the name suggests, it works with transport requests (CTS) so it is using SAP standards, it just provides a user friendly interface to get everything working the way modern day package managers do.
Because I’ve been comparing TRM to package managers like npm or pip, you might get the idea TRM is a package manager.
In some way, you’d be right because, technically, a package manager is a tool that allows installing, updating, publishing and removing software from a system, and TRM does just that.
But there’s actually a little more to the one line definition of what a package manager is.
I personally wouldn’t call TRM a package manager because it lacks a basic functionality: handling multiple dependency versions.
If the latest version of package A has a dependency with version X of package B, TRM will install first version X of package B, then package A.
If, however, you were to install package C, that also happens to have a dependency with package B but version Y, you’d have a conflict.
Unlike npm, for example, which stores the dependency release in the folder node_modules, you can’t easily do this on an SAP system (or at least, provide a solution for ALL possible object types).
In the meantime, the recommended solution is building backwards compatible packages 😀.
This topic is better explained in the official documentation.
TRM targets SAP partners that want to enhance their development workflow, keeping their work organized and automate some of the steps required when working on a project.
Furthermore, TRM could also be used by open-source ABAP developers that want to share their libraries, utilities and ABAP projects with the community.
Depending on when you’re reading this, the latest releases of the software might implement new capabilities: it’s best to keep yourself updated by reading the roadmap, and having a look at the open issues on Github.
You can find TRM software roadmap here, and TRM Public Registry roadmap here.
To sum up what to expect at this point in time:
By simplifying versioning, automating deployments, and seamlessly integrating with other existing open-source tools, TRM empowers developers and organizations to elevate their development processes.
Moreover, its open-source, so everyone (including you!) is invited to contribute 😀
Next week blog posts: Installing and publishing packages (Part 2 & 3).
If you want to know more about TRM, check out the official documentation.
Today, we introduce TRM (Transport Request Manager), a new open-source project set to transform the way developments are delivered across the SAP landscape.
This is part 1 of 5 TRM related blog articles:
- Part 1: Introduction
- Part 2: Install your first package
- Part 3: Publish your first package
- Part 4: Dependencies
- Part 5: Setup a CI/CD pipeline with Github Actions
What’s TRM?
TRM (Transport Request Manager) is a software built on top of CTS, designed to make transports across your SAP ECC/S4 OnPremise systems landscape easier.
The software is fully open-source, and it’s composed of two main components and a registry.
The components are a client-side Node.js CLI application that communicates with a server-side package installed on your SAP development system.
There’s also a registry, where packages are stored and retrieved when needed.
Other prerequisites are the installation of the SAP NW RFC SDK and a local copy of R3Trans on your pc.
Depending on when you’re reading this, the latest releases of the software might implement new capabilities: it’s best to keep yourself updated by reading the roadmap, and having a look at the open issues on Github.
But TRM is more than just a CLI software for transports.
With TRM, manifests are introduced into transports.
If you aren’t new with tools like npm or pip, you’ll find some similarities, because TRM is inspired by them.
This means commands like install, publish, view are now available in the SAP world.
The possibilities with TRM are many, such as:
- Easy development versioning
- Dependencies with other packages/standard SAP objects
- Versioning compare between packages on different systems
- Continuous Deployment with CLI tools
Do I need TRM?
TRM has many use cases, some of which may adapt to your development environment.
The best use case is modularizing your packages.
This practice can be used when dealing with many systems and, to avoid re-writing the same code, modules are built as standalone packages.
A simpler use case might be package versioning. Even if you are not modularizing your packages, assigning them a version and making a release is one of the steps needed to keep your development organized.
TRM also enables you to clearly see what dependencies are needed in a package: this is useful when you have multiple packages and you are not sure which ones should be transported to avoid errors.
TRM might also be used to install third party modules (libraries, SDKs…) on your systems with ease (this topic will be discussed later, with security and risk considerations).
Unlocking CD (Continuous deployment) with TRM
Continuous deployment means setting up a way to automatically deploy a development once it’s ready to be released, and ideally tested beforehand.
This is a common task in any development environment and it is usually very easy to set up… but with ABAP it’s a whole different story.
Up until now there was no easy way to set up a CD pipeline so this is where TRM comes into place.
TRM is heavily inspired by other programming language package managers, such as npm or pip - easy to understand install and publish commands, easy pipeline setup.
It’s also worth mentioning that CI (to achieve the final CI/CD pipeline) is already available through other open source/official projects (some listed below).
Take a look at the typical CI/CD pipeline and see how TRM will fit in:
A tutorial on setting up a pipeline with these tools will be published in the upcoming days.
TRM, an alternative to existing solutions
Before even getting started, you might be wondering why you should use TRM instead of other similar solutions.
abapGit might be considered one, however it is not actually intended for releasing a development.
The benefits of abapGit are all in the code stage (see the CI/CD pipeline above), but when it comes to releasing and distributing you’ll struggle to get it working (or atleast, I did 😛).
abapGit is very different from TRM: you could consider TRM the build of a package and the serialized files of abapGit the source code.
For these reasons, it can be used for releases, but it’s not designed for it.
gCTS is SAP official solution and it will, of course, work, but from personal experience I think the setup is somewhat complex and not user friendly and, most importantly, it doesn’t rely on a registry (this will be explained later) and has no manifest definition for packages.
If you want to take a look at TRM source code, you’ll soon find it isn’t actually magic: as the name suggests, it works with transport requests (CTS) so it is using SAP standards, it just provides a user friendly interface to get everything working the way modern day package managers do.
A package manager for ABAP?
Because I’ve been comparing TRM to package managers like npm or pip, you might get the idea TRM is a package manager.
In some way, you’d be right because, technically, a package manager is a tool that allows installing, updating, publishing and removing software from a system, and TRM does just that.
But there’s actually a little more to the one line definition of what a package manager is.
I personally wouldn’t call TRM a package manager because it lacks a basic functionality: handling multiple dependency versions.
If the latest version of package A has a dependency with version X of package B, TRM will install first version X of package B, then package A.
If, however, you were to install package C, that also happens to have a dependency with package B but version Y, you’d have a conflict.
Unlike npm, for example, which stores the dependency release in the folder node_modules, you can’t easily do this on an SAP system (or at least, provide a solution for ALL possible object types).
In the meantime, the recommended solution is building backwards compatible packages 😀.
This topic is better explained in the official documentation.
Who can make use of TRM?
TRM targets SAP partners that want to enhance their development workflow, keeping their work organized and automate some of the steps required when working on a project.
Furthermore, TRM could also be used by open-source ABAP developers that want to share their libraries, utilities and ABAP projects with the community.
Roadmap
Depending on when you’re reading this, the latest releases of the software might implement new capabilities: it’s best to keep yourself updated by reading the roadmap, and having a look at the open issues on Github.
You can find TRM software roadmap here, and TRM Public Registry roadmap here.
To sum up what to expect at this point in time:
- Compatibility with Windows OS
- Basic usage (demos and tutorials) without any major bug
- Use in production environment not recommended yet
- Full documentation and source code provided to allow community contributions and clear view of what the tools are doing
- Support on issues/enhancements/incidents available from project maintainers
Conclusion
By simplifying versioning, automating deployments, and seamlessly integrating with other existing open-source tools, TRM empowers developers and organizations to elevate their development processes.
Moreover, its open-source, so everyone (including you!) is invited to contribute 😀
Next week blog posts: Installing and publishing packages (Part 2 & 3).
If you want to know more about TRM, check out the official documentation.
Useful links
- Official documentation: https://docs.trmregistry.com
- Official website: https://trmregistry.com
- TRM CLI: https://github.com/RegestaItalia/trm-client
- TRM Core: https://github.com/RegestaItalia/trm-core
- SAP Managed Tags:
