# Com / Optage / Kopt / Bp

## Overview

The `com.optage.kopt.bp` package provides batch processing utilities for SOD (Start of Day) operations within the KOPT (likely a core banking or financial processing) system. It coordinates the preparation, validation, and dispatch of SOD-related data through the broader batch processing pipeline under `com.optage.kopt.batch`. This package acts as the entry point for triggering SOD workflows, handling formatting, and delegating to external batch validators.

## Key Classes and Interfaces

### [JKKBpServiceBase](src/main/java/com/optage/kopt/bp/JKKBpServiceBase.java)

The base service class for this package. It defines shared initialization logic (`baseInit()`) that can be inherited by or called from other components in the batch processing chain.

- **`baseInit()`** — Performs common setup (lines 8–8). The implementation is minimal (a placeholder comment), suggesting this is a hook for shared initialization that concrete subclasses or callers can extend. This is a `protected` method, intended for internal use by other classes in the package.

- **Design role**: Serves as a common parent or utility container. Its presence indicates that additional service classes extending or composing this base are expected, though none are currently present in this package.

### [JKKHakkoSODCC](src/main/java/com/optage/kopt/bp/JKKHakkoSODCC.java)

This is the central controller class in the package — the "coordination core" that orchestrates SOD operations. It exposes two primary operations:

- **`dispatch()`** (line 8) — Initiates the SOD dispatch flow. It creates a new instance of `JKKSodSendCC` and calls its `send()` method, effectively acting as a facade that delegates the actual send/dispatch work to a dedicated class.

- **`validate()`** (line 9) — Performs validation checks by instantiating `KKPRC14901` (from `com.optage.kopt.batch`) and calling its `check()` method. This is how the bp package delegates validation logic to the batch processing module.

- **Design role**: Acts as the single point of entry for SOD dispatch and validation workflows. The class follows a simple delegation pattern — it does not implement logic itself but orchestrates calls to specialized classes (`JKKSodSendCC` for dispatch, `KKPRC14901` for validation).

### [JKKHakkoSODHelper](src/main/java/com/optage/kopt/bp/JKKHakkoSODHelper.java)

A utility class that provides formatting assistance for SOD data.

- **`format(String input)`** (line 8) — Returns the trimmed version of the input string. This is a simple convenience method that strips leading and trailing whitespace from string values before they are used in downstream processing.

- **Design role**: A lightweight, stateless helper. Despite the "Helper" suffix suggesting a broader role, it currently provides a single formatting utility. This class is designed to be instantiated on demand (there is no constructor logic) and used for pre-processing string inputs before they enter the dispatch or validation flow.

### [JKKSodSendCC](src/main/java/com/optage/kopt/bp/JKKSodSendCC.java)

The class responsible for the actual SOD sending/dispatch logic.

- **`send()`** (line 8) — Executes the SOD dispatch logic. The implementation placeholder indicates this is where the actual data sending/forwarding to downstream systems occurs. It is invoked by `JKKHakkoSODCC.dispatch()`.

- **Design role**: Separates the concerns of orchestration (handled by `JKKHakkoSODCC`) from the actual dispatch implementation. This separation makes it easier to modify the sending mechanism independently of the coordination flow.

### [JKKHakkoSODCCTest](src/test/java/com/optage/kopt/bp/JKKHakkoSODCCTest.java)

The JUnit test class for verifying SOD dispatch behavior.

- **`testMain()`** (lines 11–14) — Uses `@Test` annotation (JUnit) to run a basic assertion test. Currently contains a placeholder `assertTrue(true)`, indicating that the test infrastructure is in place and the test framework is configured, but actual functional test coverage for the SOD dispatch and validation flows is pending implementation.

## How It Works

### SOD Dispatch Flow

The typical SOD dispatch operation follows this sequence:

```mermaid
flowchart TD
    subgraph Package["com.optage.kopt.bp"]
        Caller["External Caller"]
        HakkoSODCC["JKKHakkoSODCC"]
        SodSendCC["JKKSodSendCC"]
        HakkoSODHelper["JKKHakkoSODHelper"]
        TestClass["JKKHakkoSODCCTest"]
    end

    subgraph External["com.optage.kopt.batch"]
        KKPRC14901["KKPRC14901"]
    end

    Caller -->|"dispatch()"| HakkoSODCC
    HakkoSODCC -->|"send()"| SodSendCC
    HakkoSODCC -->|"check()"| KKPRC14901
    HakkoSODHelper -.->|"format()"| HakkoSODCC
    TestClass -->|"tests"| HakkoSODCC
```

**Step-by-step dispatch flow:**

1. An external caller invokes `JKKHakkoSODCC.dispatch()`.
2. `dispatch()` creates a new `JKKSodSendCC` instance and calls `send()` to perform the actual SOD dispatch.
3. Separately, validation can be triggered via `JKKHakkoSODCC.validate()`, which delegates to `KKPRC14901.check()` in the `com.optage.kopt.batch` module.
4. String data can be pre-processed via `JKKHakkoSODHelper.format()` before being fed into the dispatch or validation flow.

### Validation Flow

1. A caller invokes `JKKHakkoSODCC.validate()`.
2. This creates a `KKPRC14901` instance from `com.optage.kopt.batch` and calls `check()` to perform the validation.
3. `KKPRC14901` is part of a broader batch processing module and may in turn trigger additional batch jobs (it has a `run()` method that delegates to `EKK0301A010`).

### SOD Sending Flow

1. `JKKHakkoSODCC.dispatch()` is called.
2. A new `JKKSodSendCC` is instantiated and `send()` is invoked.
3. The `send()` method contains the core dispatch logic (placeholder currently), which handles the actual communication with downstream systems.

## Data Model

This package does not define its own data model classes (entities, DTOs, or value objects). The data flows through the system as:

- **String inputs** — Processed by `JKKHakkoSODHelper.format()` for trimming before use.
- **Batch records** — Handled internally by `KKPRC14901` and `JKKSodSendCC` (detailed schemas are defined in the `com.optage.kopt.batch` package).

## Dependencies and Integration

### External Dependencies

| Dependency | Module | Purpose |
|---|---|---|
| `KKPRC14901` | `com.optage.kopt.batch` | Validation checks for SOD data |
| `KKPRC24901` | `com.optage.kopt.batch` | Additional batch validation logic |
| `KKPRC34901` | `com.optage.kopt.batch` | Additional batch validation logic |
| `EKK0301A010` | `com.optage.kopt.batch` | Batch process invoked by `KKPRC14901` |

### Package Hierarchy

```mermaid
flowchart TD
    Kopt["com.optage.kopt"]
    Bp["com.optage.kopt.bp"]
    Batch["com.optage.kopt.batch"]

    Kopt --> Bp
    Kopt --> Batch

    Bp -->|"validate() calls"| Batch
```

The package lives directly under `com.optage.kopt` as a top-level subpackage. Its primary integration point is with `com.optage.kopt.batch`, from which it pulls validation classes.

## Notes for Developers

### Extension Points

- **`JKKBpServiceBase.baseInit()`** is a `protected` method designed to be overridden by subclasses or called during setup. If you need to add common initialization for SOD batch operations, this is the intended hook.
- **`JKKHakkoSODHelper.format()`** is a stateless utility. Additional formatting methods can be added to this class as new string preprocessing needs arise.
- **`JKKSodSendCC.send()`** is where the core dispatch logic lives. If the sending mechanism changes (e.g., switching transport protocols, adding encryption), this method is the primary place to modify.

### Testing

The test class `JKKHakkoSODCCTest` exists with a placeholder test. As functional logic is added, the `testMain()` method should be expanded to cover:

- SOD dispatch end-to-end (happy path and error cases)
- Validation delegate behavior with `KKPRC14901`
- String formatting edge cases in `JKKHakkoSODHelper`

### Conventions

- **Delegation over composition**: `JKKHakkoSODCC` creates new instances of its collaborators (`JKKSodSendCC`, `KKPRC14901`) rather than holding references. This keeps the classes stateless and simple but means dependencies are instantiated on each call.
- **Naming convention**: Class names follow the pattern `JKK` prefix + descriptive suffix + `CC` suffix (e.g., `JKKHakkoSODCC`, `JKKSodSendCC`). The `CC` suffix likely denotes "Credit Control" or a similar batch control concept.
- **Placeholder implementations**: Several methods currently contain only comments or placeholders. These indicate areas where business logic will be added as the SOD processing requirements are further specified.