OK, my memory has been refreshed and I must apologize for giving you some incorrect intel Michael. Here's how it works. The query parameters on HTTP messages are handled by 2 different pieces of software, and the one that handles interactionID is unfortunately not in play for your use case.

First off, I also gave some misinformation regarding the "Is session affinity enabled?" cluster attribute. This setting doesn't impact whether the "affinity" query parameter is processed. The only thing that this impacts is whether the load balancer distributes messages using round robin or if it will do a hash of the client's IP address to determine which machine to target for a given request. If a large % of messages will be sent from a single IP address, you probably want this to be disabled.

The "affinity" query parameter is processed by the load balancer. It allows the client to target a specific machine in a cluster, and it must include an accurate IP address. The presence / absence of this query parameter doesn't impact whether "interactionID" is processed. Therefore, populating this parameter with a bogus IP address (as I suggested you do) would never make sense.

The "interactionID" query parameter is NOT processed by the load balaner. The only component that looks for this parameter is the Eventing Connector, which handles incoming events over HTTP and publishes them to the Eventing Framework. If this parameter is populated, The Eventing Connector invokes the same method you were using (getNodeThatHostsThisCall). If the call is hosted on a different node, it issues a 302 redirect to the invoker, instructing them to send the HTTP event directly to the correct node (bypassing the load balancer).

So, where does that leave you? Two options:
1. You can stick with your current method that we thought was a temporary workaround
2. You could move to using the Eventing Connector and Eventing Framework as opposed to handling the incoming HTTP directly

Option 1 is likely preferable for you since you have it (mostly) working.

Apologies once again. Sometimes the memory gets rusty...

No worries, thanks for running this down.

Although for this one I don't think I have a work around, I've just been calling the service up to 5 times (5 servers) to hit the right server.

If there is code to move the HTTP call to the correct node, can you share that since it's not included in the developer's guide that I can find? Or if it is easier/more appropriate to use the Eventing Framework for this kind of thing, I'm not opposed to changing, it is likely just a lot of copy and paste. Maybe some pros/cons and which one seems like a better fit for this scenario?

If you want the hop to the other server to be transparent to the browser / JavaScript, you would need to do something like a basic proxy function:
- Use the API to find the right server
- Use HTTPClient in your snap-in on server A to invoke your web service on server B
- When server B sends its response to server A, respond to the browser

If you did this the easy way with out using ascynchronous responses, you'd be holding a container thread on server A open while server B was doing its thing. Ideally this would be avoided but if your machines are near each other it seems that this would not be too much worse than processing it locally.

If your browser / JavaScript can handle a 302, it might be simplest just to change your code to send a 302 back from server A, directing the browser to send the same request to server B. This is what the Eventing Connector does.

Some of the benefits to using the Eventing Framework and Eventing Connector would be:
- You don't directly have to deal with HTTP
- You could potentially have multiple snap-ins handling different event types and your clients wouldn't have to explicitly target the correct service (provides a level of abstraction / indirection).

Thanks for the info. Can you provide a link to some Eventing documentation? The dev guide suggests "Breeze ReliableEventStreaming Adapter User Guide" but I haven't been able to find anything named that.

I know it's a bit confusing, but we have 2 different Eventing Frameworks. You want the Eventing Framework (EF) rather than the Reliable Eventing Framework. The difference is described on page 70 of the Developer Guide. Page 68 includes a brief description on how to use EF. Our Javadoc has a com.avaya.collaboration.eventing package with the classes you'd want to use on the snap-in side. Particularly look at the samples package for a sample event consumer.

The 3.4 SDK also has a REST-API-Docs directory. The information in there on how to publish to the Eventing Connector would be relevant for 3.2 Breeze; we just didn't have that documentation when we released 3.2.

Let me know if you have any further questions. I'd suggest perhaps moving any further queries on EF to another thread so it's easier for others to find if they're looking for similar information.

Will do. Thanks again.