Writing multitarget ABAP applications
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 🎉
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,
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.
- 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 🤠
Please keep on expanding my mind. Thanks!
thanks, after moving to use fetch, I'll add another target where both frontend and backend of the application is merged, then monkey patch fetch so the frontend calls the backend with just a function call(instead of REST), then the application can possibly run in just a static html page(using sqlite as database running in the browser)
Great work as always!
Brave out-of-the-box developments from Lars, as usual 🙂 👍
And with this PR: Run in SAP Business Technology Platform - Cloud Foundry environment #31 the project is packaged in a Multi Target Archive (MTAR), deployed and running in SAP BTP Cloud Foundry.
cool, now even more multi 😊