Petals SE Camel

Postponed to 1.2.1

One of the most problematic things arrising with this issue is the following:

• Currently, when using Camel as a BC for incoming external events (i.e., having a route with a from that is not from petals), the flow are initialised at the moment the Petals service is called by the Camel SE.
• So whatever happens before in the Camel SE (such as processing, execution, logging, etc), is NOT associated by the Camel SE to the current flow.

The solution would thus be to:

• Detect that a route is starting but not from Petals
• To initialise the flow just before and log the ConsumesExt MONIT trace.

This is not easy, as we have to plug in Camel infrastructure.
This is maybe not desired as it goes a bit agains SOA principles by doing the bindings to external events inside Camel instead of isolating it in a dedicated service.
This is maybe better if we can do it anyway because Camel is really helpful in many tricky situation where we need to interact with systems other than those supported by the Petals BC.

Reopening because there is more work to do

A preliminary fix is in v0.5.1 (and thus will be in 1.0.0 at least).

A first shot has been committed in https://github.com/petalslink/petals-se-camel/commit/da06d89edcef18a20dbe9fba39bf355bd2793514 and https://github.com/petalslink/petals-se-camel/commit/134af0dbd1e4e51b22af3eb6fb5cde1c26d3f5a2 (for Petals 4.3.x).

For now it considers that if there is no flow attributes available in the execution context, it means that we are acting as a BC.
A warning is logged to keep some traces of that assumption and then ConsumesExtFlow... MONIT traces are logged (ConsumesFlow... in Petals 4.3.x) around the call to the Petals service.

We could at least initialize the a flow if there is no flow attributes presently available (most certainly because the exchange never entered in Camel from Petals) when the exchange is sent from Camel to Petals.

We should log a warning in that case to be sure we don't overlook another problem: this wouldn't solve this issue, but at least it would make it less problematic (see for example PETALSSECAMEL-10 for a case where it would be nice).