Table of Contents

eBonding Domains

Author : Colm Carew
Date : 2017-02-01

Customer

The purpose of this domain is to store information about a customer.

  String name - This is the Customer Name
  String ticketerUser - This is the Customers Name within the Ticketer
  String ticketerWorkflow - This is the Workflow we want all the 
  String ticketerFormTableName - This is the form database name we want associated with the customer i.e. f_ebonding
  String ticketerFormPublishedName - This is the published form name we want associated with the customer i.e. eBonding
  String communicationType - This is the communication method we use to contact the customer e.g. 'soap'
  CustomerMessageResponseTemplate outgoingMessage - This is the Message Template we use to construct messages going to the Customer
  String closeStateTransition - This is the close state to move a ticket to if the customer closes the ticket
  String revertStateTransition - This is the open state to move a ticket to if the customer rejects a ticket close
  
  messages: CustomerMessage - These are the incoming messages that are associated with a Customer i.e. their create and update messages we may receive
  elements: AllowedElement - These are all the elements that the customer has and that are allowed to proceed to create Tickets for a customer
  formChanges: FormChange - These are the form change updates the Customer is subscribed to such that we may get an update of a field we do not want to send out to a customer thus we only subscribe to the ones we want
  

AllowedElement

The purpose of this domain is to track all Circuit IDs which are allowed to progress through the eBonding system

  String circuitId - The circuit ID
  NetworkIdentifier networkIdentifier - The Network Identifier
  String hubClli - The Hub Information
  String nodeId - The Node ID that the circuit belongs to
  String customerNodeId - The Customer Node ID that the circuit Belongs to
  Long fiberStrands - The number of fiber for that circuit
  Visibility visibility - The Ticketer visibility that the Circuit ID is in

  static belongsTo = [customer: Customer] - An element belong to a customer

FormChange

The purpose of this domain is to track what form changes we want to notify the customer about.

  String formName - The name of the form e.g. 'DAS Alarm'
  String formVariable - The form variable name e.g. 'carrier_update'

CustomerMessage

The purpose of this Domain is to track all message that a Customer can send to use.

  String name - The Name of the Message e.g. 'VerifyRepairCompletion'
  CustomerMessageResponseTemplate response - The template response used to generate a customer response
  
    static belongsTo = [customer: Customer] - a message belongs to a customer
  static hasMany = [mappings: CustomerMessageMapping] - mappings are used to pull information from the incoming XML message

Due to the limited configurability of Soap and not wanting to use groovlets the specific names of what messages are supported can be seen in the MessageHandlerFactory.groovy class

CustomerMessageMapping

The purpose of this domain is to store XPaths which are used to pull information from the Incoming XML of the Customer Message.

  String errigalKey - what we want the errigal key to be i.e. if its ticket_id or circuit_id
  String customerXPath - this is the Xpath location of the information
  CustomerMessageMappingField associatedField - This determines whether the errigalKey is a ticket field or form field
  
  static hasMany = [transformers : CustomerMessageMappingTransform] - A value from the customer may not be the same for us such that a priority of 5 to them may mean a critical where as to Errigal a 1 is a critical so we have to Transform the Customer value to an Errigal Value

CustomerMessageMappingField

Determines what part of the system information belongs to e.g. Ticket or Form

  String fieldName - The field data should belong to i.e. 'ticket' or 'form'

CustomerMessageMappingTransform

The purpose of this domain is to store a customer value and what it would be as an Errigal value i.e. transform a 5 to a 2 or a 0 to 'Circuit Down'

  String customerValue - the customer value i.e. 5
  String errigalValue - the errigal value i.e. 1

CustomerMessageResponseMapping

The purpose of this is to find an Errigal value from an outgoing map (which can be seen in the logs when a message is being sent out) and place it into the response message.

  String replaceMe - The string that will be replaced in the outgoing message
  String withThis - The errigal map key i.e. ticket_id or circuit_id
  DateFormatter formatter - Incase the outgoing value is a date and the customer needs it in a specific date format

CustomerMessageResponseTemplate

This domain is used for storing the overall template of the response message.

  String name - the name of the response template
  String templateResponse - the response template
  
  static hasMany = [subTemplates: CustomerMessageResponseSubTemplate] - for lower level control of the outgoing message a template can have many subtemplates like various exceptions and the normal case

CustomerMessageResponseSubTemplate

The purpose of this Domain is to give finer grain control over the response we can send back to a customer. Place close attention the the value of name. If a Template Message hasMany subTemplates starting with the name REPLACE, that is okay as it will replace all of these. A Template have also have many subTemplates starting with the name INJECT_. This is where DSL (Domain Specific Logic) comes into play. Essentially only 1 INJECT subTemplate will ever be used in a response, so various exceptions will be INJECT sub templates where as items that will always be in a message response such as Message ID would be REPLACE items.

  String name - can be REPLACE_SOMETHING or INJECT_SOMETHING
  String template - The template that will be place into the outgoing message. Note this Domain has mappings which will populate the outgoing data
  
    static hasMany = [mappings: CustomerMessageResponseMapping] - the mappings to obtain the outgoing data

DateFormatter

The purpose of this is to format an outgoing date in a desired format i.e. “yyyy-MM-dd'T'HH:mm:ss'Z'”

String format - the outgoing date format

ReceivedMessage

This is a simple Domain which is used to track messages we have received. It does not track the entire body of the message (would be a lot of data to store)

  Customer customer - who sent the message
  String messageId - the message id of the message
  String messageName - the name of the message e.g. VerifyRepairCompletion
  Date dateCreated - the date we received the message

SentMessage

This domain tracks the messages we send back to the customer

  Customer customer - the customer we are sending the message to
  EbondedTicket ebondedTicket - the eBonded Ticket if there is one
  String messageName - the name of the message we sent
  Date dateCreated - the date we sent the message

Not in this case the id of the sentMessage object is the message id we use for outgoing messages.

EbondedTicket

This domain tracks tickets that we created via eBonding

  String ticketId - the Ticket ID in the Ticketer
  Date createDate - the date the ticketer ticket was created
  Date updatedDate - the last date the eBonded ticket was updated
  Date closedDate - the close date of the eBonded ticket - set back to null if ticket is reopened
  AllowedElement element - the circuit id belonging to the ticket
  String workflow - the workflow in the ticketer
  String summary - the summary of the ticket in the ticketer
  String visibility - the visibility the ticket is in the ticketer

NetworkIdentifier

The purpose of this domain is to track the network identifiers. A domain was created to eliminate redundant data as many circuit ids will have the same network identifier.

  String name - the network identifier name

Visibility

The purpose of this domain is to track the visibility a network identifier should be in the Ticketer, i.e. what Visibility the Ticket will be created in the Ticketer.

  String name - The visibility name i.e. 'CA - AT&T'