# Business Logic — JKKTvSvcKeiCourceChgCC.editErrorInfoCom() [60 LOC]

| Field | Value |
|-------|-------|
| Fully Qualified Name | `com.fujitsu.futurity.bp.custom.common.JKKTvSvcKeiCourceChgCC` |
| Layer | CC/Common Component — a shared utility class used across business screen (BS) components for common error-message handling |
| Module | `common` (Package: `com.fujitsu.futurity.bp.custom.common`)

## 1. Role

### JKKTvSvcKeiCourceChgCC.editErrorInfoCom()

This method is a **centralized error-information consolidation utility** that reconciles error status codes between the service-component (SC) response layer and the business-perspective (BP) layer, then merges all error-field values from an SC message template into the caller's parameter map. In the telecom order-fulfillment system, screen controllers invoke service components that return structured response templates carrying both a numeric status code and a set of per-field error messages. This method reads the SC template's status code, overrides it to `9000` (error) if the caller already signaled a failure via `returnCode`, validates that the status code maps to a known return message, and — critically — propagates the *more severe* of the two status codes back into the parameter control map along with its human-readable message. After status reconciliation, it iterates over every key in the template's hash map whose name ends with `_err` and copies the corresponding error text values into the caller's data map, keyed under the `dataMapKey` parameter. The design pattern is **delegation with merging**: the method delegates to standard `IRequestParameterReadWrite` and `CAANMsg` API calls to read/set control and data parameters, and it merges SC-level errors into the BP-level parameter object so downstream screens can display per-field validation feedback. Its role in the larger system is as a **shared error-formatting utility** called from within the same class (`callSC`, `editErrorInfo`) that handles multiple telecom service types (FTTH registration, mail change, ENUM portability, etc.), ensuring a consistent error-reporting contract regardless of which service component was invoked.

## 2. Processing Pattern (Detailed Business Logic)

```mermaid
flowchart TD
    START(["editErrorInfoCom params templates returnCode dataMapKey"])
    START --> T0["Get templates[0] as template"]
    T0 --> GET_STATUS["Read template.getInt ECK0011B002CBSMsg.STATUS"]
    GET_STATUS --> CHECK_RC{"returnCode != 0"}
    CHECK_RC -->|Yes| SET_RC["templateStatus = 9000"]
    CHECK_RC -->|No| CHECK_MSG
    SET_RC --> CHECK_MSG{"RETURN_MESSAGE + status exists?"}
    CHECK_MSG -->|No| RESET_STATUS["templateStatus = 0"]
    CHECK_MSG -->|Yes| GET_BP
    RESET_STATUS --> GET_BP
    GET_BP["Read param.getControlMapData RETURN_CODE"]
    GET_BP --> BP_NULL{"obj == null"}
    BP_NULL -->|Yes| SET_BP_NEG1["bpStatus = -1"]
    BP_NULL -->|No| PARSE_BP["bpStatus = Integer.parseInt RETURN_CODE"]
    SET_BP_NEG1 --> CMP_STATUS
    PARSE_BP --> CMP_STATUS{"templateStatus > bpStatus"}
    CMP_STATUS -->|No| IN_MAP
    CMP_STATUS -->|Yes| FORMAT_STATUS["formatStatus = String.format format templateStatus"]
    FORMAT_STATUS --> GET_MSG["Get message from RETURN_MESSAGE formatStatus"]
    GET_MSG --> SET_CONTROl["Set RETURN_CODE and RETURN_MESSAGE in param"]
    SET_CONTROl --> IN_MAP
    IN_MAP["inMap = param.getData dataMapKey"]
    IN_MAP --> ITERATE["Iterate template.getHashMap keySet"]
    ITERATE --> HAS_NEXT{"it.hasNext"}
    HAS_NEXT -->|No| RETURN
    HAS_NEXT -->|Yes| GET_KEY["key = it.next"]
    GET_KEY --> ERR_ENDS{"key ends with _err"}
    ERR_ENDS -->|No| HAS_NEXT
    ERR_ENDS -->|Yes| IS_NULL{"template.isNull key"}
    IS_NULL -->|Yes| HAS_NEXT
    IS_NULL -->|No| PUT_MAP["inMap.put key template.getString key"]
    PUT_MAP --> HAS_NEXT
    RETURN["Return param"]
```

**CRITICAL — Constant Resolution:**

| Constant Reference | Resolved Value | Business Meaning |
|--------------------|----------------|-----------------|
| `ECK0011B002CBSMsg.STATUS` | `"status"` | Field name for the status code in the CBS response message template |
| `SCControlMapKeys.RETURN_CODE` | `"RETURN_CODE"` | Control-map key holding the numeric return code from the BP layer |
| `SCControlMapKeys.RETURN_MESSAGE` | `"RETURN_MESSAGE"` | Control-map key holding the human-readable error message text |
| `JCMAPLConstMgr.getString("RETURN_MESSAGE_...")` | Lookup into a constants properties file | Maps status codes (e.g., `RETURN_MESSAGE_0000`, `RETURN_MESSAGE_9000`) to human-readable messages |

## 3. Parameter Analysis

| No | Parameter Name | Type | Business Description |
|----|---------------|------|---------------------|
| 1 | `param` | `IRequestParameterReadWrite` | The bidirectional parameter container that flows between the screen controller, business perspective (BP), and service component (SC) layers. It holds control-map data (such as `RETURN_CODE` and `RETURN_MESSAGE`) and a typed data map (`dataMapKey`) containing per-field error strings for UI display. |
| 2 | `templates` | `CAANMsg[]` | An array of CBS message templates returned by service-component calls. Each template contains structured response fields including a numeric `status` code and a hash map of field-level data. The method accesses `templates[0]`, indicating it expects at least one template — typically the primary SC response. |
| 3 | `returnCode` | `int` | A caller-supplied numeric flag. When non-zero, it signals that the calling business logic has already detected a failure condition; the method then overrides the template status to `9000` (generic error), ensuring downstream screens always surface the error message. When `0`, the template's own status is trusted. |
| 4 | `dataMapKey` | `String` | The key under which the method retrieves the caller's data map from `param`. This map receives all per-field error strings extracted from the template (keys ending in `_err`), allowing the calling screen to iterate and display validation errors next to their respective input fields. |

**External state / instance fields:** None. The method is fully stateless and relies solely on its parameters and the static `JCMAPLConstMgr` for constant lookups.

## 4. CRUD Operations / Called Services

This method does **not** perform any database or SC-level CRUD operations. It is a **pure parameter transformation and error-merge utility** that reads/writes only in-memory data structures (`IRequestParameterReadWrite`, `CAANMsg`, `HashMap`).

| CRUD | SC / CBS | SC Code | Entity / DB | Operation Description |
|------|----------|---------|-------------|----------------------|
| - | `JCMAPLConstMgr.getString` | - | - | Reads a human-readable error message from the constants properties file using the key `RETURN_MESSAGE_<status>` |
| - | `param.getControlMapData` | - | - | Reads the BP-layer return code from the control map for severity comparison |
| - | `param.setControlMapData` | - | - | Writes the reconciled return code and error message back into the control map |
| - | `param.getData` | - | - | Retrieves the typed data map (HashMap) identified by `dataMapKey` for error string merging |
| - | `template.getInt` | - | - | Extracts the numeric status code from the CBS message template |
| - | `template.getHashMap().keySet().iterator` | - | - | Iterates over all keys in the CBS message template's hash map |
| - | `template.isNull` | - | - | Checks whether a specific error-field value is null/absent in the template |
| - | `template.getString` | - | - | Retrieves the error message string value for a given key |

## 5. Dependency Trace

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

No screen/batch entry points found within 8 hops. Direct callers found: 2 methods.

| # | Caller (Screen/Batch) | Call Chain (Full Path to this Method) | Terminal (SC / CRUD / Entity) |
|---|----------------------|--------------------------------------|-------------------------------|
| 1 | `JKKTvSvcKeiCourceChgCC.callSC()` | `callSC()` → `editErrorInfoCom()` | `getControlMapData` [R], `setControlMapData` [R], `getData` [R], `getString` [R], `isNull` [-] |
| 2 | `JKKTvSvcKeiCourceChgCC.editErrorInfo()` | `editErrorInfo()` → `editErrorInfoCom()` | `getControlMapData` [R], `setControlMapData` [R], `getData` [R], `getString` [R], `isNull` [-] |

Both callers are methods within the same class `JKKTvSvcKeiCourceChgCC`, which is the screen controller for the **service detail change** business screen (telecom service contract line-item modification). `callSC` invokes `editErrorInfoCom` after making a service-component call to reconcile any returned errors, while `editErrorInfo` invokes it to prepare error display data for the BP layer before forwarding to the view.

## 6. Per-Branch Detail Blocks

**Block 1** — [ASSIGNMENT] `(initialization: extract template and status)` (L522)

> Extract the first template from the array and read its status code. This is the baseline SC response status before any caller-side overrides.

| # | Type | Code |
|---|------|------|
| 1 | SET | `CAANMsg template = templates[0]` // Extract first (primary) SC response template |
| 2 | SET | `int templateStatus = template.getInt(ECK0011B002CBSMsg.STATUS)` // Read SC response status code; `[-> ECK0011B002CBSMsg.STATUS = "status"]` |

**Block 2** — [IF] `(returnCode != 0)` — Caller signaled error (L526)

> If the calling method passed a non-zero returnCode, the business logic already determined a failure occurred. Override the template's status to `9000` (generic error) so the downstream screen always shows the error message regardless of what the SC returned.

| # | Type | Code |
|---|------|------|
| 1 | SET | `templateStatus = 9000` // Override status to generic error because caller signaled failure [-> 9000 = generic error status] |

**Block 3** — [IF] `(JCMAPLConstMgr.getString("RETURN_MESSAGE_" + ...) == null)` — Validate status code (L532)

> Validate that the current `templateStatus` maps to a known return message in the constants file. If there is no `RETURN_MESSAGE_<NNNN>` entry for this status code, reset the status to `0` (success/no-error) to prevent the display layer from looking up a non-existent message.

| # | Type | Code |
|---|------|------|
| 1 | EXEC | `String.format("%1$04d", templateStatus)` // Format status as zero-padded 4-digit string, e.g. `9000` |
| 1 | CALL | `JCMAPLConstMgr.getString("RETURN_MESSAGE_" + formatStatus)` // Lookup error message in constants properties file; returns null if no message defined for this status code |
| 2 | SET | `templateStatus = 0` // Reset to success if no mapped message exists [-> 0 = success/OK] |

**Block 4** — [ASSIGNMENT + IF/ELSE] `(bpStatus extraction)` (L535)

> Read the BP layer's return code from the control map to determine which status code is more severe. This enables the method to keep the *higher* (worse) status between the SC response and the caller's own assessment.

| # | Type | Code |
|---|------|------|
| 1 | SET | `int bpStatus = 0` // Initialize BP status to 0 (success) |
| 2 | SET | `Object obj = param.getControlMapData(SCControlMapKeys.RETURN_CODE)` // Read BP-layer return code; `[-> SCControlMapKeys.RETURN_CODE = "RETURN_CODE"]` |
| 3 | IF | `(obj == null)` — BP has no return code set (L537) |

**Block 4.1** — [ELSE-IF: obj is null] `(bpStatus = -1)` (L538)

> When the BP has not yet set a return code, default `bpStatus` to `-1` so that any positive template status will always win the comparison in Block 5.

| # | Type | Code |
|---|------|------|
| 1 | SET | `bpStatus = -1` // No BP return code set; any SC error wins [-> -1 = no BP assessment] |

**Block 4.2** — [ELSE: obj is not null] `(bpStatus = parsed value)` (L541)

> Parse the BP's return code string into an integer for numeric comparison.

| # | Type | Code |
|---|------|------|
| 1 | SET | `bpStatus = Integer.parseInt((String) param.getControlMapData(SCControlMapKeys.RETURN_CODE))` // Parse BP return code to int for severity comparison |

**Block 5** — [IF] `(templateStatus > bpStatus)` — Status comparison and error propagation (L545)

> If the SC template's status code is numerically higher (more severe) than the BP's current status, propagate the SC's error status and its human-readable message into the parameter's control map. This ensures the downstream screen always displays the most severe error message. This block represents the core business logic of **severity-based error escalation**.

| # | Type | Code |
|---|------|------|
| 1 | SET | `String formatStatus = String.format("%1$04d", templateStatus)` // Format as zero-padded 4-digit string, e.g. `0000`, `1000`, `9000` |
| 2 | SET | `String message = JCMAPLConstMgr.getString("RETURN_MESSAGE_" + formatStatus)` // Retrieve human-readable error message from constants; e.g. `RETURN_MESSAGE_9000` → "Error occurred" |
| 3 | EXEC | `param.setControlMapData(SCControlMapKeys.RETURN_CODE, formatStatus)` // Write the SC status code back to the control map for BP consumption; `[-> SCControlMapKeys.RETURN_CODE = "RETURN_CODE"]` |
| 4 | EXEC | `param.setControlMapData(SCControlMapKeys.RETURN_MESSAGE, message)` // Write the human-readable error message to the control map; `[-> SCControlMapKeys.RETURN_MESSAGE = "RETURN_MESSAGE"]` |

**Block 6** — [ASSIGNMENT] `(data map extraction)` (L553)

> Retrieve the caller's data map from the parameter object. This is the in-memory HashMap where per-field error strings will be accumulated for UI display.

| # | Type | Code |
|---|------|------|
| 1 | SET | `HashMap<String, String> inMap = null` // Declare reference |
| 2 | SET | `inMap = (HashMap<String, String>) param.getData(dataMapKey)` // Retrieve typed data map; the map stores field-name → error-message pairs for screen display |

**Block 7** — [WHILE LOOP] `(iterate template hash map keys, extract _err fields)` (L557)

> Iterate over every key in the template's hash map. For keys whose names end with the `_err` suffix (the convention for error-field names), copy the error value from the template into the caller's data map. This merges SC-level per-field validation errors into the BP-level parameter so the screen controller can display them next to the corresponding form fields. This represents the **error-merge** phase of the method's business logic.

| # | Type | Code |
|---|------|------|
| 1 | EXEC | `Iterator<String> it = template.getHashMap().keySet().iterator()` // Obtain iterator over all keys in the SC template's hash map |
| 2 | WHILE | `(it.hasNext())` — More keys to process |

**Block 7.1** — [WHILE BODY] `(extract next key)` (L558)

| # | Type | Code |
|---|------|------|
| 1 | SET | `String key = it.next()` // Get next key from template hash map |

**Block 7.2** — [IF] `(key.endsWith("_err"))` — Filter error fields (L559)

> Only process keys that follow the naming convention of ending with `_err`, which identifies them as error-field names (e.g., `tel_no_err`, `addr_err`). Non-error keys (data fields, metadata) are skipped.

| # | Type | Code |
|---|------|------|
| 1 | EXEC | `key.endsWith("_err")` // Check if this key is an error-field marker [-> suffix "_err" identifies error fields] |

**Block 7.2.1** — [IF] `nested: (template.isNull(key))` — Skip null error values (L561)

> If the template's error value for this key is null/absent, skip it. Only copy error strings that are actually present, avoiding null-to-string coercion that could produce `"null"` text in the UI.

| # | Type | Code |
|---|------|------|
| 1 | EXEC | `template.isNull(key)` // Check if error value is null/absent in template |

**Block 7.2.2** — [ELSE: not null] `(copy error to data map)` (L563)

> Copy the actual error message string from the template into the caller's data map, keyed by the original error-field name. The screen controller iterates this map to display validation feedback.

| # | Type | Code |
|---|------|------|
| 1 | EXEC | `inMap.put(key, template.getString(key))` // Copy error string from template to caller's data map for screen display |

**Block 8** — [RETURN] `(return merged param)` (L567)

> Return the modified parameter object, which now contains the reconciled error status code, error message, and merged per-field error strings. The caller can then set this parameter into the view for display.

| # | Type | Code |
|---|------|------|
| 1 | RETURN | `return param` // Return the parameter with merged error info to the caller |

## 7. Glossary

| Term | Type | Business Meaning |
|------|------|------------------|
| `templateStatus` | Field | SC response status code — numeric code returned by the service component indicating success or failure (e.g., `0` = success, `9000` = error) |
| `bpStatus` | Field | BP-layer return code — the status code already set by the business perspective layer for comparison with the SC status |
| `RETURN_CODE` | Field | Control-map key — standard key storing the numeric return code in the parameter's control map, used for status code exchange between BP and screen layers |
| `RETURN_MESSAGE` | Field | Control-map key — standard key storing the human-readable error message corresponding to a return code |
| `dataMapKey` | Parameter | Data map identifier — the key used to retrieve the caller's HashMap from the parameter, where per-field error strings are accumulated |
| `ECK0011B002CBSMsg.STATUS` | Constant | Message field name — the string key `"status"` used to access the status code field within a CBS response message template |
| `RETURN_MESSAGE_XXXX` | Constant | Constants file key pattern — maps zero-padded 4-digit status codes to human-readable messages (e.g., `RETURN_MESSAGE_9000` = error message text) |
| CAANMsg | Technical class | CBS message object — a structured message container used for request/response between screen controllers and service components; supports typed getters (`getInt`, `getString`, `isNull`) and hash-map iteration |
| IRequestParameterReadWrite | Technical interface | Bidirectional parameter container — the shared data structure flowing between screen, BP, and SC layers; provides `getData` for typed maps and `setControlMapData`/`getControlMapData` for control metadata |
| `_err` suffix | Naming convention | Error field naming convention — field names ending in `_err` denote validation error messages for their corresponding input fields (e.g., `tel_no_err` is the error for the telephone number field) |
| SC | Acronym | Service Component — the backend service layer that executes business operations and returns structured CBS response messages |
| BP | Acronym | Business Perspective — the middle layer that orchestrates SC calls and prepares data for screen display |
| SCControlMapKeys | Technical class | Control-map key definitions — constants class defining standard keys (`RETURN_CODE`, `RETURN_MESSAGE`, `ERROR_INFO`) used in the parameter's control map |
| JCMAPLConstMgr | Technical class | Constants manager — static utility class that reads named constants from a properties file, used here to look up error message text by status code |
| 9000 | Constant value | Generic error status — the overridden status code used when the caller signals a failure, ensuring an error message is always displayed |