camel flatpack component shortcomings

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

camel flatpack component shortcomings

Ronny Aerts
Hallo camel community,

I am a heavy user of camel in the integration projects in the company I work for. We use camel 2.15.2 and all routes are defined using spring dsl (no java).

I have to do several fixed-length conversions where I have a lot of differences per line in the file. Each line contains some kind of record type field the beginning of the line.

I came across the camel flatpack component<http://camel.apache.org/flatpack.html> to fulfill my request using the "fixed" format with pzmap/record definitions. I decided to use the flatpack dataformat<http://camel.apache.org/flatpack-dataformat.html> to do the actual conversion (unmarshal) as shown below.
<unmarshal>
            <flatpack fixed="true" definition="whorder/PEOPLE-FixedLengthWithHeaderTrailer.pzmap.xml"/>
      </unmarshal>
I have several points about this unmarchal:

1.       The output of the unmarchal is a org.apache.camel.component.flatpack.DataSetList and although it is not so difficult to process in java, it is more difficult in spring dsl. I didn't found any camel convertor from org.apache.camel.component.flatpack.DataSetList to anything so I created one to convert to an ArrayList. A standard camel converter for this would be handy.

2.       The DataSetList as output format loses information from the original net.sf.flatpack.DataSet. It would handy to have to possibility to choose the output format for the flatpack dataformat.

3.       The use of "special records" is a very handy feature of the flatpack library. These "special records" are supported in de DataSetList BUT only if header/trailing id's "header" and "trailer" are used. Any other id's will fail and that is a petty since it is possible to have it more flexible.

I would like to contribute to this camel component but I'm not registered yet.

--
Kind regards,
Ronny Aerts<mailto:[hidden email]> - Intris nv - Wapenstilstandlaan 47, 2600 Berchem, Belgium
R&D Integration Architect
Prince II<http://en.wikipedia.org/wiki/PRINCE2> certified - ITIL<http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library> certified
Tel: +32-3-326.50.75

Intris nv
Wapenstilstandlaan 47
B-2600 Berchem  Tel.  +32 3 326 50 75
Fax  +32 3 326 42 23
www.intris.be<http://www.intris.be/>    [http://www.intris.be/mail/AEO_Sticker_108pxRGB.jpg] <http://www.intris.be>

DISCLAIMER
This is an e-mail from Intris. The information contained in this communication is intended solely for use by the individual or entity to whom it is addressed.
Use of this communication by others is prohibited. If the e-mail message was sent to you by mistake, please notify [hidden email]<mailto:[hidden email]>, destroy it without reading, using, copying or disclosing its contents to any other person.
We accept no liability for damage related to data and/or documents which are communicated by electronic mail.
Reply | Threaded
Open this post in threaded view
|

Re: camel flatpack component shortcomings

Claus Ibsen-2
Hi

Yeah sure we love contributions. You can read here how-to
http://camel.apache.org/contributing

On Sat, Feb 6, 2016 at 4:14 PM, Ronny Aerts <[hidden email]> wrote:

> Hallo camel community,
>
> I am a heavy user of camel in the integration projects in the company I work for. We use camel 2.15.2 and all routes are defined using spring dsl (no java).
>
> I have to do several fixed-length conversions where I have a lot of differences per line in the file. Each line contains some kind of record type field the beginning of the line.
>
> I came across the camel flatpack component<http://camel.apache.org/flatpack.html> to fulfill my request using the "fixed" format with pzmap/record definitions. I decided to use the flatpack dataformat<http://camel.apache.org/flatpack-dataformat.html> to do the actual conversion (unmarshal) as shown below.
> <unmarshal>
>             <flatpack fixed="true" definition="whorder/PEOPLE-FixedLengthWithHeaderTrailer.pzmap.xml"/>
>       </unmarshal>
> I have several points about this unmarchal:
>
> 1.       The output of the unmarchal is a org.apache.camel.component.flatpack.DataSetList and although it is not so difficult to process in java, it is more difficult in spring dsl. I didn't found any camel convertor from org.apache.camel.component.flatpack.DataSetList to anything so I created one to convert to an ArrayList. A standard camel converter for this would be handy.
>
> 2.       The DataSetList as output format loses information from the original net.sf.flatpack.DataSet. It would handy to have to possibility to choose the output format for the flatpack dataformat.
>
> 3.       The use of "special records" is a very handy feature of the flatpack library. These "special records" are supported in de DataSetList BUT only if header/trailing id's "header" and "trailer" are used. Any other id's will fail and that is a petty since it is possible to have it more flexible.
>
> I would like to contribute to this camel component but I'm not registered yet.
>
> --
> Kind regards,
> Ronny Aerts<mailto:[hidden email]> - Intris nv - Wapenstilstandlaan 47, 2600 Berchem, Belgium
> R&D Integration Architect
> Prince II<http://en.wikipedia.org/wiki/PRINCE2> certified - ITIL<http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library> certified
> Tel: +32-3-326.50.75
>
> Intris nv
> Wapenstilstandlaan 47
> B-2600 Berchem  Tel.  +32 3 326 50 75
> Fax  +32 3 326 42 23
> www.intris.be<http://www.intris.be/>    [http://www.intris.be/mail/AEO_Sticker_108pxRGB.jpg] <http://www.intris.be>
>
> DISCLAIMER
> This is an e-mail from Intris. The information contained in this communication is intended solely for use by the individual or entity to whom it is addressed.
> Use of this communication by others is prohibited. If the e-mail message was sent to you by mistake, please notify [hidden email]<mailto:[hidden email]>, destroy it without reading, using, copying or disclosing its contents to any other person.
> We accept no liability for damage related to data and/or documents which are communicated by electronic mail.



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2