Integrating PC, BC & CC

The functional modules showed three flows that cross application boundaries: billing instructions, non-payment cancellation and policy retrieval for claims. This module shows the machinery underneath — events, messaging, APIs and plugins — and how to keep it reliable.

Two directions, two styles

Outbound, asynchronous

"Something changed here; tell the other system." Done with messaging: the change commits, a message is queued in the same transaction, and a sender delivers it afterwards with retries.

Inbound or synchronous

"I need an answer now" or "another system is calling me". Done with APIs (REST / web services) and plugins that make a call and wait for the reply.

Events and messaging

  1. CommitEntity changese.g. a check is approved.
  2. PlatformEvent firesEntity events like Added / Changed / Removed, plus custom events.
  3. RulesEvent fired rulesFor each interested destination, decide whether to create a message.
  4. Same transactionMessage savedPayload stored with the change.
  5. AsyncTransport sendsDestination's transport plugin delivers; ack or error.

A destination represents one external system or channel. Its configuration lists the events it listens to and the plugins that build and send messages. An event fired rule might look like this:

// Event fired rule for the payments destination (ClaimCenter)
if (messageContext.EventName == "CheckStatusChanged") {
  var check = messageContext.Root as Check
  if (check.Status == TransactionStatus.TC_REQUESTING) {
    messageContext.createMessage(CheckPayloadBuilder_Ext.build(check))
  }
}
  • Ordering: messages for the same primary object (e.g. one policy or account) are sent in order; a failed message blocks later ones for that object until it is resolved.
  • Acknowledgement: the transport (or a later reply) acks the message. Errors can be retried automatically or flagged for an operator.
  • Monitoring: administration screens show queued, failed and acknowledged messages and let operators retry or skip.
Idempotency

Retries mean the receiver can see the same message twice. Include a stable message ID or business key in every payload, and make receivers ignore duplicates. This single habit prevents double payments and duplicate charges.

PolicyCenter ↔ BillingCenter

FlowDirectionMechanism (typical)
Billing instruction on bind / issue / change / cancel / renewPC → BCPC's billing system plugin, called from messaging so the job commit doesn't wait on BC
Account and producer syncPC → BCSame billing integration, before the first policy's instruction
Available payment plans and invoice streams for quotingPC → BC (synchronous)Plugin call to BC during the quote
Cancel for non-payment / rescindBC → PCBC's policy system plugin, triggered by delinquency events
Billing summary on policy screensPC → BC (synchronous)Read-only API call when the screen is opened

When PolicyCenter is the master for policy data, BillingCenter must never invent policy periods on its own. If an instruction fails, the fix is to repair and resend it, not to edit BillingCenter by hand.

PolicyCenter ↔ ClaimCenter

  • Policy search and retrieval (CC → PC). During FNOL, ClaimCenter's policy search plugin calls the policy system to find matching policies and then retrieve the snapshot as of the loss date. The result is mapped into ClaimCenter's own policy entities.
  • Policy refresh. The same plugin can re-fetch the snapshot later and show differences.
  • Claims history (PC → CC). PolicyCenter can show prior losses on the policy or account by querying ClaimCenter, which underwriting rules can use at renewal.
Mapping is the hard part

PolicyCenter's product model (lines, coverables, coverages, terms) must be mapped to ClaimCenter's policy model (risk units, coverages, limits, deductibles). Agree the mapping per product early — it decides what adjusters see and what limits ClaimCenter can enforce.

Beyond the suite

The same patterns connect the core apps to everything else:

Finance / GL

Batch extracts or messages of billed, paid and reserved amounts.

Payments

Outbound checks and disbursements by messaging; inbound bank and gateway results by API or file.

Documents

Document production and storage plugins for policy wording, invoices and claim letters.

Portals

Customer and agent front ends calling the apps' REST APIs.

Data & analytics

Change data feeds into a warehouse or data platform.

Third-party data

Address validation, vehicle data, credit and fraud scoring via plugins.

On Guidewire Cloud, the preferred inbound route is the product's REST APIs, extended with your own endpoints where needed, and outbound eventing can be offloaded to platform integration services. On self-managed installations you'll also meet SOAP web services published from Gosu classes.

Testing integrations

  • Stub first. Use the demo plugin implementations or your own mocks so each app can be tested alone.
  • End-to-end scenarios across PC, BC and CC: issue → invoice → pay → claim → payment; change → billing adjustment; delinquency → cancellation → reinstatement.
  • Failure tests: target system down, slow, returning errors, duplicate messages. Check that messages retry and nothing is lost or doubled.
  • Data lineage: for every field crossing a boundary, know the source system, the mapping and who fixes it when it's wrong.