Functional Overview

As depicted in the diagram below, with Ticket Exchange integration in place customers and partners may initiate support tickets directly from their helpdesk systems to Microsoft Support. Once a support ticket has been initiated and linked through the platform, either party may communicate ticket updates to the other party.

Core Concepts

It is important to gain an understanding of the following core concepts.

Central Integration Hub – The Ticket Exchange Platform (TEP) serves as a central integration hub for all integrated parties. This allows all parties to have just one single integration point while gaining access to communicate with all other integrated parties.

Common Message Format – A common set of flexible message structures are used for communication with the platform and internally within the platform.

Conversation Types – Communications between parties are governed by a conversation type. The conversation type defines roles and the data which can be passed between roles. Generally, a customer or partner integrating with the platform will use the same conversation type and role consistently.

Conversations – A ticket exchange conversation is established when a party initiates it by sending a ticket message for a ticket which is not already involved in a conversation. After the message is processed and delivered to the receiving party, a new conversation is established, and updates can now flow in both directions. A conversation is always of a particular conversation type (described above).

Message Transformation – One of the key jobs of the ticket exchange platform is to transform data provided in an inbound ticket message to create an outbound ticket message which meets the needs of the receiving party. These transformations are driven by configurations called transformation maps. Some of these maps are defined as part of the conversation type and others are defined for each integrated party at the time of onboarding.

Canonical Message – All ticket messages sent to the platform are transformed to use the canonical terms which are defined for the conversation type. This allows the inbound message to be sent to any integrated party which supports the conversation type.

Message Types

There are three different message types used for ticket exchange:

Ticket – The ticket message communicates incident data, and is used for the following.

• Incident Escalation – Establish a new ticket conversation

• Bi-Directional Updates – Provide updates to an existing conversation

• Addition of Parties – Add an additional party to an existing conversation

Attachment – The attachment message is used to move file attachments between the ticket exchange platform and integrated parties.

Receipt – The receipt message is used to report delivery status back to the sender of a ticket message.

Interaction Model

The diagram below depicts the basic interaction model used for ticket exchange. This model includes 4 separate steps:

1. Receive Inbound - Sending party sends a ticket message to Ticket Exchange Platform (TEP)

2. Process - TEP processes the inbound message and prepares an outbound message for the receiving party.

3. Deliver Outbound - TEP delivers the ticket message to the receiving party.

4. Report Result - TEP sends a receipt message to the sending party to provide information on status of deliver (success, failure, delay, etc.)

The diagram below shows the same basic interaction model which has been expanded to include attachments.

1. Receive Inbound - TEP receives the following from the sending party:

   1. Attachment(s)

   2. Ticket, including references to previously sent attachment(s)

2. Process - TEP processes ticket received from the sender and prepares a message suitable for the receiving party.

3. Deliver Outbound – TEP delivers the following to receiving party:

   1. Attachment(s)

   2. Ticket, including references to previously sent attachment(s)

4. Report Result - TEP sends a receipt message to the sending party to provide information on status of deliver (success, failure, delay, etc.)

Integration Options

The table below defines currently available integration options for each of the three message types. Integrating parties must select a method for each message type and direction combination.

Integration Example 1 – Push/Push Model

In this example, the integrating party exposes web services to receive ticket, receipt, and attachment data from TEP. Calls are made to TEP web services to send data. This is the preferred integration approach because it allows ticket data to move as soon as it is available.

Integration Example 2 – Push/Pull Model

In this example, the integrating party is not required to expose any new web services for ticket exchange. All interactions with TEP are done by calling TEP web services. The PostTicket() and PostAttachment() web services are called to publish ticket data to TEP. The GetTicket(), ReportTicketResult(), GetAttachment(), and GetReceipt() web services are called to retrieve data. (In this scenario, GetTicket() and GetReceipt() must be called recursively.)

Integration Example 3 – Mixed Model

In this example, the integrating party has chosen push model for publication and mixed model for subscription. PostTicket() and PostReceipt() web services are exposed to receive tickets and receipts, while calling GetAttachment() to retrieve attachments.