Re: Custom component for weird legacy format
Hi all, many thanks for your helpful responses. As I don't have to deal with headers I'll write a custom DataFormat. Regards, Frank -- View this message in context: http://camel.465427.n5.nabble.com/Custom-component-for-weird-legacy-format-tp5733030p5733070.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Custom component for weird legacy format
I don't think we need to write a customer HTTP binding this time, writing a custom Data Format should be enough. If you have some special HTTP header need to deal with, you may consider to write that HTTP binding. -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Friday, May 24, 2013 at 1:03 AM, Raul Kripalani wrote: > Hi Frank, > > By no means do you need to write a custom component! Camel has a lot of > features to help you in processing and/or transforming the message. > > First of all, take a look at our Data Formats [1] and see any can help you > digest the message. Of special relevance in your case are Bindy, Flatpack, > BeanIO, etc. > > If none helps you, you need to think what "overcoming this mess" actually > means. Do you mean transforming the content into a POJO? Or into another > serialized format for which there are more processing options readily > available, e.g. XML, JSON? > > Your solution could be as simple as a Bean that transforms the message into > something higher-level, if this is just a one-off case in your integration > middleware platform (one service, one operation). If it's a recurring > scenario, you're seeking something reusable and pluggable: > > - If all your interactions are over HTTP, you can consider a custom HTTP > Binding for camel-jetty [2]. > - If you're targeting a variety of protocols, you want something more > higher-level, in which case you can create your own custom Data Format [3]. > > To sum up, with Camel you normally don't need to create custom components, > unless you're interfacing over/with a new protocol, technology or > communication channel for which a component doesn't already exist (somewhat > unlikely). > > Hope this helps, > > [1] http://camel.apache.org/data-format.html > [2] http://camel.apache.org/jetty.html#Jetty-CustomizingHttpBinding > [3] http://camel.apache.org/custom-dataformat.html > > *Raúl Kripalani* > Enterprise Architect, Open Source Integration specialist, Program > Manager | Apache > Camel Committer > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Thu, May 23, 2013 at 2:56 PM, Frank Ertl < > frank.e...@f-i-solutions-plus.de (mailto:frank.e...@f-i-solutions-plus.de)> > wrote: > > > Hi everybody, > > > > we have to implement a route that listens on a defined http-port and > > receives a message with a very strange legacy format. Partly XML, partly > > TLV > > (tag-length-value). > > I wonder what would be the best option to overcome this mess. Writing a > > custom component that could work as a consumer endpoint (somehow using > > jetty, maybe by extending the jetty-component) or would it be better just > > to > > write a new TypeConverter and call convertToType after receiving the > > message > > via the jetty-component? > > What would you propose? > > > > Regards, > > Frank > > > > > > > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/Custom-component-for-weird-legacy-format-tp5733030.html > > Sent from the Camel - Users mailing list archive at Nabble.com > > (http://Nabble.com). >
Re: Custom component for weird legacy format
Hi Frank, By no means do you need to write a custom component! Camel has a lot of features to help you in processing and/or transforming the message. First of all, take a look at our Data Formats [1] and see any can help you digest the message. Of special relevance in your case are Bindy, Flatpack, BeanIO, etc. If none helps you, you need to think what "overcoming this mess" actually means. Do you mean transforming the content into a POJO? Or into another serialized format for which there are more processing options readily available, e.g. XML, JSON? Your solution could be as simple as a Bean that transforms the message into something higher-level, if this is just a one-off case in your integration middleware platform (one service, one operation). If it's a recurring scenario, you're seeking something reusable and pluggable: - If all your interactions are over HTTP, you can consider a custom HTTP Binding for camel-jetty [2]. - If you're targeting a variety of protocols, you want something more higher-level, in which case you can create your own custom Data Format [3]. To sum up, with Camel you normally don't need to create custom components, unless you're interfacing over/with a new protocol, technology or communication channel for which a component doesn't already exist (somewhat unlikely). Hope this helps, [1] http://camel.apache.org/data-format.html [2] http://camel.apache.org/jetty.html#Jetty-CustomizingHttpBinding [3] http://camel.apache.org/custom-dataformat.html *Raúl Kripalani* Enterprise Architect, Open Source Integration specialist, Program Manager | Apache Camel Committer http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Thu, May 23, 2013 at 2:56 PM, Frank Ertl < frank.e...@f-i-solutions-plus.de> wrote: > Hi everybody, > > we have to implement a route that listens on a defined http-port and > receives a message with a very strange legacy format. Partly XML, partly > TLV > (tag-length-value). > I wonder what would be the best option to overcome this mess. Writing a > custom component that could work as a consumer endpoint (somehow using > jetty, maybe by extending the jetty-component) or would it be better just > to > write a new TypeConverter and call convertToType after receiving the > message > via the jetty-component? > What would you propose? > > Regards, > Frank > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Custom-component-for-weird-legacy-format-tp5733030.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: Custom component for weird legacy format
Hi, Am Do, 23. Mai 2013, um 15:56, schrieb Frank Ertl: > just to write a new TypeConverter and call convertToType after receiving the > message via the jetty-component? This should not be too difficult. Parsing the Exchange body sounds like the difficult part, not receiving it via HTTP. You could even configure a Restlet consumer that doesn't care about the body. Lutz -- Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/ Looking for an email service? Try FastMail! http://www.fastmail.fm/?STKI=600622 http://fixtracking.com/ | http://dontbubble.us/ | http://donttrack.us
