Authoritative Guide to the QeasyCloud QueryStrategyData API — Field Manual & Hands-on Tutorial for Cross-Strategy Execution Queue Queries

What This API Solves

Inside the QeasyCloud (Datahub) integration platform, a single business domain is usually composed of multiple chained strategies. In the sales-order domain, for example, you often see strategies like "Delivery Note => Sales Outbound Order" and "Return/Exchange Order => Sales Return Order". When a downstream strategy needs to decide whether to trigger immediately based on the execution queue status of an upstream strategy — or when it needs to reset upstream records from "In Queue" back to "Awaiting" so they can be re-scheduled — the QueryStrategyData API comes into play. It addresses cross-strategy orchestration needs, and is typically used for cascading scheduling, failure retries, and queue-status synchronization, giving upstream and downstream strategies a controllable, replayable data chain.

API Capabilities Overview

• Authentication: Internal QeasyCloud platform authentication; the caller must hold access rights to the target strategy.
• Request structure: POST to QueryStrategyData. Core parameters: strategy_id, status (single value or comma-joined multi-value, e.g. "5" or "5,4"), created_at_begin/end, response_at_begin/end, id, number, page, pageSize, projection, and lastId.
• Response structure: response.rows[] array; each row is a queue record. Internal fields are auto-filled by _autoFillResponse.
• Pagination & incremental: Both classic page/pageSize and lastId cursor-based incremental fetching are supported. When filtering by time range, always use 10-digit Unix timestamps.

Typical Field Mapping

How to Configure on QeasyCloud

On the QeasyCloud integration platform, this API is encapsulated as a "Query Another Strategy" source component. Just pick the QueryStrategyData adapter. Typical setup: fill in the target strategy_id → set status default (commonly 5) → configure the time window and pagination → in the field mapper, check the columns to forward (_id, F_status, F_created_at, F_response_at, etc.) → choose "Write Empty Operation" on the Target side, and put the real logic in the AfterSourceInvoke script: iterate rows → call updateMany to set the corresponding target-strategy records' status to AWAIT; if rows is empty, trigger an immediate schedule on the target strategy. Finally, control cadence with crontab (e.g. 3 8 * * *). QeasyCloud's field mapper will automatically hide non-business internal fields besides _id, preventing accidental mapping.

Cross-Strategy Best Practices

1. Always make status explicit: 5 (in queue) is the most common filter. Forgetting to pass status and accidentally pulling all completed records is a classic pitfall — hard-code the default in the adapter.
2. Use comma-joined multi-status: The platform supports "5,4". If you need to retry both "in queue" and "unaudited" records, one multi-value query beats two.
3. _id is the real batch-update anchor: primaryWriteback looks like a primary key but is only a writeback marker; for updateMany, you must use _id, otherwise nothing will match.
4. Prefer response_at over created_at for time windows: Cross-strategy scheduling cares more about "latest processing time". Filtering by response_at reflects true business state better.
5. Empty rows is a trigger, not an error: No need to throw; treat it as a signal to immediately schedule the target strategy instead.
6. F_respone is an object, not a string: Recognize it as a nested structure in the mapper; otherwise it will be serialized as a string and pollute downstream data.

Pitfall Review

• Pitfall 1: Missing status causes a full table scan. Symptoms: scheduled job pulls hundreds of thousands of completed records and blows up the target DB. Fix: hard-code status=5 as the adapter default and enforce required validation.
• Pitfall 2: Using primaryWriteback as the update key. Symptoms: updateMany always matches 0 rows. Fix: consistently use $row->_id and add a code comment to lock in the convention.
• Pitfall 3: Timestamp digit mismatch. F_created_at is a 10-digit Unix timestamp; passing a 13-digit millisecond value returns empty or wrong results. Fix: normalize with Math.floor(Date.now()/1000) before sending.
• Pitfall 4: F_respone forwarded as a string. Symptoms: downstream parse errors and escaped values. Fix: mark it as object in the QeasyCloud mapper, expose it only on the debug channel, and uncheck it for business output.
• Pitfall 5: No throttling across strategies. Symptoms: upstream and downstream fire at high frequency simultaneously, overloading the target system. Fix: stagger crontabs (e.g. upstream 3:08, downstream 3:10) and add a concurrency lock in the script.

When to Use It

Use this API when multiple strategies within the same business domain are chained and the downstream needs to be driven by the upstream's queue status — typical cases include cascading sync, failure retry, and cross-strategy status reset in the sales-order domain. The boundary: it serves QeasyCloud internal orchestration only and does not directly talk to external business systems. If you need cross-domain business data rather than queue state, switch to the corresponding business query interfaces of the source systems (e.g., GuanyiCloud Qimen or Kingdee Cloud Galaxy's business document query).