[jira] [Updated] (CAMEL-18740) Automatic encapsulation of outgoing invocations

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-18740:
--------------------------------
    Fix Version/s: Future

> 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)