Skip to Content
Author's profile photo Vinita Sinha

Recommendations for addressing the n+1 landscape – Approach 3

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:

 Recommendations for addressing the n+1 landscape – Approach 1

 Recommendations for addressing the n+1 landscape – Approach 2(When new BOs are created in the existing solution)

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 Patil Stefan Hagen Sridhar Natarajan




Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Gayatri Bagde
      Gayatri Bagde

      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?