update simulation logic

  `jms:queue:CREATE/<category>/<version>/PLANNING`, wired to the same `resourceRepoService.createResource`

  bean method as the real queue. (`UPDATE`/`DELETE` are Day-2 service actions with no simulation flag on

  the OSOM side — out of scope, unchanged.)

- `ResourceRepoService.createResource`: when the `X-OSL-SIMULATION` header is present, skip the catalog

  write and skip `resourceLogic(...)` (and therefore its background thread) entirely. Instead build and

  return a synthesized `Resource` echo (status `AVAILABLE`, a `status.infoMessage` = "simulated

  (planning)" characteristic) directly from the mapped `ResourceUpdate`, so OSOM's `simulateAdapter`

  still gets a valid non-null response to fold into the tentative plan view.

- `ResourceRepoService.createResource`: when the `X-OSL-SIMULATION` header is present, skip the real

  catalog write. The controller logic (`ResourceA/B.resourceLogic(...)`) **still runs** so the tentative

  plan reflects the resource characteristics the controller actually computes — it is called in

  simulation mode, which suppresses only its persistent side effects (the catalog-writing background

  thread and the blocking deploy sleep); see the `20260704_0023` doc. OSOM's `simulateAdapter` thus gets

  a valid non-null response carrying the real computed characteristics to fold into the tentative plan

  view.

> **Note (superseded):** an earlier iteration of this fix skipped `resourceLogic(...)` entirely during

> simulation and returned a hardcoded `status.infoMessage = "simulated (planning)"` echo. That bypassed

> the controller's real computation, so the follow-up (`20260704_0023`) restored the call behind a

> `simulation` flag on `resourceLogic`.

## Files changed

## Solution

In `ResourceRepoService.createResource`, on the simulation path:

1. Add the computed `status.infoMessage` / `status.Health` characteristics directly onto the inbound

   `ResourceCreate` (reusing it as the callback body — `ResourceCreate extends ResourceUpdate`, so no

   separate mapped copy is needed for this path).

1. Run the **real** controller logic (`ResourceA/B.resourceLogic(...)`) so the callback body carries the

   characteristics the controller actually computes (`status.infoMessage`, `status.Health`,

   `status.UUID`, …) rather than a hardcoded "simulated (planning)" placeholder. `resourceLogic` gained a

   `boolean simulation` parameter: called with `true` it computes and adds the characteristics exactly as

   in production but suppresses its persistent side effects (the catalog-writing background worker thread

   and the blocking deploy sleep). The inbound `ResourceCreate` is reused directly as the callback body —

   `ResourceCreate extends ResourceUpdate`, so no separate mapped copy is needed for this path.

2. Send it to OSOM's `PLANNING_RESOURCE_CREATEORUPDATE` queue (`jms:queue:PLANNING.RESOURCE.CREATEORUPDATE`)

   via `ProducerTemplate.requestBodyAndHeaders`, forwarding the correlation headers

   (`org.etsi.osl.serviceOrderId`, `org.etsi.osl.serviceId`, `org.etsi.osl.resourceId`) already present on

- `src/main/resources/application.yml` — new `PLANNING_RESOURCE_CREATEORUPDATE` queue property (same

  value as OSOM's).

- `src/main/java/org/etsi/osl/example/gc/api/ResourceRepoService.java` — `ProducerTemplate` +

  `PLANNING_RESOURCE_CREATEORUPDATE` fields, new `sendPlanningResourceCallback` helper, simulation branch

  now calls it instead of only building a local echo.

  `PLANNING_RESOURCE_CREATEORUPDATE` fields, new `sendPlanningResourceCallback` helper; simulation branch

  now runs `resourceLogic(..., true)` and reports the result instead of only building a local echo.

- `src/main/java/org/etsi/osl/example/gc/api/ResourceA.java`,

  `src/main/java/org/etsi/osl/example/gc/api/ResourceB.java` — `resourceLogic` gained a `boolean

  simulation` parameter guarding the background thread + blocking sleep; a 2-arg overload delegating to

  `..., false` keeps existing callers (`updateResource`) unchanged.

## Verification

# De-duplicate ResourceRepoService

**Date:** 2026-07-07 00:44

**Type:** Structural change (extract helpers; no behavior change)

## Problem

`ResourceRepoService` accumulated three near-identical copies of the same boilerplate as the

planning/simulation support was layered in:

1. **Header → `resourceid` extraction** repeated in `createResource`, `updateResource`, `deleteResource`

   — plus two dead no-op `if` blocks (testing `org.etsi.osl.serviceId` / `org.etsi.osl.serviceOrderId`

   and doing nothing) in the latter two.

2. **Spec-name → `ResourceA/B.resourceLogic` dispatch** repeated 3× (both branches of `createResource`

   and in `updateResource`).

3. **Header-key string literals** (`org.etsi.osl.resourceId` / `.serviceId` / `.serviceOrderId`) repeated

   ~15× across the class.

## Solution

Introduced three constants and two private helpers; the three public methods now share them. Behavior is

unchanged.

- Constants `HDR_RESOURCE_ID`, `HDR_SERVICE_ID`, `HDR_SERVICE_ORDER_ID` (naming mirrors OSOM's

  `PlanningResourceCallbackHandler`), used in the extraction helper and `postPlanningResourceCallback`.

- `resourceIdFromHeaders(headers)` — returns the resource-id-to-update-back header, or `""` when absent;

  replaces the repeated extraction and removes the dead no-op blocks.

- `applyResourceLogic(specName, ru, resourceid, simulation)` — the spec-name dispatch to

  `ResourceA/B.resourceLogic(...)`, returning `null` for an unknown spec (matching the prior

  `updateResource` contract). `createResource` (both branches) and `updateResource` now call it.

Note: `updateResource` now routes through the 3-arg `resourceLogic(..., false)` via `applyResourceLogic`

instead of the 2-arg overload — behaviorally identical, since the 2-arg overload just delegates with

`false`. The 2-arg overloads on `ResourceA`/`ResourceB` are retained as public convenience API.

## Files changed

- `src/main/java/org/etsi/osl/example/gc/api/ResourceRepoService.java` — constants + two helpers; the

  three public methods de-duplicated.

## Verification

- `mvn -o compile` — builds clean.

- Behavior preserved: the helpers reproduce the exact prior branching; no automated tests exist in this

  module, so no runtime retest beyond the compile.

| Doc | Description |

|---|---|

| [20260707_0044_dedup-resourcereposervice.md](20260707_0044_dedup-resourcereposervice.md) | Refactor `ResourceRepoService`: extract `resourceIdFromHeaders` + `applyResourceLogic` helpers and header-key constants to remove three duplicated boilerplate blocks (no behavior change). |

| [20260704_0023_send-simulated-resource-to-planning-queue.md](20260704_0023_send-simulated-resource-to-planning-queue.md) | During simulation, report the controller's computed resource to OSOM's `PLANNING.RESOURCE.CREATEORUPDATE` callback queue instead of only building a local echo. |

| [20260704_0009_fix-planning-simulation-support.md](20260704_0009_fix-planning-simulation-support.md) | Add a `/PLANNING` queue consumer and skip real catalog writes/background threads when the `X-OSL-SIMULATION` header is present, so this example controller works correctly under OSOM planning/simulation. |

  }

  public static ResourceUpdate resourceLogic( ResourceUpdate resourceUpdate,  String resourceid ) {

    return resourceLogic(resourceUpdate, resourceid, false);

  }

  /**

   * example

   *

   * @param simulation when true (OSOM planning dry-run) the resource characteristics are still computed,

   *        but the persistent side effects are suppressed: no background worker thread is started/stopped

   *        (it would keep writing to the catalog forever against a placeholder id) and the blocking

   *        deployment sleep is skipped.

   */

  public static ResourceUpdate resourceLogic( ResourceUpdate resourceUpdate,  String resourceid ) {

  public static ResourceUpdate resourceLogic( ResourceUpdate resourceUpdate,  String resourceid, boolean simulation ) {

    for (Characteristic c : resourceUpdate.getResourceCharacteristic()) {

      if (c.getName().equalsIgnoreCase("paramA")) {

    resourceUpdate.addResourceCharacteristicItemShort("status.Health", healthStatus,  EValueType.TEXT.getValue());

    resourceUpdate.addResourceCharacteristicItemShort("status.UUID",UUID.randomUUID().toString(),  EValueType.TEXT.getValue());

    if (!simulation) {

      if (paramA.equals("start")) {

        controller.startThread( resourceid);

      } else {

        // TODO Auto-generated catch block

        e.printStackTrace();

      }

    }

    resourceUpdate.setResourceStatus(ResourceStatusType.AVAILABLE);