Organization Master Data Query Strategy: Pulling the Org Tree from ERP to the Integration Platform

What This Strategy Solves (Scenario & Value)

In supply chain integration, almost every business document carries an "organization" field: shipping org, settlement org, inventory org, store org. The source ERP's organization API usually returns a multi-level tree, and downstream business systems, reporting systems, and even the integration platform itself all consume this "organization panorama." In one real project, the customer wanted us to pull the full organization set before each material and sales order sync, so it could serve as the "address book" for all subsequent documents. This strategy is the very front of that chain: the Yonyou BIP /yonbip/digitalModel/orgunit/querytree API is queried, and the result lands on the Qeasy data integration platform for later strategies to reference. It looks like just "one query," but it plays the role of "A-sequence master data foundation" across 41 strategies.

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

The source side is Yonyou BIP's digital model organization API; the target is the "empty write" action on the Qeasy integration platform—this isn't pushing data to a business system, but keeping an organization snapshot inside the platform as a lookup dictionary for subsequent mappings.

Key field mapping:

One detail worth emphasizing: number is code and id is id, which means the organization code is the unique key. Any subsequent field mapping depending on org code will use this dictionary as the source of truth.

How to Configure on Qeasy

In the Qeasy data integration platform, this strategy takes the form of a "source metadata + target metadata" pair.

Source side (Yonyou BIP):

• palatom.code = YonYon.BIP, platform ID bound to tenant;
• api = /yonbip/digitalModel/orgunit/querytree, method=POST, type=QUERY, effect=QUERY;
• request has three items: code, name, enable status, with enable defaulting to 1 (only enabled orgs);
• number=code, id=id, idCheck=true enables idempotency check to prevent duplicate writes;
• buildModel=false, autoFillResponse=false means model fields are maintained manually and no auto-fill on response.

Target side (Qeasy integration platform):

• palatom.code = datahub (representing the platform itself);
• api = "empty write operation", method=POST, type=EXECUTE;
• request/response are both empty, meaning "data lands on the platform, no external system is pushed."

Putting the two configurations together: "query from ERP → land on platform."

Implementation Steps

On a customer site, we usually advance in three phases:

Phase 1: Increment first. Run with enable=1 to get enabled orgs; compare the returned tree with the customer's master data ledger. Whether code is unique, whether there are "disabled but still referenced" dirty records—these all surface at this step.

Phase 2: Full alignment. Change enable to empty or omit it, run a full pull (including stopped), diff against the enabled set to get a "stopped organization list," and manually decide whether to include them in the dictionary. A common Qeasy customer pattern is: keep the enabled set in memory at all times, archive the stopped set monthly, so main flows never reference dirty orgs while audit trails are preserved.

Phase 3: Scheduling frequency & dependency orchestration. The source cron is 49 3 * * *—runs once daily at 3:49 AM, scheduled to finish before material and sales order strategies. The target cron is 23 2 1 1 1, representing "2:23 AM on January 1st"—an annual snapshot trigger, typically used for year-end org restructuring.

In the orchestration of 41 strategies, this strategy is sequence=A and depends_on=[], meaning it's the "no-dependency starting point" of the entire chain. We usually place it under a "centralized code-mapping management" directory, so all org-dependent field mappings reference the same dictionary, avoiding the fragmentation where "module A uses code, module B uses ID."

Pitfall Review

1. Empty operation doesn't mean "no config needed". The target api=empty write operation looks like a placeholder, but idCheck=true and number=id must align with the source side; otherwise, the platform side creates duplicates, and the dictionary doubles in size within 3 months.
2. enable default value is the easiest to flip. The source enable defaults to 1, which keeps things clean; but if the customer's business has a "create org first, enable later" workflow, the result will be empty, and you'll spend hours debugging why the dictionary wasn't built. The safe practice is to run a "request preview" on Qeasy before going live and confirm the return is non-empty.
3. Organization code is not globally unique. In the source system, code is unique within a tenant, but can repeat across tenants. Once the platform side enables multi-tenant mode, you must add a tenant + code composite key at the mapping layer.
4. Stopped orgs are silently filtered. After running with enable=1 for a while, business users will ask "why can't I find a certain org anymore?"—in reality, it was stopped. It's better to flag stopped orgs separately on the platform side rather than dropping them outright.
5. Cron windows must be staggered. The source 49 3 * * * and target 23 2 1 1 1 may look arbitrary, but they deliberately avoid the peak hours of downstream material and sales order strategies. If many strategies all run at 3 AM, the platform side will see a race condition: "downstream tries to reference the dictionary before it's ready."

Applicable & Non-applicable Scenarios

Applicable: Multi-org retail, chain, and manufacturing enterprises; scenarios needing a unified organization dictionary before supply chain document sync; all downstream strategies requiring idempotent mapping by code.

Not applicable: Small businesses with a single org and no multi-level tree; scenarios requiring real-time push of orgs to third-party business systems (this strategy only lands on the platform, no external push); scenarios requiring minute-level sensitivity to org changes—the daily scheduling of this strategy is insufficient.