Skip to Content
User Experience Insights
Author's profile photo Vinita Sinha
Vinita Sinha
July 21, 2016 5 minute read

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

/wp-content/uploads/2016/07/4_1000283.png

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)

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?

      Thanks,

      Gayatri