User Experience Insights
Recommendations for addressing the n+1 landscape – Approach 3
In the previous blog, Recommendations for Addressing the n+1 landscape – Approach 2we 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”
Here are some examples of how you can achieve this:
Create a BC Set and a configuration UI -> PDI new BCO and BC set values
These are initial values -> you can delete this and create 2 separate values in the FT UI -> Eg Active and Inactive
Call this reuse function in the events like save/modify
Eg:
UI Designer
In the Controller tab add a transformation for this field, and call the reuse function from the library to get the fine tuning setting value
This switch can be assigned to any business role
Switch can then be assigned to the Roles
To control ECs, its section groups and fields, you can also add anchors to these, so that the properties of these like visibility can be controlled via KUT. This applies to both ECs on standard facets/header as well as custom facets on standard UIs
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:
Recommendations for addressing the n+1 landscape – Approach 1
Recommendations for addressing the n+1 landscape – Approach 3 (Switch Option) This Blog !
Recommendations for addressing the n+1 landscape – Approach 4 (Commenting out Code)
With contributions from Pramodh PatilStefan HagenSridhar Natarajan
Thanks
Vinita
Hi Vinita,
We have similar scenario in our project where we need to work on existing solution bug fixes as well as develop a code for new phase. We are considering an option of Switch as mentioned in your blog.
Can you please give more clarity on the steps of how can we Create a BC Fine Tuning Option and read it in SDK to identify whether its phase 1 or phase 2?
Thanks,
Gayatri