New in our Service Communicator XPages application: displaying Trouble Tickets, getting Tickets via Webservice from any external system

Note: this post has been migrated from another blog. Some links may be broken.

Since we were a software development AND a service company we have a trouble ticket software, just as every other professional service company has. (Our trouble ticket software is a product of our own for sure, but that doesn’t matter here… 🙂 ).

So one big item on our todo list for
Service Communicator was to provide our customers with a list of their tickets in the web, so that they can have a look after the status on their own. Futhermore we wanted to give our customers the possibility to create comments to tickets, and to express their mood (if someone is happy or sad, we want to know that).

Having tickets in Service Communicator has the advantage that we don’t need to expose our trouble ticket software to the internet. We just sync tickets to Service Communicator, and customers view their tickets in Service Communicator, not in the trouble ticket software.

Our trouble ticket software is Notes based, and Service Communicator is a Notes application, too. So, synchronisation is piece of cake, isn’t it?

Yes and no. Yes, it would be easy if we use Notes techniques to transfer the data (like a simple LotusScript agent). But we didn’t want that. Service Communicator should be used by Non-Notes shops, too!
So we needed a way to push data of trouble tickets from any external ticket software to our Service Communicator.

I think the best approach for that is a webservice, and we are quite happy that Lotus Domino supports webservices so well, even with authentication and SSL encryption. We simply used LotusScript to implement an easy to use webservice provider which has just one method:

setTicket(key As String, values() As ynScValue)

where “key” is a key to identify if a ticket already exists in Service Communicator, and values() as an array of field values. One value contains:

name As String

value As String

type As String

with name as the name of the field, value as the string value and type as the field type (so that we can set datetime, number and text fields).
At this moment we have a defined list of mandatory fields and some optional fields. The beauty of this approach is that we can always add optional fields later while every existing webservice consumer can stay as it is.

Inside Service Communicator we’re working with reader fields to ensure that every customer only sees his own tickets, and other users cannot see any tickets at all. Think about implementing such functionality without the Domino security features… for example with PHP or so. Would be much more work I guess.

So far were quite happy with this latest addition to Service Communicator. I really like webservices in Domino, and we will use webservices for many other features in the future, too.

Comments are closed.