Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Boy-o-boy did I have an interesting discussion again during my current project. It’s all about bringing a new crafted feature safely into production with one thing in mind. When the feature is not working for some reason, we want to disable it in runtime on the fly without any un-deployment / redeployment? This way of feature delivery to production is not a principle of the platform, but more a principle of ‘Continuous Delivery’. Quoted from here: Continuous Delivery is the ability to get changes of all types (including new features, configuration changes, bug fixes and experiments) into production, or into the hands of users, safely and quickly in a sustainable way. If you ever brought a failed feature to production, you know what a @#$!@$%! it is to fix your feature in DEV, built a new package, bring it to TST, and eventually (after some days?) land it on PRD. In the meantime a lot of damage might already been produced on your PRD environment if you don’t have the ability to remove the feature on the fly! So, this post will introduce you to the term “feature toggles” (also known as “feature flags”) for your crafted solution. This way you have the ability to disable a feature once landed into “production”.

Let get right into it…

First start with the disadvantages 😞 …WHAT? Isn’t it all bright and shiny stuff? Yes, it is, but (as “Johan Cruyff” once quoted) Every advantage has its disadvantage. So, there we go:

• Keep track on your features (if you didn’t already)
• Document the implementation of the feature toggle (the rest of the team should be aware)
• Produce a strategy / convention for these toggles
• Your configuration will be more complex with extra “toggle” checks
• Update your testers, so they can assess with / without enabled toggle
• Update your administrator on how to enable / disable a toggle and inform about the consequences (deploy by default in ‘disabled’ mode)
• The security layer will get more complex (as you’ll see in this post)
• Remove your toggle from the solution once accepted on PRD (that’s why we document it!)
• Not every part of the platform can be flagged (it has a complexity limitation)

With that said…Time to just build some feature toggles and explore what IS possible based on some use-cases…

Application configuration page

First things first…That’s the creation of an ‘Application configuration’ page for our administrator-people. It’s a feature available when you right-click a project. It creates a special kind of entity (including the building blocks) with the terrible name ‘Generic’ and also saved by default in the root of the project! 😞

Let start with some ‘Boolean’ typed toggle properties from the modal popup (and we generate all the other default BBs):

We as good developers like “structure”, so let’s update the entity properties and update it to nicer name like project_config

Some extra changes I did:

• Update the ‘DefaultLayout’ name (and label)!
• Remove the ‘None’ value from all those properties and set ‘False’ as default.
• Update the ‘Create’ form with a ‘toggle’ section and make checkboxes out of the properties
• Add a Security BB with the role ‘Identity Administrator’ who has permission to update information for the entity. Our Developer rolled account will then have access!

Time for a small trick to move this ‘entity’ from the project root to our “entities” folder. Did you notice this entity can’t be dragged & dropped from within the workspace documents? What we can do is viewing the properties and update the location from here. I know…Don’t blame the messenger! 🙃

Time for a publication, and a view in the ‘/app/admin/‘ section of the platform:

Hit it, and have a look…Nice…right? Enable the ‘Action rule’ toggle for now and go to the next step for the implementation!

Hide action button from ‘Rule’ BB

• Use-case: Hide a created action button on an entity action bar which sets the property of an entity
• Complexity: simple

Start with a simple ‘project’ entity; quickly prototyped with some interesting properties. Just craft something…Doesn’t matter that much. It’s just to play around. Make it all nice and shiny, so you can create new instances in runtime. Sneak peek:

Now add a new action ‘Rule’ BB with the name a_set_property, and make sure to add the condition to check our toggle!

This is the advanced view of the condition: item.Properties.prj_is_active==false && config.project_config.Properties.toggle_action_rule==true

Let’s do a publication, have a test, and play with the toggle setting…An easy task you can do on your own…correct?

Next one…

Hide properties on ‘Form’ BB

• Use-case: Hide (or “not show”) properties on a form when our feature toggle is enable
• Complexity: medium

From the previous user-case we have our ‘project’ entity available (with some crafted properties). Hiding properties from a form can be done in 2 ways:

1. Via the form ‘Categories’

Open the generated “Create” form of the entity and add a new section to it; Add a new category prop_toggle to it and move a field to the new section.

Why a section? Well, you can also apply a ‘Category’ to a sole property, but with lots of properties on a form this can get unmaintainable. So, be careful! On the other hand…A section is also not the holy grail when it comes to form design, but for this demo it fits.

Now, return to the BB overview of the entity, and you’ll have a new ‘Categories’ element available. Guess what! We can show / hide this categorized section via an event type of “Rule” BB. Make it like this (with name e_show_toggle_props), and you should be fine for evaluating it!

2. Via the ‘Security’ BB

The second way to “hide” properties from a form, would be the ‘Security’ BB. I don’t have it applied yet on my entity, so I just add it and also add the ‘Identity User’ role in the “Roles” section of the security configuration. Just like this (with applying all marks):

The nice part of the section is behind the red arrowed filter / condition icon (for our demo on the ‘prj_budget’ property). Hit it like a pro and add a condition like this:

Yes, I know…It’s a double-denial configuration which is always hard to understand for ‘normal’ people! 🤓
Let’s see if you’re still with me:

• config.project_config.Properties.toggle_hide_properties==false
• config.project_config.Properties.toggle_hide_properties!=true
• config.project_config.Properties.toggle_show_properties!=false
• config.project_config.Properties.toggle_show_properties==true

It’s all the same…correct?

Right…save it, publish it, and check out the result! You will also have a green flag…. 💚 ✅

The big advantage (of the security way) is the reusability of the condition on other elements! After reviewing this post, I also found a disadvantage as we miss the part where a ‘Category’ can be limited in the security BB…Is it a feature request for the product!?

Next one…

Skip activities in BPM

• Use-case: Make sure to pass by activities in a BPM by an enabled feature toggle
• Complexity: medium

I hear you thinking Isn’t this just a decision construct in BPM? Indeed correct, but how do we get to the ‘Application configuration’ information? You might have noticed we don’t have the ‘Web service’ BB available on our project_config entity! So, also no “Read” service operation which we can use in a BPM like we would ‘normally’ do!? Well, for this one we have a workaround available where we read the table ‘o2appworkstipsgenericgeneric’…Have a look!

!!SPOILER ALERT!! The Webservice BB will be available on this type of entity in release 22.2 of AppWorks!

After implementing the workaround we have a nice webservice available with the name AppWorksMetadataWSOps which returns us a nice BPM-ready result:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<data>
  <AppWorksMetadataWSOpsResponse>
    <tuple>
      <old>
        <o2appworkstipsgenericproject_config>
          <toggle_action_rule>true</toggle_action_rule>
          <toggle_hide_properties>true</toggle_hide_properties>
          <toggle_skip_bpm_activity>false</toggle_skip_bpm_activity>
          <toggle_skip_lifecycle_state>false</toggle_skip_lifecycle_state>
        </o2appworkstipsgenericproject_config>
      </old>
    </tuple>
  </AppWorksMetadataWSOpsResponse>
</data>

Time for a simple BPM (named bpm_test_toggle):

The first activity will be injected with our generated webservice (right-click > insert > webservice operation). The second activity will have a condition in the properties like this:

1	ns2:AppWorksMetadataWSOpsOutput/ns2:AppWorksMetadataWSOpsResponse/ns2:tuple/ns2:old/ns2:o2appworkstipsgenericproject_config/ns2:toggle_skip_bpm_activity/text() = 'false'

Let’s do a publication of the BPM. To make it testable from within runtime, I create a quick action rule called a_start_bpm on the ‘project’ entity which triggers the just crafted BPM…Why not triggering just from within design-time? Well, my webservice is (for some unexplained reason) giving back empty XML elements directly from BPM initiation (right-click on the BPM itself in the “Workspace documents” artifact). When I evaluated the service via the ‘Web Service Interface Explorer’ it was giving back a fine result, so shoot me!? Any comment is welcome…

Ohw yeah, and because we introduced a ‘Security’ BB on our ‘project’ entity in the previous section, we need to give permission to execute our ‘Action’ type of rule…Otherwise, it wouldn’t be available in runtime!

Once everything falls into place, you should be able to double-check the PIM artifact on the skipped activity. Start one with the toggle on and start one with the toggle off…NICEEEEE! 🤠

We could off-course also use the “larger” decision construct to skip multiple activities!

Next one…

Skip lifecycle states

• Use-case: Make sure to pass by states in a lifecycle with an enabled feature toggle
• Complexity: easy

Let’s say we have a simple lifecycle BB like this one on our ‘project’ entity, where I also created a “skip” state flow for us to configure:

Now have a look at the state transition options (those green checkmarks after each state). By default, they are triggered when we finish an ‘Activity’ (aka a ‘Task’) within the state. For our try-out we’re not using activities, so we can update them all to a ‘Conditional Event’. We update the condition to false for “State2” and “State3”. Why ‘false’? Because we want to ‘hold’ the state at that moment for monitoring later on:

On the first state we’ll read our toggle in pseudo-code like this (you can low-code it…right?):

1
2
3
4
5

if(config.project_config.Properties.toggle_skip_lifecycle_state==true) {
  //Go to state3
} else if(config.project_config.Properties.toggle_skip_lifecycle_state==false) {
  //Go to state2
}

I know…It’s terrible pseudo-code, but that’s how we need to low-code it! Read it like this:

1 2 3 4 5

if(config.project_config.Properties.toggle_skip_lifecycle_state) { //go to state3 } else { //go to state2 }

Publish the entity and create a new instance in runtime (we all know a lifecycle will be triggered at that moment!). For monitoring, we have the ‘Case Instance Manager’ artifact…Our CIM will show something like this after 2 tries (one with selected toggle; one without selected toggle):

Next one…?? Is it possible to skip more on BB level, connector level, and code level? We’ll see!

Other flags?

Let’s just jump through the list quickly and check what is possible based on what we crafted already…

Relationships

The building block itself can’t be limited, but a look in the ‘Security’ BB tells me we are able to limit the ‘Read’ and ‘Update’ operations on the relationship. The ‘Create’ operation of a relationship should be limited on a form like we saw before on the property-hide functionality!

Action bar

An action bar itself can’t be limited. It shows the available actions on an entity. The default actions can be limited in the ‘Security’ BB again, the ‘Rule’ actions can be limited as already explained.

Form itself

A whole form on itself can’t be limited with a real feature flag; They are used in layout panels (without any conditional options). In the latest version of the platform you can also use forms in the ‘List’ BB to create new entity instances with a certain form (also this is unconditional). So, limitation is only possible for the properties on the form (as explained already).

Layout

Layouts ‘smell’ (in terms of feature flagging) the same as forms; So, no real limitation. They can indirectly be limited based on the used panels. On the other hand, you want to toggle a functional feature most of the time. A layout is more a UI feature.

Homepage

Well, no toggle features possible. We can only define a runtime security, but this is based on roles. On roles level there is also nothing to feature flag to make sure they are usable or not. A homepage can have custom actions where we can read our toggles, but that’s just a “read” action; not a “checked” action.

List

No toggle feature possible. I was thinking to add some smart filter on the list, but the ‘Application configuration’ entity properties can’t be selected from here. The only thing we can do is limit the “usage” action from a ‘Security’ BB point of view.

Title

No toggling possible. It’s a UI element which we can only limit on the “update” action via the ‘Security’ BB.

Activity flow

We can limit the initialization of an activity flow in the ‘Security’ BB with a toggle feature like already shown.

Assignee

This one can also be limited in its usage from within the ‘Security’ BB. Be careful too as more configuration can be dependent on this feature.

This last line of information also applies off-course for all the toggles. Always keep in mind if limited functionality has a consequence further up in the chain of information!

Deadline

An easy condition (which can read our toggles) can be created which makes it possible to limit the start and stop action for the deadline policy. Also, in the ‘Security’ BB of the entity, we can limit the update action for the deadline due-date.

Lifecycle itself

Hmmm…Avoiding the start of a lifecycle (with the applied BB) on entity creation!? Well, it looks like it isn’t going to happen. So, the already shown ‘Skip lifecycle state’ would be our fallback scenario. With the help of two “help”-states at start and before ending, you should be able to give it a shot!

Sharing

Sharing has its own set of security rules based on so-called “instance roles”. The security part works the same as the ‘Security’ BB, so we can use the conditional filter options to limit sharing capabilities. The ‘Sharing’ BB itself can be limited again in the ‘Security’ BB of the entity like this (with again those conditions!):

Tracking/History

Two out of the box BBs which can only be limited via the ‘Security’ BB of the entity itself. The view part can definitely be toggled.

Content / File

The ‘File’ BB can be toggled as feature in the ‘Security’ BB of the entity on all the thinkable “File” kind of actions. The ‘Content’ BB comes with its own entity, and a full-blown set of building blocks which includes the ‘Security’ BB where we can limit actions like we already described.

Discussion

Via the ‘Security’ BB on the entity we can toggle the ‘Add comment’ action.

Looks like the ‘Security’ BB is a big player in the “toggle feature” capabilities of the platform…as expected!

Email

The ‘send mail’ action can be toggled via (again) the ‘Security’ BB of the entity. The ‘Email’ BB also comes with a related mail entity with its own set of building blocks which also includes a ‘Security’ BB.

Webservices

The exposed CRUD operations (including the find operations) can be limited in the ‘Security’ BB. Here we have a ‘Web service’ section available to limit the ‘find’ operations on usage level. The default CRUD operations can be limited via the View, Create, and Delete options on the entity security itself. The ‘Updates’? Well, that’s what you define in all the rest of that same ‘Security’ BB.

BPM itself

We already explained the skip activity trick; On the BPM itself we can only apply a runtime security which uses the same principles as we’ve seen on a “Homepage” type of document. So, no real feature toggle on the BPM itself.

Connectors/service containers

Well, I would not know how?, when?, what?, or why? Do we even want to limit a service container!? Comment me otherwise! 😎

Code

In code, we are as flexible as we want. We can read our exposed service (via the ‘Database metadata’), but we can even read our database directly. On the other hand; there is a platform library available to read toggles from code…I did a quick search but couldn’t find a quick entrance…Help me out here with your great comment!

After a second search, I found some interesting information in the \components\basicutil\basicutil.jar. This library contains a FeatureToggles class under the package com.eibus.util.

Any other types of documents?

Well, most other documents are ‘helper’ documents to serve a certain functionality. We leave them out of scope for the post. Some can be applied with a ‘Runtime security’, but this is based on roles and not our toggles.

I give it a toggled “DONE” where we saw some interesting features of the platform. It looks like the ‘Security’ BB of the entity is most of the time key in applying a feature toggle. We saw it is for sure impossible to toggle for a feature, and we also saw it’s not always ‘logical’ to apply a feature toggle. I leave it with this last comment…Have a great “toggling” week-end; CU in the next post.

Finally, a small list of interesting resources about feature toggling/flagging:

• Fixed/dynamic toggling
• Toggle categories
• Blue-green deployment

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?