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

feat: cloud event message header keys names constants #44

Merged
merged 1 commit into from Dec 13, 2018

Conversation

Projects
None yet
3 participants
@igdianov
Copy link
Member

igdianov commented Dec 13, 2018

This PR add shared classes with message header key names used in event messages with CloudRuntimeEvent[] and IntegrationContext message payload types

@mergify mergify bot merged commit 66eb310 into develop Dec 13, 2018

4 checks passed

continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
license/cla Contributor License Agreement is signed.
Details

@mergify mergify bot deleted the igdianov-cloud-api-message-headers-keys branch Dec 13, 2018

erdemedeiros added a commit to Activiti/activiti-cloud-runtime-bundle-service that referenced this pull request Dec 21, 2018

feat: Inject process run-time message headers for aggregated events (#…
…143)

This PR fixes Activiti/Activiti#2069 via injecting Runtime Bundle configuration property values and execution context attributes derived from execution bound to entities aggregated in Activiti engine CommandContext as Spring Message headers, so that these headers can be used by consumers to correlate events based with business context using business key, process definition key, process definition id, runtime bundle attributes, etc. 

Depends on Activiti/Activiti#2240 and Activiti/Activiti#2251. Part of Activiti/activiti-cloud-api#44

![image](https://user-images.githubusercontent.com/20428629/48309101-0b3f8e80-e527-11e8-8ac7-cce1ec96a691.png)

There are a few gotchas that need to be discussed:

1. ExecutionContext can only be resolved within process engine transaction boundary. It relies on existing CommandContext to find execution, processInstance and deployment entities using ExecutionEntityManager instance. All runtime execution context key attributes can be discovered and added as message headers with minimum overhead. 

2. IntegrationContext has only a few attributes such as processInstanceId, processDefinitionId that can be resolved only from event itself. It is would be nice to have businessKey attribute. The only option is to actually inject it into event attributes directly. 

3. We need to decide what key attributes set is required to support in messages for events:
* `RuntimeBundleInfo.*`
* `businessKey`
* `processDefinitionKey`
* `processDefinitionVersion`
* `processDefinitionId`
* `processInstanceId`

4. The message destination (routing key or topic) could be very useful for selectively consuming events in other micro-services. The destination could represent a hierarchy of key attributes that could be subscribed to using mask binding on the consumer side, i.e.: for message with destination `rb-app.app-name.proc-def-key.proc-id.biz-key`, consumers could create bindings to receive only messages with business-key: `#.biz-key` or `rb-app.#.biz-key`.

![image](https://user-images.githubusercontent.com/20428629/49545925-ea532a80-f893-11e8-96d2-6880fd82b39a.png)

5. Resolving Execution Context attributes for all events once per transaction offers the best performance. 

6. It is possible to apply sending strategies inside `MessageProducerCommandContextCloseListener`, i.e.  dis-aggregating events into single messages. 

7. It would be best practice to resolve and apply execution context from events aggregated inside transaction to ensure consistent event handling to be able to inject context attributes for all events in one place.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment