Rhythm 2.0 Specifications

Appearance

ATS-PFM-INT-015Route integration events to their application owners: Capability Test Specification

Markdown

ATS-PFM-INT-015

Route integration events to their application owners: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-INT-015

Design

Executed by
TST-PFM-INT-480, TST-PFM-INT-509, TST-PFM-INT-537

KindAcceptance test setProduct areaPlatformModuleIntegration access, customer extensions and shared workflow configurationRevision3

Read atservices-platform ad3f6a65macroservice-libraries 54536a44react-console baf6dae3

Route integration events to their application owners: Capability Test Specification ​

Coverage ​

RuleProved By
BR-CAP-PFM-INT-015-01ATS-PFM-INT-015-01
BR-CAP-PFM-INT-015-02ATS-PFM-INT-015-02, ATS-PFM-INT-015-07, ATS-PFM-INT-015-10
BR-CAP-PFM-INT-015-03ATS-PFM-INT-015-03, ATS-PFM-INT-015-08
BR-CAP-PFM-INT-015-04ATS-PFM-INT-015-04
BR-CAP-PFM-INT-015-05ATS-PFM-INT-015-05, ATS-PFM-INT-015-07, ATS-PFM-INT-015-09
BR-CAP-PFM-INT-015-06ATS-PFM-INT-015-06
BR-CAP-PFM-INT-015-07FND-PFM-INT-080
BR-CAP-PFM-INT-015-08FND-PFM-INT-080

Integration events connect provider-message processing and execution completion to application consumers. The interaction cases inspect acknowledgement and repeated routing alongside the originating work, retaining failures for later recovery.

The structured scenarios name the capabilities and rules involved. A bound test contributes only the outcomes it asserts; proposed transition matrices and composed interactions still require executable proof.

Coverage

  • Rule covered
  • Transition covered
  • Validation gap: FND-PFM-INT-080
  • Permission covered
  • Edge gap: FND-PFM-INT-080
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant gap: FND-PFM-INT-080
  • Interaction covered

Test Scenarios

10 scenarios proving CAP-PFM-INT-015; 6 bound to an existing test.

01 Consumer registration replaces earlier interestsruleapitest
Proves
BR-CAP-PFM-INT-015-01
Preconditions
Accounting is registered for payment events.
Steps
Register a narrower replacement list.
Expected
Only the replacement event interests remain stored.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#replaces what a principal registered before, whole
02 Routing retains failures and unclaimed events visiblyfailureapitest
Proves
BR-CAP-PFM-INT-015-02
Preconditions
Prepare two consumers, one requesting retry, and an event with no match.
Steps
Route batches through repeated attempts.
Expected
Matching consumers receive events, retry is scheduled and can end dead at six attempts, and unmatched events become unclaimed without invocation.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#records an event every consumer handled or ignored as delivered, to each of them
03 Completion goes to its calling applicationinteractionapitest
Proves
BR-CAP-PFM-INT-015-03
Preconditions
Accounting and Events both have event consumers.
Steps
Complete Accounting’s asynchronous operation.
Expected
Only Accounting receives that completion and its response.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/e2e-adapters/events-dummy.adapters.spec.js#reaches the consumer of the application that invoked it, carrying the response
04 Adapter emissions are validated as a wholeboundaryapinegativetest
Proves
BR-CAP-PFM-INT-015-04
Preconditions
The test adapter has its own connection.
Steps
Emit undeclared types, malformed data, one hundred and one events and a foreign-connection batch, then valid events.
Expected
Each invalid batch refuses; the valid batch saves event identities.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/adapter-callbacks/adapter-callbacks.integration.spec.js#refuses a type the manifest does not produce, InvalidRequest
05 Stale event dispatch cannot repeat its attemptconcurrencyapitest
Proves
BR-CAP-PFM-INT-015-05
Preconditions
An event dispatch was already routed.
Steps
Redeliver that same work message.
Expected
Routing performs no further work.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#does nothing for a message of an attempt already made
06 Staff event inspection spans customerspermissionapitest
Proves
BR-CAP-PFM-INT-015-06
Preconditions
Two workspaces contain unclaimed events.
Steps
List with a staff identity and a customer identity.
Expected
Staff can inspect both; the customer can reach only its own workspace event list.
Data
Fixtures establishing the stated accounts, declarations and history in an isolated workspace.
Bound to
Source
services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#lists the events nobody took for Rhythm HQ, across tenants
07 Exercise the complete integration event routingtransitionapinegativeproposed
Proves
BR-CAP-PFM-INT-015-02 BR-CAP-PFM-INT-015-05
Preconditions
Prepare one independent record in each starting state, including absent-record cases where the model defines creation.
Steps
Run each listed transition once with its guard satisfied, then repeat it with the guard denied. Inspect the resulting record and listed side effects after commit.
Expected
Each positive case reaches its listed destination and records its defined side effects. Each denied case preserves the starting record and creates no transition side effects.
Data
Run-owned records and principals in an isolated workspace.
Source
rhythm-v2-docs:specs/platform/integrations/design/state-models/STATE-PFM-INT-010-integration-event-routing.md#transitions
08 Settled asynchronous work reaches only its callerinteractionapiproposed
Proves
BR-CAP-PFM-INT-010-05 BR-CAP-PFM-INT-015-03
Preconditions
Two applications have completion consumers and the first owns an unanswered asynchronous operation.
Steps
Settle the operation, route its completion and repeat settlement.
Expected
Only the calling application receives the response and no second completion is created.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/tests/integration/services/executions/execution-settlement.integration.spec.js#is written once for two settlements that both read the execution running, the loser moving nothing,services-platform:modules/integrations/tests/e2e-adapters/events-dummy.adapters.spec.js#reaches the consumer of the application that invoked it, carrying the response
09 Redelivered change work preserves delivery identityinteractionapiproposed
Proves
BR-CAP-PFM-INT-014-02 BR-CAP-PFM-INT-015-05
Preconditions
A subscription accepts a change event and the routed change has a stable identity.
Steps
Fan out the same change twice and redeliver already claimed routing work.
Expected
One projected delivery exists and stale routing work makes no further attempt.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/tests/integration/services/subscriptions/subscriptions.integration.spec.js#turns a CRM change event into a queued delivery of the catalog projection, never the row,services-platform:modules/integrations/tests/integration/services/events/event-router.integration.spec.js#does nothing for a message of an attempt already made
10 Verified notifications become routed eventsinteractionapiproposed
Proves
BR-CAP-PFM-INT-013-04 BR-CAP-PFM-INT-015-02
Preconditions
A provisioned endpoint and matching application consumer are available.
Steps
Process a valid notification, route its emitted event, then process a tampered notification.
Expected
The valid message reaches its consumer; signature refusal emits no event.
Data
Run-owned records and principals in an isolated workspace.
Source
services-platform:modules/integrations/tests/integration/services/webhooks/webhook-worker.integration.spec.js#rejects a request whose signature does not verify, writing no event,services-platform:modules/integrations/services/events/event-router.ts:routeIntegrationEvents

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