Government

Online Petition Integration with the Provincial Platform

A single intranet gateway with a closed two-way loop for push, receipt, return and completion notices.

LiveGovernmentFocused projectPC operations console

Client: City-level online petition platformUndisclosed by agreement
Industry: Government
Platforms: PC operations console
Scale: Focused project · 2025

01Background

A city-level online petition platform had run for years, with every citizen letter, referral, reply, and closure stored in an Oracle database. Once the provincial public-opinion platform was rolled out, local letters had to flow both ways with it under the provincial API specification. The core mailbox system could not be changed, so an auditable integration channel had to be built alongside it.

Client: City-level online petition platform
Volume: About 100–200 letters per day
Users: Case handlers, integration operators
Deployment: Intranet gateway server, managed via VPN and bastion host

02Challenges

1Mismatched status models

Five local handling stages did not map cleanly to the four provincial actions: submit, accept, return, and resolve.

2Scattered sources

Letters, accept/return actions, and formal replies lived in three tables, so a shared sync timestamp kept overwriting itself.

3Untouchable core

The mailbox workflow was stable; embedding integration code risked live operations and made acceptance testing harder.

4Silent failures

Failed script pushes were buried in logs, and case handlers could not tell which letters never reached the province.

Close the loop with the provincial platform without touching the live mailbox core.

03Solution

Shanku deployed a standalone integration service on an intranet gateway server as the only path to the provincial platform; the mailbox system never calls provincial APIs directly. The service handles incremental extraction, field mapping, authenticated calls, and write-back, with a PC operations console that shows the sync status of every letter.

Single gateway exit

The integration service runs on its own intranet gateway, isolated from the mailbox and able to start, stop, and ship independently.

Four upstream actions

New letters, acceptances, returns, and final replies are converted to the provincial format and pushed one by one.

Downstream write-back

Provincial closure receipts are matched by business ID and written back as status, reply, and routing records.

Per-action checkpoints

Sync checkpoints are kept per table and action type, so accepts and returns never collide and runs resume after interruption.

Idempotency and retries

The same business ID and action is never pushed twice; network failures go to a retry queue and escalate to staff after the limit.

Visible, re-pushable

The console shows checkpoints, sync records, and request logs, and can force a re-push by tracking number without disturbing progress.

04Core workflow

Two-way letter loop

1
Extract
Read changes from Oracle by action type
2
Map
Build provincial payloads; defaults from config
3
Push
Sign, obtain a token, and call the provincial API
4
Record
Store the response; failures go to retry
5
Receive
Province pushes the closure receipt
6
Write back
Update status, add reply and routing records

Each letter keeps one business ID from first push to closure, so upstream and downstream records reconcile line by line.

05Results

Compliant, uninterrupted

Meets the provincial platform’s unified access and data aggregation requirements without rebuilding the mailbox workflow.

Reconcilable status

One business ID runs from push to closure, so the full upstream and downstream history of any letter is traceable.

Accountable operations

Sync records, request logs, and a retry queue replace digging through server logs; logs are kept for at least 180 days.

Reusable pattern

The sidecar gateway plus checkpoint-and-record approach carries over to other provincial data exchanges.

06Screens

Screens are prototypes or rebuilt with sample data. They contain no real client data, amounts or accounts.

07Tech stack

Backend: Spring BootMyBatis-FlexCool-Admin
Ops console: Vue 3Element Plus
Data & integrations: OracleMySQLApache HttpClientSigned token auth
Deployment: Intranet gateway serverVPNBastion host

More case studies

All case studies

Facing a similar challenge?

See how we work together: from requirements and prototypes to launch and handover, every step is spelled out in advance.

How we work See proposal samples