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

BXMSDOC-4192-master: Add note about API calls for process instances in KIE APIs doc. #1606

Merged
merged 1 commit into from
Jun 3, 2019

Conversation

sterobin
Copy link
Contributor

See JIRA for details.

.REST API requests for process instances
[NOTE]
====
For REST API requests to the process instance endpoint `/server/containers/{containerId}/processes/{processId}/instances`, ensure that you include the fully qualified class name in the request body. The class name is required for the request body to be mapped to the correct business object in {PRODUCT}. If you exclude the class name from the request, {KIE_SERVER} silently creates a null process variable.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

both FQCN and simple name of the class would work e.g. com.myspace.Person and Person

about the null variable, isn't that it will be a map instead of expected type instead of null?

Copy link
Contributor Author

@sterobin sterobin May 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mswiderski, how about this then:

For REST API requests that send complex data objects to the process instance endpoint `/server/containers/{containerId}/processes/{processId}/instances`, ensure that you include either the fully qualified class name (such as `com.myspace.Person`) or the simple class name (such as `Person`) in the request body. The class name is required for the request body to be mapped to the correct business object in {PRODUCT}. If you exclude the class name from the request, {KIE_SERVER} does not unmarshall the object to the expected type.

I have no clue about the KIE server behavior if the name is excluded. That's just what Michael said in RHPAM-1917.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add when sending complex data object to the message as it is only needed when data are of not simple types. About the null process variable maybe it would be better to state it won't be unmarshalled to expected type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mswiderski, I see. I've revised the note in my previous comment accordingly ^^. How about that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

@sterobin
Copy link
Contributor Author

sterobin commented May 30, 2019

Thanks @mswiderski. Also, as part of this, can you likewise update the Body parameter description in the Swagger source for this endpoint to mention the same? This way it's in both Swagger itself and in the s2m rendering when users look up the endpoints.

Like this:

Body | Optional map of process variables. Requires fully qualified class name or simple class name.

[Update]

@mswiderski, thoughts on this? Seems like a good idea, imo.

@kie-qe-ci
Copy link

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.

@sterobin sterobin changed the title WIP: BXMSDOC-4192-master: Add note about API calls for process instances in KIE APIs doc. BXMSDOC-4192-master: Add note about API calls for process instances in KIE APIs doc. Jun 3, 2019
@sterobin sterobin merged commit 83a1fa3 into apache:master Jun 3, 2019
@sterobin sterobin deleted the BXMSDOC-4192-master branch November 12, 2019 17:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants