Time is the best teacher. :)
I've found a way to do a processing message after activity receives it - with
interceptors. There some exceptions, but both persistence and processing works.
Solutions looks next:
interceptFrom("activemq:incoming")
.split(body())
.multicast()
.to(sys1.getEndpoint())
.to(sys2.getEndpoint())
.end()
.end();
Łukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez Łukasz Dywicki w dniu 2012-01-11, o godz. 11:48:
> Hey Hadrian,
> I started investigating the camel-bam code and one from statements I wrote is
> not true. The Process name can be set by calling the ProcessBuilder
> constructor. The Process-N name is a default behaviour.
>
> Also, if it makes a sense to support delaying the activity? Eg making an
> activity suspended? I don't see use of it in my case so far, but that's might
> be required by other processes.
>
> Łukasz Dywicki
> --
> Code-House
> http://code-house.org
>
>
> Wiadomość napisana przez Hadrian Zbarcea w dniu 2012-01-11, o godz. 03:29:
>
>> Lukasz, do you mind opening a jira with your findings?
>> Thanks, Hadrian
>>
>> On 01/10/2012 06:36 PM, Łukasz Dywicki wrote:
>>> Hey everyone,
>>> I tried yo use camel-bam and it works for very basic example shown in
>>> documentation. It works well for correlating the files without any middle
>>> processing steps.
>>>
>>> The process I try to monitor looks following
>>>
>>> - receive incoming JMS message - split - multicast (queue1, queue2)
>>>
>>> So I've build a following configuration for the process:
>>> ValueBuilder correlation = header("JMSCorrelationID");
>>> ActivityBuilder incoming =
>>> activity("activemq:incoming").correlate(correlation).name("incoming");
>>>
>>> ActivityBuilder sys1 =
>>> activity("amq2:queue1").correlate(correlation).name("system1");
>>> ActivityBuilder sys2 =
>>> activity("amq2:queue2").correlate(correlation).name("system2");
>>>
>>> sys1.starts().after(incoming.starts());
>>> sys2.starts().after(incoming.starts());
>>>
>>> But after receiving messages and initializing a process instance nothing
>>> happens. Er it happens, the activity is created. I can not reuse a
>>> incoming.getEndpoint to create an from statement and process message.
>>> Multiple consumers on same destination are not allowed.
>>>
>>> Issues I've discovered:
>>> - Lack of support for parallel activities.
>>> - No support for processing received message. Usually a incoming message is
>>> only a entry point for a process.
>>> - No support for a custom process names. Not everyone are happy with
>>> Proces-N name. A ProcessBuilder extensions can't change a naming schema.
>>> - Activity definition is not put into the database as long as it is not
>>> called by flow. Process is created and the activities are known, but
>>> they're not persisted before processing. So whole definitions are useless
>>> if we would like display process definitions somewhere else.
>>> - Hard coded dependency to JPA, can't be replaced by alternative way of
>>> storing process definitions eg like in IdempotentRepository.
>>>
>>> These issues makes a camel-bam useless in my case. Should I use an
>>> alternative tool like activiti-camel integration? It's fine but I don't
>>> need whole BPMN, diagraming. I want to track a flow between systems in an
>>> easy way, there is no human tasks, only service calls and camel logic.
>>>
>>> Łukasz Dywicki
>>> --
>>> Code-House
>>> Krasiczyńska 3/80
>>> 03-379 Warszawa
>>>
>>>
>>>
>>
>> --
>> Hadrian Zbarcea
>> Principal Software Architect
>> Talend, Inc
>> http://coders.talend.com/
>> http://camelbot.blogspot.com/
>
