The request would be triggered only once and not again and again. When a request is triggered it would send 3 responses at certain interval of time,I am unable to configure the same. Please help.
What transport protocol is being used? HTTP? JMS? This sort of interaction can be modeled by chaining messaging clients to the responder to send the different responses.
Http transport protocol is used. Please let me know how to implement it.
So it sends back multiple messages over the same connection?
Yes. I need to design a responder which will send multiple messages over the same connection for a single request at certain time interval
I know you could send all of them at once as one combined response but I am not sure how to send them as individual messages over the HTTP transport at varying intervals.
Yes. At once can be done using responder generator. But here I need to send multiple response individually for a single request.
I'm not sure I understand what you're asking here. HTTP(S) protocols necessitate a 1:1 ratio of requests:responses, unless you have an asynchronous setup that I will detail below. Are you saying that in your application when you send out a request you get multiple responses from the client before a connection is closed?
When we see these kinds of workflows for asynchronous HTTP messaging, there is a secondary endpoint for the responses to come to. Is there anything like that in your system?
we have one responder giving 2 responses webservice call synch response from webservices and aysch MQ response for same request in Virtualize.
where both sync resonse will have 1 delay time and async reponse will have its own delay time
What protocol is the "sync" response using? is it HTTP? Or is it also MQ?
for sync response HTTP and for async its MQ response
2 different type response for same request with diff delay time required for both responses
So this gets a bit more complicated. Responders execute their chained tools in order and they run before the response is sent back. This means that the chained tool cannot be delayed to respond after the response to the incoming request. To work around this you could have the chained messaging client send an MQ message to a queue meant for a different virtual asset. That virtual asset could have the responder that would then send the actual "async" message back with its delay so that it could happen after the HTTP sync response.