Notifications (xlyMsg)

Outbound notifications — DingTalk and WeChat — go through the xlyMsg module. This is not an HTTP surface that callers hit; it's an internal SDK that in-scope services call when a business event should push a message out to a chat platform.

What's inside

xlyMsg/src/main/java/com/xly/:

Package	Role
dingtalk/service/DingTalkService + dingtalk/util/SendDingTalkUtil, DingTalkMsgContentUtil, LocalCacheClient	DingTalk corp-message dispatch. Wraps com.aliyun:dingtalk:2.1.14 and com.aliyun:alibaba-dingtalk-service-sdk:2.0.0.
wechat/service/WechatService + wechat/util/SendWxUtil, Wx_SignatureUtil, JedisMsgUtil, MsgContentUtil, Xml2JsonUtil	WeChat work-platform dispatch — signature + send, including a Redis-backed access-token cache.
notice/service/NoticeService	Provider-agnostic notice abstraction; routes a logical "notify user X about event Y" to the right backend.

xlyMsg/build.gradle — sole framework dependency is xlyPersist. The module is consumed as a library, not deployed as its own service.

Who calls it (in-scope callers)

This is what makes xlyMsg framework-relevant rather than plat-tier:

Caller	What it does
xlyEntry/.../web/businessweb/TestController.java	Diagnostic endpoint to fire a test DingTalk message.
xlyBusinessService/.../thread/UpdateDingTalkThread.java	Async worker that pushes DingTalk updates after document changes.
xlyBusinessService/.../service/impl/CheckExamineFlowServiceImpl.java	Workflow approval notifications — when an Activiti task is reassigned or completed, the assignee gets a chat message.
xlyBusinessService/.../service/impl/GenericProcedureCallServiceImpl.java	Generic-proc hook: any gdsmodule proc that opts in can publish a notice through this path.
xlyInterface/.../util/DingTalkUtil.java + scheduler/ScheduledTasks.java, ErpJobRunStatus.java	Scheduled-job heartbeat / failure alerts on the integration side.

Configuration

Credentials (DingTalk corp-app key/secret, WeChat AppID, agent IDs) are read from environment-specific yaml profiles. There is no global default — each customer deployment fills its own values, which is why the framework wiki cannot give a canonical example. Look at the active profile yaml under xlyEntry/src/main/resources/application-<env>.yml for the keys actually consumed.

The WeChat path uses Redis for access-token caching (wechat/util/JedisMsgUtil.java) — same Redis instance the rest of the framework uses. See Multi-service deployment for the broader picture of which services share which Redis.

What this is not

• Not an inbound webhook receiver. DingTalk callbacks (e.g., approval-button clicks) go through xlyInterface with the rest of the webhooks.
• Not the xlyPlat* push-notification path. The plat tier has its own channel (xlyPlatSmsService, JPush, app-side push) that this wiki treats as out of scope.