The Ticketer and eBonding

We receive a CREATE request from the carrier via SOAP. This is processed first through the soap_component, then through the ebonding_component where business logic is applied to build the message. This message is then sent on to the Ticketer. RabbitMQ is used to pass these messages between the applications.

The CREATE request is processed by the Ticketer by parsing the JSON string which is received from the ebonding_component. At this point the Ticketer will create the Ticket with those values and populate the eBonding form. It should be noted that the Ticketer is almost entirely unaware of specific eBonding logic, this is all passed to it via the ebonding_component.

This work is all completed via the CreateMessageHandler in the ticketer codebase. This uses the incoming message taken off of the queue to populate a Ticket object and a FormVO object.

Assumptions:

• The user who is marked as the ticket creator must be created in the Ticketer prior to the CREATE message being received.
• The workflow must be created in the Ticketer prior to the CREATE message being received. The workflow which is being used with eBonding is currently Extenet DAS Alarm workflow.
• If a visibility cannot be found in the incoming message then the creators primary visibility will be used to populate the ticket.
• If a priority cannot be found in the incoming message then the default priority of the ticket is set to 2-High.
• The ticket is placed in the start node status of the assigned workflow, which in this case is Alarm Received.
• The eBonding form is populated from the incoming message.

A read query is then run against the ticket that is saved from this incoming message. The results of this query are used to populate the response message which is placed back onto the queue from the Ticketer as a JSON map consisting of the keys “ticket” and “form”.