PolicyCenter and billing system asynchronous communication flow

The following steps show the high-level flow within PolicyCenter for asynchronous communication of a new submission to a billing system.

1. A policy period binds.
2. The submission process adds CREATEPERIOD event to the database transaction.

   In the file SubmissionProcess.gs:

   _branch.addEvent( BillingMessageTransport.CREATEPERIOD_MSG )

3. As PolicyCenter tries to commit the policy period’s bundle, the Event Fired rule set fires.
4. The Event Fired > Billing System > Policy Period > Bind Period rule detects this event and creates an event message.
5. The event message is put into the messaging send queue in the same transaction as the change that triggered the event (the submission).
6. PolicyCenter in a separate thread pulls a message and delivers it to the BillingMessageTransport plugin, which is a MessageTransport plugin.
7. The messaging transport (in BillingMessageTransport.gs) calls out to the billing plugin.

   case CREATEPERIOD_MSG:
     ...
     plugin.createPolicyPeriod(policyPeriod, getTransactionId(message) + "-2")
     break

8. The currently registered implementation of the billing plugin (IBillingSystemPlugin) handles the request. PolicyCenter includes two implementations of this interface:
   • For demonstration purposes whenever a billing system is unavailable, the class StandAloneBillingSystemPlugin implements this interface. This implementation does nothing with the billing information and pretends that a billing system is attached.
   • For the real integration with BillingCenter, the class BCBillingSystemPlugin implements this interface. See the Gosu file BCBillingSystemPlugin.gs for this code. Wherever this documentation refers to the PolicyCenter side of the base configuration BillingCenter integration, this class and its related implementation typically implement this behavior. This class does not handle all integration tasks. For example, PolicyCenter handles some behaviors by using web services that PolicyCenter publishes.
9. In the createPolicyPeriod method, the plugin handles the request by calling web service (SOAP API) calls on BillingCenter:

   override function createPolicyPeriod( period: PolicyPeriod, transactionID : String) : String {
     var issuePolicyInfo = new IssuePolicyInfo()
     issuePolicyInfo.sync(period)
     var publicId = billingAPI.issuePolicyPeriod(issuePolicyInfo, transactionID)
   
     return publicId
   }

10. PolicyCenter calls its billing plugin method createPolicyPeriod, which would do different things for different billing systems. In the BillingCenter integration, PolicyCenter integration code constructs an IssuePolicyInfo object that is specific to web services that BillingCenter publishes. These SOAP objects are not Guidewire entities. The web service implementation on the BillingCenter side transforms this SOAP-specific object into what it calls a billing instruction. BillingCenter uses these billing instructions to track charges and instructions from the policy system.

@Throws(AlreadyExecutedException, "if the SOAP request already executed")
@Throws(BadIdentifierException, "If a policy already exists with the given number")
function issuePolicyPeriod(issuePolicyInfo : IssuePolicyInfo, transactionId : String) : String {
    var publicID = tryCatch( \ -> {
    var issuance = issuePolicyInfo.toIssuance()
    var bi = BillingInstructionUtil.executeAndCommit(issuance) as Issuance
    return bi.IssuancePolicyPeriod.PublicID 
  }, transactionId)
  return publicID
}