Skip to content
Build 6ff80cd

5B. Run the Complete Gladly Flow Locally

Once cm-ext-service-exp starts successfully, the next step is to run all three Gladly services on the laptop and send one request through the complete chain:

client → cm-ext-service-exp:8080
       → cm-order-prc:8081
       → cm-osor-sys:8082
       → OMS

Before you start

  • The Cato client, provisioned Cato access, and an active VPN connection when using the dev profile.
  • A nonprod basic-auth user for cm-ext-service-exp when using the dev profile.
  • An approved sandbox customer email or customer ID that may be queried.
  • Confirmation that the sandbox OMS and order-process database are available for this exercise.

Do not use production credentials or real customer data chosen at random.

Choose the path

Either path is fine for this initial run:

  • Dev-backed local services are the shortest path to a real sandbox payload. The request is safe for the shared dev environment when the HTTP-only guardrails below are applied and the team performs only this read-only Gladly lookup with approved test data.
  • Fully isolated local services use local configuration, a local datasource, and a stubbed OMS response. They require more setup but cannot affect the shared dev environment.

These safety statements apply to this lookup only. Do not assume that other routes or endpoints are read-only.

Credentials for the request

cm-ext-service-exp validates Basic Auth inside the running JVM from the users XML matching the active profile. It does not authenticate the username and password against APIM or another remote identity provider.

  • When using the supported dev profile and shared dev resources, contact the integration team for the nonprod Basic Auth credential and approved sandbox access. The plaintext password is intentionally not stored in the repository; it should be provided through the approved team password manager, such as a shared LastPass item or folder.
  • With a fully isolated local profile, create a local-only user in users-local.xml and choose its password locally. No shared Basic Auth credential is needed.

Never put shared credential values in PopDocs, source control, tickets, or chat.

An APIM subscription key is not required for this localhost request because it does not pass through APIM. The remote dev Config Server supplies the application property needed at startup, but the local downstream services do not validate that header. An APIM key is needed only when calling the nonprod APIM gateway directly; if that becomes necessary, distribute the nonprod key through the same approved secret manager.

For the fully isolated path, also use a harmless dummy APIM property. No shared nonprod credential or APIM key is required.

Local services, sandbox configuration

Use the dev profile so each service can read its required configuration through the nonprod Config Server. Override only the HTTP handoffs between the three services so they remain on the laptop:

Running service Keep Override locally
cm-ext-service-exp dev configuration order-prc.gladly.order-details → http://127.0.0.1:8081/gladly/order-details
cm-order-prc dev configuration and datasource both osor-sys.gladly.order-details-* URLs → the matching endpoints on http://127.0.0.1:8082
cm-osor-sys dev OMS URLs and token No internal override; this is the read-only call to sandbox OMS

This is not an isolated run: the services load shared nonprod configuration, and cm-order-prc initializes its sandbox datasource. Keep Cato connected for the entire session.

Make cm-order-prc HTTP-only

cm-order-prc normally starts Service Bus receivers and two scheduled jobs. They are unrelated to Gladly and must be disabled before running it locally against shared dev configuration:

servicebus.consumers.enabled=false
azure.servicebus.jackyun.connection-order-jackyun-queue=false
azure.servicebus.nav-order-release.connection=false
order.schedule.cron=-
jackyun-sys.qimen-orders.schedule.cron=-

The first property disables the three primary receivers. The Jackyun and NAV receivers have separate conditions, which is why their connection properties also need explicit false values. The two - cron values disable the scheduled jobs.

Before sending a request, check the startup logs and confirm that no receiver or scheduled job is processing shared work.

Start in dependency order

Build each repository with its Maven wrapper, then start:

  1. cm-osor-sys on 8082;
  2. cm-order-prc on 8081 with the HTTP-only settings and local osor-sys URLs;
  3. cm-ext-service-exp on 8080 with its order-prc URL pointed at localhost.

Bind the applications to localhost and disable tracing export for this exercise. Do not call the Service Bus health indicator with a configured connection string.

Send a basic Gladly lookup

Use an approved sandbox email or customer ID to send a basic Gladly order-details request through cm-ext-service-exp. The endpoint contract is available from the application's controller, request DTOs, tests, and generated API documentation.

Confirm that the request appears in the logs for all three services and returns a Gladly-shaped JSON document with a results array. A valid empty array still proves that the request crossed the complete chain.

Fully isolated alternative

To avoid sandbox OMS and the VPN entirely, add a fourth local process: an OMS stub. Point cm-osor-sys's two oms.gladlyFetchOrders* properties at the stub and return synthetic OMS fixtures. The basic fixture is an array containing fields such as customer_id, name, email, and billing_address.

That mode also requires safe local configuration for all three services and a local datasource for cm-order-prc's ShedLock/JPA startup dependencies. It is better for repeatable development, but it is more setup than the VPN-backed sandbox lookup.

Shut down cleanly

Stop all three JVMs after the request. Confirm ports 8080–8082 are closed and the three tracked worktrees are unchanged.