Rhapsody cannot be configured to obtain licenses through our corporate proxy

We purchased an IBM ELM environment from a SaaS vendor, along with an RLKS instance to host our token-based licensing for this ELM deployment and our numerous local installations of Rhapsody. The goal was to avoid to deal with the management of licenses or jazz servers on our side.

However, it is not possible to use these tokens on our corporate networks because Rhapsody cannot be configured to obtain licenses through our corporate proxy. Of course, we can configure said proxy for the ELM RMM part (see https://www.ibm.com/docs/en/elm/7.0.3?topic=administering-configuration-proxy-server ), but this parameter is completely ignored for the Rhapsody license itself when trying to retrieve the license from our SaaS provider, despite having the necessary rules in place in our corporate proxy. Add that our network policies explicitly prohibit any type of direct internet access, and we are in a situation where we cannot use our tokens for our daily work, as Rhapsody is a necessary part of most of our projects.

Managing countless user-by-user licenses is not an option and we specifically choose a token-based licensing model to simplify this part. Hosting an RLKS server on our side is also not an option as the goal of the SaaS solution was to avoid this as we can't or want to manage the server side ourselves. Obviously, letting our SaaS provider access our corporate network for the necessary ELM licenses is not an option either.

At the very least, we need to be able to configure Rhapsody to access a license server through our corporate proxy, as it is supposed to. It would be even better if, in the future, a solution based entirely on HTTPS (like that of the HCL products) came to replace the TCP-based protocol currently used by Rhapsody (and other Rational products like RPE). This will make configuration approval easier for our IT team and our SaaS provider, as HTTPS web traffic is easier to manage for both unlike this old way.

This RFE is raised after the following CASE TS011772243 which has been created and closed due to a non-implementation of such requirement.