Skip to content
Build 6ff80cd

5A. Run the Gladly Experience Layer Locally

The Gladly flow spans three repositories:

  • PopSockets/cm-ext-service-exp
  • PopSockets/cm-order-prc
  • PopSockets/cm-osor-sys

Clone them from master into the same working folder. Do not base local work on develop, dev, qa, or stage. For the first startup, focus on cm-ext-service-exp; the other two repositories provide the downstream flow.

Basic prerequisites

  • GitHub access to the PopSockets organization and all three repositories.
  • Java 21 (Temurin).
  • No global Maven installation is needed; each repository includes ./mvnw.
  • Port 8080 available locally.
  • The Cato client, a provisioned Cato VPN account, and a connected VPN session if you intend to use the remote dev configuration.

Choose how configuration is supplied

dev and local mean very different things here:

Mode VPN Configuration Use it for
Remote dev profile Required PopSockets Config Server + real shared nonprod values Integration work against the sandbox environment
Isolated local startup Not required Local dummy values with all outbound connections disabled First boot, code exploration, and unit work

Either mode is fine for the initial run. An isolated local startup cannot affect the shared dev environment. The dev profile is also appropriate for the read-only Gladly lookup in the next step when its consumers and scheduled jobs are disabled and only approved sandbox test data is used.

Remote dev profile

The checked-in application-dev.yml imports configuration from:

https://camelconfigserver-np.corp.popsockets.com/config/

That .corp host requires a connected, provisioned Cato VPN and working corporate DNS. If startup fails while importing configuration, verify VPN access and hostname resolution before debugging Maven or Spring. Having the Cato client installed is not sufficient: developers must also be granted access. Request that access through the normal IT or integration-team onboarding channel before using this mode.

The values returned for dev are real shared nonprod configuration, including Service Bus and downstream service connections. Starting with dev is therefore not an isolated local boot. Developers choosing this path must contact the integration team for the required nonprod access, Basic Auth credentials, and an approved sandbox identity before calling business endpoints.

Isolated local startup

cm-ext-service-exp does not currently include application-local.yml or users-local.xml. Setting the active profile to local by itself will not work.

The repository's src/test/resources/application.properties and users-test.xml show the minimum property set and security-file pairing needed for an isolated context. They are the best starting point for local startup. A safe local configuration must:

  • disable Spring Cloud Config;
  • provide a users XML matching the active profile;
  • supply harmless values for every required property;
  • keep Service Bus, downstream HTTP, Blob, and tracing connections disabled or pointed at local substitutes; and
  • contain no company credentials; keep developer-specific overrides untracked.

Basic Auth is enforced inside the application from that users XML; it does not authenticate against a remote identity provider. For an isolated local profile, developers create their own local-only username and password rather than request a shared nonprod credential.

Inspect health checks before calling them

The Azure Service Bus health indicator sends a message when its connection string is configured. Keep that connection blank for isolated startup before calling /actuator/health.

A durable, credential-free local profile should eventually be added to the repository so every developer uses the same safe defaults. Until then, local startup requires explicit local/test configuration rather than an environment profile.

First build

Run the repository's Maven wrapper and include its tests:

cd cm-ext-service-exp
./mvnw -B package

Once the experience layer starts, the other two repositories contain the Gladly process and OMS-system handoffs needed to follow the request downstream.

Continue with Run the complete Gladly flow locally to connect all three services and fetch a sandbox or synthetic payload.