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.

• …