How do I get JMS headers on my spring integration jms inbound channel ? I have not found much information on the reference.
Thanks and regards.
Take a look at the DefaultJmsHeaderMapper class. It is responsible (by default) for mapping to and from JMS messages into Spring Integration messages. Once you define appropriate rules, JMS message headers will be visible as any other SI message headers (message.getHeaders()).
Related
is it possible to implement following concept with WSO2 ESB:
http listener for webservices with a method to be called (SOAP)
java routine to process message
same routine to put message to MQ queue Q1
same routine to get answer message from MQ queue Q2
return with processed answered message to webservice caller
or it's better to go with J2EE server and handle messaging part fully through java code?
Regards, Nikola
Well now usecase is much more clear so that we can go ahead and implement it. There are two ways of doing this.
First Approach
Write a Proxy(HTTP to JMS) service which accepts HTTP requests and
place it in JMS Q1 using the jms sender.
Then write another proxy (JMS to JMS), which picks the messages from
JMS Q1, process it and place it in JMS Q2.
Finally create another proxy (JMS to HTTP) to get the message from
JMS Q2 and send it back to the client using the respond mediator.
Second Approach
Create a proxy service (HTTP to JMS) and use store mediator to store the message into JMS Q1.
Create a Forwarding Message Processor to listen to Q1 and pick the message, process it, place it in Q2.
Then create another forwarding message processor to listen to Q2, and send it back to the client using a reply sequence in the message processor.
Choose which ever the way you like and let me know how it goes.
You can use ESB to implement this. But your usecase is not that clear to me. Appreciate if you can explain your usecase in functional perspective. Anyway you have HTTP(S)/JMS listeners and senders with ESB . You can't listen to a SOAP web service using ESB. What you can do is listen to HTTP traffic. Create a proxy that listens to HTTP traffic and send the message to JMS queue Q1 ussing JMS end point. Then write a JMS listener proxy to listen to the answers in Q2. Once it is received you can call the endpoint web service using send or call mediator. This is how I understood your usecase. I have no idea on transformation of data in Q1 and place it in to Q2 due to wired requirements specified above. It looks simple HTTP to JMS switching usecase to me.
I am new to this.I created a jms message store in wso2 esb and sent a message to it.message was received in activeMq but cannot see the message body in Activemq.
Message Details:
org.apache.synapse.message.store.impl.commons.StorableMessage#79f1d1d8
As ESB using jms message stores to store messages as objects, you can't see the message body via activemq. You can use message processor to get messages from the store and then use it in whatever the process you want.
As ESB use message store purely for storing process, it will use exact format. That is why you have to use processors to work with stored messages.
What is the difference between Endpoint And Connectors in Mule . For example , there is http endpoint and there is http connector . Are these terms used interchangeably ?
Connectors:
provide abstract layer over data transport mechanisms
Mule specific
provide connections to external resources(Protocols, DB, 3rd party
API)
Are Operation-based or Endpoint-based.
Endpoints:
Flow level elements
Represents specific usage of a Connector
When you drag a Connector from palette into canvas, an Endpoint is
created
Any Connector can function as an Endpoint.
Endpoints are a type of connector. Connectors in Mule are either endpoint-based or operation-based. Endpoint-based connectors follow either a one-way or request-response exchange pattern and are often (but not always) named and based around a standard data communication protocol, such as FTP, JMS, and SMTP. Operation-based connectors follow an information exchange pattern based on the operation that you select and are often (but not always) named and based around one or more specific third-party APIs.
You shouldn't confused about this, its in mule document
https://docs.mulesoft.com/mule-fundamentals/v/3.7/mule-connectors
https://docs.mulesoft.com/mule-user-guide/v/3.7/endpoint-configuration-reference
I have a requirement where in (RabbitMQ)server sends the request to the client and client executes the operation and sends the response back to the server.
I would like to know which mechanism to use for this Topic, PubSub, Routing...
Can we create the bi-directional connection like server-client similar to xmpp in rabbit mq, if yes how can we do?
thanks
Lokesh
You can use a Spring AMQP asynchronous consumer with a MessageListenerAdapter to invoke a POJO. See the reference documentation.
If you want more control; use a simple MessageListener and send the reply with a RabbitTemplate.
This test case shows an end-to-end configuration (client side and server side). The client side automatically takes care of setting the correlationId.
I'm trying to evaluate the set of out-of-the-box transports provided by Mule, and compare it with the offerings from e.g. ServiceMix and OpenESB.
On Mule's homepage, I find a list of supported transports at:
http://www.mulesoft.org/documentation/display/current/Transports+Reference
However i also find a list of Connectors at:
http://www.mulesoft.org/connectors
There seem to be at least some overlap between these lists, but some technologies are listed as transports, and not as connectors, for example there is a Quartz transport, but not a connector.
So the question is: What exactly is the difference between a Mule Transport and a Mule Connector, and why is e.g. Quartz a transport and not a connector?
Transports are targeted towards a way of transporting data, i.e. a protocol like HTTP or reading/writing files. These are general concepts and the other party behind such a data channel can be anything, a pure data sink or a party with whom data can be exchanged, own company or other.
Connectors are made for using specific APIs, e.g. those from salesforce.com or facebook. Usually, choosing a connector also determines how the data will be transferred in the end, e.g. HTTP.
From mulesoft.org:
Connectors function like endpoints by sending and receiving data over
a transport. However, while endpoints are generic for a widely-used
protocol (such as JDBC, FTP, HTTP, POP3, etc) each connector is built
to optimize the connection with a specific third-party API, such as
Salesforce or Twitter.
Message sources (inbound or outbound) in Mule make use of transports to carry messages from application to application in the Mule framework. Transports implement message channels and provide consistent connectivity to an underlying data source or message channel. Whenever there is a message source in Mule, there is a corresponding transport working in the background to establish and maintain communication. For example, the HTTP transport handles messages sent to an HTTP endpoint in Mule via HTTP protocol.
The heart of a transport is the connector which maintains the configuration and state for the transport. In other words, connectors contain nearly all the connectivity details that Mule needs to actually connect with another system or application.