Hi JB, thanks for your reply. First of all, your needs look like the servicemix pdfcomposer that I'm > creating currently. The PDF composer could take XML data, populate a PDF > template with XML data (xpath or marshaler) to generate a new PDF doc. > I plan to complete this new component is around two weeks. >
In this specific case the pdf is already populated but the one your describe could easily be a future scenario. I'll check it when available even if we are working on the 3.2.3 version. > Anyway, in your case, you need: > 1/ a servicemix-file poller endpoint to read XML files (and send XML > messages in the NMR). > 2/ you can create your own bean to get incoming XML files and make your > business. This bean can be exposed in ServiceMix using servicemix-bean > component. > 3/ If you want to send the data directly, your bean can send to a > targetService/targetEndpoint. This targetEndpoint could be a HTTP provider > endpoint (or CXF-BC provider endpoint). > If you want to send data as attachment, I think that you need to implement > the WebService call directly in your bean (using CXF for example). > Calling the WS in the bean looks like something hardcoded this is why I do no feel sure about it. I could implement this writing only one component or I could write two: the first one reading the file and creating the document on the relational db followed by another looking up again the document from the db and invoking the final WS. Maybe this last step could be again split in two components. At first I would expect the fewer components the better (less config, files, etc.) but this means to hardcode more things. Is it just a trade off between configuration complexity vs configurability? Are there any simple guidelines to choose one option over the other? Even articles, books o sample apps where this is discussed could be useful. If you use JBI packaging, it's not possible to place the poller and consumer > in the same XBean as it's based on two different components. So you need one > SU based on servicemix-file component (with one xbean.xml) and one SU based > on servicemix-http/servicemix-cxf-bc component (with one xbean.xml) and > assemble both in a SA. > I missed this point. To me this is a big issue that leads to many micro maven project with dependencies difficult to see. > To be honest, I can't really see the advantage of using ODE in your case. > What workflow/business logic you want to implement with BPEL/ODE ? > > This is a three step process, single flow so there is not much to coordinate. I expect there could be two reasons for using ODE: 1. to be able to see if the flow it's still running, on which step it's waiting and so on using ode API. I never did this but I was told there is a part of our codebase to do this. 2. to describe the whole flow in a single location instead of having it fragmented in several xbeans files. As I told I'm new to smix so maybe this is not correct. Bye Lorenzo
