This is with respect to setting up the K2 Database for automatic failover via the SQL Always on feature:

https://help.k2.com/kb001572

In a scenario where both the primary and secondary replica are in different subnets we will configure the listener to have two IP addresses, one for each subnet. However, due to SQL configuration, once we failover to the secondary replica and need to hit secondary subnet, we will hit the SQL Availability group listener and try the subnet IPs configured for the listener in a serial manner. This causes the K2 product to run into connection timeout issues after a failover has occurred. Adding the MultiSubnet=True to the SQL connection string on K2 can resolve this and allow the connection to hit both of the IPs in parallel instead so we do not hit a connection timeout error. Per this MS Documentation (https://docs.microsoft.com/en-us/sql/relational-databases/native-client/features/sql-server-native-client-support-for-high-availability-disaster-recovery) . At this time in K2 we can add this parameter, but it requires modification of K2 Config files and can be easily overwritten by an upgrade or reconfigure. Request here is to make this a supported and configurable addition to how K2 product connects to it's SQL Database.

Currently the K2 Webservice Endpoint broker does not support Security Username Token authentication; at the moment this is only implemented for WCF Endpoint broker.

With the WCF Endpoint broker, once successfully configured and registered, you have to pass in the username token every time you execute a SmO method against the registered service -- sure, you can put this in a variable field or maybe even an environment filed but this is very static in nature. In other words if or when you change the password information for the underlying service account you will need to update the serialized complex string value with the updated username token value across multiple solutions i.e. workflows forms, views, etc. This can be painstaking in larger implementations.
For this kind of scenarios there should be an option to allow this to flow down from the service instance level similar to the "Default HTTP Request Headers" service key.

So, this is a two part feature request:

1. Support for Security Username Token authentication with the Webservice Endpoint broker

2. Option for a "Default Security Username Token" service key in the service instance configuration.