The proxy virtual service looks like this:
You can see that there's an extra "JMS Send Receive" step which doesn't exist in an auto-generated model.
That step looks like this:
Note that it's a custom property, not a JMS header.
So it's referencing the properties "request_paymentMethod" and "request_payload" that don't normally exist. Those properties are generated by a scriptable DPH in the listen step, and look like this:
Ok, so that's the changes to the proxy service completed. What about the services with message selectors?
There are a number of models that listen to the same topic, each with "JMS Consumer" set in the listen step:
When I send a payment method of "NEFT", that virtual service responds, and my client receives a response within a couple of seconds.
When I select a payment method of "RICK", my virtual service with a JMS Consumer matching "paymentMethod = 'RICK' " responds, and my client receives a response within a couple of seconds.
When I select a payment method that doesn't match a virtual service, my client times out.
I believe this is the expected behaviour. Please let me know if it isn't.
Rick