C/ALM Event Handling
Kai
Scenario
Scenario
RTC
ProjectArea
ProjectArea
RQM
Iteration Plan Approved
Create Test Casesor
Create Task to Create Test Casesor
Do other smart things
Observation
• Types of issued events are application specific• Events are issued in the context of projects• Event handling is project or even team specific• End users configure event handlers
• This is really just “remote listeners”
Context
• Use Webhooks over Atom feeds
• “Listeners” are URLs the subject POSTs the event to
• The listener may be remote to interested application
Flow (stylized)
Subject
ProjectArea
ProjectArea
Consumer
Listener H1 (Service)
knows
registers H1
POST eventoperates on
Tasks (subject side)
• Define resource format of events• Make issued events discoverable• Define protocol for webhook registry• POST to registered webhooks
• Utilize existing process events
Tasks (consumer side)• Define a way to register webhooks
– [label, description, URL]
• Allow end users to configure webhooks– allow to browse configured friends for available events– allow to directly enter URL– allow to configure parameters for webhook – support on project area and team area level– take Web UI perspective
• Persist webhook configuration in the Foundation Storage Service
• Register configured webhook with subject’s registry
• Find reasonable integration in eclipse client
Open Issues
• Authentication
• Licensing
• When does the registration happen?
• How do we represent cross app event handling in process templates? In what kind of process templates?
Potential Points of Authentication
Subject
ProjectArea
ProjectArea
Consumer
Listener H1 (Service)
knows
registers H1
POST eventoperates on
Interesting Points of License Enforcement
• User needs licenses to register webhook, number of webhooks a user can register could be limited
• The total number of webhooks on a server could be limited
• The number of webhooks that can be called by the server for any given event could be limited.
• …