nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Integrating Activiti with Apache Camel

mproch

Hello,
I created simple component for integration of Activiti with Apache Camel (http://camel.apache.org/).

There are two use cases:
- implementing receive tasks using camel, so that one can write camel route:

from("direct:a").to("activiti:simpleProcess:receive");‍

which signals activity with id receive in process simpleProcess i.e.

<receiveTask id="receive" name="Wait State" />‍

- implementing service tasks using camel, so that one can write:

from("activiti:simpleProcess:serviceTask").setBody().property("var1").
                to("mock:service1");‍‍

and in process code sth like:

<serviceTask id="serviceTask" activiti:delegateExpression="${camel}"/>‍

(where var1 is name of process variable).

In the future I hope it would be possible to integrate it with OSGI deployment, especially when http://jira.codehaus.org/browse/ACT-324 is resolved. It would be also good to find some nicer way of invoking camel from activiti process.

The code is on github: https://github.com/mproch/camel-activiti.
I would be happy to contribute it to Activiti.

what do you think about it?
maciek

Find more posts tagged with

Comments

tombaeyens

sorry for the late reply. can you elaborate on what exactly you want to contribute to activiti?
fyi: we don't know camel, but we're interested in the integration.

mproch

Thx for answer.

1. Apache Camel - http://camel.apache.org/
Camel is a integration framework based on known Enterprise Integration Patterns with powerful Bean Integration.
It's somewhat similar to Mule, the main differences are:
a) Camel is more a library than container - it can be embedded in virtually every environment - one of most common usages is acting as EIP implementation for Apache Servicemix ESB - http://servicemix.apache.org/home.html, or Apache Karaf OSGi container - http://karaf.apache.org/
b) Camel's strong point is Java DSL, which allows for easy definition of integration routes (called flows in Mule)
What's more:
a) It's v. easy to add new components (called modules/transports in Mule) - there are more than 70 I guess - http://camel.apache.org/components.html.
Components are autodiscovered on classpath, and identified by uri (e.g. file:///tmp - identifies endpoint reading or writing files to folder /tmp, jsm:topic:myTopic - identifies endpoint publishing or subscribing to myTopic)
b) It's very easy to integrate Camel with spring or OSGi Blueprint

2. What we want to doOur main use case is to be able to deploy Activiti processes in OSGi container. We use mainly Camel for our integration needs, so we thought it'd be nice to be able to perform integration (both calling services from process, and processes waiting for messages from external systems) by custom Camel component.

3. How would it work?
The process would be deployed as a OSGi bundle, together with appropriate camel context, using OSGi deployment model currently available in Activiti.
https://github.com/mproch/activitiCamelKarafSample/tree/master/process/src/main - here is sample project structure.

a) setup
This part is a bit tricky.
First, you have to create CamelBehaviour class, which has to know which camel context (there could be many for many processes) should be invoked.
Here: https://github.com/mproch/camel-activiti/blob/master/sample/src/main/resources/camel-activiti-context.xml is the example for monolithic environment, in OSGi context one has to use OSGi services,
as it's done here:
https://github.com/mproch/activitiCamelKarafSample/blob/master/bundle/src/main/resources/OSGI-INF/blueprint/context.xml, https://github.com/mproch/activitiCamelKarafSample/blob/master/process/src/main/resources/META-INF/spring/context.xml. For OSGi example I had to do some extesion of activiti-osgi to be able to use blueprint beans in activiti expressions, btw.

b) invoking Camel route from ServiceTask.
In process code, it's as simple as adding
<serviceTask id="serviceTask" activiti:delegateExpression="${camel}"/>
Then CamelBehaviour is responsible for finding Camel route starting with
from("activiti:camelProcess:serviceTask")….)(camelProcess is the processName). Exchange is created with empty body, and process variable values as properties (maybe some better solution is needed), and passed to the route, e.g.

from("activiti:camelProcess:serviceTask")<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .to("log:smileytongue:l.touk")<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .setBody().property("var1")<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .to("file:///tmp/activiti/serviceTask");<br>

will log contents to 'pl.touk' log appender and then create file in /tmp/activiti/serviceTask, with value of process variable var1 as content.

c) Invoking process by camel.
When process is in receive node:
<receiveTask id="receive" name="Wait State"/>it can be invoked (signaled) by following camel route:

<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from( "file:///tmp/activiti/receive")<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .convertBodyTo(String.class)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .setProperty("PROCESS_KEY_PROPERTY").xpath("//@key")<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .to("activiti:camelProcess:receive");<br>

It scans /tmp/activiti/receive directory. When file appears, it's parsed as XML and attribute key is set as process business key. Then Camel component looks for process instance of camelProcess with this key,
waiting in activity named receive. Then it signals this process, it also passes exchange properties as process variables (probably need some better solution).

Summary:
This component is not a rocket science, especially configuration is slightly awkward in OSGi environment, but it enables us to leverage power of Camel in Activiti. Guess it would serve some similar role as Mule integration, but for Apache Camel users, which are also quite numerous

davsclaus

sorry for the late reply. can you elaborate on what exactly you want to contribute to activiti?
fyi: we don't know camel, but we're interested in the integration.

Hi Tom

What do you mean with you don't know Camel? We spoke at the Devoxx 2010 conference

You and Tijs came by the FuseSource booth.

I had a look at the activiti-camel component and it seems good work.

Maciek also posted on the Camel forum
http://camel.465427.n5.nabble.com/Integrating-camel-with-activiti-tp3331707p3331707.html

So we are talking about where the component should live. Obviously we can host it at Apache Camel.
But I wonder the Activiti team plans to host integrations to 3rd party as well? If so maybe this component is better hosted at Acitivi.

/Claus Ibsen
http://davsclaus.blogspot.com/

gnodet

If Maciek had not worked on the the Camel component, it was on my todo list for activiti anyway, but I'm glad it's done.
I think it would make sense to host it in Activiti …

agoncal

Hi Maciek,

First of all a little disclaimer : I've just discovered Camel and don't know much about Activiti. This being said, here is my use case.

The project I'm currently working on uses Camel. There are plenty of Camel routes, all completely stateless and it works fine. Now we need to go further and we are talking about workflows : we need to take some of these routes, link them together, know at which step of the workflow an error occurred… and so one. So basically we need to orchestrate our Camel routes.

Would your component allow this kind of things ? Can I use Activity processes to invoke Camel routes in a seamless way ? In our use case I still don't see the inverse conversation (Camel routes accessing Activity) but I definitely need Activity to orchestrate Camel.

Thanks,
Antonio

richardketteler

+1 for having Activiti/Camel integration. With Mule and Spring Integration support in the pipeline it makes sense to also add Camel integration. Then Activiti will have support for three leading open source integration platforms: Mule, Spring Integration and Camel.

trademak

Hi,

This is great stuff!
I think this would be a good addition to the Activiti framework.
I'll have to play a little bit with the code to get a really good grasp on it, but this sure looks very promising!

Best regards,

tombaeyens

Looks very interesting and promising indeed.

We're certainly open to accept all code in our codebase which is appropriate to be included in Activiti. Ideally one contributor would take the lead and tries to find consensus. There seem to be multiple people interested in contributing this. Who all is volunteering to lead this Activiti code base part of the Activiti-Camel integration?

My guess would be that the Activiti-to-Camel integration should be contributed to Activiti. Ideally that would be a service task that calls out to Camel.

I would think that the camel routes that call out to Activiti would be best contributed to the camel project.

Does all this make sense?

I don't yet see the value of OSGi deployment of processes. As the process instances live in the DB. And the process instances have a reference to the process definition. If the process definition lives on the classpath (or in this case as an osgi bundle) then the process instance can get easier out of sync with their process definition. And this gets even more tricky in cluster situations. If someone wants to contribute OSGi deployment of business archives or processes, I would like to get a better understanding of why that is considered beneficial over the storage of business archives in the DB as we do now.

tombaeyens

…one more thing: if you think that it's best to host the camel routes code also at Activiti, I'm definitely OK with that!

mproch

Hi,
thanks for feedback to everyone,

I think it would be easier to host both invocations camel->activiti and activiti->camel in same project. I guess it would be difficult for camel to have two separate components with one uri schema. I think that most usecases would involve integration in both ways, anyway.

As for OSGi deployment of business archives/processes - it's already contributed I believe - in activiti-osgi module? At least I'm using it

I agree that keeping DB and OSGi container in sync is tricky. I believe that the biggest advantage would be to be able to deploy java classes with process files - but for that classloading mechanism would have to be extended. There is already issue on that: http://jira.codehaus.org/browse/ACT-324.

davsclaus

Yes it only makes sense to have one module with the activiti-camel integration. The module should work both ways.

And that's what the current logic could easily be extended to do.
The Camel Component API has APIs for such use-cases (consumer and producer).

/Claus

tombaeyens

Maciek, are you interested in bringing that code to Activiti codebase?
If yes, then here's instructions on how to get started as an Activiti developer: http://docs.codehaus.org/pages/viewpage.action?pageId=163872771
We will guide you through all those steps and support you in making the contribution.

mproch

Hi Tom,
yes, I would be very pleased to do this. I will send you the contribution agreement and prepare the code to be included - add some docs, rename packages and so on.

thanks,
maciek

bernd_ruecker

Interesting initiative. Looking forward to it!

Can anybody maybe provide a small "near real life" example using it end to end? That would be really interesting to see the whole picture.

Since we currently started a project caring about the correlation of asynchronous responses (beside other stuff), could Camel handle that as well somehow? I currently assume the Camel stuff is stateless, or am I wrong on this?

mproch

Bernd,
first version of code is already in svn - it still needs some changes, though. I will try to make some more decent example in next days and put it on my github

As for Camel - yes, it's basically stateless, however, there are some features that enable keeping state between exchanges, for example using http://camel.apache.org/hawtdb.html. With some effort, I think it would be possible to handle asynchronous responses - although I'm not really sure about it.

I read your blog about asynchronous responses - it looks really interesting, but looking at the post and camunda fox psi project but I still don't see how would you like to handle such situations - i.e. how would code & configuration look like.
But maybe this starts to become slightly non-activiti topic

bernd_ruecker

Okay, waiting for easy to understand examples 🙂

For PSI: We just started. Give us some weeks to present an easy to understand example for you in this case (working out of the box with Activiti and jBPM 3 :-)). We do this together with a customer in an enterprise environment with multiple clusters and huge amounts of processes. So hawtdb doesn't sound like an option 😉

Cheers
Bernd

davsclaus

Hi

Just wanted to know how the Activiti - Camel module is going?
Is there anything the Camel community can do to help?

psiva

Any update on the examples and notes. Could you please point to where I can find them if they are already are?