# Com / Fujitsu / Futurity / Bp / Custom / Common

## Overview

This module is the **Service Order (SOD) Issuance** engine for the K-Opticom eo customer base system. It handles the automatic generation of downstream service orders whenever a customer's contract state changes — such as during new contract registration, course (plan) changes, suspension, recovery, cancellation, or address modifications. The module's Japanese module description states: "Issuance of service orders based on contract content during inspection and course change operations" ([JKKHakkoSODCC.java](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/common/JKKHakkoSODCC.java:302)).

It is a single large component (`JKKHakkoSODCC`) containing roughly 200 methods that coordinate contract queries, condition evaluation, and order registration against a suite of backend Service Interfaces (S-IFs). This module serves as the **central orchestrator** for the entire service order lifecycle across all service types — internet (FTTH, ADSL), light phone (eo Hikari Denwa), mobile (eo Mobile / UQ WiMAX), and their many add-on options (email, My Homepage, Wi-Fi, multi-function routers, IPv6, etc.).

---

## Key Classes and Interfaces

### JKKHakkoSODCC

**Location:** [Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/common/JKKHakkoSODCC.java](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/common/JKKHakkoSODCC.java:302)

This is the sole class in the module, extending `AbstractCommonComponent`. It is the heart of the system's order issuance logic — a massive switchboard that dispatches to hundreds of specialized sub-methods depending on the operation context and the service type involved.

#### Class responsibilities

1. **Entry point orchestration** — The `hakkoSOD` method iterates over a list of SOD maps (each representing a contract/service unit), evaluates its attributes, and dispatches to the appropriate order control handler.
2. **Order control dispatch** — A family of `*OdrCtrl` methods each handle a specific business operation (new contract, course change, cancellation, recovery, suspension, etc.).
3. **Work registration** — The `addSOD` family maps contract data to the order condition and order information creation work tables, then calls the relevant S-IFs.
4. **Contract data queries** — A large suite of `get*` methods query the backend for service contract info, option service lists, sub-option lists, service detail lists, and equipment service lists.
5. **S-IF call wrappers** — Each backend Service Interface has a corresponding `callEKK...SC`, `mappingEKK...InMsg`, `mappingEKK...OutMsg`, and `editErrorInfoEKK...CBS` trio (or quadruplet). This pattern is repeated for 30+ service interfaces.

#### State fields

The class carries a significant amount of instance state, which is populated during the processing of a single `hakkoSOD` request and consumed by downstream methods:

| Field | Purpose |
|-------|---------|
| `same_trn_no` | A "same process number" (同一処理番号) assigned to group orders that must be processed together |
| `prc_grp_cd` / `pcrs_cd` | Price group and price course codes used to determine service type |
| `svc_kei_stat` | Service contract status |
| `ido_div` | Discontinuation division (異動区分) — tracks which service lines are being affected |
| `svc_pause_ymd` / `svc_pause_rls_ymd` | Pause start/end dates |
| `op_svc_kei_no_*` | Various option service contract number fields (email, My Homepage, mailing list, dial-up, multi-session, IPv6, fixed IP, number porting, etc.) |
| `svc_kei_ucwk_no[]` | Service contract detail numbers |
| `kktk_svc_kei_no[]` | Equipment provision service contract numbers |
| `itnm_svc_kei_no` / `itnm_svkei_gadtm` | Migration-source service contract (for transfer tracking) |

This stateful design means the class **must not be shared across concurrent requests** — it follows the per-request instantiation pattern of the underlying framework's `AbstractCommonComponent`.

---

## How It Works

### The main request flow

Here is what happens when a customer action triggers service order issuance:

```mermaid
flowchart TD
    subgraph Entry["Entrance"]
        H["hakkoSOD<br/>Main SOD dispatch entry"]
    end

    subgraph Control["Order Control Dispatch"]
        NKC["newKeiOdrCtrl<br/>New contract"]
        SKC["stpUkOdrCtrl<br/>Suspension reception"]
        SRC["stpRlsOdrCtrl<br/>Suspension release"]
        KRC["kaihkOdrCtrl<br/>Recovery"]
        DLC["dslOdrCtrl<br/>Cancellation"]
        KSC["ksiDslOdrCtrl<br/>Forced cancellation"]
        CFC["cnclOdrCtrl<br/>Cancel order"]
        CCC["courseChgeOdrCtrl<br/>Course change"]
        OPC["opSetOdrCtrl<br/>Option settings"]
        AFC["adchgFixOdrCtrl<br/>Address change"]
        HtelNOC["htelNo*OdrCtrl<br/>Light phone number ops"]
    end

    subgraph Core["Core processing"]
        ASOD["addSOD<br/>Order condition + work reg"]
        TAOSOD["tsuikabunAddSOD<br/>Additional order proc"]
        ATOSOD["addTakinoSOD<br/>Multi-func router"]
        IPRC["idpwShkkaSaifuriOdrCtrl<br/>ID/PW reset"]
    end

    subgraph SvcOps["Service Operations"]
        NNET["newNet<br/>Internet new contract"]
        NEMOB["newEoMobile<br/>Mobile new contract"]
        NTNEW["addSODTelNew<br/>Light phone new reg"]
        NFDTH["addSODFtthNew<br/>FTTH auth new reg"]
        NEMAIL["addSODEmailNew<br/>Email new reg"]
    end

    subgraph Query["S-IF Query Layer"]
        S1["getSvcKeiInfo<br/>Contract lookup"]
        S2["getOpSvcKeiList<br/>Option list"]
        S3["getSbOpSvcKeiList<br/>Sub-option list"]
        S4["getSvcKeiUtwkList<br/>Detail list"]
        S5["getKktkSvcKeiList<br/>Equipment list"]
        S6["checkKKOPChanged<br/>Router check"]
    end

    subgraph CBS["Service Interface Layer"]
        CBS1["callEKK0081A010SC<br/>Contract lookup"]
        CBS2["callEKK0351B010SC<br/>Option list"]
        CBS3["callEKK1081C011SC<br/>Same trn no"]
        CBS4["executeOdrHakkoJokenAdd<br/>Cond registration"]
        CBS5["executeOdrInfoSakseiWkAdd<br/>Work registration"]
    end

    H --> NKC
    H --> SKC
    H --> SRC
    H --> KRC
    H --> DLC
    H --> KSC
    H --> CFC
    H --> CCC
    H --> OPC
    H --> AFC
    H --> HtelNOC

    NKC --> ASOD
    NKC --> NNET
    NKC --> NEMOB
    NKC --> S2
    NKC --> S3
    NKC --> S4
    NKC --> S5

    SKC --> S2
    SKC --> S4

    KRC --> S2
    KRC --> S4
    KRC --> S1

    DLC --> S2
    DLC --> S4

    CCC --> S2
    CCC --> S4
    CCC --> ASOD

    ASOD --> CBS4
    ASOD --> CBS5
    ASOD --> IPRC

    S1 --> CBS1
    S2 --> CBS2
    S5 --> CBS2
    S6 --> CBS2
    S4 --> S1
```

### Step-by-step: a new contract flow

A new internet service contract demonstrates the most typical path through the module:

1. **`hakkoSOD`** receives a `SessionHandle`, `IRequestParameterReadWrite` (containing model group and control map data), and a `fixedText` string as the data map key. It extracts the `TRGT_DATA_LIST` from the input map.

2. For each `sodMap` in the list, it reads the `SOD_KIHON_INFO` (order basic info) and `SVC_KEI_INFO` (service contract info) sub-maps, applies character-code sanitization via `shkkaMap`, and determines the `ido_div` (discontinuation division) and `syori_div` (processing division).

3. Based on the service kind (determined by `jdgSvcKind()` using `prc_grp_cd`), it dispatches to the appropriate control method. For internet services, this is `newKeiOdrCtrl`.

4. **`newKeiOdrCtrl`** acquires a same-process-number (`same_trn_no`), queries option services, sub-options, service details, and equipment provision contracts. Then it calls `newNet` to process internet-specific service registration (FTTH auth, email, My Homepage, mailing list, dial-up).

5. **`newKeiOdrCtrl`** then invokes `addIpv6SODAft` for IPv6 option processing.

6. Meanwhile, the `addSOD` method (called from higher-level controllers like `courseChgeOdrCtrl`) dispatches based on `orderNaiyoCd` codes:
   - `101`: FTTH auth registration
   - `102`: FTTH auth password change
   - `103`: FTTH auth cancellation
   - `104`: FTTH auth deletion
   - `105`: Light phone registration
   - And many more (see `addSOD` at [line 1123](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/common/JKKHakkoSODCC.java:1123))

7. Each registration path calls:
   - `executeOdrHakkoJokenAdd` → "Order condition registration" S-IF
   - `executeOdrInfoSakseiWkAdd` → "Order information creation work registration" S-IF

8. Between the two S-IF calls, `getSameTrnNo` assigns a shared transaction number so that all orders in a single business operation are processed atomically.

### Order control methods

The module contains a rich family of order control methods, each handling a specific business scenario:

| Control Method | Lines | Purpose |
|----------------|-------|---------|
| `newKeiOdrCtrl` | 6088–6169 | New contract processing |
| `stpUkOdrCtrl` | 6295–6807 | Suspension reception |
| `stpRlsOdrCtrl` | 6817–7182 | Suspension release |
| `kaihkOdrCtrl` | 7193–8918 | Recovery (service restoration) |
| `dslOdrCtrl` | 8929–10565 | Cancellation |
| `ksiDslOdrCtrl` | 10576–10598 | Forced cancellation |
| `ksiDslFixOdrCtrl` | 10609–10631 | Forced cancellation confirmation |
| `cnclOdrCtrl` | 10640–10662 | Cancel order |
| `courseChgeOdrCtrl` | 10673–11464 | Course (plan) change |
| `opSetOdrCtrl` | 11476–14402 | Option settings |
| `htelNoAddOdrCtrl` | 14414–14514 | Light phone number addition |
| `htelNoChgeOdrCtrl` | 14553–14705 | Light phone number change |
| `htelNoDslOdrCtrl` | 14716–15320 | Light phone number cancellation |
| `htelNoKaihkOdrCtrl` | 15332–15861 | Light phone number recovery |
| `htelItntokiOdrCtrl` | 15870–16355 | Light phone relocation (Toki) |
| `htelNoInfoChgeOdrCtrl` | 16367–16910 | Light phone number info change |
| `adchgFixOdrCtrl` | 16922–17035 | Address change/confirmation |
| `opHktgiOdrCtrl` | 17074–17465 | Option inheritance |
| `idpwShkkaSaifuriOdrCtrl` | 17675–17837 | ID/PW initialization/reset |
| `pauseUkOdrCtrl` | 18196–18660 | Pause reception |
| `pauseRlsChgeOdrCtrl` | 18669–18968 | Pause change / reservation cancel |
| `useStpOdrCtrl` | 18978–19005 | Use suspension |
| `useStpRlsOdrCtrl` | 19014–19041 | Use suspension release |
| `wribInfoAddOdrCtrl` | 19050–19133 | Discount info registration |

These methods share a common structure:
1. Extract required parameters from `sodMap` (basic info, service contract info, service detail info)
2. Apply `shkkaMap` sanitization to all maps
3. Determine the service kind via `jdgSvcKind()`
4. Query relevant option services, sub-options, and service details
5. Branch on service type (NET, TEL, MOB, etc.)
6. Call specialized operation methods or invoke `addSOD`/`tsuikabunAddSOD`

### Query methods

The module provides a comprehensive set of query methods for fetching service state before order generation:

| Method | Lines | Purpose |
|--------|-------|---------|
| `getSvcKeiInfo` | 21954–22000 | Single service contract lookup |
| `getSvcKeiList` | 22009–22039 | Service contract detail list |
| `getOpSvcKeiList` | 22052–22197 | Option service list (by contract number) |
| `getOpSvcKeiNotDslList` | 22214–22337 | Option list excluding DSL |
| `getOpSvcKeiGaDtm` | 22352–22391 | Single option service contract lookup |
| `getOpSvcKeiIsp` | 22407–22515 | Option service ISP lookup |
| `getSbOpSvcKeiList` | 22528–22680 | Sub-option service list |
| `getSvcKeiUtwkList` | 22693–22823 | Service contract detail list |
| `getSvcKeiUtwkListSysid` | 22836–22852 | Service detail list (by SYSID) |
| `getSvcKeiUtwk` | 22867–22919 | Single service contract detail lookup |
| `getKktkSvcKeiList` | 22934–23078 | Equipment provision service list |
| `checkTakinoRT` | 23098–23842 | Multi-function router function check |
| `checkKKOPChanged` | 23856–23920 | Option change detection |

Each query method follows a consistent pattern:
1. Build an input hash map with lookup keys
2. Call the corresponding `callEKKxxxxSC` method
3. Map the response via `mappingEKKxxxxSCOutMsg`
4. Return the result (either `IRequestParameterReadWrite` or `HashMap`)

### S-IF call infrastructure

For each backend Service Interface, the module implements four methods:

1. **`callEKKxxxxSC`** — Constructs the `CAANMsg` template, maps input data via `mappingEKKxxxxSCInMsg`, invokes the service via `ServiceComponentRequestInvoker`, maps the output, and returns a status code.

2. **`mappingEKKxxxxSCInMsg`** — Takes a `CAANMsg` template and a `HashMap` of input data, populates the template's fields.

3. **`mappingEKKxxxxSCOutMsg`** — Extracts result data from `CAANMsg[]` responses into a `HashMap` or `CAANMsg[]`.

4. **`editErrorInfoEKKxxxxCBS`** — Maps S-IF error information into `IRequestParameterReadWrite` for the calling layer.

Additionally, `editInMsg_*CBS`, `editResultRP_*CBS`, and `editErrorInfo_*CBS` methods serve as the S-IF mapping layer for the two registration S-IFs used by `addSOD`:
- `EKK1081D010CBS` — Order condition registration
- `EKK1551D010CBS` — Order information creation work registration

### Service kind determination

The `jdgSvcKind()` method ([line 5813](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/common/JKKHakkoSODCC.java:5813)) maps a `prc_grp_cd` (price group code) to a service kind constant:

- `SVC_KIND_NET` — Internet services (FTTH, ADSL)
- `SVC_KIND_TEL` — Light phone (eo Hikari Denwa)
- `SVC_KIND_MOB` — Mobile services (eo Mobile, UQ WiMAX)

This single determination branches the entire processing flow for any given contract.

---

## Data Model

This module operates on a layered `HashMap` data structure rather than formal entity classes. The contract data is passed through the call chain as nested maps with the following hierarchy:

### SOD Map structure

```
sodMap
  ├── SOD_KIHON_INFO        (HashMap) — Basic order information
  │     ├── ido_div          — Discontinuation division
  │     ├── syori_div        — Processing division
  │     ├── malware_blocking_div — Malware blocking division
  │     ├── kotei_ip_ad_8_div — Fixed IP address 8 division
  │     ├── rt_op_chg_div    — Router option change division
  │     └── sysid            — SYSID
  │
  ├── SVC_KEI_INFO           (HashMap) — Service contract info
  │     ├── svc_kei_no       — Service contract number
  │     └── (other contract attributes)
  │
  ├── SVC_KEI_UCWK_INFO      (HashMap) — Service contract detail info
  │     ├── svc_kei_ucwk_no   — Service contract detail number
  │     └── (other detail attributes)
  │
  └── (additional sub-maps)
```

### Order dispatch work map

A separate work map (`HAKKOSODCCWORKMAP`) is used for order condition and order information creation work registration. It carries fields such as:

- `order_sbt_cd` — Order type code (e.g., NET, TEL, MOB)
- `svc_order_cd` — Service order code (e.g., FTTH auth, light phone)
- `yokyu_sbt_cd` — Request type code (NEW, CHG, DSL/cancel, DEL/delete)
- `odr_hakko_joken_cd` — Order issuance condition code (SOKJI_HAKKO = immediate issuance)
- `same_trn_no` — Shared transaction number
- `svc_kei_ucwk_no` — Service contract detail number
- `svc_order_cd` — Service order code
- `taknkiki_model_cd` — In-home equipment model code
- `kiki_seizo_no` — Equipment serial number

### Service Interface message types

The module imports and uses a large set of CAANMsg types for backend communication. These follow the pattern `EKKnnnnMmMmCBSMsg` and `EKKnnnnMmMmCBSMsg1List`, where the codes correspond to specific S-IFs:

| Message Type | S-IF Purpose |
|-------------|--------------|
| `EKK0081A010CBSMsg` | Service contract single lookup |
| `EKK0161A010CBSMsg` | Service contract detail single lookup |
| `EKK0161B003CBSMsg` | Service contract detail list (SYSID) |
| `EKK0161B004CBSMsg` | Service contract detail list |
| `EKK0191A010CBSMsg` | Service contract detail <eo Light Phone> |
| `EKK0191B001CBSMsg` | Service contract detail list <eo Light Phone> |
| `EKK0251B001CBSMsg` | Service contract line detail (current usage) |
| `EKK0341A010CBSMsg` | Equipment provision service contract single |
| `EKK0341B002CBSMsg` | Equipment provision service contract list |
| `EKK0351A010CBSMsg` | Option service contract single |
| `EKK0351B002CBSMsg` / `EKK0351B010CBSMsg` | Option service contract list |
| `EKK0361A010CBSMsg` | Option service contract <ISP> single |
| `EKK0401B001CBSMsg` | Sub-option service contract list |
| `EKK1041A010CBSMsg` | Order setting single lookup |
| `EKK1041B001CBSMsg` | Order setting list |
| `EKK1081C011CBSMsg` | Same process number assignment |
| `EDK0301B060CBSMsg` | Number porting related |

### Order content codes

The `orderNaiyoCd` parameter in `addSOD` and `tsuikabunAddSOD` determines the specific operation. Key codes include:

| Code | Description |
|------|-------------|
| `101` | FTTH auth registration |
| `102` | FTTH auth password change |
| `103` | FTTH auth cancellation |
| `104` | FTTH auth deletion |
| `105` | Light phone registration |
| `111` | Email alias registration |
| `112` | Email mailbox capacity change |
| `113` | Email virus check registration |
| `121` | My Homepage capacity change |
| `122` | My Homepage access analysis registration |
| `131` | Mailing list registration |
| `141` | Dial-up registration |
| `151` | Multi-function router settings (new) |
| `152` | Light phone VA change |
| `161` | Wi-Fi spot registration |
| `162` | Wi-Fi spot change |
| `163` | Router connection info change |
| `171` | UQ WiMAX registration |
| `181` | UQ WiMAX purchase registration |
| `163` | Router connection info change |
| `164` | IPv6 order processing |

---

## Dependencies and Integration

### Internal dependencies

The module depends on these packages:

| Dependency | Purpose |
|-----------|---------|
| `eo.common.constant` | Shared string constants (e.g., `JDKStrConst`, `JKKStrConst`) |
| `com.fujitsu.futurity.bp.custom.constant` | Module-specific constants (e.g., `JKKHakkoSODConstCC`, `JKKItntokiStaEndConstCC`, `JKKSvcConst`) |
| `eo.common.util` | Utility classes (`JKKStringUtil`) |
| `eo.ejb.cbs.cbsmsg` | CAANMsg type definitions for S-IF communication (20+ message classes) |

### Framework dependencies

The class extends the Futurity framework's `AbstractCommonComponent` and uses:

- `SessionHandle` — Session management handle for database connections
- `IRequestParameterReadWrite` / `IRequestParameterReadOnly` — Parameter passing abstraction
- `ServiceComponentRequestInvoker` — Invokes backend service components
- `CAANMsg` — The canonical message envelope for S-IF communication

### Backend Service Interfaces

The module calls the following backend S-IFs (by S-IF code):

| S-IF Code | Purpose |
|-----------|---------|
| `EKK0081A010` | Service contract single lookup |
| `EKK0161A010` | Service contract detail single lookup |
| `EKK0161B003` | Service contract detail list (SYSID) |
| `EKK0161B004` | Service contract detail list |
| `EKK0191A010` | Service contract detail <eo Light Phone> single |
| `EKK0191B001` | Service contract detail list <eo Light Phone> |
| `EKK0251B001` | Service contract line detail (current usage) |
| `EKK0341A010` | Equipment provision service contract single |
| `EKK0341B002` / `EKK0341B008` / `EKK0341B504` | Equipment provision service contract list |
| `EKK0351A010` | Option service contract single |
| `EKK0351B002` / `EKK0351B010` | Option service contract list |
| `EKK0361A010` | Option service contract <ISP> single |
| `EKK0401B001` | Sub-option service contract list |
| `EKK0411A010` | Sub-option service contract <ISP> single |
| `EKK1041A010` / `EKK1041B001` | Order setting lookup |
| `EKK1081C011` | Same process number assignment |
| `EKK1551D010` | Order information creation work registration |
| `EKK1081D010` | Order condition registration |
| `EZM0411A010` | In-home equipment model single lookup |
| `ETU0011B010` | Banpo construction list lookup |

---

## Notes for Developers

### Service type branching

The module branches processing based on `jdgSvcKind()` return value. Always ensure new service types add a new branch rather than being silently handled by the default case. The current service kinds are:

- `SVC_KIND_NET` — Internet (FTTH, ADSL/flet's)
- `SVC_KIND_TEL` — Light phone (eo Hikari Denwa)
- `SVC_KIND_MOB` — Mobile (eo Mobile, UQ WiMAX)

### IPv6 special handling

IPv6 option processing has a unique code path with dedicated instance fields (e.g., `ipv6_svc_kei_ucwk_no`, `op_gadtm_ipv6`, `sod_pattern_ipv6`). The `jdgIpv6` and `jdgIpv6EKK0361A010` methods determine whether an IPv6 order should be issued. Be careful when modifying contract data that affects IPv6 — the `addIpv6SODAft` method uses the `sod_pattern_ipv6` flag to control issuance.

### State management

This class uses instance fields as working storage across a single `hakkoSOD` invocation. The `hakkoSOD` method clears key state variables at the start of processing ([line 633](Source/koptBp/ejbModule/com/fujitsu/futurity/bp/custom/common/JKKHakkoSODCC.java:633)). If you add new state fields, ensure they are cleared in the same location.

### Same process number (同一処理番号)

The `same_trn_no` is a critical concept — it groups multiple SODs that belong to the same business operation. The `callEKK1081C011SC` method assigns this number, and it must be propagated to all related order registrations. Failing to share this across orders in the same operation can cause inconsistency.

### Method duplication patterns

The S-IF call pattern (`call*SC`, `mapping*InMsg`, `mapping*OutMsg`, `editErrorInfoEKK*CBS`) is highly repetitive. When adding a new S-IF, follow the existing pattern exactly — the methods are generated with consistent naming and parameter structures.

### Large file warning

The source file is 42,000+ lines. Key sections to know:
- Class definition and state fields: ~302–500
- `hakkoSOD` entry method: ~611–1038
- `addSOD` dispatch: ~1123–4908
- `tsuikabunAddSOD` (additional): ~4926–5313
- `addTakinoSOD` (multi-func router): ~5333–5761
- All `*OdrCtrl` methods: ~6088–17465
- S-IF query methods: ~21916–23920
- S-IF call infrastructure: ~26668–31105
- IPv6 handling: ~29976–30704

### Version history

The module has undergone 70+ version changes since 2011, with major feature additions including:
- IPv6 support (v3.00.00, 2012)
- Mobile service (eo Mobile / UQ WiMAX) support (v3.00.00, 2012)
- Multi-function router support (v6.00.00, 2013)
- Email feature enhancement (v6.00.00, 2013)
- VLAN-ID support (v4.00.00, 2012)
- Malware blocking (v49.00.00, 2020)
- Tobira support (v50.00.00, 2020)
- Netflix integration (v51.00.00, 2020)
- 5G/10G course additions (v53.00.00, 2021)
- PSTN migration ENUM support (v56.00.00, 2021)
- MT existing lease support (v60.00.00, 2022)
- e-o Home Gateway introduction (v61.00.00, 2023)
- Rakuten Fletts support (v66.00.00, 2023)
- eo Hikari Net "Simple Plan" addition (v71.00.00, 2024)
- NTT response (v73.00.00, 2024)
- Fiber wiring course update (v73.00.00, 2024)

### Extension points

New order operations should be added by:
1. Defining a new `ODR_NAIYO_CD` constant in `JKKHakkoSODConstCC`
2. Adding a new `if` branch in `addSOD` (or `tsuikabunAddSOD` for additional orders)
3. Implementing the required S-IF call methods if it uses a new backend S-IF
4. Wiring the dispatch in the appropriate `*OdrCtrl` method

For new service types, add a new branch in all `*OdrCtrl` methods where service-kind branching occurs. The `jdgSvcKind()` method is the central branching point but many controllers hardcode service-kind checks.