# Notifications (xlyMsg)

Outbound notifications — DingTalk, WeChat, and email — 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 or mailbox.

## 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. |
| `emial/service/SendEmailService` + impl | Email dispatch (note the package typo `emial`). Used by `xlyFlow`'s `QuartzTask` for scheduled-job mail; `xlyEntry` also has its own `com.xly.web.email.SendEmailService` for `ScheduledTasks`-driven mail — same interface name, parallel implementation, kept for historical reasons. |
| `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](../reference/maintainer/deployment.md)
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](webhooks.md).
- **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.