In the previous blog, Recommendations for Addressing the n+1 landscape – Approach 2 we talked about the scenario where only new objects were being created in the new phase of development. In this Blog we talk about using the SWITCH option
Approach 3: Switch Option
Scenario: The more complicated case where – In Phase 2, you need to fix bugs that go to production, while you might still be doing additional development on the same object that is not yet complete and is not in a state to be made available on production. Since there is only ONE development tenant on which you maintain your code, understanding how to take care of the above challenge is key
Objective: Although the code is still the same across both environments, achieve differentiation by using switches and hiding what is not needed on Phase 1 environment
There may be a variant of the 3 tenant landscape if in Phase 2 you want a dedicated separate test environment to test fresh development related to Phase 2 and not see it on production till it is ready (Lets call this the n+1 landscape). This is shown below – the Dev tenant remains the same since you cannot have more than 1 Development tenant, you also have the option for an ‘additional’ test tenant which will now have code developed for Phase 2 and tested in a separate testing environment meant only for phase2. Of course the Phase 2 related code is NOT meant to be visible or testable on the Test1 environment nor in production
Remember: Dev tenant is ONE. All code enhancements -> be it for bug fixes or additional development would get deployed to both the test tenants. You cannot have multiple code lines for the 2 phases in separate tenants and think of merging these later. What you can do is hide in that single codeline what is not needed yet in the Phase 1 environment.
We need to look at all components of development though -> Absl, UI elements through KUT or PDI within/without Embedded components, Data Sources and Extension scenario
In the figure above:
In Phase 1, Development happened on Dev1, tested in an Integrated PI 1 environment on Test1, and deployed in production
In Phase 2, Development continued on Dev1, and tested on a phase 2 specific integrated Test environment Test2
There are 2 situations now in Phase2:
Bug Fixes -> Should be there in Phase 1 environment + Phase 2 environment
New development -> Should be there only in Phase 2 environment
But HOW do we make this differentiation when the coding tenant is just ONE, the object for the bug fix as well as new development is also the same, or when we have a completely new object introduced only in Phase2
What you can do to achieve this differentiation is:
- Create a BC Fine Tuning Option to denote: Phase1 or Phase 2. Depending upon what this is set to, you can control the absl code.
- ABSL Code: For all new code written for Phase2, precede this with a check for Fine Tuning Value Phase2. Hence, this code gets executed only if the FT value is Phase2
- New Extension Fields through KUT and PDI: UI: Make this visible in production only in Phase 2, by controlling the visibility on UI via Page Layouts + Business Roles
- Visibility of PDI fields on Data Sources and Process Extensions: Extension fields cannot be hidden if they were introduced in PDI.
- Visibility of KUT fields on Data Sources and Process Extensions: This can be controlled by not enabling this field in the “Further usage”
In the next and final part of this series, we talk about commenting the code approach Recommendations for addressing the n+1 landscape – Approach 4 (Commenting out Code)
This is a 4 part blog series with the following links: