Metadata-management services (xlyManage)

The xlyManage module is the service tier behind the BACK builder. When a PM clicks 修改 / 新增 / 删除 in any of the 系统模块配置 / 界面显示内容配置 / 数据表内容配置 / 系统权限配置 / 系统常量配置 / 用户信息配置 / Mysql脚本配置 screens, the call lands on a Gds*Controller in xlyEntry/.../web/systemweb/, which then delegates to a Gds*ServiceImpl in xlyManage/src/main/java/com/xly/service/systeminfo/impl/.

These services are the framework's metadata-CRUD spine — they own the read/write logic for every gds* table. The runtime (Slice 1, runtime.md) reads metadata; xlyManage writes it.

Services at a glance

Service	Lines	Owns	BACK page
GdsmoduleServiceImpl	729	gdsmodule (modules), gdsroute (URL whitelist), module-tree CRUD, edition gating	系统模块配置
GdsconfigformServiceImpl	878	gdsconfigformmaster, gdsconfigformslave, gdsconfigformcustomslave, gdsconfigformpersonalize (form definitions + per-tenant overlays)	界面显示内容配置
GdsconfigtbServiceImpl	555	gdsconfigtbmaster, gdsconfigtbslave (virtual-table definitions)	数据表内容配置
SqlScriptsServiceImpl	489	DDL / proc / view scripts authored in BACK; uses templates from templesql/	Mysql脚本配置
GdsjurisdictionServiceImpl	362	gdsjurisdiction (the action catalogue per module — see permissions)	(part of 系统权限配置 + builder flows)
GdsparameterServiceImpl	319	gdsparameter (system-wide parameters)	(parameter screens)
GdsformconstServiceImpl	243	gdsformconst (per-form constants — labels, default text). Slice 1 anchor table.	系统常量配置
GdslogininfoServiceImpl	221	sftlogininfo* family (user / login / group catalogue)	用户信息配置
SysbrandsServiceImpl	125	sysbrands (manufacturer / tenant master)	(tenant admin)
CommonServiceImpl	56	shared helpers used across the rest	n/a

Total: ~4,000 lines of metadata-CRUD logic — a meaningful share of the framework runtime that this wiki had previously left undocumented.

Method-shape convention

Every Gds*Service follows the same five-method shape:

Feedback<Map<String,Object>> getXxx(Map<String, Object> params);       // list / paged read
Feedback<Map<String,Object>> getXxxBysId(Map<String, Object> params);  // single-row read
Feedback<Map<String,Object>> addXxx(Map<String, Object> params);       // insert
Feedback<Map<String,Object>> updateXxx(Map<String, Object> params);    // update
Feedback<Map<String,Object>> deleteXxx(Map<String, Object> params);    // delete (often soft, via bInvalid)

— mirrored exactly by the corresponding Gds*Controller's endpoint methods. So the BACK admin surface is essentially a thin pass-through: controllers in xlyEntry/.../systemweb/, services in xlyManage/.../systeminfo/impl/. This is the inverse of the runtime side (runtime.md), where one universal BusinessBaseController handles every business-data CRUD against any table the metadata names — here, every framework-metadata CRUD has its own dedicated controller+service pair.

Notable specifics

• GdsconfigformServiceImpl is the largest because it owns four closely-coupled tables (form-master, form-slave, customslave, personalize) plus the DDL-script generation flow. Methods like getFormslaveScriptSqlPro and getMasterSlaveScriptSqlPro produce SQL that an engineer can apply against the underlying physical tables when adding fields. This is what makes the customization-overlay model (Slice 4) end-to-end usable: the BACK builder can also generate the schema-migration SQL the overlay implies.
• GdsmoduleServiceImpl includes getModuleTreePro — the per-edition / per-tenant module-tree resolution called by the SPA at login (the first /gdsmodule/getModuleTreePro request you see in the live trace). Edition gating (Slice 2) happens here, as a filter on gdsmodule.sVersionFlowId against the user's sisversionflow row.
• SqlScriptsServiceImpl glues the templesql/ scaffolds into the BACK script authoring screen. Engineers fill in the placeholder spec; the service materialises a compilable proc/view body and runs it against the connected schema.
• GdsjurisdictionServiceImpl writes the action *catalogue*; sysjurisdiction (the per-user grant table) is written elsewhere (in xlyBusinessService's permission-admin flow). See How to set permissions for the catalogue-vs-grant distinction.
• SysbrandsServiceImpl writes the tenant master (sysbrands + sBrandsId rows); a fresh tenant onboarding flow is essentially a row insert here plus seed metadata.

Cache-invalidation hookpoints

Every write through these services synchronously calls BusinessCleanRedisData.delCleanRedisData* on commit. This is why metadata edits in BACK take effect immediately on every node — the shared Redis cache (RedisCacheManager, see cache-invalidation.md) gets the relevant regions evicted in the same transaction the write commits. There is no JMS fan-out here for cache-bust — that's a common misconception, addressed in detail on the cache-invalidation page.

What's not in xlyManage

• Business-data CRUD. That's the universal BusinessBaseController + BusinessBaseServiceImpl path (runtime.md, Slice 1).
• API metadata (sysapi). That's xlyApi's own admin surface — see external API.
• Workflow metadata (gdsmoduleflow, act_*, biz_flow). That's in xlyFlow — see activiti.md.

Where to look first when something breaks

Symptom	First place to look
BACK 修改/新增 against gdsconfigform* returns "操作失败"	GdsconfigformServiceImpl — check field validation + the matching DDL-script generation path
Edition gating shows wrong modules	GdsmoduleServiceImpl.getModuleTreePro — verify the user's sVersionFlowId resolution
BACK script-authoring screen produces broken SQL	SqlScriptsServiceImpl + the templesql scaffolds
Permission catalogue (BtnAdd / BtnUpd / …) missing for a module	GdsjurisdictionServiceImpl — check the rows under that sParentId
User can log in to BACK but FROUNT is empty	GdslogininfoServiceImpl — check the sftlogininfo* link tables