# KKW02410SFLogic

## Purpose

`KKW02410SFLogic` is the screen-level business logic controller for the **Femtocell Operation Agreement Screen** (screen ID `KKW02410`) in the JPC Online service. It handles the full lifecycle of a customer-facing screen where a subscriber can **confirm and finalize** either the **cancellation (解約)** or **restoration (回復)** of a femtocell operation agreement — a critical business process for managing the activation and deactivation of femtocell base stations used in carrier mobile networks.

This class sits at the intersection of the presentation layer (JSP/XML view definitions) and the backend business services, acting as a **screen orchestrator** that initializes screen data, dispatches to the correct backend service based on user intent (cancel vs. restore), and navigates to the next screen upon completion.

## Design

`KKW02410SFLogic` follows the **front-controller / action-based MVC pattern** common to the JCCWeb framework. It extends `JCCWebBusinessLogic`, which provides shared infrastructure for screen data binding, service invocation, and logging. The class uses the `paramBean` (a DataBean array) as its primary data carrier between methods and between the web view and backend services.

The class's single `tranDiv` (processing division) field drives all branching logic. Depending on whether the user is performing a cancel or restore operation, different backend services and mapper configurations are used, and different messages are presented to the user.

## Key Methods

### `actionInit()` → `boolean` (lines 77–130)

This is the **entry point** — the first method invoked when the user opens the femtocell operation agreement screen. It orchestrates the entire initialization sequence:

1. Retrieves screen information and obtains the service form bean via `JCCWebCommon.getScreenInfo(this)`.
2. Wraps the single bean into a `paramBean` array for passing through internal methods.
3. Calls `setHktgiBean(paramBean)` to populate the DataBean with customer contract data (SYSID, service contract number, move reason list, application numbers, etc.) from the incoming request.
4. Calls `executeInitSvc(paramBean)` to invoke the backend initialization service `KKSV0577` (femtocell operation information registration agreement inquiry). This service performs a **preliminary agreement check** using two mapper registrations: `setKKSV057701SC` and `setKKSV057702SC`, which register service items and DataBean item mappings.
5. Reads the `TRAN_DIV` field from the bean to determine whether this is a cancel (`KKK02410SFConst.OP_TRAN_DIV_DSL`) or restore (`KKK02410SFConst.OP_TRAN_DIV_KAIHK`) operation.
6. Calls `setDataInit(paramBean, trandiv)` to set additional display fields based on the operation type:
   - For **cancel**: sets `USE_ENDYMD` to the current operation date and the special item text to " femtocell information + cancel ".
   - For **restore**: sets the special item text to " femtocell information + restore ".
7. Displays an appropriate informational message (`EKB0370__I`) with context-specific text (" femtocell operation cancellation " or " femtocell operation restoration ").
8. Sets the next screen name (`SCREEN_NAME_KKW02410`) in the common info bean for tracking purposes.
9. Dumps the DataBean to the log for debugging.
10. Returns `true` (normal completion).

### `actionBack()` → `boolean` (lines 141–155)

Handles the user pressing the "Back" button. Simply sets the `NEXT_SCREEN_ID` in the common info bean to the current screen's ID (allowing the framework to navigate back to the calling screen) and dumps the DataBean to the log. Returns `true`.

### `setHktgiBean(X31SDataBeanAccess[] paramBean)` → `void` (lines 231–310)

This is a **data transfer and transformation** method that copies data from incoming request beans to the screen's working DataBean. It performs several operations:

- Gets the operation date and stores it in `USE_YMD`.
- Extracts customer contract continuation data (`CUST_KEI_HKTGI_LIST`) from the bean array.
- Copies the following fields from the first continuation item:
  - `SYSID_01` → `SYSID`
  - `SVC_KEI_NO_01` → `SVC_KEI_NO` (service contract number)
  - `IDO_RSN_MEMO_01` → move reason memo
  - `IDO_RSN_CD_01` (iterated over all count elements) → `IDO_RSN_CD_02` (move reason codes, dynamically adding new DataBean rows as needed)
  - `OP_SVC_KEI_NO_01` (index 0) → `OP_SVC_KEI_NO` (operation service contract number)
  - `TRAN_DIV_01` → `TRAN_DIV` (processing division)
  - `MSKM_NO_01` → `MSKM_NO` (application number)
  - `MSKM_DTL_NO_01` → `MSKM_DTL_NO` (application detail number)

The move reason reason code loop is noteworthy: it dynamically creates DataBean entries if the incoming list has more items than the target array already contains.

### `executeInitSvc(X31SDataBeanAccess[] paramBean)` → `void` (lines 196–222)

Invokes the backend **initialization service** `KKSV0577` (femtocell operation information registration agreement inquiry). This method:

1. Creates a `paramMap` with the use case ID `KKSV0577`.
2. Instantiates a `KKSV0577_KKSV0577OPDBMapper` for field mapping between DataBeans and the service.
3. Calls `setKKSV057701SC` and `setKKSV057702SC` to map input parameters (service items and DataBean fields).
4. Invokes `invokeService(paramMap, inputMap, outputMap)` — inherited from the parent class — to call the actual backend service.
5. Calls `getKKSV057701SC` and `getKKSV057702SC` to map the results back into the DataBean.

### `actionFix()` → `boolean` (lines 319–402)

This is the **confirmation/finalization method** — invoked when the user presses the "Fix" (確定) button. It is the most methodologically complex in the class:

1. Gets the service form bean and the `TRAN_DIV` value to determine the operation type.
2. Branches on the operation type:
   - **Cancel (DSL)**: Calls `executeDslSvc(paramBean, JPCModelConstant.FUNC_CD_1)`. Note: the return message ID is NOT captured for cancel operations (the code for this is commented out).
   - **Restore (KAIHK)**: Calls `executeKaihkSvc(paramBean, JPCModelConstant.FUNC_CD_1)`. The return message ID IS captured into `rtn_msg_id`.
3. Sets `msgInfo[0]` to the context-appropriate message (" femtocell operation cancellation " or " femtocell operation restoration ").
4. Navigation decision:
   - If `rtn_msg_id` is empty: navigates to screen `KKW02411` (`SCREEN_ID_KKW02411` / `SCREEN_NAME_KKW02411`) and displays a success message (`EKB4390__I`).
   - If `rtn_msg_id` is non-empty: displays an error message. Currently, the code uses a hardcoded substitution text `[" restoration period invalid ", " restoration "]` for the `rtn_msg_id` case. This appears to be a temporary placeholder (noted by the surrounding commented-out code).
5. Returns `true` (the result is always `true`; error handling appears to be done via screen navigation and messages rather than returning `false`).

### `executeDslSvc(X31SDataBeanAccess[] paramBean, String func_code)` → `void` (lines 456–493)

Invokes the **cancellation confirmation backend service** `KKSV0578`. Steps:

1. Sets use case ID to `KKSV0578`.
2. Creates a `KKSV0578_KKSV0578OPDBMapper` instance.
3. Registers three mapper entries:
   - `setOpSvcKeiDslCC` — cancellation contract confirmation mapping.
   - `setJKKHakkoSODCC` — SODCC (service order data change contract confirmation) mapping.
   - `setFmtcelIdoInfAddCC` — femtocell move information registration contract confirmation mapping (added in v5.00).
4. Clears `RTN_MSG_ID` to `""` before the call.
5. Invokes the service and retrieves results via `getOpSvcKeiDslCC`.

### `executeKaihkSvc(X31SDataBeanAccess[] paramBean, String func_code)` → `void` (lines 501–538)

Invokes the **restoration backend service** `KKSV0579`. Steps:

1. Sets use case ID to `KKSV0579`.
2. Creates a `KKSV0579_KKSV0579OPDBMapper` instance.
3. Registers five mapper entries:
   - `setOpSvcKeiKaihkCC` — restoration contract confirmation.
   - `setJKKHakkoSODCC` — SODCC mapping.
   - `setKKSV0009WORK` — WORK mapping (with empty func code).
   - `setFmtcelIdoInfAddCC` — femtocell move information registration mapping (v5.00).
4. Clears `RTN_MSG_ID` to `""`.
5. Invokes the service and retrieves results via `getOpSvcKeiKaihkCC`.

### `actionFin()` → `boolean` (lines 548–563)

Handles the finish/close action. Sets `NEXT_SCREEN_ID` in the common info bean to the current screen's ID (allowing the framework to navigate back), dumps the DataBean to log, and returns `true`.

## Relationships

### Who uses this class

Three artifacts reference `KKW02410SFLogic`:

- **WEBGAMEN_KKW02410PJP.xml** — The view definition for screen KKW02410. This XML file binds the JSP view to this logic controller.
- **WEBGAMEN_KKW02411PJP.xml** — The view definition for screen KKW02411, which is the next screen displayed after `actionFix()` succeeds.
- **x31business_logic_KKW02410SF.xml** — The business logic wiring configuration that maps the screen name to this logic class.

### Dependencies

`KKW02410SFLogic` extends `JCCWebBusinessLogic`, which provides the `invokeService()`, `getServiceFormBean()`, `getCommonInfoBean()`, and `dumpDatabean()` methods used throughout. It also depends on:

- `X31SDataBeanAccess` — The data carrier object used throughout the JCCWeb framework.
- `KKSV0577_KKSV0577OPDBMapper`, `KKSV0578_KKSV0578OPDBMapper`, `KKSV0579_KKSV0579OPDBMapper` — Auto-generated mapper classes for mapping between DataBeans and the backend services `KKSV0577`, `KKSV0578`, and `KKSV0579`.
- Various constants from `KKW02410SFConst`, `JKKCommonConst`, `JPCOnlineMessageConstant`, `JPCModelConstant`, `CommonInfoCFConst`, and `JKKScreenConst`.

### Class Diagram

```mermaid
classDiagram
    class KKW02410SFLogic {
        -String[] MSGSTRING
        -String FEMTSEL_INFO
        -String DSL
        -String KAIHK
        +boolean actionInit()
        +boolean actionBack()
        +boolean actionFix()
        +boolean actionFin()
        -void setDataInit()
        -void executeInitSvc()
        -void setHktgiBean()
        -void executeDslSvc()
        -void executeKaihkSvc()
    }
    class JCCWebBusinessLogic {
        <<base class>>
        +invokeService()
        +getServiceFormBean()
        +getCommonInfoBean()
        +dumpDatabean()
    }
    KKW02410SFLogic --|> JCCWebBusinessLogic
```

### Dependency Diagram

```mermaid
flowchart LR
    Web02410["WEBGAMEN_KKW02410PJP"] --> Logic["KKW02410SFLogic"]
    Web02411["WEBGAMEN_KKW02411PJP"] --> Logic
    Biz["x31business_logic_KKW02410SF"] --> Logic
    Logic --> Parent["JCCWebBusinessLogic"]
```

## Usage Flow

The class is used in a standard web request lifecycle:

```mermaid
sequenceDiagram
    participant UI as UI
    participant Logic as KKW02410SFLogic
    participant Parent as JCCWebBusinessLogic
    participant Svc as Backend Service

    UI->>Logic: actionInit()
    Logic->>Parent: getScreenInfo()
    Logic->>Parent: getServiceFormBean()
    Logic->>Logic: setHktgiBean()
    Logic->>Logic: executeInitSvc()
    Logic->>Svc: KKSV0577 (init service)
    Svc-->>Logic: response
    Logic->>Logic: executeInitSvc()
    Logic->>Logic: setDataInit()

    UI->>Logic: actionFix()
    alt trandiv == DSL
        Logic->>Logic: executeDslSvc()
        Logic->>Svc: KKSV0578 (cancel confirm)
        Svc-->>Logic: response
    else trandiv == KAIHK
        Logic->>Logic: executeKaihkSvc()
        Logic->>Svc: KKSV0579 (restore service)
        Svc-->>Logic: response
    end
    Logic-->>UI: navigate to KKW02411
```

**Typical usage sequence:**

1. **Screen load**: The framework invokes `actionInit()`, which prepares the screen with customer data and performs a preliminary agreement check.
2. **User review**: The user reviews the femtocell operation agreement details on the screen.
3. **Confirmation**: The user presses "Fix" (`actionFix()`), which dispatches to either `executeDslSvc()` (for cancellation) or `executeKaihkSvc()` (for restoration) depending on the `tranDiv` value.
4. **Navigation**: On success, the user is directed to screen `KKW02411`. On failure (for restore operations), an error message is displayed on the same screen.

## Notes for Developers

- **Thread safety**: This class is instantiated per request (typical of the JCCWeb framework). It holds no instance state beyond the fields defined in the class, so it should be safe for concurrent requests — but the fields are only set at class load time as `private static final` constants.

- **TranDiv branching is exhaustive but not defaulting**: The `if/else if` chains in `actionInit()` and `actionFix()` handle `DSL` and `KAIHK` values. If `tranDiv` is neither, no action is taken — the screen will display without a message in `actionInit()`, and no service call will be made in `actionFix()` (but the result will still be `true` and navigation will proceed).

- **Hardcoded error message placeholder**: In `actionFix()`, the error handling path for restore operations (when `rtn_msg_id` is non-empty) currently uses a hardcoded Japanese string `[" 復旧可能期間外 ", " 復旧 "]` instead of dynamically fetching the message from the message template. This is surrounded by commented-out code that previously attempted to use `getMsgRep()`. This appears to be incomplete work from version 4.01 and should be reviewed.

- **Cancel vs. Restore asymmetry**: For cancel operations, the return message ID (`RTN_MSG_ID`) is NOT checked — the code to retrieve it is commented out. For restore operations, it IS retrieved. This asymmetry may indicate that cancellation always succeeds (or errors are handled differently), or it may be an oversight.

- **Mapper registration order matters**: In `executeDslSvc()` and `executeKaihkSvc()`, mappers are registered before `invokeService()` and results are retrieved after. This is the standard pattern for the `KKSVxxxx` mapper classes — the `set` methods populate the `inputMap` and the `get` methods populate the `paramBean` from the `outputMap`.

- **v4.01 / v5.00 version markers**: The code contains several version markers indicating changes. `v4.01 20121007` removed several fields (service provider code, reservation application date, return message ID retrieval for cancel) and added the next screen name. `v5.00 2013/02/22` added the `setFmtcelIdoInfAddCC` mapper call to both cancel and restore services.

- **Logging**: Both `actionInit()`, `actionBack()`, `actionFix()`, and `actionFin()` dump the DataBean to the log via `JSYwebLog.println(JSYwebLog.DataBean_Dump, ...)`. This is useful for debugging but should be considered for production performance if the bean contains sensitive data.

- **All public methods return `true`**: Both `actionInit()` and `actionFix()` always return `true`. Error handling is done entirely through messages and screen navigation rather than return values. This means a caller cannot detect failure from the return value alone.