Querying Enterprise Bank Accounts from YongYou BIP to Qeasy: A Pull-Based Integration Strategy

What This Strategy Solves (Scenario & Value)

In a retail company's sales order workflow, sales staff frequently need to verify customer payment accounts on the CRM side, but enterprise bank account numbers, account names, and bank details all live inside the YongYou BIP funds master data. Manually digging through the ERP each time is slow and prone to typos.

By turning this into a "Query YongYou Enterprise Bank Accounts" strategy, the core value is threefold: first, pull account data back page by page from the ERP in one go; second, provide prerequisite data for downstream sales order writes and reconciliation; third, decouple "reading the ERP" from "writing to business systems," so the CRM side always has a stable, reusable view of the funds master. In the on-premise projects we deliver via the Qeasy data integration platform, this kind of "pull-type" strategy usually serves as a prerequisite step in the overall sales order pipeline.

Data Flow & Field Mapping (Source → Middle Layer → Target)

The data flow for this strategy is unidirectional pull: read data from the YongYou BIP funds master API and land it in the Qeasy middle layer, without triggering any downstream write. On the target side in Qeasy, it is configured as a "write null operation," with effect marked as EXECUTE but with no request body constructed. The purpose is to give the strategy a complete write mount point, so downstream consumers can be attached later without rebuilding the strategy.

Key field mapping (source field → middle layer meaning):

In the middle layer, we recommend keeping the source field names as-is rather than translating them into business terms prematurely. Add a separate "business mapping layer" when actually writing to the CRM. This is a common pattern among Qeasy customers — keeping source fields and business fields in separate layers, so a single mapping change does not ripple across the whole chain.

How to Configure It on Qeasy

When configuring this strategy in the Qeasy data integration platform, there are several typical points to pay attention to:

1. Source system connection: Choose YongYou BIP as the source platform, attach the API path to /digitalModel/basedoc/enterprisebank/batchQueryDetail, method POST, and effect QUERY. This explicitly tells the platform "read only, do not write."
2. Hard-code paging parameters: Put pageIndex and pageSize directly in the request body with default values 1 and 10. This is where many projects crash on first configuration — defaults must be written explicitly, do not rely on implicit upstream behavior, otherwise a future API version change can silently break the pull.
3. Target as "null operation": On the Qeasy side, configure the target as write null operation, mark effect EXECUTE, and set idCheck to true. The strategy runs end-to-end, data stays in the middle layer, and waits for downstream consumers — without polluting the ERP in reverse.
4. Primary key & deduplication: Use code as the number field and id as the id field, with idCheck turned off — because we only care about "whether this batch is already in the store," not about strict unique key validation per row.
5. Auto-fill response: Enable autoFillResponse so Qeasy models the response field structure from a real call, which the engineer only needs to verify, not retype.

Implementation Steps

We schedule this strategy on the customer site in three phases:

• Phase 1: Establish the incremental baseline. The first run is forced to "full," with pageSize bumped to 100 (one common pattern among Qeasy customers is the incremental + full dual-track: regular incremental pulls on schedule, full resync for first run or after exceptions). After the full run completes, record the maximum code or maximum id as the incremental watermark for later runs.
• Phase 2: Lock the schedule. The source strategy crontab is set to 3 2 * * *, triggering daily at 02:03. This time slot avoids business peak hours and avoids the on-the-hour concentration of other sales order strategies — staggered scheduling is the safe way to reduce instantaneous pressure on the ERP side.
• Phase 3: Attach downstream consumers. Although the target is configured as a "null operation," the strategy itself already occupies a node in the Qeasy orchestration graph. The next step, whether "write to CRM customer master" or "associate with sales orders for reconciliation," can be hung directly downstream of this strategy, without triggering another ERP read, saving a round of API quota.

Lessons from the Field

1. Paging defaults get overwritten. A typical mistake is passing pageIndex and pageSize only during front-end debugging, then forgetting to bake the defaults into the strategy metadata at go-live. The safe approach is to list these two fields explicitly with default values inside the Qeasy strategy, and route any change through a configuration change process — never override them inside scripts.
2. orgid___name treated as a scalar. In the source, this field is actually an object, nesting the organization name inside. If the CRM side treats it as a plain string, it shows up as "undefined" or "[object Object]." The safe approach is to keep the original type in the middle layer and only flatten it via Qeasy field mapping at consumption time.
3. Null-op target misread as "strategy failed". Seeing effect EXECUTE with no downstream write on the monitoring page can make someone think the strategy failed. In fact this is the designed "pull-type" behavior — data only lands in the middle layer. The safe approach is to write "QUERY_ONLY, INTERNAL" explicitly in the strategy description, and configure monitoring alerts based on the row count landed in the middle layer.
4. idCheck vs idempotency conflict. This strategy has idCheck set to false, meaning dedup is delegated externally. If a downstream consumer is unaware of this, it may write duplicates. The safe approach is to add a deduplication view in the Qeasy middle layer with a unique constraint on the code dimension, so idempotency is absorbed at the platform layer.
5. Time window in on-premise environments. A schedule like 02:03 can collide with ERP backup windows in cross-time-zone or multi-factory environments. The safe approach is to confirm the backup window with ERP ops, either stagger the schedule, or hook the strategy to a "backup complete" alert.

When It Applies and When It Does Not

Applies: Master-data-style queries such as enterprise bank accounts, bank codes, and organization-to-account mappings; situations where the data must be linked to other business documents downstream; on-premise scenarios that need pull rather than write-back.

Does not apply: Real-time (second-level) account validation — that should call the ERP online API directly; scenarios where account changes must be written back to the ERP, since this strategy is read-only; and bulk pulls of sensitive account fields (balances, transaction history), which are typically restricted by compliance and should not be cached in the Qeasy middle layer.