Design and Implementation of a Business Parameter Configuration Center

The article introduces a Business Parameter Configuration Center (BPCC) that enables rapid generation of front‑end pages and corresponding CRUD services through configuration. It explains the background, overall architecture, core concepts, implementation details, SDK usage, parameter priority handling, multi‑selection processing, import/export workflow, and the scenarios where BPCC is not suitable.

Background

In fast‑moving internet enterprises, back‑end developers spend a large portion of their time on repetitive CRUD work, which wastes resources. Approximately 77% of pages in the SCM supply‑chain management system are standard pages that only differ in parameter configuration. BPCC aims to eliminate this low‑value work.

What is BPCC?

BPCC is a configuration platform that, through declarative definitions, automatically generates front‑end pages (integrated with the low‑code platform Wizard) and back‑end services for create, read, update, delete, import, and export operations.

Overall Architecture and Principles

The system is divided into four layers: domain model, domain service, application service, and infrastructure (storage, import/export, logging, etc.). An SDK abstracts the underlying storage, allowing callers to query parameters without knowing the storage details.

Core Concepts

Element : a business field on a page.

Dimension : fields that uniquely identify a record (e.g., warehouse, category).

Parameter : mutable fields associated with a dimension.

Scheme : a configuration that groups dimensions and parameters for a specific scenario.

Parameter Instance : the concrete data generated from a scheme.

SDK Query Flow

The SDK provides three steps: define a request object, define a response object, and invoke the service method. Example request/response classes and usage are shown below.

@Data
public class PinkDeviceCameraConfigRequest implements Serializable {
    /** Configuration type */
    private String configType;
    /** Device number */
    private String deviceNo;
}

@Data
public class PinkDeviceCameraConfigResponse implements Serializable {
    private String configType;
    private String deviceNo;
    private List
configValueList;
    @Data
    public static class CameraConfigDto implements Serializable {
        private String position;
        private BigDecimal red;
        private BigDecimal blue;
        private BigDecimal green;
        private BigDecimal brightness;
        private BigDecimal autoExposureTimeUpperLimit;
        private BigDecimal acquisitionFrameRate;
        private String gainAuto;
        private BigDecimal gainAutoUpperLimit;
        private BigDecimal gainAutoLowerLimit;
    }
}

Typical SDK invocation:

PinkDeviceCameraConfigRequest request = new PinkDeviceCameraConfigRequest();
request.setConfigType("DEVICE_NO");
request.setDeviceNo("123@LuSun");

// Single query
PinkDeviceCameraConfigResponse response = paramInstQueryService.getParams(
        "P80-DEVICE-CAMERA-PARAM-MANAGER",
        request,
        PinkDeviceCameraConfigResponse.class);

// Paginated query
PageQueryOption option = new PageQueryOption();
option.setPageIndex(1);
option.setPageSize(200);
PageInfo
page = paramInstQueryService.getParamsPage(
        "P80-DEVICE-CAMERA-PARAM-MANAGER",
        request,
        PinkDeviceCameraConfigResponse.class,
        option);

Parameter Priority

When multiple parameter instances match a query, the system selects the one with the highest priority based on the specificity of dimensions (e.g., warehouse+category+sub‑category > warehouse+category > warehouse). This mechanism reduces the number of configurations needed for large‑scale scenarios such as safety‑stock management.

Multi‑Selection Handling

Both dimensions and parameters can be multi‑selected. The concept of a “group” aggregates related parameter instances, ensuring uniqueness of dimensions while supporting flexible search and display.

Import/Export Workflow

Import files use human‑readable text (e.g., "Shoes", "Apparel") rather than internal IDs. During import, the system converts these texts to IDs using the element range query interfaces described earlier.

What BPCC Is Not Suited For

Extremely complex UI interactions.

Complex validation logic (planned for future support).

High‑frequency write scenarios.

Queries that require non‑equality matching.

Summary and Outlook

The BPCC has already been applied to over 40 scenarios, saving considerable development effort by eliminating repetitive CRUD work. Future plans include enhancing SDK query flexibility, expanding scheme definition capabilities (e.g., HTTP‑based element sources), and improving metadata definition to allow dynamic element dependencies.