I'm attempting to update the "Springwolf" library (used to document async API definitions) to support rabbit consumer listeners using spring cloud functions for spring cloud stream. In order to accomplish this I need to find from application context
spring cloud functions defined.
map this to a channel name
map that channel name to its binding.. hopefully pulling out exchange, queue and routing key values.
I've been able to successfully track down the defined functions, get the expected payload type of the function, and map that to a channel name using defined values in application.properties.
Depending on our application properties are set up I can get the other info from there but this is not always possible. Is there a way I can pull this data from defined spring beans.
I've found bean "bindingService" has a private field "consumerBindings" which has a field "destination" which has a field "bindings" and those bindings have all of the details that I need... but given they're private and buried I don't think this would be a good way to go.
I've also found spring.cloud.stream-org.springframework.cloud.stream.config.BindingServiceProperties has a "getBindings" method on it, but those values appear to be incomplete. for instance with a rabbit consumer defined as below the "group name" is generated randomly but its name is not available from the Bindings provided in BindingServiceProperties
spring.cloud.stream.bindings.anotherConsumerMethod-in-0.destination=someDestination2
spring.cloud.stream.bindings.anotherConsumerMethod-in-0.consumer.bindingRoutingKey=testgroup.testDestination.queue2
Any help/guidance would be awesome... also if the answer is "you can't do this" I completely understand.
Related
I'm trying to configure a microservice with Sleuth and ActiveMQ.
When starting a request I can properly see appName, traceId and spanId in logs of producer, but after dequeuing the message in listener I find only appName, without traceId and spanId.
How can I get this fields filled?
Right now I'm working with spring.sleuth.messaging.jms.enabled=false to avoid this exception at startup:
Bean named 'connectionFactory' is expected to be of type 'org.apache.activemq.ActiveMQConnectionFactory' but was actually of type 'org.springframework.cloud.sleuth.instrument.messaging.LazyConnectionFactory'
My dependencies:
org.springframework.boot.spring-boot-starter-activemq 2.5.1
org.springframework.cloud.spring-cloud-sleuth 3.0.3
Thank you all!
My understanding is that the properties you're looking for are set on the JMS message when the message is sent and then retrieved from the message when it is consumed. Since you're setting spring.sleuth.messaging.jms.enabled=false you're disabling this functionality. See the documentation which states:
We instrument the JmsTemplate so that tracing headers get injected into the message. We also support #JmsListener annotated methods on the consumer side.
To block this feature, set spring.sleuth.messaging.jms.enabled to false.
You'll need to find an alternate solution for the connection factory problem if you want to use Sleuth with Spring JMS. If you're injecting org.apache.activemq.ActiveMQConnectionFactory somewhere then you should almost certainly be using javax.jms.ConnectionFactory instead. Using the concrete type is bad for portability and use-cases like this where wrapper implementations are used dynamically.
can anyone explain what is Service Data Object(SDO) and Service Message Object(SMO)?
Questions:
1. what is the purpose of SDO and SMO?
2.how it works?
These concepts aren’t used with Mule, they seem to come from IBM. https://www.ibm.com/support/knowledgecenter/SSFTN5_8.5.7/com.ibm.wbpm.main.doc/topics/cwesb_sca_smo2.html
The equivalent of the SMO in Mule is the Mule Event which you can read about here: https://docs.mulesoft.com/mule-runtime/4.1/about-mule-event
A Mule event contains the core information processed by the runtime. It travels through components inside your Mule app following the configured application logic.
It’s basically an abstraction layer so you don’t have to deal with different protocols and transports.
A Mule Event is composed of these objects:
A Mule Message contains a message payload and its associated attributes.
Variables are Mule event metadata that you use in your flow.
A Http POST for example would be represented as an event.
The event payload would be the body data of the http request
Where as the http headers such as content-type would be attributes on the event.
Same for JMS. The message body would be the payload and the jms header would be attributes.
As for SDO, each SMO has an SDO. This is very specific to that IBM article and not relevant in Mule. But from what I understand it basically allows you to access your heterogenous business data in a common way. I guess Dataweave in Mule accomplishes this as Dataweave is the transformation and expression language in Mule, it allows you to query and transform data in the same way regardless of the data type, xml, Json, CSV and so on.
Let say I get a inbound variable from an http connector when I use this URL
http://x.x.x.x:8080/post?post-message=Hallo wold.
How can I use the value of the #[header:INBOUND:post-message] accross the complete flow from after the HTTP connector all the way up tp the end. Should I use the Mule Object store to write it to ram?
This post shows the scope of variables but it seem there is not one thay can flow from start to en like a session bean
https://m-square.com.au/mule-school-the-mulemessage-property-scopes-and-variables/
Kind Regards.
If you need the variable available throughout the whole flow (and
other flows reached through a flow-ref) use the invocation scope
(set-variable to set, flowVars[] to read it)
If you need it to reach other flows through a transport (e.g. VM) put
it in the outbound or session scope.
If you need it to live as long as the app is running, through
different calls, use the Mule registry (volatile, only available as
long as the app is up) or the object store (which can be configured
as persistent, to hold state even if the app goes down).
Mule Session variables are good enough to get the value throughout application.
But if you need to use the value outside your application, then you can set mule outbound properties.
There are three type of scope level variables supported by mule .
You can use flow variable if you want the variable to be accessible throughout the whole flow.
You can use session variable if you want it to be accessible form other flows through a transport barrier.
Refer this blog for getting better understanding of how different types of variables are propagated between different mule flows.
http://blogs.mulesoft.com/dev/anypoint-platform-dev/mule-school-the-mulemessage-property-scopes-and-variables/
We purchased an Enterprise Mule license in May, and I have also bought and read your Mule in Action at Manning.com. I read Enterprise Integration Patterns, and I have used Mule doc extensively -- I cannot seem to find a comprehensive list of what endpoints produce what kind of data types, or what properties are available for that specific message at any one stage of a flow.
Example: I used a JDBC endpoint to read from a mySQL database and received back a list of maps. Yet i don't see a Mule object to process this list of maps, so i had to write a component in Java to process it and return the columns i wanted from the result set.
I stumbled in the dark thru this whole process, and I am not a rookie in Java EE; I have been using Java and WebSphere off and on for 10 years.
I had read the Mule and MVEL docs and all I see are the Mule object/context names, but no more about when and how they will be available or what data format they will return in.
Is there a comprehensive list of what endpoints (or any other Mule object(s)) produce what kind of data types and also what properties are available for that specific message at any one stage of a flow?
Unfortunately, the Mule reference guide still lacks a formal definition of the generated payload types and supported properties (inbound end endpoint). MuleSoft is aware of the lack and has started to document the latter, as you can see for the HTTP transport.
For now your best bet is to use visual breakpoints in Studio or <logger> elements to introspect the message characteristics.
I am still confused when it is appropriate to use the Message type in WCF like below
[ServiceContract]
public interface IMyService
{
[OperationContract]
Message GetData();
[OperationContract]
void PutData(Message m);
}
Why would you want to use it?
Can you use it for streaming?
Thanks
MSDN lists the follow reasons for using the message class directly:
When you need an alternative way of creating outgoing message contents (for example, creating a message directly from a file on disk) instead of serializing .NET Framework objects.
When you need an alternative way of using incoming message contents (for example, when you want to apply an XSLT transformation to the raw XML contents) instead of deserializing into .NET Framework objects.
When you need to deal with messages in a general way regardless of message contents (for example, when routing or forwarding messages when building a router, load-balancer, or a publish-subscribe system).
See Using the Message Class for more detailed information.
Edit to address the streaming question
I didn't find a definitive answer in my quick scan via google, but the article above states "All communication between clients and services ultimately results in Message instances being sent and received" - so I would assume it could be used directly in streaming.
While the reasons listed by Tim are valid, we use messages directly in our services to create one uber routing service.
we have one service that can take any method call you throw at it, Clients are generated by wsdls supplied from multiple sources.
This service would take the message, examine its content and route it accordingly.
So in my opinion if you want to get closer to the wire, or when you dont know the type of incoming messages, you can use the message in the signature directly.
Streaming is a separate concept than message signature, streaming is supported by wcf under very specific bindings and security mechanism and the method signature has to be very specific (i.e it should return/accept stream). Also in streaming the actual stream of data travels outside the scope of soap message.