[QAARQ-30] Allow RMQ commands to be used within a command chain Created: 17/Dec/18 Updated: 05/Jun/23 |
|
| Status: | Open |
| Project: | Queued Asynchronous Activation over RabbitMQ |
| Component/s: | activation |
| Affects Version/s: | 1.7.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Richard Gange | Assignee: | Andrew Warinner |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | workflow | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Template: |
|
||||
| Acceptance criteria: |
Empty
|
||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||
| Documentation update required: |
Yes
|
||||
| Date of First Response: | |||||
| Description |
|
Currently RMQ commands cannot be configured within a command chain. Therefore the RMQ modules cannot be used with the workflow modules. The problem with using PublishingProducerCommand in a workflow is it doesn’t implement: public boolean execute(info.magnolia.commands.chain.Context) even though it implements: public boolean execute(info.magnolia.context.Context) CommandJob invokes execute(info.magnolia.commands.chain.Context) but since PublishingProducerCommand doesn't implement it, MgnlCommand gets it and invokes executeSynchronized(...), which PublishingProducerCommand doesn't implement either. |
| Comments |
| Comment by Richard Gange [ 17/Dec/18 ] |
|
Currently I exclude the modules in my pom:
<dependency>
<groupId>info.magnolia.eebundle</groupId>
<artifactId>magnolia-enterprise-pro-webapp</artifactId>
<version>${magnoliaBundleVersion}</version>
<type>pom</type>
<exclusions>
<exclusion>
<groupId>info.magnolia.workflow</groupId>
<artifactId>magnolia-module-workflow</artifactId>
</exclusion>
<exclusion>
<groupId>info.magnolia.workflow</groupId>
<artifactId>magnolia-module-workflow-jbpm</artifactId>
</exclusion>
<exclusion>
<groupId>info.magnolia.workflow</groupId>
<artifactId>drools-jcr-persistence</artifactId>
</exclusion>
<exclusion>
<groupId>info.magnolia.workflow</groupId>
<artifactId>jbpm-jcr-persistence</artifactId>
</exclusion>
</exclusions>
</dependency>
|
| Comment by Richard Gange [ 17/Dec/18 ] |
|
If you already have the modules installed another approach would be to reconfigure the activate, activateRecursive and deactivate actions on the Pages app to not extend from workflow configuration. |
| Comment by Thomas Duffey [ 15/Apr/19 ] |
|
Rich, will you please elaborate here – is it not possible to use workflow and RMQ publication or is it just not part of the out of box configuration? Asking because we have a customer who wants us to explore using RMQ publication who is also using workflow. |
| Comment by Richard Gange [ 16/Apr/19 ] |
|
Hi Tom- Actually, this was something that was told to by the developer. He is no longer working for Magnolia. I don't know or remember what the problem was with trying to use the 2 together. Thinking about it now I don't see why it could not be done. So it could very well be that this is a non-issue. However, in the original docs the workflow module was bypassed. Please see https://documentation.magnolia-cms.com/display/DOCS55/Configuring+RabbitMQ. So in the new docs I did the same. But I did not give it a lot of thought at the time. Where I could see an issue is with personalization. Does you customer use personalization? Cheers |
| Comment by Thomas Duffey [ 16/Apr/19 ] |
|
Hi Rich, yes we use personalization. What would be the issue there? |
| Comment by Richard Gange [ 16/Apr/19 ] |
|
Ok, so let's say you have both workflow and personalization installed. When I activate a page from the Pages app the following sequence of events happens:
So in the end I think that you could use RMQ for the content syncing because there you call other commands to do the actual activation part. So you could still call personalizationActivation. Here is an example of the config: https://git.magnolia-cms.com/projects/SERVICES/repos/magnolia-rabbitmq-parent/browse/magnolia-rabbitmq-activation/src/main/resources/mgnl-bootstrap/rabbitmq-activation/config.modules.rabbitmq-activation.commands.withContentSyncing.yaml However, I have doubts that RMQ activation will properly activate pages that have been personalized. At least I'm not sure about that. Because in this case ultimately you will have to call the RMQ publication: Here is the config for that: https://git.magnolia-cms.com/projects/SERVICES/repos/magnolia-rabbitmq-parent/browse/magnolia-rabbitmq-activation/src/main/resources/mgnl-bootstrap/rabbitmq-activation/config.modules.rabbitmq-activation.commands.rbmqVersioned.yaml I think what I need to do is re-purpose this ticket update the documentation for the workflow scenario. Explain how to configure that. HTH |
| Comment by Thomas Duffey [ 16/Apr/19 ] |
|
OK Rich and to be honest we have already customized all of the above because we have some custom dependency checks and custom workflows in our implementation when activating Pages. In addition we have implemented our own Transactional Sender that integrates with the edge cache for purging. I need to get more familiar with the RMQ publishing but my hope would be that we can retain all of this, including our custom workflow and publication, but have RMQ do the actual sending once the overall process gets that far. I assume the Transactional Sender would be replaced by a Rabbit MQ Sender of some form. |
| Comment by Richard Gange [ 16/Apr/19 ] |
If that is the case, then the first thing to do would be to make sure that RMQ can handle personalized activation. This should be tested on a plain vanilla instance of Magnolia. It might even be a simple case of writing one more command for RMQ to handle that case. For example, info.magnolia.rabbitmq.activation.commands.publishing.PersonalizationPublishingProducerCommand. Another thing to consider here, this code base, while it does work and it is being used by some customers, it's a bit messy. For example, look at that package name info.magnolia.rabbitmq.activation.commands.publishing. It has both the words activation and publishing. Which can seem like a minor detail but there are things like this in other parts of the module as well. It's a nice idea but it did not get a proper design so this can make it a little difficult to understand and/or work with. I will say that I had a frustrating time writing the tutorial. |
| Comment by Andrew Warinner [ 17/Apr/19 ] |
|
The problem with using PublishingProducerCommand in a workflow is it doesn’t implement: |