The wTMId cookie is not adequate for client IP affinity routing to Datacap Web Services Server, as the initial request does not contain the wTMId cookie because one has not been assigned yet. Provide a cookie mechanism that will handle all cases including when a wTMId has not been assigned to the initial logon request.

It is impossible to correctly do a load balancing scheme for wTM if not under a specific architecture or configuration.

When a user uses IBM Content Navigator with the Datacap Navigator plugin, when it logs onto the repository, the Datacap Session cookie, wTmId, used on the logon request, is initially set as empty, when it should be non-existent:

This can be seen from the logon request which has an empty wTmId cookie:

POST /ServicewTM.svc/Session/LogonEx?loadUserProfile=true HTTP/1.1
Accept-Language: pt
Content-Type: application/json
Content-Length: 88
Accept: application/json
Cookie: wTmId=
User-Agent: Java1.8.0_291
Host: server1.domain.com:8091
Connection: Keep-Alive

This logon request, with an empty cookie wTmId, set by default, breaks the standard load balancers rule for using sticky sessions based on session cookie values.
This is because the load balancer assumes that:
1st) This request has the session cookie wTmId set to "", lets send it to Server 1.
2nd) Server 1 responds to the request and sets a non-empty session wTmId cookie, as follows:

HTTP/1.1 200 OK
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/10.0
Set-Cookie: wTmId=9bcb8aff-9916-4d03-9558-9ad9efc627c0;Path=/

3rd) The follow up request for the session now has a non-empty cookie (the 9bcb8aff... value) and the load balancer may route the request to another server, since the original route decision was done with an empty value, which is not now the case.

4th) If the load balancer, now for the cookie (9bcb8aff....) decides to use again Server 1, everything will work as expected since it is from where the cookie originated from. Session stickiness is set to server 1, and everything will work as expected.

If the load balancer, for the new session cookie chooses another server, for example Server 2, this Server 2 does not know about the cookie that was set by server 1, and responds with Unauthorized. Now the user will have to logon again, which is done, again, with an empty cookie. So we are back to step 1, and due to this, the user can enter a logon loop, until the server selected is the same server that provided the session cookie.

RESOLUTION:
Two solutions are possible, depending of the type of load balancer that is used:

1st) Prefix, or suffix, the wTmId cookie with the route id/server id, from where the cookie was generated from. While wTM server returns a wTmId session cookie, the load balancer prefixes/suffixes the cookie before returning it to the Datacap Web Plugin, and removes the prefix/suffix before delivering the request to the backend wTM servers. 

The load balancer routing decision is done based on the value of the suffix.

For example, the above session cookie, would be returned to the Datacap Web Plugin by the load balancer as:

Set-Cookie: wTmId=dcap_srv1~9bcb8aff-9916-4d03-9558-9ad9efc627c0;Path=/

Where ~ is the prefix separator, and dcap_srv1 indicates that this request is bound/stuck to server dcap_srv1.

When the request from the Datacap Web Plugin to the wTM server is done, the load balancer removes the dcap_srv1 prefix, restoring the original cookie, and sends it to the correct server in this case dcap_srv1.

2nd) Add another cookie with the routing info that will be used only by the load balancer to make the routing decision. This new cookie should NOT be named wTmId or SERVERID, for example, it could be named for example RouteID or other non existent name.

Responses from the wTM servers will have the RouteID cookie added, and requests will have the cookie, since Datacap Web Plugin will keep cookies, which allow the load balancer to make the correct routing decision. Before sending the request to the backend, it is recommended that the cookie is removed, hence creating a standard wTM request.