Server Routing

Server Routing

Point some or all live API traffic at the separate test SQL Server (TestServerName in Web.config) instead of the live one — a UI over the server.manage admin endpoints. Five independent controls apply, most specific wins: a per-request test flag (an approved user adding ?dbmode=test to one call's own URL) beats a per-user override, which beats a per-feature override, which beats a per-brand-database override, which beats the global default. Each action still runs the same server-side permission check as calling the API directly.

Log in

Enter your UserID/password. This calls Authenticate's password grant and fills in the Bearer token box below — your password itself is never stored, only the token.

Bearer token

Filled in automatically after a successful login above — or paste your own "user" access token belonging to an account with the server.manage permission.

Global default

Applies to every call where neither the calling user nor the target brand database has its own override. Setting this to Test with no other overrides in place sends all traffic, for every user, to the test server.

Current: —

Brand databases

Every POST/GET endpoint that touches one of these 8 brand databases (Policy Onboard among them) resolves its connection through the same shared helper, so an override here applies to all of them at once — regardless of which user calls, unless that user also has their own per-user override below.

Brand Override Effective Actions
Log in above to load the brand list.

Per-feature routing

Pins one named feature's traffic to Live or Test, for every user, beating the brand-database and global defaults — but a user's own per-user override above still wins for their own calls. PolicyOnboard covers all 5 Policy Onboard endpoints (proposal save, FA search, FA chain, address lookups, and Health Bima dependent-SA options) — this is the control for "Policy Onboard on Test for everyone, everything else stays Live." One caveat: the address-lookup endpoint reads a fixed connection string outside this mechanism entirely, so its data will not actually move to the test server even though it's tagged here for consistency. OrEntry covers just the OR/OREntryFPR row PremiumOrIssuanceRepository writes after a premium-collection POST — pinning it to Test moves only that write, never the tblPremiumCollectionViaBank insert itself. To stop OR/OREntryFPR issuance outright instead of rerouting it, use the "OR / OREntryFPR issuance" card below.

Feature Override Actions
Log in above to load the feature list.

OR / OREntryFPR issuance

Controls the Official Receipt / proposal FPR entries PremiumOrIssuanceRepository.ProcessPremiumPosting creates right after PolicyController.Post/PolicyInfoController.Post's own tblPremiumCollectionViaBank insert. Stop turns this off entirely - the premium-collection row itself is always recorded either way, only the OR/OREntryFPR step is skipped. To send these writes to the Test server instead of stopping them, pin the OrEntry feature to Test in the Per-feature routing table above.

—

Policy Onboard - manual only

Controls whether the camera-scan Policy Onboard entry path (capture proposal/NID photos, OCR extract, review & save) is available in the RupaliApp app. Disable forces manual entry only - ProposalScanExtractController, ProposalScanSaveController and ProposalScanGetController all refuse to proceed with a clear message telling the user to use manual entry instead. The manual Policy Onboard entry screen itself (PolicyOnboardController) is completely unaffected either way.

—

App local DB reset

Tells the RupaliApp Android client to drop and repopulate its own local SQLite Plan/PlanTerm lookup tables the next time that user's Dashboard screen polls in. No effect beyond recording the signal - the device does the actual reset in the background on its next visit to Dashboard.

Per-user routing

Every registered user_table account with its EFFECTIVE mode (its own override if it has one, otherwise the current global default). Backed by GET /api/v1/server-routing/users. A per-user override beats both the brand override and the global default for that user's own calls.

Test flag is independent of the override above - allowing it lets that user add ?dbmode=test to a single call's own URL and route just that call to Test, without pinning any of their other traffic (so their live operations keep running on Live). Beats every other control here, but only for a call that carries the flag.

UserID Type Override Effective Test flag Actions
Log in above to load the user list.