Connectors for Camunda

[rocky...@gmail.com]

Hello,

is it possible to get connectors for Microsoft Exchange, MSSQL Server or other systems? So that not everyone must develop it by self.
Example: I want create a appointment in Microsoft Exchange after someone after someone takes a vacation request.

thx for answers

[Daniel Meyer]

Hi Rocky,

welcome to the users' list.

Mssql server should be accessible using default Java JDBC API. You could
write a service task which uses a Java Delegate Implementation.
http://docs.camunda.org/api-references/bpmn20/#!/tasks/service-task

As for MS Exchange, at the moment there are no such ready to use
connectors available.
One of the reasons is that most of the time, requirements to such a
connector are kind of project-specific which makes it hard to write a
one-size-fits-all connector that everybody can use for all kind of
requirements.
On the other hand: if you are interested in writing an exchange connector,
we would be happy to assist you and potentially host it as a "incubation
project" so that other people can find and extend your code.
https://github.com/camunda/camunda-bpm-incubation

Cheers,
Daniel Meyer
Project Lead
www.camunda.org/community/team.html

[rocky...@gmail.com]

Hello Daniel,

thank you for the very fast answer!
The MSSQL connection should be no big problem and i heard you are working on a ldap authentification for sso, this is fine.
The background of my question is my bachelor thesis with the topic to find a workflow-management-system for our company.I tested some systems and until now i like camunda very much.
One important demand is the connectivity to our other systems (Exchange, Database, ActiveDirectory and abilitys to develop a connector for special systems like our ERP System). It would be nice if in future the community can develop and share their created connectors :)

best regards

[Bernd Rücker (camunda)]

Hi Rocky.

How do you like the idea of using an integration framework like Apache
Camel or even an ESB like Mule for leveraging the connectors already
available there?

Would be interesting to get feedback on this - as I think the preferred
way is to leverage existing connectors instead of building our own ones.
Or no?

Cheers
Bernd
Evangelist & Consultant
www.camunda.org/community/team.html

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von
rocky...@gmail.com
Gesendet: Montag, 15. Juli 2013 16:40
An: camunda-...@googlegroups.com
Cc: rocky...@gmail.com
Betreff: Re: Connectors for Camunda

--
You received this message because you are subscribed to the Google Groups
"camunda BPM users & process application developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.

[rocky...@gmail.com]

Hi Bernd,

until now I`am not the Java and ESB specialist, but the idea is interesting.
Do you want to integrate this into camunda or use it additionally to camunda?
Currently we are having a commercial ESB in our company and for everything someone must write a connector. At the moment the most important connector for me is the Microsoft Exchange Server and Active Directory and i cant find some connectors for these systems to leverage.

Cheers

[Bernd Rücker (camunda)]

Hi Rocky.

For LDAP as an example I did a quick check (read: google ;-)) and found a
LDAP connector in both worlds: http://camel.apache.org/spring-ldap.html;
http://www.mulesoft.org/connectors/ldap-connector.

But it indeed requires that you have these frameworks available. If you do
not need a full blown ESB Camel would be a good choice as it is a simple
framework which can be easily leveraged within camunda BPM without big
overhead - so it is some kind of integration - but the integration layer
will be pretty thin. At the moment we only have an example demonstrating
the use of Mule within the JBoss distribution of camunda BPM:
https://github.com/camunda/camunda-bpm-examples/tree/master/bank-account-o
pening-camel. I plan to start an incubation for an out-of-the-box Camel
integration soon.

What enviroment do you have in mind (Tomcat? JBoss? ...)?

Cheers
Bernd

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von
rocky...@gmail.com

Gesendet: Mittwoch, 17. Juli 2013 09:06

An: camunda-...@googlegroups.com
Cc: rocky...@gmail.com
Betreff: Re: Connectors for Camunda

[Bernd Rücker (camunda)]

P.S: I am pretty sure that you can leverage the Spring LDAP connector in
pure java (meaning a JavaDelegate in "plain" camunda BPM) as well - maybe
that's even easier in your case...

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com

[mailto:camunda-...@googlegroups.com] Im Auftrag von Bernd R�cker
(camunda)
Gesendet: Mittwoch, 17. Juli 2013 09:21
An: rocky...@gmail.com; camunda-...@googlegroups.com
Betreff: AW: Connectors for Camunda

[rocky...@gmail.com]

Hi Bernd,

yes, i only searched for Microsoft Exchange until now. I will later test your "bank-account-o-pening-camel" example, it sounds good.
All environments are possible, but i prefer tomcat because our ERP-System use it and i think it will be easier to connect to this.

cheers

[Bernd Rücker (camunda)]

OK - for Tomcat you will have to adapt the example (as it currently uses
CDI - in Tomcat you would have to switch to Spring - but it would run more
or less the same despite that)

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von
rocky...@gmail.com

Gesendet: Mittwoch, 17. Juli 2013 09:33

An: camunda-...@googlegroups.com
Cc: rocky...@gmail.com
Betreff: Re: Connectors for Camunda

[rocky...@gmail.com]

Iam sure that it is no Problem for me to use jBoss too, i will test it. But what i dont understand: what is the advantage to use the additional ESB (Camel or Mule) instead to write a connector for Camunda (As example for a system where no ready connector for Camel or Mule is avaible)

[webcyberrob]

Hi there,

From my perspective, Im a big advocate of process logic in the BPM engine, integration logic in the ESB layer, even for a simple email. My rationale is an ESB is usually a highly available infrastructure with lots of routines for communications/error recovery etc, whereas rolling this into process logic becomes very difficult. Hence in the email case, I can put a message on a JMS queue and its a fire and forget. Hence my process logic may only ever need to deal with on-premise JMS integration which is reliable, predictable etc and thus the process logic just has to do what it does best. The ESB can now pull a message off the queue and send to an SMTP service with retry etc...Now think about integration to the cloud. Again do you want to couple your process flow logic to the unreliable integration to the cloud, or just put a message on a local queue and let the integration infrastructure take care of it...

R

[rocky...@gmail.com]

Hey Rob,

your arguments are very plausible for me. Especially the email case. So i must now decide if i use our working ESB (Sonic ESB based on Apache Camel) or wait for the out-of-box camel integration from the camunda Team.

cheers

[Bernd Rücker (camunda)]

Hi Rocky.

 

I agree that complex integration logic should be addresses in a integration framework or some ESB. But I strongly disagree that you need to decouple via JMS. This adds another layer of complexity (basically JMS and especially monitoring it) – and it is not necessary as the process engine has these capabilities as well (we have “asynchronous continuation” with retry configuration capabilities, see https://app.camunda.com/confluence/display/foxUserGuide/Thread+and+Transaction+Management).  This has the advantage that you see all failures and retries within your process monitoring (cockpit in our case) and have all information in one place.

 

You could argue that this should be decoupled of the process as consumer of the service and handled by the provider (in the “pure” view of SOA) – but I never saw that working in real life. So we have really good experience with not forcing JMS or some kind of ESB. This still allows to use an integration framework like Mule or Camel – as they do not force you to be asynchronous or use JMS.

 

And I would not be too dogmatic about it – sometimes just sending the email is waaay easier and sufficient for the use case – then just do it (my opinion).

 

My two cents :-)

Cheers

Bernd

 

Von: camunda-...@googlegroups.com [mailto:camunda-...@googlegroups.com] Im Auftrag von webcyberrob
Gesendet: Mittwoch, 17. Juli 2013 12:00
An: camunda-...@googlegroups.com
Cc: rocky...@gmail.com; rocky...@gmail.com
Betreff: Re: Connectors for Camunda

 

Hi there,

--

[webcyberrob]

Hi Bernd (& Rocky)

You're right and I was over simplifying a bit with the email, in reality its the quality of service which really determines what integration style we use, and it does not have to be JMS, web service to a local ESB can be useful... I tend to work on systems with millions on processes a day and thus reliability is often front of mind ;-)

R