Update technical.md

Author: oblomov-dev

docs/advanced/technical/technical.md

@@ -110,7 +110,7 @@ However, in situations where significant Model and View changes are needed, espe
 
 Overall RAP does not mix View, Model and Logic as radically as the "Over the Wire" approaches. Luckily in an open-source project we do not need to take care of any conventions and can risk a little bit more. As we have seen in (6) where the first trick was sending Views from the backend instead of storing them at the frontend app, we can now further enhance flexibility (9)(10).
 
-##### (9) Define one generic HTTP-Service for all Apps
+##### 9. One HTTP-Service for all Apps
 
 First, we do not define a specific HTTP-Service for transmitting the View and the Data. Instead, every app uses the same generic HTTP-Handler including two strings (one for the View and one for the Data) eliminating the need to develop individual OData-Services with SEGW or CDS. During runtime the ABAP variables & tables are transformed into a JSON-Model and transmitted as a string to the frontend. In JavaScript it is parsed again into a JSON-Model and binded to the UI5-View:
 
@@ -124,7 +124,7 @@ Furthermore we not only send the data but also the metadata (Data Model) with ev
 
 OData vs. UI5 Over the Wire - Model & Data transfer
 
-##### (10) Define Model at Runtime
+##### 10. Define Model at Runtime
 
 This enables the possibility to define models not only at design time, but also at runtime. The user doesn't have to do any extra work because abap2UI5 handles the entire process in the background during every AJAX request:
 
@@ -138,14 +138,14 @@ In apps we can use RTTI now again in a way that is similar to how it was used wi
 
 Replacing the Model (metadata) at Runtime
 
-##### (11) Define View at Runtime
+##### 11. Define View at Runtime
 
 Same for the view: In RAP, only certain predefined control attributes can be modified at runtime, while the view is defined in CDS artifacts with UI annotations previously. However, in an abap2UI5 app, it is possible to replace entire view controls. For example, in the following app, a table control is replaced with a list control and vice versa:
 
 
 Replacing the View at Runtime
 
-##### (12) View & Model independent from the HTTP-Service
+##### 12. View & Model independent from the HTTP-Service
 
 In the end, the View & Model are defined independent from the HTTP-Service and we are no longer forced to deliver a predefined static OData-Service for every app, as is the case in RAP. The number of backend artifacts is significantly reduced:
 
@@ -154,7 +154,7 @@ RAP vs. Model & View decoupled from the (single & generic) HTTP-Service
 
 Let's take a look to the HTTP-Handler that provides us with this flexibility.
 
-##### (13) HTTP-Service
+##### 13. HTTP-Service
 
 All apps and data models use the same single generic HTTP-Handler, which can be observed by setting a breakpoint in your app and examining the call stack.
 
@@ -163,7 +163,7 @@ Call stack of an abap2UI5 app
 
 Every app implementation is a REST-based HTTP-Post implementation, in which no session is maintained between two requests.
 
-##### (14) REST
+##### 14. REST
 
 This makes it compatible with all mobile use cases and devices, as well as with 'RESTful' Environments such as the BTP ABAP Environment and the new language version 'ABAP Cloud'. Similar to an OData-Implementation, where data changes are reflected in the app without requiring an app restart, it is now possible to develop the entire application and modify its view without restarting the frontend app. Take a look at this demo:
 
@@ -174,7 +174,7 @@ We get also the advantage shared by all over-the-wire approaches that there is n
 
 Up until now, we have observed that the abap2UI5 frontend app is unaware of the specific application, just like the generic HTTP-Service on the server, which has also no knowledge of the particular model and view it is transmitting. So, which layer ultimately defines what happens in this architecture?
 
-##### (15) The abap2UI5 App
+##### 15. The abap2UI5 App
 
 The only non-generic part of this concept is the app of the user implementing the interface z2ui5_if_app:
 
@@ -185,7 +185,7 @@ In this architecture, the app has complete freedom in creating the view and the
 
 However, this is not a big deal for ABAP! From an ABAP perspective, this is similar to past practices of using selection screens or working with ALVs. Every SAP GUI app was, in a way, an HDA where ABAP performs all the necessary functions (it was just not a browser-based environment). Moreover, in this architecture, we are not limited to implementing an OData-Service or confined to a local implementation of a global RAP class with restrictions, such as commit sequences, anymore. We can now leverage the full capabilities of the ABAP stack again. Creating data models based on internal tables is straightforward, working with generic data models, as seen in (10), is easily achievable at runtime with RTTI and extended ABAP concepts like serialization are also applicable, as we will see in the next section.
 
-##### (16) Draft
+##### 16. Draft
 
 With RAP, users can save interim results in drafts, giving them the opportunity to interrupt their work and continue later. The abap2UI5 architecture works as if we send a completely new app to the frontend after every event, but we still want to preserve the inputs and state that the user has made before. To achieve this, the z2ui5_if_app interface includes the if_serializable_object interface, which enables us to serialize and persist all important information of every request (such as the current view or its status):
 
@@ -206,25 +206,25 @@ However, it is important to note that this feature should only be used for inter
 
 We have gained a lot of flexibility with (9) (10) (11) (16), now the next sections will focus more on how the framework tries to reduce its complexity. Let's begin by taking a look at the initial request.
 
-##### (17) Initial Request
+##### 17. Initial Request
 
 The first GET request sends the artifacts of the UI5 (HDA) app to the browser. Typically, we would deploy a BSP to the ABAP stack for this, but in abap2UI5, the code is copied as a string into the implementation of the initial request of the HTTP-Handler:
 
 
 index.html stored in ABAP Source Code instead of using a BSP
 
 This provides us a 100% abapGit project that solely uses ABAP source code, making it easily installable on every ABAP system by eliminating the need for separated frontend artifacts or deployments.
-##### (18) Everything is maintained & developed in the Backend
+##### 18. Everything is maintained & developed in the Backend
 
 Considering the fact that all user apps are also in pure ABAP, we can now maintain and develop everything in the backend. Duplicating apps, making changes, renaming or other refactoring takes only a few moments. The deployment process is reduced to just activating an ABAP class, enabling us to create many apps in a short amount of time. For example, all the apps of the sample section were created rapidly using mostly copy-pasting, which would have been unfeasible for separately developed and deployed frontend apps. This represents a significant reduction in complexity and an advantage of all 'Over the Wire' apps, as we observed in (3).
 
-##### (19) No Extra Layer 
+##### 19. No Extra Layer 
 
 Another way to reduce complexity is by avoiding the creation of extra customizing layers. As shown in (13), there is only one stack call between the user's app and the HTTP-Handler, and there are no additional layers such as OData, SADL or Gateway. This allows us to bring the UI5 frontend framework and its functionality as pure as possible to the abap2UI5 apps in the backend.
 
 UI5 is evolving rapidly, and additional layers can quickly become outdated. With this approach, all UI5-Controls which will be released in the future will also be automatically useable in abap2UI5. However, a potential downside is that we have to deal with the complexity of the frontend UI5 API and learn the concepts of XML-Views and UI5 Controls. Ultimately, it comes down to personal preference whether you prefer to learn UI Annotations or directly learn the concepts of SAP UI5.
 
-##### (20) No Hiding of Complexity
+##### 20. No Hiding of Complexity
 
 But not having an extra layer also means that the framework does not necessarily abstract away complexity, unlike what other frameworks aim for. In abap2UI5, the user directly sends his XML-View to the frontend and is responsible for ensuring that it is valid and executable:
 
@@ -241,7 +241,7 @@ This is in contrast to RAP, where you benefit of well-documented and organized e
 
 Expression Binding (Side Effects) in abap2UI5 - Mixture of ABAP and JavaScript
 
-##### (21) Separated _bind and _event method
+##### 21. Separated _bind and _event method
 In the first approach of this framework the event and data binding were included in every method call:
 
 
@@ -254,7 +254,8 @@ In the current approach, they are separated from the view and created using addi
 Actual Approach - extra methods for the event and binding
 
 This is a difference from many other UI rendering processes, where data and UI are usually imported together. Separating them here simplifies the view creation process, avoids data redundancies, and prevent the framework from becoming messy. The current approach has fewer lines of code than the first approach that only focused on selection screens, because the entire view creation process is clearly separated from the rest now and kept outside of the framework.
-##### (22) "Over the Wire" sending JS, HTML & CSS 
+
+##### 22. "Over the Wire" sending JS, HTML & CSS 
 
 Furthermore we can also add extra functionality (JS, HTML, CSS) without extending the framework itself or changing the abap2UI5 frontend app. For instance, let's take the Upload Files App as an example, which has its own custom control that is not part of the framework and is sent "Over the Wire" after calling the app:
 
@@ -266,7 +267,7 @@ With any request there is the chance to sent own JavaScript or Custom Controls t
 
 abap2UI5 app sending custom Javascript to the client
 
-##### (23) As simple as possible
+##### 23. As simple as possible
 
 So, we have seen in (22), apps can be made very complex, but the opposite is also possible - we can make them extremely simple. One beautifully minimalistic approach is the use of if_oo_adt_classrun. By implementing just one method, we can generate an output with a single click (F9). This is extremely efficient and was one of the role models for abap2UI5. Here's a comparison of both approaches:
 
@@ -275,7 +276,7 @@ if_oo_adt_classrun vs. abap2UI5
 
 To summarize what we have covered so far, abap2UI5 is built in a highly generic manner, placing most of the responsibility on the user's apps. As a result, we gain a a lot of flexibility and freedom in the app implementation, but we also have full responsibility for the view creation and the program flow. Furthermore we have to keep the following downsides in mind.
 
-##### (24) Downsides compared to UI5 & RAP
+##### 24. Downsides compared to UI5 & RAP
 
 Most notably, compared to UI5, we cannot implement offline capabilities because in such a situation we cannot continuously ask the server after every event to determine what will happen next.
 
@@ -285,7 +286,7 @@ Of course, we can also select from CDS Views in an abap2UI5 app and send the res
 
 Additionally Fiori Elements with all its floorplans & templates is very straightforward and will also get a lot of updates in the future. In the end the wide range of UI5 use cases makes a comparison of the different approaches very difficult and cannot bet finally discussed here. Now, let's continue to the last part of this blog post and take a closer look at the framework's code line.
 
-##### (25) System Footprint
+##### 25. System Footprint
 
 The system footprint is kept as small as possible, abap2UI5 is based only on ABAP classes without the use of CDS and RAP artifacts. Most of the coding is outside of the framework delegated to the user (21) (22). In total the framework consists only around of 2,300 lines of code, spread over one HTTP-Handler, two interfaces and one database table:
 
@@ -305,7 +306,7 @@ AJAX Post Handler
 
 In the end, we get a pure source code-based framework, which offers us the following possibility.
 
-##### (26) Running Everywhere Apps
+##### 26. Running Everywhere Apps
 
 Essentially, abap2UI5 generates two strings, one containing an XML-View and the other containing the JSON-View-Model. These strings are then transmitted to and from the frontend. As a result, there is no need for a high ABAP release, as this can be accomplished even with very old releases. This approach allows us to run on both the latest ABAP Cloud stack and on-premise systems, as well as very old releases, making it a release-independent solution. Additionally, we do not necessarily lose access to new UI5 features, as we have the option to bootstrap the UI5 framework at the frontend from a Content Delivery Network (CDN) and use the latest UI5 version even on very old releases:
 
@@ -318,7 +319,7 @@ CDN Bootstrapping - UI5 version independent from the SAP release
 
 As a result, abap2UI5 apps can also be developed to be portable across various SAP systems, releases, and environments. If an app is developed once on ABAP Cloud 2305, it can also be used on lower releases. Similarly, apps developed on older Netweaver releases can run on BTP ABAP Environment or S/4 Public Cloud ABAP Environment. However, for this compatibility to be possible, abap2UI5 and its apps need to be designed to work with both language versions, 'ABAP Cloud' and 'Standard ABAP'. To avoid redundancy, abap2UI5 tries to achieve this by using a single code line.
 
-##### (27) One-Code-Line
+##### 27. One-Code-Line
 
 With this approach, the use of dependencies is limited to cloud-released APIs and functions available in lower Netweaver releases simultaneously. To handle this, abap2UI5 only uses SAP dependencies when it is really needed -- for instance in the GUID creation:
 
@@ -327,23 +328,15 @@ GUID creation compatible to ABAP Cloud and Standard ABAP
 
 As you can see, creating methods that are compatible with both 'ABAP Cloud' and 'Standard ABAP' is considerably more complex. Fortunately, abapUI5 only requires GUIDs as a dependency. However, when developing apps, you must be aware of this (and I have no experience if this is feasable). But in the end, it does have a key advantage: abap2UI5 runs on ABAP 2305 and is still portable down to NetWeaver v702.
 
-##### (28) Compatibility & Downporting
+##### 28. Compatibility & Downporting
 
 Downporting abap2UI5 code normally would result in a release that is difficult to maintain and debug. To avoid this, abap2UI5 is divided into two repositories: a main repository (compatible from NW 7.50 to ABAP 2305) and a downport repository (compatible down to NW 7.02).
 
 The low-syntax branch is automatically generated using abaplint. The separate branch enables development with all new ABAP expressions available since ABAP v750 while still ensuring that all abap2UI5 features added in the future are automatically downported and available for ABAP v702.
 
 I'd like to extend a thank you to lars.hvam here -- he both recommended using a separated downport version and kindly helped to set abaplint up for this project. At a point when I was tediously downporting everything manually, this was a great shortcut. The functionality of automated ABAP downporting is impressive and greatly improves efficiency. Check out the abaplint dashboard of this project and the tool abaplint.
 
-##### (29) Contribution
-
-Furthermore it has been great merging every PR that has worked with and improved the project. Thank you at this point to the following who contributed their code: jacques.nomssi, marcbernardtools, Sun-Tassein, christian.guenter, axel.mohnen.ctie lars.hvam And, thank you to those who featured the project in their channels: rich.heilman, thomas.jung, jelena.perfiljeva, paul.modderman.01 And also let's not forget, besides abaplint this framework uses abapGit and benefits from the work of the people who built it:
-
-
-abap2UI5 runs on every system with abapGit & abaplint
-
-Lastly, I'd like to say that abap2UI5 did not just emerge out of thin air. Since I've started developing in ABAP I've been looking to SCN blog posts on topics like serialization, JSON parsing, HTTP-Communication, OData and UI5. I'd like to express my gratitude to those who've devoted time to sharing their knowledge, this project certainly wouldn't have been possible without it.
-##### (30) Finish & Begin
+##### 30. Summary
 
 This was the explanation of the technical background. If you are interested in more information, take a look at the previous version of this project. It provides a more in-depth explanation of the server-client communication and you can see how it all started: abap2UI5 - Development of UI5 Selection Screens in pure ABAP.
 Summary
@@ -354,11 +347,4 @@ Long blog post short: Inspired by "HTML Over the Wire" (1)(2)(3) we mixed UI and
 Next, we explored various ideas on how the framework reduces its own complexity by avoiding frontend artifacts (17), eliminating extra customizing layers (19), and separating the view from the framework (21), as well as app-specific JS or HTML (22). Finally, we got a pure source code approach with only one database table, two interfaces, one class and just 2,300 lines of code (25). It is developed in a single code line (27), making it cloud and on-premises ready and downportable to old releases (28). Its apps in combination with abapGit can be developed that they are running on nearly every release (29).
 
 All in all, with abap2UI5, you need to disregard some common rules: there is no separation between View and Model in the HTTP communication (12), HTML & JavaScript are stored directly in the source code (17) (22), we don't use OData or RAP (7) and there are other downsides to consider (24). However, if you accept all of this, you get a very minimalistic approach where you only need to implement a single method to develop standalone UI5 applications (15).
-Conclusion
-
-
-Going into this, I had no idea whether or not this idea would be interesting or find its audience. It surprised me how many people were installing it, and it really inspired me to keep putting ideas into the project over the past couple month. I’m not sure how many of these apps will find themselves in a productive system or if they’ll just stay as testing or tooling for developers, but regardless I hope working with abap2UI5 has been fun. I’d like to thank everyone who was willing to give this approach a try and 'hop over the wire'. ‌🙃‌
-
-In the next part, we will see how the project is organized on GitHub with the tools abapGit, open-abap and abaplint.
 
-Thank you for reading! Your questions, comments and wishes for this project are always welcome, leave a comment or create an issue.