Would anyone like my Tessitura REST API abstraction layer?

Hello,

So I have built several applications (in c# .net) that utilize the REST service layer for Tessitura.  In order to facilitate these projects, over time I have built an abstraction layer (C# Class) that I use to isolate the code that interacts with the REST service layer, from my project code that implements the specific application I am trying to develop..  These projects include both web applications and windows forms applications.

If you are new to software development against the Tessitura REST API, or just new to C# .NET development in general, you might find it useful just to see how it works.   Personally, I had a very hard time at first dealing with the REST service layer, and I imagine if I had something like this to look at back then it would have made things a lot easier.

What I would like to do is release it to folks to see if it will stand up to the scrutiny of other developers (I am sort of a 1-man island here), and also to see if folks might improve it or expand on it.  I am also open to suggestions.  Perhaps if enough people are interested we can officially open-source the thing and have several developers add to it over time.

For now I just compile the source directly into my code.  This makes it simple for debugging and expansion.  I have not attempted yet to create a standalone assembly out of it, although I imagine that will be where it goes eventually.   I built this to support my own projects, and as I copy it from project to project I expand its capabilities with new functionality.   Every once in a while I just copy the newest code back to my older projects to make sure that it maintains backwards compatibility (it almost always does, although I find I need to include more references as I use more of  the .NET framework within the code).

I build the class (and related references and dependencies) into my project, instantiate the class, and use it for all my Tessitura database interactions.     The mail goal here was to simplify the REST service layer, and to reduce the amount of code I would need in my projects since I would be handing off all the DB interaction and Tessitura specific stuff to the abstraction layer.   Indeed if you look at the sample projects (more on this below), you will see that there is not a whole lot of code there.    The layer passes back entirely new structures and data, and so my main application project code does not depend on the REST object classes provided by the Tessitura rest client library at all.   This simplifies things but does not provide the full-featured data that the REST service layer provides natively (I am going for simplicity here).

So because of the simplicity, and also because I have only implemented 40-ish of the many rest service calls available, the abstraction layer is probably not going to work for you 100% out of the box, since chances are your application is going to need some different REST calls, or even different data from within the implemented calls.   That said I think the coding structure for the abstraction layer is in place to make it dead-simple to add whatever else you need to support your application, no matter what it is doing…   The calls to the REST service layer itself are funneled through a single method, which you will most likely never need to touch.

So another thing I can do is not only share the source for the abstraction layer itself, but I can also share some projects that utilize it which you could probably get to run in your environment, so you can see a fully working sample project run all the way through.

Here are two of these:

Application 1: A seating reservation portal that the dinner theater can use down at the restaurant.    This is a web based application that a restaurant staffer can use to reserve seats within Tessitura for the various times of the evening.  The application creates an order in the system, seating within the time slots (zones) for the evening (performance) under the patron account (if it exists) or under a reservation name in the house account (if patron doesn’t exist).

Application 2: A simple windows forms application to develop and test order confirmation templates using the new Tessitura RAZOR based template system.  Since I find it a bit easier to use Visual Studio over the Tessitura built-in editor to create and test my templates, I built this application to read in the template source from the file system and execute it against an order in Tessitura using the Tessitura template render calls and display the results in the embedded browser.  This makes the development/testing cycle of the order confirmation templates I have been creating much faster and more convenient than using the built-in editor for that work.

Ideally, you would be able to get these applications to work in your environment with minimal set up, although to get them to work we may need to wade through a couple of dependencies.  Since I do not have these things really packaged that well for the sake of distribution, it may take a few attempts to get these to work, but in the end they should work without source code modification (I try to put all the organizational specific stuff in the .config files).

I have a few other applications as well, but I am not sure how well they will translate into other Tessitura environments.  One of these includes an order integration piece that processes order and exchange data from a foreign box office and brings those into Tessitura for use by the main organization.  This one probably utilizes the abstraction layer more than any of the others, but it is a current work in progress and probably won’t work in another Tessitura environment without some major modifications.

Anyhow, I can go on forever about how this works and what it does, and I have rambled on enough.   If you think you might be interested in utilizing (or just reviewing) my abstraction layer, just get in touch with me and I will set you up.

Let me know, and thank you for your interest

… Howard