Multi-service deployment

xly is not a single Spring Boot WAR. The repository contains several deployable modules plus a few library-like WAR modules that are also used as dependencies by xlyEntry.

The main modules

Service / module	Role	Code-backed notes
xlyEntry	Main runtime and builder/admin surface. Hosts /business/*, /gdsmodule/*, /gdsconfigform/*, /gdsconfigtb/*, reporting, login, and other framework controllers.	Depends on xlyManage, xlyBusinessService, and xlyFlow.
xlyApi	API-oriented module for /api/*, /online/*, /pro/*, /thirdparty/*, and related endpoints.	Separate Spring Boot application class in ApiApplicationBoot.
xlyInterface	External-integration module with Swagger dependencies and third-party integration code.	Separate Spring Boot application class in InterfaceApplicationBoot.
xlyPlc	Shop-floor PLC bridge (Slice 6).	Separate Spring Boot application class in PlcApplicationBoot.
xlyFace	Optional face-recognition module.	Separate module; still present in the Gradle build.
xlyFlow	Workflow / Activiti code and controllers.	Present as its own module, but in this branch XlyFlowApplicationBoot is commented out, so treat it as code that is currently consumed through xlyEntry rather than a clearly runnable standalone app.

Each has its own application.yml + several application-<profile>.yml files. The active profile is selected at startup via -Dspring.profiles.active=….

Disabled in settings.gradle

//include 'xlyErpTask'
//include 'xlyRxtx'
//include 'xlyFile'

Three modules are present on disk but excluded from the active Gradle build:

• xlyErpTask — long-running background tasks.
• xlyRxtx — native serial-port library. Disabled when xlyPlc doesn't need direct serial access (some press models use TCP/Ethernet instead).
• xlyFile — older file-management module, superseded by Aliyun OSS integration in xlyPlatFileUpload.

A maintainer cleaning up the codebase should consider whether to delete these or keep them as historical reference. They take up disk space but do not affect the build.

Plat* family

The xlyPlat* modules (xlyPlatMerchantController, xlyPlatUserService, xlyPlatPayService, xlyPlatMarketingService, xlyPlatCainiaoWaybillSevice, xlyPlatSmsService, xlyPlatReportForm, xlyPlatFileUpload, xlyPlatJmsConsumer/Productor, xlyPlatTask, xlyPlatWebsocket, xlyPlatConstant) are the B2B printing-platform layer and remain out-of-scope for this wiki.

How services find each other

Three communication channels:

1. Shared database — every service reads/writes the same MySQL schema. Most cross-service "communication" is implicit through shared tables.
2. Messaging — both ActiveMQ/JMS and RocketMQ exist in the codebase. Cache invalidation (cache invalidation on metadata change) uses the ActiveMQ/JMS path.
3. HTTP REST — for synchronous calls (e.g., xlyApi calling xlyEntry's /business/* endpoints).

There is no service registry / discovery mechanism beyond the application-<profile>.yml files, which hardcode peer URLs per environment.

URL routing in deployed environments

The workspace .env.local points BACK at port 8597 and FROUNT at port 8598 in the live environment. That is enough to identify the two operator-facing surfaces, but the reverse-proxy and context-path mapping are deployment details rather than code-backed facts in this repository.

Profile permutations

application-saas.yml, application-linux.yml, application-win.yml, application-15S.yml, application-S10.yml, application-pro.yml, application-T0.yml, application-T1.yml, … cover combinations of:

• Operating system (linux / win)
• Customer category (saas, 15S, S10, …)
• Environment (dev, pro)
• Press-model (for xlyPlc)

A given deployment selects exactly one profile per service. The mapping from "this customer" → "these profiles" lives in deployment ops documentation, not the codebase.

Open: production URL routing

The exact nginx / reverse-proxy config for 8597 / 8598 is not in this repository. Add it here only when the deployment-side config is available.