Skip to content

Claim list generation

Many claim screens and batch processes need the same thing: a list of claims produced by some caller-specific query, presented as claim identifiers and formatted SAIF claim numbers. Rather than each caller writing its own collection plumbing, this operation accepts the caller's own SQL statement and a single bind value, executes it, and hydrates a sortable, searchable collection of claim list items whose column names the caller may also override.

Field Value
Operation ID OP-BC-10
Trigger clsClaimListGenerator.GetClaimListCollection(dataPortalInfo, sqlStatement, id, requestID) or the overload accepting a fully populated Criteria
Inputs The SQL statement to execute; the single bind value named ID; an optional request identifier; optional column-name overrides for the claim identifier, claim number, check character, and worker identifier columns
Outputs A clsClaimListCollection of claim list items, each exposing a claim identifier, claim number, check character, worker identifier, and the concatenated SAIF claim number
Primary components clsClaimListGenerator.Criteria, clsClaimListGenerator.BeforeRetrieve, clsClaimListGenerator.AfterRetrieve, clsClaimListCollection, clsClaimListItem
Entry point Business\SAIF.Business.Claim\clsClaimListGenerator.vb

Steps

  1. Capture the caller's query. The factory builds a Criteria holding the SQL statement text, the bind value, and an optional request identifier; a second overload accepts a Criteria the caller has already populated, which is the route used when column names need overriding.
  2. Configure the request. BeforeRetrieve sets the data request identifier from the criteria — defaulting to the generator's own name when the caller supplied none — installs the caller's SQL statement as the statement text, and binds the single parameter named ID to the caller's value. No statement is catalogued for this operation because the text originates entirely with the caller.*
  3. Hydrate the collection. AfterRetrieve walks the data reader and, for each row, constructs a claim list item populated from four columns whose names come from the criteria: the claim identifier, claim number, claim check character, and worker identifier columns, defaulting to those same names when the caller did not override them.
  4. Build the SAIF claim number. Each item concatenates its claim number and check character value into the displayable SAIF claim number so callers never assemble it themselves.
  5. Use the collection. The resulting collection supports adding, removing, sorting, and finding items, so callers can filter or reorder the list in memory without returning to the database.
  6. All persistence is refused. The Criteria raises an application exception from its create, insert, update, delete, and retrieve SQL properties — the retrieve statement is supplied at runtime instead — so a claim list can never be written back.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Caller supplies a SQL statement<br>and a bind value]) --> Cfg[Set the request id and install<br>the caller's statement text]
    Cfg --> Bind[Bind the single ID parameter]
    Bind --> Exec[Execute the query]
    Exec --> Loop{More reader rows?}
    Loop -->|Yes| Item[Read the four configured columns<br>into a claim list item]
    Item --> Num[Concatenate claim number<br>and check character]
    Num --> Loop
    Loop -->|No| Done([Return the sortable<br>claim list collection])

Failure and edge-case behavior

  • The statement text is supplied entirely by the caller and is neither validated nor parameterized beyond the single ID bind, so statement correctness and injection safety rest with the caller.
  • A statement whose result set does not expose the four expected column names fails inside the reader loop; the operation performs no column-presence check first.*
  • Only one bind value is supported, so any query needing several filters must inline the remaining criteria into the statement text.
  • An empty result set yields an empty collection with no error, so callers must distinguish "no claims" from "query wrong".
  • The default request identifier is shared by every caller that does not supply one, which limits the usefulness of request-level diagnostics.*
  • Sorting and filtering happen in memory after the full result set has been materialized, so a broad statement can produce a large in-memory collection.*

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

  • Business\SAIF.Business.Claim\clsClaimListGenerator.vb
  • Business\SAIF.Business.Claim\clsClaimListCollection.vb
  • Business\SAIF.Business.Claim\clsClaimListItem.vb