When thinking about the setup, a first challenge is encountered: all interactions with the JMS queues, reading as well as writing is done using a “SOAP Request” test step.
Here, we usally apply all kinds of checks in the form of “assertions” in our SoapUI test. The response message is processed by the pipeline and travels the reverse path of the response message, eventually ending as the ultimate response to the SoapUI request that was sent in the first step.The business service (5), listening on the REPLY (7) queue picks up the response message through message correlation.SoapUI (1) publishes the response message on the REPLY (7) queue, providing the required metadata.Here, custom logic could be implemented to process/determine the response message.An additional script step extracts the relevant information from the metadata and data of the request message that was read from the queue.Now, SoapUI (1) retrieves this request message from the queue.The business service publishes the request message on the Request Queue (6), using the MQ-transport.At a certain stage, the business service (5) will be invoked by the pipeline (4).The proxy forwards the request to the pipeline (4) that implements the logic to be tested.It uses the PUT transport user-header to dynamically route the incoming message to the proxy we want to test. SoapUI (1) will send a request message to our so-called Gateway Proxy (2), using a custom transport user-header – PUT (Proxy Under Test) this Gateway proxy service (actually a proxy and a pipeline) effectively exposes the Proxy Under Test (3) for testing purposes.
0 kommentar(er)
