# `Fun_getProcessByControlName` (function)

> 根据工单ID，控制表ID获取工艺流


- **Type:** FUNCTION
- **Returns:** `longtext`
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sWorkOrderId` | `varchar(50)` |
| 2 | IN | `sWorkControlId` | `varchar(50)` |

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE FUNCTION `Fun_getProcessByControlName`'`._

## Narrative

**Business context:** Work-order process-flow renderer (生产管理 → 工单 / 生产计划) — assembles a JSON array describing each `mftworkorderprocess` step of a given work-order along with a colour-coded state for the planning UI's gantt/flow chart. Despite the header comment mentioning a `控制表ID` parameter, only `sWorkOrderId` is actually used in the body (the second arg is unreferenced).

**What it does:** joins `mftProductionPlanSlave` → `mftworkorderprocess` → `eleprocess` → `sisprocessclassify`, groups by `iOrder` to collapse multi-slave rows into one entry per process step, picks `MIN(sState)` as the worst-case status, and `GROUP_CONCAT`s a `JSON_OBJECT` per step (`sProcessName`, `sWorkOrderId`, `sState`, `background` colour decided by state/`bFrozen`). Returns a `[...]`-wrapped JSON array, or `''` when no rows match.

**Invocation:** wrapped by `Fun_getProcessByWorkOrderId` (the one-arg convenience version that passes `''` as `sWorkControlId`). Neither function is referenced by any other routine, form-master sSqlStr, gdsmodule hook, or xly-src file. Status: appears orphaned. No live caller found in any channel — candidate for maintainer audit (likely a feature-flag UI helper that was wired in a deprecated form).