Skip to content

SAIF.Application.Claim architecture

SAIF.Application.Claim is a Component-tier application-orchestration library* that sits between claim-related web presentation code (not part of this library) and the externally-packaged BOF business-object layer. It provides the claim/worker context model, per-claim security-flag evaluation, and the transaction lifecycle used by concrete claim-screen application managers.

Responsibilities

  • Own and mutate the current claim/worker context (ClaimContext) and re-derive claim data whenever that context changes.
  • Evaluate per-claim, per-user access flags — conflict, exposure, health-issue, and hostile/secure — against the current user's AD-resource access token (ClaimUserAccess), enforcing BR-CLM-001 through BR-CLM-004.
  • Establish the Oracle data portal for the claim domain (DataLayer.CreateOraclePortal(ClaimAppConstants.DPIClaimKey)) and delegate all reads/writes to externally-packaged business objects rather than issuing SQL directly.
  • Wrap subclass save (OnWrite()) logic in a transaction lifecycle (OnTransactionStart/OnTransactionStop) with rollback-on-exception.
  • Centralize shared user-facing message strings and the claim-domain DPI connection key (ClaimAppConstants).
  • Resolve the imaging API base URL via configuration (imagingapiurl) to construct the claim-image API client.

Component boundaries

  • ClaimAppManager: MustInherit (abstract) centerpiece of the library; extends the inherited AppManagerBase (local project reference, SAIF.Application) with claim-specific context, security, and save/transaction behavior. Concrete claim-screen application managers outside this library inherit from it.
  • ClaimContext: immutable-after-construction value object representing "what claim/worker is currently in scope" (claim ID, claim number, worker ID, context-set flag).
  • ClaimSecurity: computes the four per-claim access flags (conflict, exposure, secure/hostile, health-issue) for the current user against a specific clsClaimData instance; built from a ClaimUserAccess token.
  • ClaimUserAccess: inherits UserAccess (local project reference, SAIF.Application); exposes named AD-resource checks (SecureClaim, ConflictClaim, ExposureClaim, CollateralHealthClaim) via the inherited HasAccess lookup.
  • ClaimAppConstants: inherits AppConstants (local project reference, SAIF.Application); shared message/constant strings and the claim DPI key.
  • Institutions typed DataSet: auto-generated schema definition (Institution table); no hand-written logic, purpose beyond schema definition is unknown**.

Interaction model

  • A concrete claim-screen application manager (external to this library) calls ClaimAppManager.SetClaimContext(...) or SetWorkerContext(...), which constructs a new ClaimContext and invokes ChangeContext().
  • ChangeContext() calls OnContextChanged() (which retrieves claim data via GetClaimData() and, on success, marks the context set), then — only when the context is set — calls OnCheckSecurity() followed by OnRetrieve() (the latter implemented by the concrete subclass, not traceable from this library's source**).
  • OnCheckSecurity() calls ClaimSecurity.CheckClaim(ClaimData) to recompute the four access flags, unconditionally defaults the role to view-only (MarkViewOnly()), and calls MarkNoAccess() when the claim is a conflict claim the user lacks access to and no security override applies (CheckForSecurityOverride(), which delegates to ClaimServices.HasOverrideAcess — an external callee whose owning library could not be determined from this repository**).
  • Write() wraps subclass-implemented OnWrite() in OnTransactionStart()/OnTransactionStop(), guaranteeing commit/rollback around whatever business-object saves the subclass performs.
  • All data retrieval and persistence is delegated to externally-packaged business objects (clsClaimData, clsEmployeeData, clsClaimTaskGenerator) reached through the Oracle DPI established by OnCreateDataLayer(); this library never issues SQL directly.

Design constraints

  • ClaimAppManager is MustInherit; it has no independent runtime behavior without a concrete claim-screen subclass supplying OnRetrieve()/OnWrite().
  • The security-override bypass (CheckForSecurityOverride() → ClaimServices.HasOverrideAcess) is the only escape hatch for the conflict-claim hard-denial gate, but ClaimServices is not defined anywhere in this library or the rest of the scanned repository, so its internal logic cannot be verified from this library's source alone**.
  • SetClaimContext(inClaimID) (decimal overload) only calls MarkContextSet() directly and does not run ChangeContext()/OnCheckSecurity()/OnRetrieve(), an asymmetry versus the string overload that may be intentional (lightweight ID-only context set) or an inconsistency**.
  • Health-issue access (ClaimUserAccess.HealthIssueAccess, backed by the CollateralHealthClaim AD resource) is exposed but never consulted by ClaimSecurity.CheckClaim, which gates health-issue access using ExposureAccess instead; whether this is intentional or a latent defect could not be determined from this library's source alone**.
  • No attribute-based authorization exists in this library (no MVC controllers/actions, no [SAIFAuthorize]/[SaifAuthorize]); all enforcement is programmatic and confined to ClaimAppManager/ClaimSecurity*.
  • The library establishes exactly one configuration-driven external endpoint directly (imagingapiurl, via IEnvironmentService.GetConfigSetting); all other configuration (Oracle DPI, environment resolution internals) is inherited from SAIF.Application and out of this library's scope.

Architecture diagram

The following diagram shows the responsibility layering within SAIF.Application.Claim and its immediate external collaborators.

flowchart TD
  Caller["Concrete claim-screen<br>AppManager subclass (external)"] --> CAM["ClaimAppManager<br>(this library)"]
  CAM --> CTX["ClaimContext<br>(this library)"]
  CAM --> SEC["ClaimSecurity<br>(this library)"]
  SEC --> UA["ClaimUserAccess<br>(this library)"]
  UA --> BaseUA["UserAccess<br>(SAIF.Application, local ref)"]
  CAM --> Base["AppManagerBase<br>(SAIF.Application, local ref)"]
  CAM --> ClaimData["clsClaimData<br>(SAIF.Business, external package)"]
  CAM --> TaskGen["clsClaimTaskGenerator<br>(SAIF.Business.Tasks.Claim, external package)"]
  CAM --> EmpData["clsEmployeeData<br>(external package)"]
  CAM --> Img["ImagingClient<br>(ImagingAPI.Client, external package)"]
  SEC --> ClaimData

Sequence diagram

The following diagram shows the primary set-context/retrieve/security sequence triggered from a concrete claim-screen application manager.

sequenceDiagram
    participant Caller as Concrete claim-screen AppManager
    participant CAM as ClaimAppManager
    participant SEC as ClaimSecurity
    participant BIZ as clsClaimData (SAIF.Business)
    Caller->>CAM: SetClaimContext(claimNumber)
    CAM->>CAM: ChangeContext()
    CAM->>BIZ: GetClaimData()
    BIZ-->>CAM: clsClaimData
    CAM->>SEC: CheckClaim(ClaimData)
    SEC-->>CAM: access flags
    CAM->>CAM: MarkViewOnly() / MarkNoAccess()
    CAM->>Caller: OnRetrieve() (subclass-implemented)

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • SAIF.Application.Claim\ClaimAppManager.vb
  • SAIF.Application.Claim\ClaimContext.vb
  • SAIF.Application.Claim\ClaimSecurity.vb
  • SAIF.Application.Claim\ClaimUserAccess.vb
  • SAIF.Application.Claim\ClaimAppConstants.vb
  • SAIF.Application.Claim\Institutions.Designer.vb
  • SAIF.Application.Claim\SAIF.Application.Claim.vbproj
  • SAIF.Application.Claim\Web.config
  • SAIF.Application.Claim\app.config