Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
VinitaSinha
Advisor
Advisor

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

Create a Reuse Library: Reads the values from BCO and returns True or False


 



Call this reuse function in the events like save/modify



Eg:

UI Designer

Embedded Components: Control visibility of fields


In the datamodel create a dummy field -> Dedicated field and Work Protect mode as false(doesn’t ask you to save). Indicator field so that on applying a transformation rule(see below), it gets the value true or false


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

So, when the EC is called, the transformation will get called and this data field will have the value from the FT


The value in the field now can be used to control the visibility. Per EC you can have one such field, and you can control the visibility of the Fields in the EC or Sections Groups in the EC


PDI extension fields’ and section groups’ visibility can also be controlled using switches in SDK, since Data Fields cannot be created for standard


This switch can be assigned to any business role

Hiding custom facets on standard screens



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)
1 Comment