Practical Guide to Querying UFIDA YS Customers Strategy: Pulling Customer Master Data from BIP into Qeasy Integration Platform

What This Strategy Solves

In the sales order pipeline, customer master data is often the most overlooked yet earliest-failing piece. In one real project at a retail enterprise, sales orders were pushed from the CRM system to the ERP system for financial accounting. On the third day of go-live, customer codes in the orders could not be found on the ERP side—the root cause was that the ERP-side customer master records had not been prepared in advance.

The essence of the "Query UFIDA YS Customers" strategy is before the order sync starts, to use the Qeasy integration platform to actively pull customer profiles from UFIDA BIP, forming a reusable customer master snapshot on the platform side. All downstream strategies that depend on customer codes (orders, products, prices) read from this snapshot, avoiding repeated direct connections to the source system.

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

The source system is UFIDA BIP, calling its digital modeling domain's customer profile interface; the target side is implemented inside the Qeasy platform as an "empty write operation" execution node—its real value does not lie in the write action, but in triggering the platform's query orchestration and caching capabilities.

Among the source return fields, code as the customer code is the core key value; descriptive metadata fields like attachmentGroupId are received by Qeasy by default but not mapped to business fields, available for downstream consumption as needed.

How to Configure on Qeasy

Our approach at the customer site has four steps:

1. Register the source platform: In the Qeasy console's "System Integration" section, add UFIDA BIP and fill in the authorization information (in private deployment environments, this is usually an intranet gateway + application ID). The platform will automatically probe the API gateway reachability.
2. Configure the source interface: Create a WebAPI node following the /yonbip/digitalModel/merchant/newlist path from the material, select POST as the method, and fix the two pagination parameters pageIndex / pageSize in the request body.
3. Configure the target node: The target is an internal Qeasy node of type "Empty Write Operation" (EXECUTE). The key here is not the write itself, but making it the "data ready" signal source for subsequent strategies—downstream strategies reference this strategy's output as input.
4. Establish dependencies and triggers: Mark this strategy as sequence A (predecessor); all other sales order strategies (sequence B) reference it via depends_on. Downstream only starts after this one finishes.

One common pattern we see among Qeasy customers is centralized management of code mappings: putting mappings like code → customer full name, code → owning organization into the platform's "Field Mapping" module for unified maintenance, so all subsequent strategies reuse the same mapping rather than each writing their own transformation script.

Implementation Steps (Phased Scheduling)

• Incremental starting point: Run a full pull on the day of go-live to bring all current customer profiles from BIP to the platform; switch to incremental starting the next day.
• Full pull trigger: Configure a "full pull" button in Qeasy for "Query UFIDA YS Customers"; manually trigger it when bulk adjustments to customer profiles occur (such as organization mergers, seasonal cleanups).
• Scheduling frequency: According to the material, the source crontab is */6 8-18 * * *, i.e., every 6 minutes from 8 AM to 6 PM daily; the target crontab is 1 1 1 1 1 (one-shot trigger semantics). The safe practice is high-frequency pull during working hours, silent during off-hours to reduce pressure on the BIP gateway.
• Sequence orchestration: Sequence A (predecessor master data) must complete before all sequence B (orders/products). In Qeasy, this is achieved through the sequence field + depends_on double safeguard.

Pitfall Retrospective

• Typical mistake 1: Putting customer master sync after order sync. It looks like just a sequencing issue, but orders are already flying and unprepared customer profiles will cause the entire batch to report "customer does not exist" on the BIP side. The safe practice is any downstream strategy that depends on customer profiles must explicitly depends_on this strategy.
• Typical mistake 2: Hardcoding pagination parameters into the request body without considering growth in customer records. BIP-class interfaces will silently truncate beyond a single page size. We once discovered at a customer site that only 6000 out of 20000 customer records were returned. The safe practice is to abstract pageSize into Qeasy's "runtime parameters", letting the platform auto-paginate based on total in the response.
• Typical mistake 3: Treating code as "just a code" and ignoring its uniqueness. In Qeasy, idCheck: true must remain enabled, otherwise downstream will receive duplicate rows and the order side will have one-to-many mapping chaos.
• Typical mistake 4: Ignoring network jitter in private deployment environments. BIP interfaces occasionally time out (5xx); if Qeasy isn't configured with retries, after the first failure the remaining window of the day will not be re-pulled, causing "hollow time periods" in customer profiles. The safe practice is to configure exponential backoff retry + failure alerting in Qeasy.
• Typical mistake 5: Treating descriptive fields like attachment groups as required mappings to downstream. attachmentGroupId is of type string and not required at the source; passing it through directly is fine; but if a downstream field is defined as int and required, the entire batch will fail. During mapping, be sure to distinguish between "required business fields" and "optional descriptive fields".

Applicable and Non-applicable Scenarios

Applicable: Private deployment projects where sales order pipeline is preceded and depends on customer codes; scenarios where customer profiles change frequently (several times a day) but the single-volume level is below tens of thousands. Not applicable: scenarios where customer profile volume is at the million level and requires near-real-time (second-level) sync—change log (CDC) should be used instead of periodic pulls; also not applicable for scenarios where customer profiles are maintained across multiple systems and need bidirectional merging—this strategy only solves the "BIP one-way pull" segment.