- SAP Managed Tags:
As developers, we invest in building applications every day. Personally I want to do that investment wisely, and make sure the applications can be used on both very new and very old platforms.
Many ABAP applications contain simple configuration tables, which only target a few users, and update frequency is very low, this will be the first open source multitarget ABAP application 🎉
In a classic ABAP system a table maintenance dialog can be generated, however it is not Steampunk compatible, as it uses classic dynpro screens.
If running ABAP Environment – Release 2108 or later, it is possible to generate a SAP Fiori table maintenance, but this cannot be used on lower releases.
Also, both approaches generate vast amounts of artifacts and code, at time of writing the open source code is 360 lines of ABAP. And for my scenario I just need something simple, which can be evolved and extended over time.
If carefully developing the ABAP code, it can be compatible with almost every installation that allows custom ABAP code.
Steampunk compatibility can be ensured by abaplint, by checking the language syntax and the allowed objects.
And for this project I've chosen to write it in v740sp05 syntax.
Both restrictions can be configured and validated on every push to GitHub(Continuous Integration?)
As a final touch, the code is automatically downported to provide a 702 compatible version, this build is saved as a artifact on the actions run.
The open-table-maintenance code can also be developed and maintained locally in vscode via a multi-step setup,
As is, there is just a single class, which can easily be copied into a larger project. But I suggest setting up automatic renaming and mirroring of the code into your project, in order to have automatic suggestions to upgrade to the latest version.
This will reduce the blast radius when updating, and note, you can choose to update at any time.
The code can be imported into a Steampunk or 702+ system using abapGit.
As always, the unit tests can be run on GitHub actions. Professional applications also require proper end-to-end testing, so I've setup a Playwright test script which starts the application, changes values, saves, and checks that the result is as expected.
Note that this can run locally or on GitHub actions, so there is no risk for messing up the DEV system.
Welcome to 2022 🤠
Many ABAP applications contain simple configuration tables, which only target a few users, and update frequency is very low, this will be the first open source multitarget ABAP application 🎉
https://github.com/open-abap/open-table-maintenance
Why not reuse existing table maintenance functionality?
In a classic ABAP system a table maintenance dialog can be generated, however it is not Steampunk compatible, as it uses classic dynpro screens.
If running ABAP Environment – Release 2108 or later, it is possible to generate a SAP Fiori table maintenance, but this cannot be used on lower releases.
Also, both approaches generate vast amounts of artifacts and code, at time of writing the open source code is 360 lines of ABAP. And for my scenario I just need something simple, which can be evolved and extended over time.
What is a multi target ABAP application?
If carefully developing the ABAP code, it can be compatible with almost every installation that allows custom ABAP code.
Steampunk compatibility can be ensured by abaplint, by checking the language syntax and the allowed objects.
And for this project I've chosen to write it in v740sp05 syntax.
Both restrictions can be configured and validated on every push to GitHub(Continuous Integration?)
As a final touch, the code is automatically downported to provide a 702 compatible version, this build is saved as a artifact on the actions run.
The open-table-maintenance code can also be developed and maintained locally in vscode via a multi-step setup,
Consumption
As is, there is just a single class, which can easily be copied into a larger project. But I suggest setting up automatic renaming and mirroring of the code into your project, in order to have automatic suggestions to upgrade to the latest version.
This will reduce the blast radius when updating, and note, you can choose to update at any time.
The code can be imported into a Steampunk or 702+ system using abapGit.
End-to-End Testing
As always, the unit tests can be run on GitHub actions. Professional applications also require proper end-to-end testing, so I've setup a Playwright test script which starts the application, changes values, saves, and checks that the result is as expected.
Note that this can run locally or on GitHub actions, so there is no risk for messing up the DEV system.
Summary
- Write the ABAP application locally in vscode
- Ensure 740 compatibility via static analysis
- Ensure Steampunk compatibility via static analysis
- Automatically provide a 702 compatible version
- Run unit tests on GitHub actions
- Run end-to-end tests on GitHub actions
Welcome to 2022 🤠
6 Comments
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
