[
https://issues.apache.org/jira/browse/CAMEL-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847561#comment-17847561
]
Claus Ibsen commented on CAMEL-18740:
-------------------------------------
We have variables now - lets use that and see how that goes before doing more
bigger changes
> Automatic encapsulation of outgoing invocations
> -----------------------------------------------
>
> Key: CAMEL-18740
> URL: https://issues.apache.org/jira/browse/CAMEL-18740
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: Bruno Meseguer
> Priority: Minor
> Fix For: Future
>
>
> In pursuit of better useability of Camel and future UI tooling, it would be
> ideal for implementing in Camel an automatic encapsulation of in/out data
> when invoking endpoints.
> The following scenario is a typical processing flow in the enterprise:
> 1) receive client request
> 2) call system A
> 3) call system B
> 4) call system C
> 5) compose response (A'+ B'+ C')
> 6) reply to client
> Camel is today 100% capable of letting the developer implement such workflow.
> If the developer wants to compose a response (step 5), then the sequence of
> calls above (A/B/C) require to manually keep responses in exchange
> properties. It requires from the developer to be well familiar with Camel to
> code the right actions. New users would find it very challenging at first to
> find the right approach.
> Additionally, the current Camel mechanics of handling properties/headers/body
> do not provide a good enough level of support for UI tooling. A GUI user
> would still require a good understanding of Camel to accomplish such workflow.
> This ticket proposes to provide Camel the ability to automatically handle
> external calls in such a way that response data is inmediately available for
> developers to easility compose the response data.
> An example Exchange structure that Camel could self-populate is the following:
> (config/inputs could be defined at design time, in code or GUI)
> (outputs would be resolved at runtime)
> Exchange
> - Consumer (1)
> - configuration
> - message (received) or (output)
> - headers
> - body
> - Producer (2)
> - configuration
> - message (sent) or (input)
> - headers
> - body
> - message (response) or (output)
> - headers
> - body
> - Producer (3)
> - configuration
> - message (sent) or (input)
> - headers
> - body
> - message (response) or (output)
> - headers
> - body
> - Producer (4)
> - configuration
> - message (sent) or (input)
> - headers
> - body
> - message (response) or (output)
> - headers
> - body
> - Mapping (5)
> - configuration
> - message (input)
> - headers
> - body
> - message (output)
> - headers
> - body
> - Response to client (automatic)
> In the structure above, Camel has automatically created multiple objects
> inside the Exchange, where each endpoint interaction has been encapsulated.
> At design time, the Camel route could provide all the metadata
> (config/inputs) necessary to allow a GUI to easy present to the user
> information that can be used to configure other inputs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
