Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Webhook connector] Clarify the format we use to access request body #2564

Open
markfarkas-camunda opened this issue May 17, 2024 · 3 comments
Assignees
Labels
kind:task Categorizes an issue or PR as general maintenance, i.e. cleanup, refactoring, etc.

Comments

@markfarkas-camunda
Copy link
Contributor

markfarkas-camunda commented May 17, 2024

What should we do?

Clarify what is the correct format of the Correlation key, and what is the exact way to extract info from the request body. (request.body.name)

We already have a documentation but it would be nice to have a placeholder value in the input field, or a link to the doc in the description.

We could also have some additional checks: if the Correlation key(payload) does not start with request -> show error for example

Why should we do it?

It is not obvious for first time users what is the correct keyword (request) to access the body of the request. They might assume it is just body.name or req.body.name instead of request.body.name

@markfarkas-camunda markfarkas-camunda added the kind:task Categorizes an issue or PR as general maintenance, i.e. cleanup, refactoring, etc. label May 17, 2024
@johnBgood
Copy link
Contributor

@crobbins215 we discussed this during the architecture session, and what @markfarkas-camunda pointed out is that we don't have a consistent naming so far.
For the Kafka connector the key would be value.myKey for instance, whereas for the Webhook connector it'd be request.myKey.

We discussed possibly using a common term (message, inputData,...) but this is not ideal as the term is tightly coupled to the domain object (Webhook <-> request, Kafka <-> value) and the user would still need to look at the documentation to find inner fields (request.body for instance).

Maybe we should solve this with better documentation + nice tooltips in the modeler?

@crobbins215
Copy link

Could we improve the documentation for this as part of this ticket then?

@sbuettner
Copy link
Contributor

Agreed on improving the documentation first and find a way for a uniform message property model later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:task Categorizes an issue or PR as general maintenance, i.e. cleanup, refactoring, etc.
Projects
None yet
Development

No branches or pull requests

4 participants