F5 APM - Webtop links with different pools

I have an F5 VE, with LTM and APM, version 10.6.0) I have two Oracle Application instances on the same server listening on different ports. I have LTM virtual server (on port 443, with SSL offloading) with no pool assigned to it (wanted to achieve this through APM). I have two pools with each one member, each pointing to the same server but on a different port, one for each application instance.

I have an APM policy, that authenticates users with SecureID and assigns (using advanced resource assignment) the webtop and the two webtop-links (and ACL and POOL) based on LDAP-group-membership, split in two items. However, the pool assignment does not work as apparently you can have only one static pool assignment per branch in VPE. It only assigns one pool for both weblinks, and user ends up on instance A and never on B (if I swap the config around the results is also the otherway around) The two webtop links are very similar only one attribute in the URI is different (group on the Oracle Forms application). e.g. https:/fqdn/forms/group-attribute=JCB

Want I want to achieve If user clicks on webtop-link JCA, it will use pool A, and if it clicks on webtop-link JCB, it will use pool B.

I have everything working, if I use a decision box, before the user gets the resources assigned, as that way I can split it in two branches, but if the user needs to switch to the other application, they have to re-authenticate and go back to start.

As above didn’t work, I tried to configure an iRule which does the pool selection (if URI contain JCA send to pool A, everything else to pool B), but this does not work as besides the above URL/URI's the client connects to, when they click on the webtop link, it also connects to https:/fqdn/session-id=(random) with no part of the uri on which I can differentiate (and all the session-id connections go to pool B and Application A does not work).

What other possibilities are there to achieve this? I looked at SSO and sub VS's but as authentication is based on SecureID this does not seem suitable.

Thanks.