From the Spring Integration documentation (https://docs.spring.io/spring-integration/docs/5.1.7.RELEASE/reference/html/#delayer) it is not clear to me what the messageGroupId in the DelayHandler means exactly and which value I have to set there exactly (is it arbitrary?). This value does not exist in the xml configuration, but does in the Java configuration.
#ServiceActivator(inputChannel = "input")
#Bean
public DelayHandler delayer() {
DelayHandler handler = new DelayHandler("delayer.messageGroupId"); // THIS constructor parameter is not clear to me
handler.setDefaultDelay(3_000L);
handler.setDelayExpressionString("headers['delay']");
handler.setOutputChannelName("output");
return handler;
}
It is explained in the JavaDocs of that constructor:
/**
* Create a DelayHandler with the given 'messageGroupId' that is used as 'key' for
* {#link MessageGroup} to store delayed Messages in the {#link MessageGroupStore}.
* The sending of Messages after the delay will be handled by registered in the
* ApplicationContext default
* {#link org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler}.
* #param messageGroupId The message group identifier.
* #see #getTaskScheduler()
*/
public DelayHandler(String messageGroupId) {
It is not required because the groupId is based on the required id attribute:
String id = element.getAttribute(ID_ATTRIBUTE);
if (!StringUtils.hasText(id)) {
parserContext.getReaderContext().error("The 'id' attribute is required.", element);
}
...
builder.addConstructorArgValue(id + ".messageGroupId");
It is really mentioned and explained a little bit in the docs: https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints.html#delayer-namespace.
The value indeed is arbitrary, but it must be unique per your application, so different delayers don't steal messages from each other.
Related
I have an integration flow that sinks DML queries at the end.
I have a config file to log transactions:
logging.level.org.springframework.transaction.interceptor=TRACE
logging.level.org.springframework.transaction.support=DEBUG
The sinkSql method is called but there is no transaction log.
If I just call e.transactional(true) I get an error because there are two transaction managers (one is from the source database).
#Bean(name = SYBASE_TRAN_MANAGER)
public PlatformTransactionManager transactionManager(#Qualifier(SYBASE_DS) final DataSource sybaseDataSource) {
DataSourceTransactionManager dataSourceTransactionManager = new DataSourceTransactionManager();
dataSourceTransactionManager.setDataSource(sybaseDataSource);
return dataSourceTransactionManager;
}
#Bean
public TransactionInterceptor sybaseTransactionInterceptor(#Qualifier(SYBASE_TRAN_MANAGER) final TransactionManager tm) {
return new TransactionInterceptorBuilder(true)
.transactionManager(tm)
.isolation(Isolation.READ_COMMITTED)
.propagation(Propagation.REQUIRES_NEW)
.readOnly(false)
.build();
}
#Bean
public IntegrationFlow sinkSqlFlow(final TransactionInterceptor sybaseTransactionInterceptor) {
return IntegrationFlows.from(SYBASE_SINK_SQL)
.enrichHeaders(h -> h.header(MessageHeaders.ERROR_CHANNEL, SYBASE_ERROR))
.handle(this::sinkSql, e -> e.transactional(sybaseTransactionInterceptor))
.get();
}
public void sinkSql(final Message<?> message) {
//jdbcTemplate logic here
}
Not sure why is the question since TransactionAspectSupport does just this plain fallback if we don't provide an explicit TransactionManager to the interceptor configuration:
if (defaultTransactionManager == null) {
defaultTransactionManager = this.beanFactory.getBean(TransactionManager.class);
this.transactionManagerCache.putIfAbsent(
DEFAULT_TRANSACTION_MANAGER_KEY, defaultTransactionManager);
}
where that getBean(Class aClass) indeed is going to fail if several beans of type is present in the application context. So, what you did so far with a sybaseTransactionInterceptor bean definition is OK.
You can use an overloaded Java DSL method though:
/**
* Specify a {#link TransactionInterceptor} {#link Advice} with the provided
* {#code PlatformTransactionManager} and default
* {#link org.springframework.transaction.interceptor.DefaultTransactionAttribute}
* for the {#link MessageHandler}.
* #param transactionManager the {#link TransactionManager} to use.
* #param handleMessageAdvice the flag to indicate the target {#link Advice} type:
* {#code false} - regular {#link TransactionInterceptor}; {#code true} -
* {#link org.springframework.integration.transaction.TransactionHandleMessageAdvice}
* extension.
* #return the spec.
*/
public S transactional(TransactionManager transactionManager, boolean handleMessageAdvice) {
Although having your sink contract as void sinkSql(final Message<?> message), there is no need in that true: the transaction is going to be applied for a handleMessage() method which is really the end of your flow anyway.
Given I have IntegrationFlow and inbound adapter for AMQP queue:
#Bean
public IntegrationFlow readMessagesFlow(
ConnectionFactory rabbitConnectionFactory,
ObjectMapper jacksonObjectMapper) {
return IntegrationFlows.from(
Amqp.inboundAdapter(rabbitConnectionFactory, QUEUE)
.messageConverter(new Jackson2JsonMessageConverter(jacksonObjectMapper))
)
.log(INFO, AMQP_LOGGER_CATEGORY)
.get();
}
When some external system sends a message with JSON body, I found they use __TypeId__=THEIR_INTERNAL_CLASS.
I would like to map JSON body to my own class.
Currently, it fails on ClassCastException because of THEIR_INTERNAL_CLASS not being available.
How can I tell Jackson2JsonMessageConverter to use my own class?
This is one way how to do it:
Jackson2JsonMessageConverter messageConverter = new Jackson2JsonMessageConverter(jacksonObjectMapper);
DefaultClassMapper defaultClassMapper = new DefaultClassMapper();
defaultClassMapper.setDefaultType(MyOwnClass.class);
messageConverter.setClassMapper(defaultClassMapper);
and use messageConverter in Amqp.inboundAdapter
See this method of converter:
/**
* Set the precedence for evaluating type information in message properties.
* When using {#code #RabbitListener} at the method level, the framework attempts
* to determine the target type for payload conversion from the method signature.
* If so, this type is provided in the
* {#link MessageProperties#getInferredArgumentType() inferredArgumentType}
* message property.
* <p> By default, if the type is concrete (not abstract, not an interface), this will
* be used ahead of type information provided in the {#code __TypeId__} and
* associated headers provided by the sender.
* <p> If you wish to force the use of the {#code __TypeId__} and associated headers
* (such as when the actual type is a subclass of the method argument type),
* set the precedence to {#link Jackson2JavaTypeMapper.TypePrecedence#TYPE_ID}.
* #param typePrecedence the precedence.
* #see DefaultJackson2JavaTypeMapper#setTypePrecedence(Jackson2JavaTypeMapper.TypePrecedence)
*/
public void setTypePrecedence(Jackson2JavaTypeMapper.TypePrecedence typePrecedence) {
and here are docs on the matter: https://docs.spring.io/spring-amqp/docs/2.2.11.RELEASE/reference/html/#json-message-converter
I am very new to nodejs and typescript.
I have try to provide an API via express.
I have try to return a custom object on my API who looks like that :
export class Auction {
private _currentPrice:number = 0;
private _auctionName:string;
public constructor(currentPrice: number , auctionName: string) {
this._currentPrice = currentPrice;
this._auctionName = auctionName;
}
/**
* Getter auctionName
* #return {string}
*/
public get auctionName(): string {
return this._auctionName;
}
/**
* Setter auctionName
* #param {string} value
*/
public set auctionName(value: string) {
this._auctionName = value;
}
/**
* Setter currentPrice
* #param {number } value
*/
public set currentPrice(value: number ) {
this._currentPrice = value;
}
/**
* Getter currentPrice
* #return {number }
*/
public get currentPrice(): number {
return this._currentPrice;
}
}
But what I have seen is that the answer of my API is something like :
{"_currentPrice":0,"_auctionName":"toto"}
I was expecting something like
{"currentPrice":0,"auctionName":"toto"}
Is there any way to automaticaly convert it to the format I want ?
This is happening because when the TypeScript is compiled to JavaScript, objects created by that class have public _currentPrice and _auctionName properties (because TypeScript "private" properties are only private in terms of TypeScript's type system) and they don't have their own currentPrice and auctionName properties (they inherit them from their prototype, which has them as accessor properties). JSON.stringify only includes "own" properties.
You can deal with it in a few ways:
By using simple properties for currentPrice and auctionName. You have public accessors for both get and set for both properties, so there doesn't seem to be any reason to use private properties to hold their values. Or,
By providing your own toJSON method for the class:
toJSON() {
return {currentPrice: this._currentPrice, auctionName: this._auctionName};
}
Despite the name "toJSON", this method isn't supposed to return JSON; it's supposed to return the value for the object that should be converted to JSON. So in this case, you return an object with the properties you want the returned JSON to have.
A third solution would be to use JavaScript's own private properties (they're supported in up-to-date Node.js versions) and "own" accessors for them on the objects, but I don't think TypeScript supports JavaScript's private properties yet.
I want to use Java DSL for Spring Integration, but I can't figure out how to use message headers during transformation.
My old implementation had a Transformer like this:
#Transformer(inputChannel = "inputChannel", outputChannel = "outputChannel")
public EventB transform(
EventA eventA,
#Header("a_header") String aHeader,
#Header("other_header") String otherHeader){
return new EventB(eventA.getSomeField(), aHeader, otherHeader);
}
Now I have the following DSL:
#Bean
public IntegrationFlow aFlow(){
return IntegrationFlows.from(EventASink.INPUT)
.filter("headers['operation'] == 'OPERATION_A'")
.transform() //<-- What should I do here?
.handle(Http.outboundGateway(uri).httpMethod(HttpMethod.POST))
.get();
}
I looked at the implementation of transform() method and I found that it can receive a GenericTransformer as parameter, but it seems to work only with message payload and I also need the headers.
I also saw that some kind of reflection can be used, but I don't like it because its not refactor-safe.
Any advice? Thanks in advance.
Since the DSL is a part of the Framework and it is compiled before you start to use it, we can't infer any custom POJO methods, therefore there is no so clean way to count with any custom headers like in your sample.
The closet way to re-use your transform() with those annotations on parameters is with this .transform() contract:
/**
* Populate the {#code MessageTransformingHandler} for the {#link MethodInvokingTransformer}
* to invoke the service method at runtime.
* #param service the service to use.
* #param methodName the method to invoke.
* #return the current {#link IntegrationFlowDefinition}.
* #see MethodInvokingTransformer
*/
public B transform(Object service, String methodName)
So, you would need to declare a bean with that method and use it in the service argument meanwhile mention the method in the methodName argument.
Another way to get access to headers is to request the whole Message type for lambda:
/**
* Populate the {#link MessageTransformingHandler} instance for the provided
* {#link GenericTransformer} for the specific {#code payloadType} to convert at
* runtime.
* Use {#link #transform(Class, GenericTransformer)} if you need access to the
* entire message.
* #param payloadType the {#link Class} for expected payload type. It can also be
* {#code Message.class} if you wish to access the entire message in the transformer.
* Conversion to this type will be attempted, if necessary.
* #param genericTransformer the {#link GenericTransformer} to populate.
* #param <P> the payload type - 'transform from' or {#code Message.class}.
* #param <T> the target type - 'transform to'.
* #return the current {#link IntegrationFlowDefinition}.
* #see MethodInvokingTransformer
* #see LambdaMessageProcessor
*/
public <P, T> B transform(Class<P> payloadType, GenericTransformer<P, T> genericTransformer) {
In this case the code could be like this:
.transform(Message.class, m -> m.getHeaders())
I had the same issue. I needed both headers and payload. After a lot of tinkering I found a solution. I used .handle instead of .transform. GenericHandler's handle method provides both payload and headers.
In your case it would look something like:
#Bean
public IntegrationFlow aFlow(){
return IntegrationFlows.from(EventASink.INPUT)
.filter("headers['operation'] == 'OPERATION_A'")
.<EventA>handle((eventA, h) -> new EventB(
eventA.getSomeField(),
h.get("a_header", String.class),
h.get("other_header", String.class)))
.handle(Http.outboundGateway(uri).httpMethod(HttpMethod.POST))
.get();
}
A message is received on a channel, and is processed by a transformer. The output of the transformer is the following class, which is passed on to the next step in the flow:
public class DomainBean{
public DomainBean process() {
// code
return this;
}
}
Another bean has a #Transformer method which calls the process method on the bean above, as follows:
#Component
public class Handler {
#Transformer
public Object handle(Message<?> message) throws MessagingException {
DomainBean domainBean = (DomainBean) message;
domainBean.process();
return domainBean ;
}
}
Within the IntegrationFlow, the handle method is invoked as follows:
.transform(handler)
Ideally I would like to do away with the Handler bean class, and call domainBean.process() using an object method reference, as follows:
.transform(DomainBean::process)
When I try that, or .<DomainBean, DomainBean>transform(DomainBean::process)
compiler complains that
Non-static method cannot be referenced from a static context
Is there anyway to make this work?
Thanks
Your question isn't clear. There is really this method in the IntegrationFlowDefinition:
* Populate the {#link MessageTransformingHandler} instance for the provided {#link GenericTransformer}.
* #param genericTransformer the {#link GenericTransformer} to populate.
* #param <S> the source type - 'transform from'.
* #param <T> the target type - 'transform to'.
* #return the current {#link IntegrationFlowDefinition}.
* #see MethodInvokingTransformer
* #see LambdaMessageProcessor
*/
public <S, T> B transform(GenericTransformer<S, T> genericTransformer) {
Where that GenericTransformer really can be expressed as lambda or method reference and we have enough tests to confirm that. The code there looks like:
.transform("hello "::concat)
...
.<String, Integer>transform(Integer::parseInt)
...
.<String, String>transform(String::toUpperCase)
...
.<MessagingException, Message<?>>transform(MessagingException::getFailedMessage)
Maybe your problem that you need add exact generics agrs to the method? Therefore this:
.<DomainBean, DomainBean>transform(DomainBean::process)
However what I see that your DomainBean.process() is void. This signature doesn't fit the transformer purpose. Yes, you can do the same with a lambda what you have in the Handler or another solution is to use .handle(). This one really can call void method and, to be honest, that is exactly what fits to your logic - there is no any transformation logic so far.
However when service method is void there is no any continuation after this method call in the flow. Such a .handle() must be the last one-way endpoint in the flow definition. The void is equal to the Outbound Channel Adapter.