# Getting Started

## What This Project Does

This is the **KOPT** (Optage) platform — a Java EE web application that processes SOD (Scheduled Output Data) operations through a structured business processing pipeline. Built on Maven with JSF for the web layer and EJB for backend services, the application handles contract processing, batch jobs, and data dispatch, configured extensively via XML descriptor files.

## Recommended Reading Order

Read the wiki pages in this order to build a mental model of the codebase:

1. **[com.optage.kopt.dto](com/optage/kopt/dto)** — Start here. The DTOs are the simplest entry point and define the core request-response contract.
2. **[com.optage.kopt.bp](com/optage/kopt/bp)** — Understand the business processing layer that consumes the DTOs and orchestrates the SOD pipeline.
3. **[com.optage.kopt.batch](com/optage/kopt/batch)** — Learn the batch job subsystem that drives scheduled processing.
4. **[com.optage.kopt.ekk](com/optage/kopt/ekk)** — Study the contract processing module.

## Key Entry Points

### ACA001SFBean (highest reference count)

The most referenced class in the codebase. Located at [full-fixture-codebase/src/java/eo/web/webview/ACA001SF/ACA001SFBean.java](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/ACA001SFBean.java), this bean sits in the `eo.web.webview` package and serves as a JSF managed bean backing a web view. It is referenced 6 times across XML config files and other classes.

### JKKHakkoSODCC (SOD dispatch controller)

Located at [src/main/java/com/optage/kopt/bp/JKKHakkoSODCC.java](src/main/java/com/optage/kopt/bp/JKKHakkoSODCC.java), this is the central dispatcher in the business processing layer. It delegates to `JKKSodSendCC` for sending and `KKPRC14901` for validation — understanding its flow gives you a map of the SOD pipeline.

### Other core classes

| Class | Package | Role |
|-------|---------|------|
| [JKKSodRequestDTO](src/main/java/com/optage/kopt/dto/JKKSodRequestDTO.java) | `com.optage.kopt.dto` | Input data carrier (tenantId, serviceId) |
| [JKKSodResponseDTO](src/main/java/com/optage/kopt/dto/JKKSodResponseDTO.java) | `com.optage.kopt.dto` | Output data carrier (status, message) |
| [JKKSodSendCC](src/main/java/com/optage/kopt/bp/JKKSodSendCC.java) | `com.optage.kopt.bp` | Handles SOD send/dispatch logic |
| [KKPRC14901](src/main/java/com/optage/kopt/batch/KKPRC14901.java) | `com.optage.kopt.batch` | Batch check with contract processing |
| [EKK0301A010](src/main/java/com/optage/kopt/ekk/EKK0301A010.java) | `com.optage.kopt.ekk` | Contract processing with KKW trigger |
| [ESC0101B001](src/main/java/com/optage/kopt/esc/ESC0101B001.java) | `com.optage.kopt.esc` | Service control logic |

## Project Structure

```
com.optage.kopt
├── bp/          — Business processing: SOD dispatch, helpers, send logic
├── dto/         — Data transfer objects: request/response POJOs
├── batch/       — Scheduled batch job runners
├── ekk/         — Contract processing pipeline
├── esc/         — Service control
├── kkw/         — Batch trigger logic
└── unrelated/   — Isolated classes (no cross-dependencies)
```

The web layer lives in a parallel directory structure:

```
full-fixture-codebase/src/java/eo/web
├── webview/ACA001SF/   — JSF managed beans
├── futurity/web/x33/   — Filters and listeners (encoding, app context)
└── webview/            — Additional view layer classes
```

```
flowchart TD
    A["Web Layer
eo.web.webview"] --> B["Business Processing
com.optage.kopt.bp"]
    B --> C["DTOs
com.optage.kopt.dto"]
    B --> D["Batch Jobs
com.optage.kopt.batch"]
    B --> E["Helpers
JKKHakkoSODHelper"]
    B --> F["Send
JKKSodSendCC"]
    D --> G["Contract Processing
com.optage.kopt.ekk"]
    D --> H["Trigger
KKW0100B001"]
    G --> H
    I["Config
XML files"] --> J["web.xml
Servlet config"]
    I --> K["sun-ejb-jar.xml
EJB mapping"]
    I --> L["real-config.xml
Service wiring"]
    M["Web Pages
JSP + screens"] --> N["JSF FacesServlet"]
    M --> O["Custom filters
SjisFilter"]
    J --> N
    J --> O
```

## Configuration

This application relies heavily on XML descriptor files. The key ones are:

### Build configuration
- **[pom.xml](pom.xml)** — Root Maven POM (groupId `com.optage.kopt`, version `1.0.0-SPEC-SCOPED-WIKI`).
- **[xml-build-excluded/pom.xml](xml-build-excluded/pom.xml)** — A sub-module POM for excluded build fixtures.

### Web container config
- **[web.xml](xml-web-xml-multi-pattern/koptWebA/WebContent/WEB-INF/web.xml)** — Servlet mappings, filters (`X33JVRequestEncodingSjisFilter` for Shift-JIS encoding), and listeners (`X33AppContextListener`). Also includes the JSF `FacesServlet`.
- **[web-full.xml](full-fixture-codebase/koptWebA/WebContent/WEB-INF/web-full.xml)** — A fuller web descriptor with encoding filter and FacesServlet.

### EJB config
- **[sun-ejb-jar.xml](xml-sun-ejb-jar/koptBp/ejbModule/META-INF/sun-ejb-jar.xml)** — Maps EJBs to JNDI names (e.g. `ACSV0001FlowBean` → `ejb/ACSV0001Flow`). Used for the Sun Application Server deployment.

### Service wiring
- **[real-config.xml](xml-build-excluded/src/config/real-config.xml)** — Defines `<BL class="...">` entries that wire Java classes into the config-driven architecture.
- **[external-refs.xml](xml-unresolved-fqn/src/config/external-refs.xml)** — Contains references to both internal and third-party classes.
- **[real-config-screen.xml](xml-probe/src/app/real-config-screen.xml)** — Screen-level `<SCREEN>` config with business layer bindings.

### View definition
- **[WEBGAMEN_ACA001010PJP.xml](xml-futurity-view-def/src/futurity-app/webA/env/view/def/WEBGAMEN_ACA001010PJP.xml)** — Futurity view definition file mapping screen IDs to processing logic.

## Common Patterns

### XML-driven class wiring
Classes are wired through XML `<BL class="...">` entries rather than annotations. To find what a config file references, grep for the `class` attribute on `<BL>` elements:

```xml
<config>
  <BL class="eo.web.RealClass"/>
</config>
```

### Request/Response DTO pattern
All inter-layer communication uses plain data-carrier objects:

```
flowchart LR
    A["com.optage.kopt.bp"] --> B["JKKSodRequestDTO"]
    A --> C["JKKSodResponseDTO"]
    A --> D["JKKSodSendCC"]
    A --> E["KKPRC14901"]
    A --> F["JKKHakkoSODHelper"]
    D --> G["send method"]
    E --> H["check method"]
```

DTOs (`com.optage.kopt.dto`) are intentionally minimal: fields only, no business logic.

### Class naming conventions
- **Batch jobs**: `KKPRC<4-digit>` — `KKPRC14901`, `KKPRC24901`, etc.
- **Contract processing**: `EKK<8-digit>` — `EKK0301A010`, `EKK0301A020`.
- **EJB beans**: `AC<4-digit>SFBean` — `ACA001SFBean`.
- **Service components**: `JKK<name>CC` or `<name>Logic` — follows a specific subsystem naming scheme.

### Testing
Tests mirror the source structure under `src/test/java/`. The single existing test is [JKKHakkoSODCCTest](src/test/java/com/optage/kopt/bp/JKKHakkoSODCCTest.java) for the main dispatch controller. Run tests with:

```bash
mvn test
```

### Character encoding
The application handles Japanese text via `X33JVRequestEncodingSjisFilter` — a Shift-JIS encoding filter applied via `web.xml`. If you work on web UI or JSP pages, be aware that some pages may use Shift-JIS encoding (`<%@ page contentType="..." %>` with shift-jis).

## Next Steps

- Read the [DTO package docs](com/optage/kopt/dto) for a complete class-by-class reference.
- Run `mvn compile` to verify the build.
- Explore the XML config files under `xml-*` directories to see how different config patterns are tested.
- Look at the web fixtures under `full-fixture-codebase/` to understand the JSF + JSP integration.