[MAGNOLIA-8575] As Magnolia developer I need a mechanism to group several "atomic" actions into a single one Created: 11/Aug/22  Updated: 25/Nov/22

Status: Open
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Spike Priority: Low
Reporter: David Lopez Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
dependency
depends upon MGNLHOOK-195 Make webhooks-events JCR agnostic Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MAGNOLIA-8576 Implementation Sub-task To Do  
MAGNOLIA-8577 Review Sub-task To Do  
MAGNOLIA-8578 Pre-Integration QA Sub-task To Do  
MAGNOLIA-8579 QA Sub-task To Do  
Template:
Date of First Response:
Epic Link: Externalize JCR configuration
Team: Nucleus

 Description   

Context

The configuration of command change is in JCR and is used to "concatenate atomic actions"

e.g.:

When an action in the UI is triggered can lead to several "sub-actions"

Publishing is publishing the content from one environment to another

In addition an notification is sent to the user "The Content has been published)

Currently in Magnolia 6.2. relies on this functionality to launch the notification to the webhook service

Problem

In Magnolia 6.2 is possible because still relies in JCR but in Magnolia SaaS (6.3) is not possible because we don't have JCR to store such a configuration

We would need a different mechanism to "concatenate the granular actions" 

 

Requirement

  • Find a mechanism to group several "atomic actions" into a bigger one
  • Actions might need to respect a given order of execution
  • This configuration needs to be out of JCR

 



 Comments   
Comment by David Lopez [ 17/Aug/22 ]

Refinement 17/08/22

Hi jsimak ,

Would it be possible to have the scenario (use case) that we would use this functionality in order we can use it as acceptance criteria and/or test to validate that what we build?

 

Some brainstorming we did is the following but may be you can refine it with your insights

  1. User triggers publication in UI (that could include several nodes & childes)
  2. Publication mechanism triggers
  3. Publication finishes
  4. Notification is triggered in order you can trigger a Webhook  informing that publication has finished

 

Questions

  •  What is the required information we want to have in this event notification?

 

Feel free to add any further information you would find relevant.

If you think a quick call might be more fruitful (Rabie, Roman and myself would be the right audience)

Comment by Jaroslav Simak [ 19/Aug/22 ]

Hi dlopez,

We can consider two use cases:

  • Publication of a single node
  • Publication of a node and it's children (Recursive publication)

Both of these use cases follow the same process. Action triggers publication action, which delegates to a configured command chain (usually consists of version and publish commands) defined in the action definition.

Webhooks module adds new command to the command chain (version -> publish -> webhook). Once user publishes a page, and if publication is successful, the webhook command is triggered and notifies the 3rd party service defined in the webhook definition.

The webhook command sends this data to the 3rd party:

  • eventId (autogenerated by webhooks)
  • eventDate (set by webhooks)
  • workspace
  • path
  • recursive
  • nodeType
  • eventType (publish / unpublish)

The only difference between single and recursive node publication is what is sent in recursive property (either false if single node or true if recursive).

Comment by Roman Kovařík [ 24/Aug/22 ]

Discovery:

Events can be plugged at different levels (Assuming we can add dependency to webhooks at that level):

  • norsu-ui-integration
    •  info.magnolia.norsu.ui.contentapp.action.Norsu(Un)PublishAction
    • cons: events wouldn't be triggered outside of UI
  • magnolia-norsu
    • info.magnolia.norsu.PublishingApi
    • this seems to be a good fit
  • norsu-domain
    • SyncApi
    • cons: dependency to webhooks in a non magnolia module, probably a no go

The current implementation https://git.magnolia-cms.com/projects/ENTERPRISE/repos/webhooks/browse/magnolia-webhooks-core/src/main/java/info/magnolia/webhooks/command/BaseWebhookCommand.java

Concern: Webhook is a licensed module!

  • Can we just skip events creation if license if invalid?
  • still a dependency to an enterprise module, this might become a problem if norsu becomes a community module
Comment by Antonín Juran [ 24/Aug/22 ]

rkovarik Would be possible to use the webhooks module as it is since it depends on JCR? 

Comment by Roman Kovařík [ 24/Aug/22 ]

Good point, jsimak  is it necessary to have JCR in webhooks API?

e.g. https://git.magnolia-cms.com/projects/ENTERPRISE/repos/webhooks/browse/magnolia-webhooks-events/src/main/java/info/magnolia/webhooks/events/WebhookEvent.java#20

 

Comment by Jaroslav Simak [ 24/Aug/22 ]

rkovarik 

Once we have support from Norsu for events, we will create implementation specific submodules, so that the core and / or events doesn't depend on JCR.

Comment by Roman Kovařík [ 24/Aug/22 ]

support from Norsu for events

Do you expect some generic support? The tickets describes only publication.

We were expecting to be able to use the webhook API (when it will be JCR agnostic), not vice versa.

Comment by Jorge Franco [ 24/Aug/22 ]

I have created a PoC of some generic magnolia-events, that can be used for this initiative. https://git.magnolia-cms.com/projects/CLOUD/repos/norsu/pull-requests/182/overview. Let me know if you want to go this way

Comment by David Lopez [ 24/Aug/22 ]

Backlog check 24/08/2022

Suggested steps

  • Have a session between DevX (jsimak ), Labs (jfranco ) and Nucleus (rkovarik ) to summarize the options
  • Bring all the options to #pd-architecture session (^^mgeljic ) and decide on the approach since there are several ones

Currently consisered as Large since we would expect some new mechanism for event management but would be a new ticket after above suggested discussions. Re-evaluate t-shirt size estimation when information about the approach is available

Comment by David Lopez [ 29/Sep/22 ]

Discussion Backlog check 29/09/2022

Although created in Norsu, it relates more to UI

How it works before

  • The configuration of the command was in JCR
  • We are moving away from JCR, but we would envision to be part of configuration rather than part of the data store.

What has been done so far

  • (i)DevX already did Webhooks JCR agnostic
  • The agreement would be that the webhook consume from the Norsu publishing API (It is the simplest way)
  • In the future we would think to do it differently
  • The System Event Bus seems not too much consuming and would be more future proof

Discussion

  • It is a functionality used by our customers
    • It is present in Webhooks which is just release, not used
      • It is already available in SaaS
      • We would like that customer use it 
      • Currently DevX has including it the trigger to webhook within the "Publication" action
        • So is not a blocker, however not the long term solution
    • Command chain 
      • It can be done

Actions

ToDo dlopez 

  • Close and create a new one or Repurpose this ticket for how we will tackle the "command chain" functionality in the future
  • Re-assign the ticket to the scope "Config externalization"
  • Remove from the scope of TPR

 

Generated at Mon Feb 12 04:33:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.