---
title: SAIF.Business.Claim.SupportOrder architecture
summary: Architectural responsibilities, boundaries, and interaction patterns.
status: draft
owner: SAIF
last_reviewed: 2026-07-28
library: SAIF.Business.Claim.SupportOrder
reference_type: package
---

# SAIF.Business.Claim.SupportOrder architecture

SAIF.Business.Claim.SupportOrder is a focused BOF component that persists support-order headers and claim-to-order links, using nested criteria classes and Oracle inline SQL to manage worker-scoped support orders plus their attached claim connections.

## Responsibilities
- Represent a single support-order header and its financial, effective-date, and worker identity fields.
- Manage collections of support orders by worker and collections of claim connections by support-order identifier.
- Enforce optimistic-concurrency checks around support-order updates and connection persistence.
- Lazy-load support-order connections so consumers can inspect linked claims only when required.

## Component boundaries
- **Support-order entity:** `clsClaimSupportOrder` owns order fields, save semantics, and the worker-scoped aggregate boundary.
- **Support-order collection:** `clsClaimSupportOrderCollection` retrieves and manages support orders for a worker, including the all-claim filter path.
- **Connection entity:** `clsClaimSupportOrderConnection` models the row that links a claim to a support order.
- **Connection collection:** `clsClaimSupportOrderConnectionCollection` loads and manages the link set for a support-order record.

## Interaction model
Consumers retrieve support-order collections by worker ID, create or update header rows through the entity criteria class, and access connections through a lazily populated child collection that queries the connection table by `SupportOrderID`.

## Architecture diagram
The following diagram shows the high-level component interactions.

```mermaid
flowchart TD
    A[Claim maintenance workflow] --> B[Support order collection]
    B --> C[Support order entity]
    C --> D[Connection collection]
    C --> E[BOF data portal and criteria]
    D --> E
    E --> F[CL_CLAIM_SUPPORT_ORDER]
    E --> G[CL_CLAIM_SUPPORT_ORDER_CONN]
```

## Sequence diagram
The following diagram shows the primary request and persistence sequence.

```mermaid
sequenceDiagram
    participant Client
    participant Orders as clsClaimSupportOrderCollection
    participant Order as clsClaimSupportOrder
    participant Portal as IDataPortalInfo
    participant Oracle
    Client->>Orders: GetClaimSupportOrderCollection(workerId)
    Orders->>Portal: Execute retrieve SQL
    Portal->>Oracle: Select support-order rows by worker
    Oracle-->>Orders: Return support orders
    Client->>Order: Access Connections
    Order->>Portal: Retrieve connection rows by SupportOrderID
    Portal->>Oracle: Select from CL_CLAIM_SUPPORT_ORDER_CONN
    Oracle-->>Order: Return linked claims
```

## Inherited framework context (from Legends CLI)
- `clsBusinessBase` and `clsBusinessCollectionBase` provide the BOF entity and collection lifecycle used by both support-order object pairs, including validation surfacing and collection traversal behavior.† Source: cached Legends CLI results for `saif-framework-core` (`library` docs; api/business-rules/operations-processes/dependencies queries for the named base classes).
- `IBusinessCriteria` supplies the CRUD SQL contract that the nested criteria classes fulfill with inline Oracle statements, while `IDataPortalInfo` is the routing abstraction for those requests.† Source: cached Legends CLI results for `saif-framework-core` (`library` docs; api/operations-processes/dependencies queries for `IBusinessCriteria` and `IDataPortalInfo`).
- `IDataRequest`, `clsSAIFDataReader`, and `clsSmartDate` are inherited framework transport or helper types in the BOF data-access path rather than local support-order domain logic.† Source: cached Legends CLI results for `saif-framework-core` (`library` docs; api/dependencies queries for the named types).

## Design constraints
- Update semantics depend on `UPDATE_NUM` optimistic concurrency in `CL_CLAIM_SUPPORT_ORDER`.
- Connection retrieval is intentionally child-scoped and should remain lazy to preserve the current aggregate boundary.
- All persistence is defined as inline Oracle SQL inside criteria classes, so schema changes require code changes rather than only package updates.

## Related documentation
- [Index](index.md)
- [Overview](overview.md)
- [Dependencies](dependencies.md)
- [Operations and processes](operations-processes.md)
- [Business rules](business-rules.md)
- [Database tables](database-tables.md)
- [SQL catalog](sql/index.md)
- [API reference](api/index.md)

> **Note:** Statements marked with `†` are derived from dependency library documentation via the Legends CLI. They describe inherited behavior from the indicated origin library and should be verified if the dependency version changes.

## Sources
- `Business\SAIF.Business.Claim.SupportOrder\clsClaimSupportOrder.vb`
- `Business\SAIF.Business.Claim.SupportOrder\clsClaimSupportOrderCollection.vb`
- `Business\SAIF.Business.Claim.SupportOrder\clsClaimSupportOrderConnection.vb`
- `Business\SAIF.Business.Claim.SupportOrder\clsClaimSupportOrderConnectionCollection.vb`
- `Business\SAIF.Business.Claim.SupportOrder\packages.config`
- `Business\SAIF.Business.Claim.SupportOrder\SAIF.BOF.Business.Claim.SupportOrder.nuspec`