Endpoints represent the central components in Citrus to send or receive a message on some destination. Usually endpoints get defined in the basic Citrus Spring application context configuration as Spring bean components. In some cases this might be over engineering as the tester just wants to send or receive a message. In particular this is done when doing sanity checks in server endpoints while debugging a certain scenario.
With endpoint components you are able to create the Citrus endpoint for sending and receiving a message at test runtime. There is no additional configuration or Spring bean component needed. You just use the endpoint uri in a special naming convention and Citrus will create the endpoint for you. Let us see a first example of this scenario:
<testcase name="DynamicEndpointTest"> <actions> <send endpoint="jms:Hello.Queue?timeout=10000"> <message> <payload> [...] </payload> </message> </send> <receive endpoint="jms:Hello.Response.Queue?timeout=5000"> <message> <payload> [...] </payload> </message> </receive> </actions> </testcase>
As you can see the endpoint uri just goes into the test case action in substitution to the usual endpoint reference name. Instead of referencing a bean id that points to the previously configured Citrus endpoint we use the endpoint uri directly. The endpoint uri should give all information to create the endpoint at runtime. In the example above we use a keyword jms: which tells Citrus that we need to create a JMS message endpoint. Secondly we give the JMS destination name Hello.Queue which is a mandatory part of the endpoint uri when using the JMS component. The optional timeout parameter completed the uri. Citrus is able to create the JMS endpoint at runtime sending the message to the defined destination via JMS.
Of course this mechanism is not limited to JMS endpoints. We can use all default Citrus message transports in the endpoint uri. Just pick the right keyword that defines the message transport to use. Here is a list of supported keywords:
- jms: Creates a JMS endpoint for sending and receiving message to a queue or topic
- channel: Creates a channel endpoint for sending and receiving messages using an in memory Spring Integration message channel
- http: Creates a HTTP client for sending a request to some server URL synchronously waiting for the response message
- ws: Creates a Web Socket client for sending messages to or receiving messages from a Web Socket server
- soap: Creates a SOAP WebService client that send a proper SOAP message to the server URL and waits for the synchronous response to arrive
- ssh: Creates a new ssh client for publishing a command to the server
- mail: or smtp: Creates a new mail client for sending a mail mime message to a SMTP server
- camel: Creates a new Apache Camel endpoint for sending and receiving Camel exchanges both to and from Camel routes.
- vertx: or eventbus: Creates a new Vert.x instance sending and receiving messages with the network event bus
- rmi: Creates a new RMI client instance sending and receiving messages for method invocation on remote interfaces
- jmx: Creates a new JMX client instance sending and receiving messages to and from a managed bean server.
Depending on the message transport we have to add mandatory parameters to the endpoint uri. In the JMS example we had to specify the destination name. The mandatory parameters are always part of the endpoint uri. Optional parameters can be added as key value pairs to the endpoint uri. The available parameters depend on the endpoint keyword that you have chosen. See these example endpoint uri expressions:
jms:queuename?connectionFactory=specialConnectionFactory&timeout=10000 jms:topic:topicname?connectionFactory=topicConnectionFactory jms:sync:queuename?connectionFactory=specialConnectionFactory&pollingInterval=100&replyDestination=myReplyDestination channel:channelName channel:sync:channelName channel:channelName?timeout=10000&channelResolver=myChannelResolver http:localhost:8088/test http://localhost:8088/test http:localhost:8088?requestMethod=GET&timeout=10000&errorHandlingStrategy=throwsException&requestFactory=myRequestFactory http://localhost:8088/test?requestMethod=DELETE&customParam=foo websocket:localhost:8088/test websocket://localhost:8088/test ws:localhost:8088/test ws://localhost:8088/test soap:localhost:8088/test soap:localhost:8088?timeout=10000&errorHandlingStrategy=propagateError&messageFactory=myMessageFactory mail:localhost:25000 smtp://localhost:25000 smtp://localhost?timeout=10000&username=foo&password=1234&mailMessageMapper=myMapper ssh:localhost:2200 ssh://localhost:2200?timeout=10000&strictHostChecking=true&user=foo&password=12345678 rmi://localhost:1099/someService rmi:localhost/someService&timeout=10000 jmx:rmi:///jndi/rmi://localhost:1099/someService jmx:platform&timeout=10000 camel:direct:address camel:seda:address camel:jms:queue:someQueue?connectionFactory=myConnectionFactory camel:activemq:queue:someQueue?concurrentConsumers=5&destination.consumer.prefetchSize=50 camel:controlbus:route?routeId=myRoute&action=status vertx:addressName vertx:addressName?port=10105&timeout=10000&pubSubDomain=true vertx:addressName?vertxInstanceFactory=vertxFactory
The optional parameters get directly set as endpoint configuration. You can use primitive values as well as Spring bean id references. Citrus will automatically detect the target parameter type and resolve the value to a Spring bean in the application context if necessary. If you use some unknown parameter Citrus will raise an exception at runtime as the endpoint could not be created properly.
In synchronous communication we have to reuse endpoint components in order to receive synchronous messages on reply destinations. This is a problem when using dynamic endpoints as the endpoints get created at runtime. Citrus uses a caching of endpoints that get created at runtime. Following from that we have to use the exact same endpoint uri in your test case in order to get the cached endpoint instance. With this little trick synchronous communication will work just as it is done with static endpoint components. Have a look at this sample test:
<testcase name="DynamicEndpointTest"> <actions> <send endpoint="jms:sync:Hello.Sync.Queue"> <message> <payload> [...] </payload> </message> </send> <receive endpoint="jms:sync:Hello.Sync.Queue"> <message> <payload> [...] </payload> </message> </receive> </actions> </testcase>
As you can see we used the exact dynamic endpoint uri in both send and receive actions. Citrus is then able to reuse the same dynamic endpoint and the synchronous reply will be received as expected. However the reuse of exactly the same endpoint uri might get annoying as we also have to copy endpoint uri parameters and so on.
<testcase name="DynamicEndpointTest"> <actions> <send endpoint="http://localhost:8080/HelloService?user=1234567"> <message> <payload> [...] </payload> </message> </send> <receive endpoint="http://localhost:8080/HelloService?user=1234567"> <message> <payload> [...] </payload> </message> </receive> </actions> </testcase>
We have to use the exact same endpoint uri when receiving the synchronous service response. This is not very straight forward. This is why Citrus also supports dynamic endpoint names. With a special endpoint uri parameter called endpointName you can name the dynamic endpoint. In a corresponding receive action you just use the endpoint name as reference which makes life more easy:
<testcase name="DynamicEndpointTest"> <actions> <send endpoint="http://localhost:8080/HelloService?endpointName=myHttpClient"> <message> <payload> [...] </payload> </message> </send> <receive endpoint="http://localhost?endpointName=myHttpClient"> <message> <payload> [...] </payload> </message> </receive> </actions> </testcase>
So we can reference the dynamic endpoint with the given name. The internal endpointName uri parameter is automatically removed before sending out messages. Once again the dynamic endpoint uri mechanism provides a fast way to write test cases in Citrus with less configuration. But you should consider to use the static endpoint components defined in the basic Spring bean application context for endpoints that are heavily reused in multiple test cases.