Skip to content

Write claim application changes

Write() wraps the subclass-specific save logic in an Oracle transaction so that either all pending changes commit together or none of them do. It is the transactional counterpart to Retrieve claim application data.

Field Value
Operation ID OP-AC-04
Trigger Caller calls Write() on an active ClaimAppManager subclass instance
Inputs Pending in-memory changes accumulated by the subclass since the last save
Outputs Boolean commit/rollback result; committed or rolled-back Oracle transaction
Primary components ClaimAppManager.Write, ClaimAppManager.OnTransactionStart, ClaimAppManager.OnWrite, ClaimAppManager.OnTransactionStop, IDataPortalInfo
Entry point Application\SAIF.Application.Claim\ClaimAppManager.vb

Steps

  1. Write() initializes a local WriteResult to False.
  2. Write() calls OnTransactionStart() before attempting any subclass save logic.
  3. OnTransactionStart() checks DPI.TransactionPending; if it is false, it calls DataLayer.DAL.BeginTransaction(DPI.PortalID) to open a new Oracle transaction. If a transaction is already pending, no new transaction is started.
  4. Inside a Try block, Write() calls OnWrite() and assigns its result to WriteResult.
  5. OnWrite() is abstract in ClaimAppManager; the concrete subclass performs its own business-object save calls here.
  6. On an exception during OnWrite(): the Catch block calls OnTransactionStop(False) (forcing a rollback) and then re-throws the caught exception via Throw ex, which resets the original stack trace to this catch block rather than preserving the original throw location.*
  7. The Finally block calls OnTransactionStop(WriteResult) unconditionally, whether or not an exception occurred.
  8. OnTransactionStop(inCommit) checks DPI.TransactionPending; if a transaction is pending, it calls DataLayer.DAL.EndTransaction(DPI.PortalID, inCommit), committing when inCommit is true and rolling back when it is false.
  9. Because the Catch block already called OnTransactionStop(False) on failure, the Finally block's subsequent call finds no transaction pending (from the perspective of DPI.TransactionPending) and is effectively a no-op on the exception path.*
  10. Write() returns WriteResult as the overall success indicator.

Process flow

The following diagram visualizes the transaction-wrapped save sequence, including the exception path.

flowchart TD
    Start([Caller invokes Write]) --> TxStart[OnTransactionStart:<br>begin transaction if none pending]
    TxStart --> OnWrite[OnWrite in subclass]
    OnWrite -->|Success| SetResult[WriteResult = OnWrite result]
    OnWrite -->|Exception| Rollback[OnTransactionStop False;<br>rethrow exception]
    SetResult --> Finally[Finally: OnTransactionStop WriteResult]
    Rollback --> Finally
    Finally --> Commit{WriteResult True?}
    Commit -->|Yes| Committed([Transaction committed])
    Commit -->|No| RolledBack([Transaction rolled back<br>or exception propagates])

Failure and edge-case behavior

  • If OnWrite() throws, the transaction is rolled back immediately in the Catch block and the original exception is re-thrown to the caller — callers must handle the propagated exception themselves; Write() does not swallow it.
  • Re-throwing with Throw ex (rather than a bare Throw) resets the stack trace, which can make root-cause diagnosis harder for callers inspecting the exception.*
  • If OnTransactionStart() finds a transaction already pending (DPI.TransactionPending = True), it does not begin a new one — nested Write() calls share the same outer transaction rather than each managing their own.*
  • OnWrite() has no base-class implementation; a subclass that does not override it will have WriteResult remain at its default False, and the transaction will always roll back.*

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

Sources

  • Application\SAIF.Application.Claim\ClaimAppManager.vb