add simulated resource

	<classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources">

		<attributes>

			<attribute name="maven.pomderived" value="true"/>

			<attribute name="optional" value="true"/>

		</attributes>

	</classpathentry>

	<classpathentry kind="src" output="target/test-classes" path="src/test/java">

		<attributes>

			<attribute name="test" value="true"/>

			<attribute name="maven.pomderived" value="true"/>

			<attribute name="optional" value="true"/>

		</attributes>

	</classpathentry>

	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-17">

# Fix example generic controller to properly work under OSOM planning/simulation

**Date:** 2026-07-04 00:09

**Type:** Linear change (new Camel route + a simulation branch in one method)

## Problem

OSOM's `GCOrchestrationService` sends generic-controller deployment requests during planning/simulation

to a dedicated `.../PLANNING` queue suffix, tagged with the `X-OSL-SIMULATION` header, using a

placeholder resource id that does not exist in the real catalog (see OSOM doc

`20260703_1615_gc-planning-queue-suffix.md`). This example controller had two bugs that broke that

contract:

1. **No consumer on the `/PLANNING` queue.** `PartnerRouteBuillder` only listened on

   `jms:queue:CREATE/<category>/<version>`, not the `/PLANNING`-suffixed variant. Every planning run

   against this controller silently timed out after OSOM's wait budget and marked the service

   `TERMINATED`.

2. **Real side effects during simulation.** `ResourceRepoService.createResource` checked for the

   `X-OSL-SIMULATION` header but only logged it — it still called

   `aCatalogClient.updateResourceById(resourceid, ...)` (a real HTTP/JMS write to the catalog) using

   OSOM's placeholder resource id, and still invoked `ResourceA/B.resourceLogic(...)`, which spawns a

   background thread that keeps polling/writing to that same placeholder id forever.

## Solution

- `PartnerRouteBuillder.configure()`: added a second `from(...)` route consuming

  `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.

## Files changed

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

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

## Verification

- `mvn -o compile` — builds clean.

- No automated tests exist in this module; verified by code inspection against the OSOM-side contract

  (`X-OSL-SIMULATION` header, `.../PLANNING` queue suffix, placeholder resource id) documented in

  `org.etsi.osl.osom/docs/20260703_1520_execute-adapters-for-real.md` and

  `.../20260703_1615_gc-planning-queue-suffix.md`.

# Send simulated resources to OSOM's planning resource callback queue

**Date:** 2026-07-04 00:23

**Type:** Linear change (new outbound queue call in one method)

## Problem

OSOM's `PlanningResourceCallbackHandler` consumes a request-reply queue,

`PLANNING.RESOURCE.CREATEORUPDATE`, so a controller can report a resource it created/updated during a

planning/simulation run and have OSOM fold the controller's own computed details (name, characteristics,

status) into the tentative plan's `PlanningResourceInventory`/view — replacing the placeholder resource

OSOM guessed before sending the deployment request (see OSOM doc

`20260703_1600_planning-resource-callback-queue.md`). This example controller's simulation path (added in

`20260704_0009_fix-planning-simulation-support.md`) only built a local echo `Resource` and returned it —

it never told OSOM about the resource it simulated, so the tentative plan view always kept OSOM's

placeholder guess instead of this controller's computed characteristics (`status.infoMessage`,

`status.Health`, etc.).

## 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).

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

   the inbound deployment request, plus `resourceName`/`resourceVersion`/`resourceCategory`. Forwarding

   the same `org.etsi.osl.resourceId` (OSOM's placeholder) makes OSOM update its existing tentative

   inventory entry in place rather than create a duplicate.

3. Use OSOM's replied `Resource` as this method's own reply; if the callback queue is unreachable

   (exception, or a non-`String` response), fall back to the pre-existing local echo

   (`toSimulatedResource`), so the controller always returns a valid Resource to the caller.

## Files changed

- `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.

## Verification

- `mvn -o compile` — builds clean.

- No automated tests exist in this module; verified by code inspection against the OSOM-side contract in

  `org.etsi.osl.osom/src/main/java/org/etsi/osl/osom/tentative/PlanningResourceCallbackHandler.java`

  (header names, body/reply types, update-vs-create-by-resourceId semantics).

# Docs Index

| Doc | Description |

|---|---|

| [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. |

    String EVENT_CREATE = "jms:queue:CREATE/"+compcategory+"/" + compversion;

    // OSOM routes planning/simulation dry-run deployment requests to this dedicated queue

    // (same category/version, "/PLANNING" suffix) instead of the real CREATE queue.

    String EVENT_CREATE_PLANNING = EVENT_CREATE + "/PLANNING";

    String EVENT_UPDATE = "jms:queue:UPDATE/"+compcategory+"/" + compversion;

    String EVENT_DELETE = "jms:queue:DELETE/"+compcategory+"/" + compversion;

        .marshal().json( JsonLibrary.Jackson)

        .convertBodyTo( String.class );

    from(EVENT_CREATE_PLANNING)

        .log(LoggingLevel.INFO, log, EVENT_CREATE_PLANNING + " message received!")

        .to("log:DEBUG?showBody=true&showHeaders=true").unmarshal()

        .json(JsonLibrary.Jackson, ResourceCreate.class, true)

        .bean( resourceRepoService, "createResource( ${headers}, ${body} )")

        .marshal().json( JsonLibrary.Jackson)

        .convertBodyTo( String.class );

    from(EVENT_UPDATE)

        .log(LoggingLevel.INFO, log, EVENT_UPDATE + " message received!")

        .to("log:DEBUG?showBody=true&showHeaders=true").unmarshal()