RabbitMQ, The Ticketer & The Footprints Component Interaction

— Anna Dowling 2018/02/23 05:34

1. Ticketer
2. RabbitMQ
3. Footprints Component

The Ticketer function within this integration reuses the AuditProvider Attribute Value Change(AVC) functionality in order to monitor for the status change events needed to trigger the email in the footprints_component. As this process has already been documented in relation to the eBonding project, for further details on how this works see the following wiki entry: The Ticketer and eBonding

Details to Note:

1. The booleans footprints.enabled = true and gormListener.enabled = true need to be set in the TicketerConfig.groovyfile for this process to work.
2. RabbitMQ credentials must be set in the TicketerConfig.groovy file in order to connect to rabbitmq and create all queues, exchanges, bindings.
3. Update events only are being monitored for AVC's on the Ticket domain: updateDomains = [“com.errigal.ticketer.Ticket”]
4. The trigger statuses for the email generation are FOT Dispatched and FOT Dispatched - Pending parts currently.
5. The update which comes back to the Ticketer contains the Footprints Global Ticket Number which gets populated on the Field Technician Dispatch Form on the ticket which sent the audit event.
6. The process handles the scenario in which a ticket is apart of a group. In this case the update will only occur on the parent ticket. If the parent is recalculated due to the SLA process i.e. the parent is now a child ticket, then the update will be received on the new parent ticket of that group.

TicketerConfig.groovy Additions:

// footprints
// Parameter to turn on or off the footprints functionality [true | false]
// Default to false to avoid looking for the RabbitMQ and failing to start
footprints.enabled = true
//Determines event types which are auditable via the gormlistener
auditableEvent {
  domains{
    updateDomains = ["com.errigal.ticketer.Ticket"]
  }
}


 //ensure this is enabled
gormListener.enabled = true

  // The queues which need to be declared.
rabbitmq {
  credentials {
    username = 'rabbit_footprints'
    password = '#rabbit321!#'
    host = 'atclb1'
    virtualHost = 'footprints'
  }
  queues {
    //Incoming Message
    ticketerInboundQueue = 'ticketer_inbound_queue'

    //Outgoing Message
  }
  exchanges {
    //Incoming Message

    //Outgoing Message
    ticketerAuditEventExchange='ticketer_audit_event_exchange_topic'
  }
  tags {
    //Put the tags used for exchanges here
  }
  bindings {
    //In the Form "QUEUEMAME::EXCHANGENAME::TAG"
    //Incoming Message
    //Outgoing Message
  }

  numberOfTriesBeforeFail=1
  numberOfSecondsBetweeTries=1
  numberOfSecondsToWaitForRabbitReconnect = 30
}

RabbitMQ acts as the message broker for passing messages back and forth between the Ticketer and Footprints Component. This was chosen in order to leverage the AVC development within the Ticketer application

The RabbitMQ setup is handled in the bootstraps of both applications (footprints_component and ticketer). All credentials are available in the resepective grails configuration files for those applications.

• The TicketerConfig.groovy additions for this are detailed above.
• The FootprintsConfig.groovy details are linked here: Configuration File

Details to Note:

1. The Ticketer pushes out the AVC JSON messages onto the following exchange: ticketer_audit_event_exchange_topic
2. The Footprints Component consumes the footprintsOutboundQueue: footprints_outbound_queue
3. This queue binds to the Ticketer Audit Event Exchange (ticketer_audit_event_exchange_topic) with the following routing key to receive the audit event updates from the Ticketer: com.errigal.ticketer.Ticket
4. Valid Updates to the Ticketer are published onto the ticketer_inbound_queue via the Footprints Component. These are then processed as normal via the UpdateMessageHandler class.

The Footprints Component is used in the context of a MicroService in order to act as a go between for all logic required to connect the Ticketer and the ATC Footprints Application. The goal is to send and receive email via this application in order to create the ETA dispatch ticket and receive updates.

Details to Note:

1. The email generation process is kicked off once a valid status change event is received from the Ticketer via RabbitMQ.
2. We also poll the mailbox for responses from ATC containing a global ticket number mapping to the Footprints ticket and a valid Errigal ticket id in order to update the IDMS ticket.
3. This poll generates a TicketUpdate which is formatted and pushed out to RabbitMQ in order for the Ticketer Application to receive and process into a form value update.