Rhythm 2.0 Specifications

Appearance

CAP-PFM-INT-015Route integration events to their application owners

Markdown

CAP-PFM-INT-015

Route integration events to their application owners

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationPartially observed

Planning

Feature
FEAT-PFM-INT-04
Exercised by
FAS-PFM-INT-04-01, FAS-PFM-INT-04-02, FAS-PFM-INT-04-03, FAS-PFM-INT-04-04, FAS-PFM-INT-04-05
Key concepts
CON-PFM-INT-004
Actors
ACT-PFM-020, ACT-PFM-021, ACT-PFM-006, ACT-PFM-019
Depends on
CAP-PFM-INT-013
Related
CAP-PFM-INT-010, CAP-PFM-INT-014
Open questions
OQ-PFM-INT-002
Proved by
ATS-PFM-INT-015

Implementation

Executable suites
TST-PFM-INT-480, TST-PFM-INT-509, TST-PFM-INT-537

KindCapabilityProduct areaPlatformModuleIntegration access, customer extensions and shared workflow configurationRevision1

Read atservices-platform ad3f6a65macroservice-libraries 54536a44

Route integration events to their application owners ​

Purpose ​

Rhythm forwards provider events and completion results to the applications registered to receive them.

How It Works ​

An application registers a consumer for the event types it understands. The router matches integration events to those registrations. Consumers answer whether they handled, ignored or need another attempt at a message. Events without a matching consumer remain visible rather than disappear. Provider references can link an event back to the Rhythm operation responsible for it. Completion results return to the application that initiated the call. Staff can investigate failed or unclaimed events across customers. Data access callbacks remain marked as unavailable. The product should establish event-consumer acceptance independently of the still-deferred data-grant feature.

Relationships ​

  • Requires retain and verify incoming provider notifications to supply the prerequisite configuration or operation.
  • Connects with determine the result of uncertain or overdue calls through shared integration records.
  • Connects with deliver subscribed rhythm changes to integrations through shared integration records.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Registered applications receive relevant events; unclaimed events remain visible.Completion results go to the application responsible for the call.
Surfaces
apijob
Intent sources
services-platform:docs/milestones/INTG-M3-webhooks-events-deliveries.md#Objectiveservices-platform:docs/milestones/INTG-M2-calls-through-the-gateway.md#M2-D6

Controls

38 controls apply, from the corpus control catalogue.

TC-AVL-004 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CHG-005 TC-CHG-006 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-IAM-001 TC-IAM-002 TC-IAM-003 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-LOG-001 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
hq.integrations.publishserviceglobal
platform.integrations.readapitenant
hq.integrations.operateapiglobal

Business Rules

8 rules, 8 to be proved before approval. A rule's product intent is derived from its origin: 1 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
An application registers its consumer event types or prefixes under its own principal during deployment, replacing its previous registration in full.
proved by ATS-PFM-INT-015-01, TST-PFM-INT-537
policyservicetest
services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#replaces what a principal registered before, whole
02must prove
Proposed
Each routing attempt invokes relevant consumers as Platform with batches no larger than ten; retries may repeat delivery to earlier successful consumers, requiring event-identity deduplication, and end dead after six attempts while events without recipients remain unclaimed.
proved by ATS-PFM-INT-013-11, ATS-PFM-INT-015-02, ATS-PFM-INT-015-07, ATS-PFM-INT-015-10, TST-PFM-INT-537
lifecycleserviceobserved
services-platform:modules/integrations/services/events/event-router.ts:routeIntegrationEvents
03must prove
Confirmed
Execution-completion events reach only a consumer for the invoking application and include the response or error.
origin: services-platform:docs/milestones/INTG-M2-calls-through-the-gateway.md#M2-D6
proved by ATS-PFM-INT-010-10, ATS-PFM-INT-015-03, ATS-PFM-INT-015-08, TST-PFM-INT-480
policyservicetest
services-platform:modules/integrations/tests/e2e-adapters/events-dummy.adapters.spec.js#reaches the consumer of the application that invoked it, carrying the response
04must prove
Proposed
An adapter emits no more than one hundred events per batch for its own connection, limited to declared produced types and valid event data.
proved by ATS-PFM-INT-015-04, TST-PFM-INT-509
validationservicetest
services-platform:modules/integrations/tests/integration/services/adapter-callbacks/adapter-callbacks.integration.spec.js#refuses a type the manifest does not produce, InvalidRequest
05must prove
Proposed
Event identifiers support consumer deduplication, and redelivered work for an already attempted dispatch has no further effect.
proved by ATS-PFM-INT-014-10, ATS-PFM-INT-015-05, ATS-PFM-INT-015-07, ATS-PFM-INT-015-09, TST-PFM-INT-537
invariantservicetest
services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#does nothing for a message of an attempt already made
06must prove
Proposed
Workspace routes expose their own events, while Rhythm staff can list unclaimed and dead events across customers.
proved by ATS-PFM-INT-015-06, TST-PFM-INT-537
permissionapitest
services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#lists the events nobody took for Rhythm HQ, across tenants
07must prove
Proposed
Webhook-derived events use the originating Rhythm record and execution where a provider reference matches, retaining the provider reference when no match exists.
no proof recorded yet
calculationservicetest
services-platform:modules/integrations/tests/unit/services/webhook-rules.spec.ts#names the Rhythm record of the execution that created the provider object
08must prove
Proposed
Data-grant query and projection callbacks validate adapter connection authority and then return the marked not-implemented response.
no proof recorded yet
policyserviceobserved
services-platform:modules/integrations/aws/api/gateway.routes.ts:queryIntegrationDataGrant

Scenarios

IdGivenWhenThenProvenance
01The provider updates a payment initiated by Accounting.The router delivers the corresponding event.Accounting receives the associated Rhythm payment reference and acknowledges it.test
services-platform:modules/integrations/tests/e2e-adapters/events-dummy.adapters.spec.js#reaches Accounting’s consumer, which acknowledges it

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software