Hi all, another option would be to implement the idempotent Consumer on our Component. https://camel.apache.org/components/latest/eips/idempotentConsumer-eip.html
This would allow to place processed messages in a repository (Trigger polling) and just execute the route if something is different (like Trigger bit). The result would be the same, but this feature is also implmented in other components so I thought of maybe we could use it aswell, what do you think? Etienne On 2020/04/17 20:28:52, Christofer Dutz <[email protected]> wrote: > Hi Etienne, > > Exactly ... Use the current api and when we refractor the scraper we just > have to change all usages equally. > > Chris > ________________________________ > Von: Etienne Robinet <[email protected]> > Gesendet: Freitag, 17. April 2020 20:27 > An: [email protected] <[email protected]> > Betreff: Re: Camel Component features > > Hi Chris, > So what do tou think? Adapt the old scraper to use in the API and then use > this in the Camel component? > > Etienne > > > Le 17 avr. 2020 à 12:10, Christofer Dutz <[email protected]> a > > écrit : > > > > Hi all, > > > > And we should really rewrite and clean up the scraper internally ;-) > > > > Still got that on my ToDo, but would be happy if someone would beat me to > > it ;-) > > > > But I also agree that we shouldn't re-invent the wheel and reuse the > > components we already have. > > > > I think from an API side even a new scraper would be pretty much like the > > current one and the current one does work fine. > > > > Chris > > > > > > Am 17.04.20, 09:45 schrieb "Julian Feinauer" > > <[email protected]>: > > > > Etienne, > > > > like so often you are absolutely right with your analysis oft he > > Situation : ) > > Indeed these are very valuable features. > > > > In plc4x there exists a compontent called the "Scraper" (which I wrote > > initially) and which was extended to a "TriggeredScraper" by @Tim Mitsch > > which does exactly that. > > Watch a bit or a condition and only fetch data, when this condition > > changes. > > > > In fact we want (since months) integrate our in-house developed Engine > > for these Tasks, CRUNCH as a PLC4X Subproject to push this even further > > (see here for CRUNCH https://github.com/pragmaticminds/crunch). > > > > I guess it helps you to take a look at both resoures! > > > > Julian > > > > Am 17.04.20, 09:21 schrieb "Etienne Robinet" <[email protected]>: > > > > Hi everyone, > > As the Camel component is now working correctly, I thought about > > some features we could add on it, based on work I read from a coworker. I > > would like to know if these would fit inside this project and if so I would > > be glad to implement them. > > > > Trigger & Completion > > To prevent writing to a PLC that is using data or to fetch a bunch > > of data that has not changed, we could use Flags (Bits). A transaction will > > only take place if the Trigger bit is 1, and once it is done, it's set back > > to 0 and the completion bit to 1 (or Error bit). This way, the PLC is the > > master of the transaction and can tell when it can be written to or read > > from. > > > > Polling > > In order to be aware of the change of state of the trigger, we > > should do a polling on this bit. This way, we only read 1 bit, at an user > > specified interval, and once the bit is 1, we do the transaction(read/write) > > > > Default values > > If none or not every of these parameters are given, then we could > > use default values like reading the tags given every 1000ms or so (e.g. for > > monitoring) > > > > Hope this is interesting for you and if so I would start next week. > > > > Etienne > > > > > > > > >
