# Business Logic — JKKKikiIchiranKkKaifukuCC.editErrorInfoComArray() [77 LOC]

| Field | Value |
|-------|-------|
| Fully Qualified Name | `com.fujitsu.futurity.bp.custom.common.JKKKikiIchiranKkKaifukuCC` |
| Layer | CC/Common Component — shared validation and error-routing utility used across FutoKoku (futo-koku = order registration) screen CBS (Customer Business Services) |
| Module | `common` (Package: `com.fujitsu.futurity.bp.custom.common`) |

## 1. Role

### JKKKikiIchiranKkKaifukuCC.editErrorInfoComArray()

This method is a **centralized error-information consolidation routine** used during order registration (FutoKoku, 顧客登録) screen processing. It receives structured error data from the service component (SC) layer — encoded as `CAANMsg` templates — and merges all error message payloads into a single flat map (`inMap`) that the screen layer renders to the user.

The method performs three business operations in sequence:

1. **Status dominance check** — It compares the SC-derived template status against the business process (BP) return code stored in the control map. If the SC status is higher (more severe), it overwrites the BP's return code and message with the SC's own status code and associated return message. This ensures that low-level service errors always surface with correct severity, overriding any higher-level BP result codes.

2. **Per-row error extraction** — It iterates over a list of data rows (`inList`), extracting field-level error messages from corresponding `CAANMsg` child templates. For each row, any error message key (e.g., `key + "_err"`) that exists in the child template and has not yet been placed into `inMap` is added. This supports screen layouts with repeated data sections (e.g., multiple service lines) where each row can have its own validation errors.

3. **List-level error extraction** — It checks for structural errors at the list/message-group level (identified by `inListMsgName + "_err"`) and adds them to `inMap` if not already present. This covers cases where entire rows or the entire data set is invalid (e.g., insufficient quantity, conflicting service combinations).

The method implements the **template-based message resolution** pattern — error messages are not hardcoded; instead, they are stored in `JCMAPLConstMgr` under keyed constants (`RETURN_MESSAGE_XXXX`) and resolved at runtime. The return map (`inMap`) becomes the data source for error message rendering on the registration screen.

## 2. Processing Pattern (Detailed Business Logic)

```mermaid
flowchart TD
    START(["editErrorInfoComArray"])
    START --> T0["Extract template from templates array"]
    T0 --> TS["templateStatus = template.getInt STATUS_INT_KEY"]
    TS --> RC{returnCode != 0 ?}
    RC -->|Yes| SET9K["Set templateStatus = 9000"]
    RC -->|No| RM{RETURN_MESSAGE exists ?}
    SET9K --> RM
    RM -->|No| SET0["Set templateStatus = 0"]
    RM -->|Yes| GETCM["Get bpStatus from controlMapData"]
    SET0 --> GETCM
    GETCM --> BPCHK{bpStatus null ?}
    BPCHK -->|Yes| BPNEG1["bpStatus = -1"]
    BPCHK -->|No| BPPARSE["bpStatus = parseInt(RETURN_CODE value)"]
    BPNEG1 --> CMP
    BPPARSE --> CMP{templateStatus > bpStatus ?}
    CMP -->|No| PROCERR
    CMP -->|Yes| FMTSTATUS["Format status to 4-digit string"]
    FMTSTATUS --> GETMSG["Get message from JCMAPLConstMgr"]
    GETMSG --> SETCM1["Set RETURN_CODE in controlMapData"]
    SETCM1 --> SETCM2["Set RETURN_MESSAGE in controlMapData"]
    SETCM2 --> PROCERR
    SETCM3["Extract inMap from param.getData"]
    PROCERR --> INLM["Get template array from inListMsgName"]
    INLM --> FORI["Loop over inList entries"]
    FORI --> CHMAP["Get childMap at index i"]
    CHMAP --> CT["Get childTemplate at index i"]
    CT --> KEYS["Create keySet iterator from childMap"]
    KEYS --> WHILE{iterator has more ?}
    WHILE -->|No| FORNEXT
    WHILE -->|Yes| KEY["Get next key from iterator"]
    KEY --> CTERR{childTemplate has _err key ?}
    CTERR -->|No| FORNEXT
    CTERR -->|Yes| IMCHK{inMap has _err key ?}
    IMCHK -->|Yes| FORNEXT
    IMCHK -->|No| IMPUT["Put err message into inMap"]
    IMPUT --> FORNEXT{"loop more ?"}
    FORNEXT -->|Yes| CHMAP
    FORNEXT -->|No| LASTERR
    LASTERR{template has _err key ?}
    LASTERR -->|No| RETURN
    LASTERR -->|Yes| LCHK{inMap has _err key ?}
    LCHK -->|Yes| RETURN
    LCHK -->|No| LPUT["Put err message into inMap"]
    LPUT --> RETURN["Return param"]
```

**Step-by-step processing flow:**

| Step | Operation | Business Purpose |
|------|-----------|-----------------|
| 1 | Extract template and read template status | Retrieve the SC's validation status code from the first template element |
| 2 | Override status to 9000 if returnCode != 0 | A non-zero returnCode indicates a hard processing error — escalate to failure status |
| 3 | Resolve or reset templateStatus | If no `RETURN_MESSAGE_XXXX` constant exists for the resolved status, reset to 0 (success) so no false error message is displayed |
| 4 | Read bpStatus from control map | Determine what status the business process itself returned; if absent, treat as -1 (lowest priority) |
| 5 | Compare statuses and update control map if SC is more severe | If the SC found a worse error than the BP, overwrite the return code and message with the SC's values — service layer errors take precedence |
| 6 | Extract the flat error map (`inMap`) | Get the target map where all error messages will be accumulated |
| 7 | Get template array for list items | Retrieve the `CAANMsg` array that holds per-row error message templates |
| 8-9 | Iterate each data row, extract field-level errors | For every data row, scan all keys; if the child template carries an error message for a key and the map doesn't already have it, add the error |
| 10 | Extract list-level error if present | After per-row processing, check for a group-level error associated with the list/message group; add if not already in the map |
| 11 | Return param | Return the updated parameter object with all consolidated error messages in `inMap` |

## 3. Parameter Analysis

| No | Parameter Name | Type | Business Description |
|----|---------------|------|---------------------|
| 1 | `param` | `IRequestParameterReadWrite` | The request parameter object that holds both the control map (for return code/message) and the application data map (for error messages). It serves as the single input/output carrier between the screen, CBS (Customer Business Service), and SC (Service Component) layers. |
| 2 | `templates` | `CAANMsg[]` | An array of structured message templates produced by the SC layer. Each `CAANMsg` carries typed values including status codes, error messages, and per-field annotations. The first element (`templates[0]`) contains the overall operation status. |
| 3 | `returnCode` | `int` | The raw processing return code from the caller. A value of `0` indicates success; any non-zero value signals an error. When non-zero, this method forcibly sets the template status to 9000 (hard failure), ensuring the SC-level failure message is displayed. |
| 4 | `dataMapKey` | `String` | The map key under which the flat error-message map (`HashMap<String, String>`) is stored within `param`. This key identifies the target location for all accumulated error messages. |
| 5 | `mappingData` | `Object[][]` | Unused parameter in this method — a pass-through array likely intended for column-to-field mapping in the caller. It is accepted for API compatibility but never referenced in the method body. |
| 6 | `inListMsgName` | `String` | The message group name used to retrieve the per-row template array from the root template (e.g., a list identifier like "detail" or "serviceLine"). This name is also appended with `"_err"` to check for list-level error annotations on the root template. |
| 7 | `inList` | `ArrayList<HashMap<String, Object>>` | A list of data-row maps, where each map represents one row of structured data (e.g., one service contract line item). The size of this list determines the iteration count for per-row error extraction. Each child map's keys correspond to field names used in the error template lookups. |

**External state / constants referenced:**

| Source | Constant/Resource | Usage |
|--------|-------------------|-------|
| `JCMConstants.STATUS_INT_KEY` | String key | Used to extract the integer status code from the SC's root template |
| `JCMAPLConstMgr` | Message catalog | Resolves `RETURN_MESSAGE_XXXX` constants — if a constant doesn't exist for a given status, the status is reset to 0 |
| `SCControlMapKeys.RETURN_CODE` | String key | Key used to read/write the BP return code in the control map |
| `SCControlMapKeys.RETURN_MESSAGE` | String key | Key used to write the resolved return message into the control map |

## 4. CRUD Operations / Called Services

### Pre-computed evidence from code analysis graph:

| CRUD | SC / CBS | SC Code | Entity / DB | Operation Description |
|------|----------|---------|-------------|----------------------|
| - | `JCMConstants.STATUS_INT_KEY` | - | - | Accesses the `STATUS_INT_KEY` constant used to extract the status code from the SC template |
| - | `JCMAPLConstMgr.getString` | - | - | Resolves return message constant from the application message catalog (e.g., `RETURN_MESSAGE_9000`) |
| - | `SCControlMapKeys.RETURN_CODE` | - | - | Accesses the control map key constant for the return code field |
| - | `SCControlMapKeys.RETURN_MESSAGE` | - | - | Accesses the control map key constant for the return message field |
| R | `CAANMsg.getInt` | - | - | Reads the integer status code from the SC template message |
| R | `IRequestParameterReadWrite.getControlMapData` | - | - | Reads the BP return code from the control map for severity comparison |
| R | `CAANMsg.getCAANMsgList` | - | - | Retrieves the per-row template array for the specified message group name |
| R | `IRequestParameterReadWrite.getData` | - | - | Retrieves the flat error message map (`HashMap<String, String>`) from the request parameter |
| R | `CAANMsg.isNull` | - | - | Checks whether the child template or root template carries an error message for a given key |
| R | `HashMap.containsKey` | - | - | Checks whether an error message for a key is already present in the inMap (prevents overwrites) |
| R | `CAANMsg.getString` | - | - | Extracts the actual error message string from a template annotation |
| - | `ArrayList.size` | - | - | Determines the iteration count for the per-row error extraction loop |
| - | `HashMap.keySet.iterator` | - | - | Iterates over all field keys in each row's data map for per-row error extraction |
| W | `IRequestParameterReadWrite.setControlMapData` | - | - | Writes the resolved return code and message back into the control map for screen display |
| W | `HashMap.put` | - | - | Accumulates error message key-value pairs into the flat `inMap` for screen rendering |

**Note:** This method does not perform any direct database CRUD (Create/Read/Update/Delete) operations. It is a **pure error consolidation and status-routing utility** that operates entirely on in-memory objects (`CAANMsg` templates, `HashMap` maps, control map entries). All actual data operations are performed by the SC layer methods called earlier in the call chain.

## 5. Dependency Trace

| # | Caller (Screen/Batch) | Call Chain (Full Path to this Method) | Terminal (SC / CRUD / Entity) |
|---|----------------------|--------------------------------------|-------------------------------|
| 1 | `JKKKikiIchiranKkKaifukuCC.callSCArray` | `callSCArray` → `editErrorInfoComArray(param, templates, returnCode, dataMapKey, mappingData, inListMsgName, inList)` | No direct DB terminal — this method only routes error info; actual SC calls are upstream in `callSCArray` |

**Call chain context:** `callSCArray` is a CBS-level method within `JKKKikiIchiranKkKaifukuCC` that orchestrates multiple service component invocations for the FutoKoku (customer order registration) screen. After each SC call, it invokes `editErrorInfoComArray` to capture and consolidate any errors returned by that SC before proceeding to the next service call or returning to the screen.

## 6. Per-Branch Detail Blocks

### Block 1 — IF `(returnCode != 0)` (L1288)

> Business description: If the caller passed a non-zero returnCode, the operation has a hard error. Force the template status to 9000 (failure) regardless of what the SC template reported.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | SET | `templateStatus = 9000` | Override with hard-failure status code 9000 |

### Block 2 — IF `(JCMAPLConstMgr.getString("RETURN_MESSAGE_" + ...) == null)` (L1292)

> Business description: Validate that a message constant exists for the current templateStatus. If no such constant exists, the status is invalid or undefined — reset to 0 (success) so no phantom error message is displayed. The status is zero-padded to 4 digits via `String.format("%1$04d", templateStatus)`.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | SET | `templateStatus = 0` | Reset to success if no return message constant exists |

### Block 3 — BP STATUS EXTRACTION (L1296–1305)

> Business description: Read the business process's own return code from the control map. If absent (null), treat it as -1 — meaning the BP has not set any return code yet, so the SC's status will almost certainly dominate in the comparison.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | GET | `param.getControlMapData(SCControlMapKeys.RETURN_CODE)` | Read current BP return code from control map |
| 2 | IF | `obj == null` | Check if BP has set a return code |
| 3 | SET | `bpStatus = -1` | Default to lowest severity — SC will override |
| 4 | SET | `bpStatus = Integer.parseInt((String) param.getControlMapData(...))` | Parse the BP's return code as integer for numeric comparison |

### Block 4 — IF `(templateStatus > bpStatus)` (L1307)

> Business description: If the service component detected a worse error than the BP, propagate the SC's error status and message into the control map. This implements the "SC errors always win" policy — the SC layer has lower-level domain knowledge and its error should take precedence over the BP's generic status.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | SET | `formatStatus = String.format("%1$04d", templateStatus)` | Format the status as a zero-padded 4-digit string (e.g., `9000`) |
| 2 | SET | `message = JCMAPLConstMgr.getString("RETURN_MESSAGE_" + formatStatus)` | Resolve the human-readable return message from the constant catalog |
| 3 | EXEC | `param.setControlMapData(SCControlMapKeys.RETURN_CODE, formatStatus)` | Write the SC's status code into the control map |
| 4 | EXEC | `param.setControlMapData(SCControlMapKeys.RETURN_MESSAGE, message)` | Write the SC's return message into the control map |

### Block 5 — MAP AND TEMPLATE EXTRACTION (L1311–1315)

> Business description: Prepare the data structures needed for per-row error extraction. `inMap` is the flat destination map where all error messages will be accumulated. `templateArray` is the per-row template slice from the root template.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | SET | `inMap = (HashMap<String, String>) param.getData(dataMapKey)` | Extract the flat error map from the request parameter |
| 2 | SET | `templateArray = template.getCAANMsgList(inListMsgName)` | Get per-row child templates from the root template |

### Block 6 — FOR LOOP `(i = 0; i < inList.size(); i++)` (L1317)

> Business description: Iterate over each data row in the list. For each row, extract field-level error messages from the corresponding child template and accumulate them into the flat `inMap`. This supports screens where multiple service lines are displayed and each line can independently have validation errors.

#### Block 6.1 — ROW DATA EXTRACTION (L1318–1320)

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | SET | `childMap = (HashMap) inList.get(i)` | Get the data row at the current index |
| 2 | SET | `childTemplate = templateArray[i]` | Get the error template for this row |

#### Block 6.2 — KEY ITERATION `(it.hasNext())` (L1322)

> Business description: For each field key in the current data row, check if the child template has an associated error message, and if so, copy it to the flat map (if not already present). This prevents duplicate error messages if multiple code paths set the same field error.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | SET | `key = (String) it.next()` | Get the next field key from the data row's key set |

#### Block 6.2.1 — IF `(!childTemplate.isNull(key + "_err"))` (L1324)

> Business description: Check whether the child template carries an error message for the current field. The suffix `"_err"` is the naming convention for error annotations in the template system. The concatenation `key + "_err"` creates the lookup key (e.g., `fieldName_err`).

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | IF | `!childTemplate.isNull(key + "_err")` | The child template has an error message for this field |

##### Block 6.2.1.1 — IF `(!inMap.containsKey(key + "_err"))` (L1326)

> Business description: Before writing the error, verify it hasn't already been placed in the flat map. This idempotency guard ensures that even if multiple templates or processing paths generate the same field error, it is only stored once.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | EXEC | `inMap.put(key + "_err", childTemplate.getString(key + "_err"))` | Add the field-level error message to the flat map for screen rendering |

### Block 7 — IF `(!template.isNull(inListMsgName + "_err"))` (L1338)

> Business description: After processing all per-row errors, check for a list-level (structural) error on the root template. This covers errors that apply to the entire data set rather than a specific row or field (e.g., "at least one service line must be specified", "duplicate service codes detected").

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | IF | `!template.isNull(inListMsgName + "_err")` | Root template has a list-level error for the message group |

#### Block 7.1 — IF `(!inMap.containsKey(inListMsgName + "_err"))` (L1340)

> Business description: Apply the same idempotency guard for list-level errors — only add the error if it hasn't already been placed in the map.

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | EXEC | `inMap.put(inListMsgName + "_err", template.getString(inListMsgName + "_err"))` | Add the list-level error message to the flat map |

### Block 8 — RETURN (L1344)

| # | Type | Code | Business Description |
|---|------|------|---------------------|
| 1 | RETURN | `return param` | Return the parameter object with all consolidated error messages |

## 7. Glossary

| Term | Type | Business Meaning |
|------|------|------------------|
| `templateStatus` | Variable | The severity/status code extracted from the SC template; 0 = success, higher values = more severe errors. Forced to 9000 on hard failure. |
| `bpStatus` | Variable | The business process's own return code from the control map; used for severity comparison against the SC status. |
| `returnCode` | Parameter | Raw return code from the caller; 0 means success, non-zero triggers hard-failure status 9000. |
| `inMap` | Variable | Flat map (`HashMap<String, String>`) accumulating all error message key-value pairs for screen rendering. |
| `inList` | Parameter | List of data-row maps, each representing one item in a repeating data section (e.g., service line items). |
| `inListMsgName` | Parameter | Message group name used to identify per-row templates and list-level error annotations. |
| `dataMapKey` | Parameter | The key under which `inMap` is stored within the request parameter's data map. |
| `_err` suffix | Naming convention | Error message annotation suffix used in `CAANMsg` templates. A field named `fieldName` in the template has its error message stored at `fieldName_err`. |
| `STATUS_INT_KEY` | Constant | Key constant (from `JCMConstants`) used to extract the integer status code from a `CAANMsg` template. |
| `RETURN_MESSAGE_XXXX` | Constant pattern | Message catalog key format used to resolve human-readable error messages. `XXXX` is the zero-padded 4-digit status code. |
| `RETURN_CODE` | Constant | Key constant (from `SCControlMapKeys`) for the return code field in the control map. |
| `RETURN_MESSAGE` | Constant | Key constant (from `SCControlMapKeys`) for the return message field in the control map. |
| `CAANMsg` | Type | Fujitsu's structured message/annotation container used across SC and CBS layers to carry typed values, error messages, and metadata. |
| `IRequestParameterReadWrite` | Type | The request/response parameter object that flows between the screen layer, CBS, and SC. Holds both control data (return code, message) and application data (error maps, field values). |
| `SC` | Acronym | Service Component — the lower-tier business logic layer that performs domain-specific processing and validation. |
| `BP` | Acronym | Business Process — the middleware layer that orchestrates SC calls and manages the overall transaction flow. |
| `CBS` | Acronym | Customer Business Service — the screen-facing service layer that handles user-facing business operations. |
| `FutoKoku` | Japanese term | 顧客登録 (Customer Registration / Order Registration) — the screen domain this method supports. |
| `JCMAPLConstMgr` | Type | Message catalog manager — resolves string constants from the application's localized message repository. |
| `SCControlMapKeys` | Type | Constant holder class defining keys used in the control map (e.g., `RETURN_CODE`, `RETURN_MESSAGE`). |
| `formatStatus` | Variable | The template status formatted as a zero-padded 4-digit string (e.g., `0000`, `9000`) for use as a message catalog lookup key. |
| `callSCArray` | Method | The direct caller of this method; a CBS-level orchestration method in `JKKKikiIchiranKkKaifukuCC` that calls multiple SCs and consolidates errors via this method. |