Jacques Franken created CAMEL-18482:
---------------------------------------

             Summary: camel-core - Pre 3.13 Split EIP behaviour
                 Key: CAMEL-18482
                 URL: https://issues.apache.org/jira/browse/CAMEL-18482
             Project: Camel
          Issue Type: Wish
          Components: came-core
            Reporter: Jacques Franken


We are busy updating some of our deployments to the latest camel LTS, but found 
a change in behaviour in split on maps.  We've tracked it down to the following 
ticket as being a likely cause of the change. 

https://issues.apache.org/jira/browse/CAMEL-17101

So my wish item is: Please add an option to .split() to allow processing the 
map the "old way". 

This is not a "bug" - we all feel that the current behaviour is logically how 
the split EIP should work when splitting a single object in a complex map. 

Notwithstanding, the old behaviour was really elegant in cases where we had to 
split("${body.Map}").

In version 3.12 that allowed us to process the Map as a "record", pass the 
record to a bean, do a simpleJdbcinsert() and once the split ended, the body 
was restored for the next split().

I asked around Stackoverflow and in zulip for ideas, and we tried a few things 
- but eventually found the only way for is significant code modification.

This involves setting a header variable to the sub-map --> and call the bean to 
handle SQL insert. 

The bean also now has to do some logic.  if the header variable is set --> then 
it should use the header for insert value. if header is null - then do default 
behaviour. 

If you need me to provide code examples to illustrate - please let me know.

link to Zulip:

[https://camel.zulipchat.com/#narrow/stream/257301-camel-spring-boot/topic/split.28.29.20change.20in.20behaviour.203.2E13.20onwards]

link to Stack-overflow:

[https://stackoverflow.com/questions/73615483/how-to-return-non-array-json-object-from-apache-camel-split]

 

Sorry if this is not appropriate way to raise this request. I felt that it was 
worth raising officially as it does make for simpler code in some use-cases. 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to