# Com / Optage / Kopt / Batch

## Overview

The `com.optage.kopt.batch` module contains three lightweight batch entry-point classes (`KKPRC14901`, `KKPRC24901`, `KKPRC34901`). These classes serve as the top-level execution points for batch operations within the KOPT system. Each class exposes a `run()` method designed to be invoked by a batch scheduler or job framework, and `KKPRC14901` additionally provides a `check()` method for pre-flight validation.

## Key Classes and Interfaces

### KKPRC14901

The most feature-complete class in the package. It provides two public methods:

- **`check()`** — A validation hook with an empty body. This method appears to be a pre-flight or health-check placeholder that can be called before the main batch logic. Its current implementation is a no-op, suggesting it may be wired up to a future validation framework or scheduled separately.

- **`run()`** — The primary batch execution method. It delegates to `EKK0301A010.process()`, instantiating `EKK0301A010` from the sibling package `com.optage.kopt.ekk` and calling its `process()` method. This makes `KKPRC14901` the bridge between the batch entry point and the actual business logic implemented elsewhere.

```java
public void run() { new EKK0301A010().process(); }
```

### KKPRC24901

A secondary batch runner with a single public method:

- **`run()`** — A placeholder batch method. The body contains only a comment (`/* KKPRC secondary batch */`) indicating it is intended as a stub for future batch processing logic. This class follows the same naming convention as its siblings but currently has no operational behavior.

### KKPRC34901

The tertiary batch runner, structurally identical to `KKPRC24901`:

- **`run()`** — A placeholder batch method with only a comment body (`/* KKPRC tertiary batch */`). Like `KKPRC24901`, it is a scaffold awaiting implementation.

## How It Works

The typical execution flow starts with an external scheduler (cron, Spring Batch, Airflow, etc.) invoking the `run()` method on the appropriate `KKPRC*` class:

1. The scheduler calls `run()` on the target batch class.
2. If the target is `KKPRC14901`, the method instantiates `EKK0301A010` and delegates to its `process()` method, which contains the actual business logic.
3. If the target is `KKPRC24901` or `KKPRC34901`, the method currently does nothing (stub implementations).
4. For `KKPRC14901`, an optional `check()` call may precede `run()` as a pre-flight validation step — though currently `check()` is a no-op.

A simplified view of this flow:

```mermaid
flowchart TD
    Sched["Scheduler / Job Framework"] --> KKPRC14901["KKPRC14901.run()"]
    KKPRC14901 --> EKKEKK["EKK0301A010.process()"]
    Sched --> KKPRC24901["KKPRC24901.run()"]
    Sched --> KKPRC34901["KKPRC34901.run()"]
    EKKEKK --> BizLogic["Business logic in EKK package"]
    KKPRC14901 -.->|optional pre-flight| Check["KKPRC14901.check() (no-op)"]
    KKPRC24901 -.->|stub| NoOp2["No-op (future impl.)"]
    KKPRC34901 -.->|stub| NoOp3["No-op (future impl.)"]
```

## Dependencies and Integration

This module has a single known dependency outside its own package:

| Dependency | How it is used |
|---|---|
| `com.optage.kopt.ekk.EKK0301A010` | Instantiated and invoked within `KKPRC14901.run()`. This class lives in the `ekk` package and likely contains the core business logic for the primary batch job. |

No other cross-module relationships are detected. The batch classes themselves have no constructor parameters, no injected dependencies, and no external configuration — they are static entry points.

## Notes for Developers

- **Stubs awaiting implementation.** Two of the three classes (`KKPRC24901` and `KKPRC34901`) are currently no-op stubs. If you are adding batch processing logic, this is likely where it should go.
- **Naming convention.** Classes follow the pattern `KKPRC` + five-digit code (14901, 24901, 34901). The numbering may carry business meaning — check with the team for the convention behind these codes.
- **KKPRC14901 is the only wired class.** Only `KKPRC14901` delegates to an actual processor class (`EKK0301A010`). The other two are scaffolds.
- **No constructor arguments or injection.** All classes have a default no-arg constructor. New methods or classes in this package should follow the same pattern — simple, stateless entry points.
- **EKK0301A010 has no imports.** The processor class it delegates to is also minimal, so the actual batch work likely lives further down the call chain.