Petals SE Camel

JBI of camel su

Petals log file with executing se

Hi,

It would be simpler with debug logs.

What seems strange to me is that the component "petals-bc-shell" logs invalid MONIT traces: there is missing flow attributes (you can see the flow*Id are null).

That's why it fails after.
I will fix that at the Camel level (checking for missing MONIT traces), but you won't have any meaningful MONIT traces until you fix this "petals-bc-shell" (that is not one of our components .

Edit: I may be wrong, I will investigate more

Ok, now it's clearer, it is linked to PETALSSECAMEL-9.

The thing is that at first the Camel SE wasn't meant to be used as a BC (i.e., starting new flows of exchange without having one entering first).

I will commit something today and then you can use the development version (which mostly contains bugfixes since version 0.5.0).

In a strict SOA point of view, this use case should be exploded in two parts:

1. the consumer part that is the file presence should be assumed by a service unit deployed on Petals BC FileTransfer: when the file 'file:///XXX' occurs, the Petals BC FileTransfer will invoke the service provider available on the SE Camel,
2. the provider part implemented with the SE Camel and embedding the Camel route defined below without the part 'file'.

Ok, normally it should be fixed in https://github.com/petalslink/petals-se-camel/commit/655dc21e506cecab9127e378ab498d6f890fc428

You can either choose to only apply this diff to version 0.5.0 or directly use the development version 0.5.1-SNAPSHOT (which contains various fixes).

Note that it's normal that you don't see any MONIT traces (or that they have null values, not sure... normally there should be the traces but the ids would be null...) because of PETALSSECAMEL-9 as explained before.
The MONIT trace is logged when the Petals provider is executed, so it's not handled by the the Camel SE in your case.
But maybe, if after applying the fix you don't see any MONIT traces, then there is a bug, could you report it (in the Petals CDK project in Jira) in that case? Thanks!

I will look at PETALSSECAMEL-9 in the near future when I have time

Note also that if you follow Christophe's advice by separating the service responsible for reading files (with filetransfer) from the service doing the integration (with camel) then the problem of PETALSSECAMEL-9 won't apply to your case then (and actually, you shouldn't even see the bug you just reported!).

Hi Victor, Hi Christophe,

I notice christophe's advice and we effectively can do this (BC FT -> SE Camel --> BC).
But i think a strenght of SE Camel is also to be able to consume petals service through a lot of
other protocol (for example, you don't have BC-Hazelcast, it become possible to define one with this SE...). We plan to use this se-camel for EIP integration but also for external protocol integration (our use case with file is also to test these functionnality).

Victor, i see your code modification : to be honest i'll done the same this morning before opening this defect, and i see anothers errors in log file : to be sure, i'll test with your 0.5.1-SNAPSHOT (if you done other modifications...)
I keep you informed.
Regards.

Ok, I would need the logs in debug mode (to see the details of what is happening at the camel level so, FINEST on the components, but also on org.apache.camel), or even better, an example standalone project that illustrates the problems, because it's difficult for me to fix things without actually executing anything.

Thanks!

Sorry but i know your release maven repo (http://maven.petalslink.com/libs-release/; even if we get petals-se-camel from public repo) but not your snapshots one : is it possible for you to give me its URL to declare it in our nexus's proxy please ?

Victor, i send you by mail and extract of maven module (notice some configurations properties). I'll give you details in mail.

Finest log with base of project i sended to you yesterday

Maven artefacts are now on Maven central for released one, and ow2 for snapshot ones, but I don't think it is documented, we should do it (maven.petalslink.com should not be used anymore).
For now you can find the latest version of the SE Camel there: http://repository.ow2.org/nexus/content/repositories/snapshots/org/ow2/petals/petals-se-camel/

I got your email, I will take a look and see directly with it if I can do something with that, thanks!

Ok so, everything seems to work perfectly (in the constraints of PETALSSECAMEL-9 of course).

I get the following traces when executing your example:
sample-0 2015/09/30 11:39:18,166 GMT+0200 FINEST [Petals.Container.Components.petals-bc-shell] : Process an exchange as PROVIDER with id : petals:uid:1ed2df20-6757-11e5-903f-0090f5fbc23b
sample-0 2015/09/30 11:39:18,169 GMT+0200 MONIT [Petals.Container.Components.petals-bc-shell] : traceCode = 'provideFlowStepBegin', flowInstanceId = null, flowStepId = null, flowStepInterfaceName = '{http://jaxb.bss.ocb.orange.com/}ShellService', flowStepServiceName = '{http://jaxb.bss.ocb.orange.com/}ShellService', flowStepOperationName = '{http://jaxb.bss.ocb.orange.com/}execute', flowStepEndpointName = 'ShellServiceSatinMassCommandsPort', flowPreviousStepId = null

followed by

sample-0 2015/09/30 11:39:18,184 GMT+0200 MONIT [Petals.Container.Components.petals-bc-shell] : traceCode = 'provideFlowStepEnd', flowInstanceId = null, flowStepId = null

It is what is normally expected: there is one service call happening in the bus, to petals-bc-shell, and it begins and then ends.

FYI, there is a preliminary fix for PETALSSECAMEL-9 and the version 0.5.1 of the Camel SE is going to be released soon with it.

Petals SE Camel 0.5.1 was released. It is available here: http://repository.ow2.org/nexus/content/repositories/public/org/ow2/petals/petals-se-camel/0.5.1/petals-se-camel-0.5.1.zip

Hi.
Test done with Petals SE Camel 0.5.1.
There's no more error logged and route is correctly executed but no MONIT log yet.
Maybe petals's version problem (we always use 4.2 version)

After discussing with Fabrice, we clarified that it is not a problem with MONIT log but with Camel logs not being outputed in the log file for the current flow.
This is caused by PETALSSECAMEL-9: the flow is initialised just before the message is sent to the bus (and not when the first external event from the camel file component happens), and whatever is happening before that point is internal to Camel and Petals can't know that it has to associate the Camel logs to this very flow.
This is to be expected as the Camel SE is not really meant to be used like this in a SOA context, even though it would be best if we could cope with it.
Discussion should thus continue in PETALSSECAMEL-9 where I will make note of this important point.

Yes. And after a quick test with version 4.3, MONIT log are produced. It's just a little problem with the unsupported couple petals 4.2/SE Camel.
Subject close for me. Thanks for you help Victor & Christophe.