Guidewire Install & Auth

Overview

Authenticate a backend service to a Guidewire Cloud tenant using OAuth2 client credentials and operate the auth layer in production. This is not a hello-world walkthrough; it is the auth code your service runs at 3am when a token expires mid-batch, when a tenant admin rotates a scope, when a private CA renews a cert, and when on-call needs to swap a leaked secret without dropping in-flight requests.

The four production failures this skill prevents:

1. Token expiry storms — every request races to refresh, the Hub rate-limits the auth endpoint, the integration cascades to red.
2. Scope drift — a GCC admin removes a scope, every cached token starts returning 403, retrying does not help.
3. PKIX path building failed — JVM cannot validate the tenant's TLS chain because the private CA is not in the trust store; common when carriers front Cloud API with their own DLP appliance.
4. Secret rotation downtime — the active client secret is rotated and the old secret stops working before the new one is loaded; in-flight token refreshes fail until restart.

Prerequisites

• JDK 17 (Guidewire Cloud release 202503 and later)
• A registered Service Application in Guidewire Cloud Console (GCC) with Cloud API roles assigned per least privilege
• Network egress from your runtime to *.guidewire.net (runtime APIs) and gcc.guidewire.com (console only)
• A secret store the runtime can read at startup and on rotation signal (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, or Kubernetes Secret with CSI driver)
• For private-CA tenants: the carrier's CA chain in PEM form

Instructions

Build the auth layer in this order. Each section solves one production failure mode; do not skip steps because the failure shows up in production, not in dev.

1. Implement the token-cache pattern below — proactive refresh, single-flight gate, JWT-based expiry.
2. Wire secret rotation to your secret store; do not commit secrets or bake them into images.
3. For private-CA tenants, install the trust store at the JVM/init-container layer.
4. Validate scope hardening on every refresh so drift fails fast, not on the next business call.

Token-cache pattern (production)

Tokens are short-lived, typically one hour. Reactive refresh on 401 is wrong: it doubles latency on the failing request and creates a thundering herd when many requests notice expiry simultaneously. Cache the token in-process and refresh proactively at 80% of TTL, behind a single-flight gate so concurrent refreshers serialize.

impor

Guidewire Local Dev Loop

Overview

Run a local InsuranceSuite instance and iterate on Gosu rule logic in seconds, not minutes. The single biggest productivity killer in Guidewire development is paying the 5–15 minute gradle runServer cold-start cost on every change because the developer does not know which edits hot-reload and which force a restart.

Three production problems this skill prevents:

1. Restart cascade — developer changes a Gosu rule, restarts runServer, waits 8 minutes, finds the rule was wrong, repeats. A full day disappears in restarts.
2. Silent stale code — Studio claims it hot-reloaded a class but the running JVM is still executing the old bytecode (common when interfaces change). Tests pass against stale code.
3. GUnit drift — unit tests for Gosu rules diverge from the rules themselves because the cycle to run a single test through Studio is too slow; developers stop writing them.

Prerequisites

• JDK 17 (for Cloud release 202503+)
• Guidewire Studio installed (IntelliJ-based, distributed by Guidewire)
• Local InsuranceSuite configuration zone (PolicyCenter, ClaimCenter, or BillingCenter)
• ≥16 GB RAM on the dev machine — runServer + Studio + the JVM debug agent need headroom
• Sample data loader configured for the chosen product (e.g., PersonalAuto for PC)

Instructions

Build the inner loop in this order. Every step targets one of the three productivity killers above.

1. Start runServer once, keep it warm

Cold start takes 5–15 minutes; treat it as a session investment.

# Start in dev mode with debug agent on 8088, leaves the server attached to the terminal
./gradlew runServer -Pdebug=true -PdebugPort=8088 -Dgw.servermode=dev

gw.servermode=dev enables the hot-reload paths inside the JVM. debugPort=8088 exposes the JDWP debug agent — attach IntelliJ to it once and leave it. Restart only when the what hot-reloads table below says you must.

2. What hot-reloads, what does not

Memorize this table — it determines whether the next edit costs 0 seconds or 8 minutes.

export async function patchResource<T>(path: string, mutate: (current: T) => Partial<T>): Promise<T> {
  const token = await getToken();
  const getRes = await fetch(`${BASE}${path}`, { head

sops-init                                    # writes .sops.yaml + .env.sop

// modules/configuration/gsrc/com/acme/messaging/ClaimEventBuilder.gs
package com.acme.messaging

uses gw.api.messaging.MessageContext
uses entity.Claim

class ClaimEventBuilder {
  static function buildClaimStatusChangedEvent(ctx: MessageContext, claim: Claim): String {
    return new gw.api.web.json.JsonObject() {{
      put("eventType", "