Tessitura for developers — part 2, building the calendar page
How to better develop arts & culture business by becoming friends with Tessitura — the key software used in the industry
Part 1 is available here: https://medium.com/@jkubisiowski/tessitura-for-developers-part-1-d4c068f4e8f6
The goal of this article
I will walk you through a typical calendar page, present the underlying data model and show you how to fetch the data from Tessitura API to make your calendar page alive.
The calendar page
Most of cultural organizations websites contain the calendar page which is often the entry point to the checkout process (buying tickets online). It basically lists all the ongoing performances and events in a form of a calendar.
Let’s think about the calendar page as a product catalog in a standard e-commerce. It is a place where the user can browse through interesting products (performances and events).
There are two important features that should be available on the calendar page when it comes to selling tickets: call to action button and filters.
CTA button (buy tickets) should be available for each performance listed in the calendar in order to provide a quick way to the checkout process. It redirects the user to the select seats page. We are going to cover the select seats page in another article. Also a read more link should be available that redirects to the production page where the user can find all the details about the given production.
Filters that makes it easier to find the desired performance. Most popular types of filters are:
- Production season filter - shows only performance of given production season, for example only Romeo and Juliet performances taking place in spring 2020
- Stage filter - shows only performances taking place on the given stage, for example only the main stage
- Start date and end date filter - limits the performances within given time range
- Event type filter - showing events of a given type, for example only performances or only some specific event type that takes place at your organization
Data model
The underlying data model is fairly simple.
A performance is an instance of an event that happens on the stage at given date and time.
A production is work created by the cultural organization with the given title. Let’s image some theater that created a production Romeo and Juliet and is going to perform a set of performances of type Romeo and Juliet on given dates.
What is more, the performances can be grouped into production seasons — for example let’s group all Romeo and Juliet performances that happens in spring 2020 into a production season called Romeo and Juliet Spring 2020.
Tessitura API provides a set of endpoints to interact with productions, production seasons and performances. First step is to create appropriate model classes: Production , ProductionSeason and Performance. The respective objects of these types will be easily serialized and deserialized when doing API calls.
Before we move further we should get familiar with basic classes from Tessitura (they are part of our domain model). To simplify — snippets below contain only properties needed to understand the class.
Let’s start with the basics — the Production class is pretty self-explanatory.
All active production seasons are listed on the calendar page. Please note that ProductionSeason class has a property of type ProductionSummary instead of just Production. It is a simplified version of Production that contains just a few properties but they are usually enough to effectively work with the data.
An object of type Performance represents a single occurrence of the show with given:
- Date -
Date - Time -
DoorsOpenandDoorsClose - Stage -
Facility
A performance belongs to a production season and the tickets for given performance can be purchased between defined sales dates: DefaultStartSaleDateTime and DefaultEndSaleDateTime.
Fetching the data from Tessitura API
Now we should be able to populate the calendar page by performing an API call in order to to get all the required performances. We are going to use the following endpoint:
POST /TessituraService/TXN/Products/Search
Bear in mind that it needs to be a POST request instead of a GET request. The reason is fairly simple — we want to pass some complex object with filter definitions which is easier when sending it the request body instead of relying on URL parameters in a GET request.
This is how the filter object looks like (again — a bit simplified). Just pass the values of current filters to get only performances that meet the specified criteria.
The API is going to respond with a collection of ProductSearchResponse objects.
In the most basic scenario the returned result can be mapped to Performance objects and displayed on the calendar page. In more advanced cases we may want to get some additional data about each performance (for example information about ongoing campaigns or number of tickets already sold). We will cover these scenarios in later articles.
Summary
This article aimed to explain what is the purpose of the calendar page and how to feed it with relevant data. We got familiar with basic Tessitura model classes such as Production, ProductionSeason and Performance . Then we used the Tessitura API to fetch the filtered performances using POST /TessituraService/TXN/Products/Search endpoint.
Thank you for reading the article two of three from Tessitura for developers series (next article (part 3) is available here: https://medium.com/@jkubisiowski/tessitura-for-developers-part-3-designing-the-select-seats-page-5cca1ba7640b ).
Please let me know in the comments which topic should I cover next. Also — don’t hesitate to write me an email, I promise I’ll answer all of them!(jakub.kubisiowski@gmail.com)
