Connector Refresh (New Account Set) Strategy in Practice: Scheduled Re-Push Authorization via Qeasy to Keep Supply Chain Integration Always On

What This Strategy Solves

The biggest fear in supply chain integration is not slow sync, but sudden loss of flow. After a retail company switched Kingdee YXC from an old account set to a new one, all API authorization tokens were invalidated, causing 60+ strategies covering customers, materials, and sales orders to fail overnight. By the time operations noticed, every downstream system had stopped. The "Connector Refresh (New Account Set)" strategy installs a heartbeat scheduler on the whole pipeline: it pulls the latest authorization state every hour and writes the inner outerInstanceId to the Qeasy integration platform, ensuring all dependent strategies always have a valid credential — instead of passively firefighting after a 401.

Data Flow and Field Mapping

This strategy itself carries almost no data (only one authorization instance per run), but it is the pre-dependency of the entire integration; the other 60+ strategies all rely on it being healthy.

The source side is a WebAPI POST to /jdyconnector/app_management/push_app_authorize, effect QUERY. The target side is the same platform's 写入空操作, effect EXECUTE. The core mapping is a single value: outerInstanceId.

How to Configure on Qeasy

For the source connector, choose "Kingdee YXC V2" and configure /jdyconnector/app_management/push_app_authorize as a query API. In the request body, outerInstanceId is a fixed string generated by the open platform after the enterprise is onboarded. For the target connector, choose "Qeasy integration platform" and pick 写入空操作 — a platform-native empty-write API that exists exactly for this kind of "trigger but don't persist" operational strategy. Enable idCheck on both sides, disable buildModel, and skip response parsing — this is not data sync, it just keeps the connector warm.

Implementation Steps

1. Incremental starting point: On first deployment, manually trigger the source once to push the current account set's outerInstanceId to the platform as the baseline for later validation.
2. Full trigger: In the Qeasy scheduler, assign cron 3 * * * * to this strategy (3 minutes past every hour, avoiding the top-of-hour peak); meanwhile assign 23 2 * * * to the target side as an early-morning safety refresh in case the hourly schedule ever skips.
3. Schedule frequency: Hourly is enough. Authorization tokens typically last 24 hours; probing once per hour catches account-set switches in time without putting pressure on the source system.
4. Linked check: Once the refresh succeeds, Qeasy refreshes the connection pool of every downstream strategy that depends on this connector — no manual restart needed.

Pitfalls Revisited

1. Assuming one-time config lasts forever — A typical mistake is hardcoding outerInstanceId in the request, so the moment the enterprise opens a second account set, the old authorization dies. The safe approach: make outerInstanceId a configurable item, and when the account set changes, edit one place and let this strategy take over automatically.
2. Mixing refresh strategies with data strategies in the same schedule group — If the refresh breaks, the data breaks too. But the reverse is also risky: high-frequency data jobs can slow down the refresh judgment. The recommendation is centralized encoding & mapping management: keep all "authorization/connector" strategies in a separate group with priority above the data strategies.
3. Ignoring the cascade after a 401 — In one real project, the customer didn't enable this strategy. One day after an account-set switch, customer, material, and sales-order strategies all returned 401 almost simultaneously and operations received hundreds of alerts. After enabling the refresh strategy, alerts dropped to zero.
4. Misusing the "incremental + full dual-track" pattern — This strategy has no "full" mode; do not be misled by the wording. It only has one state: "did the refresh succeed or not." Do not reuse a business-data full-pull template here.
5. Pointing the target side at a real business write API — Many people casually re-point it at a real target interface and write an empty record to the business database every hour. A few days later, downstream reconciliation fails. Empty-write means empty-write; don't take shortcuts by tweaking the config.

When to Use and When Not to

Use when: Multi-account-set, multi-org enterprises, especially systems like Kingdee YXC that isolate data by account set; integrations whose authorization tokens expire quickly and depend on an open platform; supply chain pipelines that must run 24/7. Do not use when: One-time data migration (no heartbeat needed); lightweight integrations with a single account set and long-lived tokens (over-engineering that just adds scheduling cost).