Skip to content

Expense status worklist

Supervisors and specialists work their queues by status: everything pending approval, everything ready to pay, everything in check status. This operation supplies those queues. Unlike the rest of the library it does not use the Oracle package or the data portal at all — it calls the EAIP integration REST API, deserializes the response into flat projection objects, and returns them as a read-only list. There is no save path, no rule set, and no concurrency handling, because nothing here is editable.

Field Value
Operation ID OP-EAIP-05
Trigger Caller invokes clsExpenseByStatus.GetExpenseList(dataPortal, status) or GetExpenseList(dataPortal, status, eaipUser); the specialist argument defaults to ALL
Inputs IDataPortalInfo (supplies the API access layer and the configured EaipApi client), an expense status code, and an optional EAIP specialist mail identifier
Outputs A clsExpenseByStatusList of projections carrying expense identifier, claim number, worker name, specialist, expense type description, description, paid amount, status date, and credit-card date; an empty list when the API returns no records
Primary components clsExpenseByStatus (GetExpenseList, Criteria.ConfigureRoutes), clsExpenseByStatusList (AddToList)
Entry point Business\SAIF.Business.Claim.EAIP\Period\clsExpenseByStatus.vb

Steps

  1. Build the criteria. GetExpenseList constructs an API criteria from the data portal. The criteria derives from the API criteria base rather than the database criteria base, which is what routes this operation away from the Oracle package.
  2. Configure the route. ConfigureRoutes resolves the configured API client under the key EaipApi for the Integration controller and registers one retrieve route with the pattern V1/Integration/SelectExpensesByStatus/?ExpenseStatus={0}&Specialist={1}.
  3. Format the request. The criteria formats that route with the requested status code and specialist, producing a fully-qualified query string. When the caller supplies no specialist, the literal ALL is substituted, which the service interprets as "every specialist" rather than as a user named ALL.*
  4. Call the service. The data portal's API access layer processes the request and returns an array of clsExpenseByStatus instances deserialized from the response body. The underlying data is produced server-side by the EAIP integration service, which is the API face of the package routine that selects expenses by status (Details).
  5. Project into the list. When the result array is non-empty, each record is appended to a clsExpenseByStatusList through AddToList. Every property on the projection is a plain read/write field with no change tracking, no smart-type wrapping, and no code-table resolution — the expense type and status arrive from the service already described in text.
  6. Return. The populated list (or an empty one) is returned. The caller is expected to use the expense identifiers on the rows to open the underlying purchase or wage subsidy through Expense lifecycle and payment approval when action is required; the worklist itself carries no behavior.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Caller requests a status queue]) --> Crit[Build API criteria<br>from the data portal]
    Crit --> Route[ConfigureRoutes resolves the<br>EaipApi client for Integration]
    Route --> Fmt[Format route with status<br>and specialist, defaulting to ALL]
    Fmt --> Call[API access layer processes<br>the retrieve request]
    Call --> Any{Any records returned?}
    Any -->|No| Empty([Empty list returned])
    Any -->|Yes| Add[Append each record<br>to the projection list]
    Add --> Done([Read-only worklist returned])

Failure and edge-case behavior

  • The operation registers no business rules — the rule-registration method is deliberately empty — and performs no validation on the status code it is given. An unrecognized status simply returns nothing rather than raising an error.*
  • Nothing here writes. The projection has no criteria statements, no save path, and no update number, so a worklist row cannot be used to change an expense; the caller must load the real expense object to act.
  • The list is a point-in-time snapshot taken from a remote service. Rows can be stale by the time the user acts on them, and the operation provides no refresh or change notification.*
  • Failures of the remote service surface as whatever the API access layer raises; this class adds no try/catch, no retry, and no fallback to a database query, so an unavailable service means an unavailable worklist.*
  • The specialist and status values are interpolated into a query string. Values containing reserved URL characters are passed through as-is by this code, so correctness depends on the API client's own encoding.*

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.EAIP\Period\clsExpenseByStatus.vb
  • Business\SAIF.Business.Claim.EAIP\Period\clsExpense.vb