I have developed one JMS based virtual service. I want to discard the difference variances of same message (Arguments signature are different) without using Message selector and JMSCorrelationID concept.
Only appropriate message should be subscribed rest of variances message should be discarded.
I am using Signature match style as arguments values are dynamic in nature.
Thanks In Advance.
Do you want to discard all arguments and do the matching only on operation name?
Or do you want to keep a small selected set of arguments and use them in the matching process?
For the first requirement, you can obviously set the matching style to operation.
For the second requirement, this is easiest done by adding a Request Data Manager DPH in the Listen step. And then you add the necessary number of "keep"-actions. You "keep" only the arguments you want to use for matching, all the other arguments will be removed from your internal request object before it is passed to the VS Image Response Selection step. You also need to adjust your signatures in the VSI, and remove all arguments that you do not keep from the signatures.
I tried with the Request Data Manager DPH approach but still difference variance of same message (Signatures are different) are hitting to the Listen step and getting “No Match found” in response. Due to frequent occurrence of these messages in short span of time, transaction count is getting increased with “No Match found” response
and its decreasing the performance of VSE.
My question is how can we filter those variance messages with different signatures before Listen step and only matching performed as per Request Data Manager DPH configuration.
Below is the basic configuration did in VS.
Transport Protocol: JMS
Request and Response message format: Delimited Text File.
From the documentation: for JMS topics, the VSE service takes the place of the live service during playback. You must shut down the live service so that it does not interfere with the handling of requests. Live invocation mode is not supported. The virtual service model that is generated does not include a passthrough step.
So, every request published by the client will be picked up by the virtual service. You cannot filter BEFORE the Listen step. A functional VSE is limited to 10 transactions/second throughput. The decreased performance of the VSE might be due to the 10 tps throttling. The performance degradation is NOT because of the "No Match Found"
The Request Data Manager DPH should work, if you use Keep-actions it allows you to reduce your signature to the base minimum of arguments that you need to select the correct answer for the incoming request. If you continue to get "No Match Found" then you're adapted incoming request resulting from the DPH in the Listen step is not in sync with the signatures in your VSI.
You either need to post some screenshots from the Portal's inspection view together with your vsi signatures.
Or alternatively, if you open an support issue then someone can have a look during a webex.