Hello Tessitura Wise Collective,
I built a ticket design and put a mask on an element it looks like this.
The code we tried in the Mask field (we tried the if statement and the case statement)
If(upper(val) = 'PRESENTS', 'CARNEGIE HALL PRESENTS', val)
Case(val When 'PRESENTS' Then 'Carnegie Hall Presents' Else val)
when we do an API call we get the text in Production Season 1 value instead of the replaced logic.
This is the API call we use (with a given order).
ttgateway2svc.corp.carnegiehall.org/.../PrintTicketElements
this is the body we put in (where we specify the ticket design we are using and the sli number that corresponds to the order
and the result we see
Maybe this counts as an "insight", but I believe the reason for this is that the mask syntax is actually from PowerBuilder. That means that the code which parses your mask expression and produces output lives only in the Tessitura Client (and in the Tessitura Processing Service, which sits next to a copy of the client executable so that it can run InfoMaker reports and produce PAHT tickets). The API Service is a .NET application, and does not include PowerBuilder or reimplement the PowerBuilder expression engine. That's why your API response includes the mask -- it's basically leaving it to the caller to apply the mask to the presented value.
I don't disagree that it would be really handy if the API services did reimplement the PowerBuilder expression engine, but that is probably too much effort for too little outcome to be included in the roadmap. (Maybe it could be a community effort to reimplement the PowerBuilder expression engine so that your application could apply the mask to the value by itself?) The replacement technology for this sort of thing in Tessitura is actually HTML Templates, since their syntax is parseable by the API services. I think that means the recommended direction for new development is to leave the ticket designs to physical tickets only, and use HTML template designs for PAHT or virtual tickets.
Hello Nick Reilingh Thank you for the reply.
Let me ask the question differently then - if I want to use Tessitura native API without coding anything extra - we are pulling elements from Tessitura performance fields - we can't touch the fields themselves and we are avoiding custom code - thus the Native API call. We thought add a mask to return logic that says if the field = 'A' return ABC if the field <> 'A' return the field as it is. An if or case statement which we are trying to accomplish.
This approach seems to be a no go, are there any other suggestions of using Native API calls in Tessitura that can pull elements in Performance set up with some if/case logic on top of them.
Thank you again for your reply. -Lisa Rudnitsky
I'm not quite clear on how you are calling the API if you are avoiding custom code -- is this an existing vendor application that is calling the API? If not, and if you have to make do with the fields that you have, then the place where you should switch out the "PRESENTS" value would be in your own software calling the API. The only way to do this at the API layer without touching the database or API-consuming application would be a service interceptor (more custom code).
If I were in your shoes, I would perhaps look to using a production elements content type to be treated as an "override" value when it exists. Content type values can be retrieved via the native API, but then the caller still has to implement the fallback functionality. I've implemented that pattern both in HTML templates (from API results) and in custom ticket design elements in SQL. The benefit there is that you aren't hardcoding any values in your custom code, you're just defining some business logic that you can utilize whenever necessary.