Before I talk about the options that might be open to you, can you tell me what version of Service Desk you're running and also what specific aspects of the web you're not happy with please? I ask because Open Touch is not the API used for delivery through browsers outside of the product and I want to be sure you are being given the correct advice.
We are looking at upgrading to 7.4 - We would like to have more control on how self - service renders and specifically we'd like to build a Silverlight frontend to it. The rails type interface that is there right now seems a little clunky.
I hope that answers your questions.
I appreciate the response.
So at the moment, you're running which version please? It sounds like you are still using the old service portal which has been completely replaced with a new Web Access serviced environment. Also at this point in time, you should be looking to be upgrading to 7.5 not 7.4.
You are correct. We are currently on 7.3.2 but TESTING 7.4 we may go to 7.4 or 7.5 (is it feasible to go from 7.3.2 to 7.5 directly?). We HAVE looked at the new 7.4 webaccess and self service and would like to look at alternatives such as building our own silverlight frontend (for our end users). Analysts will continue using the Console app.
Ok. As far as the APIs are concerned, there is the API delivered though the web access layer to enable deliver of service desk into other web environments. This is not Open Touch. This would be the API you would use and is a standard part of the web access installation of Service Desk. I would, however point out some important things to consider. First and foremost if you choose to do this, any code work that you do would not be supported by LANDesk unless scoped and delivered in conjunction with our SI team. Second, by using this, especially for Self Service, you will remove the ability to utilise some of the key functionality delivered in Self Service such as Service Catalogue.
I would be keen to understand what the drivers are for considering such a large amount of additional work to deliver a completely separate web interface. It may well be useful to share those on the community to see what other customers have done to address similar challenges.
That is a fair question.
In our environment we put a premium on simplicity and user experience. Also we have the technical expertise to build front ends.
That is the motivation.
If I understand correctly, the webaccess app itself has some sort of undocumented API interface. What kind of interface is that and how can we get the information needed?
There is documentation available from which can be obtained through your account manager. Do you know who yours is?
Also, I'd still like to now more specifics on those ease of use issues. There are two reasons, first, I would like to be sure that you completely understand what the capability of the configuration of the web environment is and secondly because if you are experiencing these issues we need to know so we can address them in the product. The ability to deliver well structured and efficient solutions that do not require coding is a major driver for us and as such any situation where customers feel the need to go down the code path compromises that.
The front end decision is not mine primarily (my boss ). I am just looking at options to do so. Personally I am comfortable with the self-service web access but there are more things in the mix here.
I am trying to find out my Account Manager's name from my Systems Engineer (he is the primary contact). In the meanwhile, can you not help me and point me to the API docs? We will not be using any SI services for sure. In fact if I find from the Webaccess documentation that it is too much trouble, I will use database queries for inquiry and e-mail for updates.
We are currently using OpenTouch as we are still on 7.3.2 in production. Because we are currently stuck with ServicePortal for end users we decided to use SharePoint hosted InfoPath forms to add the flexibility into the forms that we required. This was simply down to accessibility which ServicePortal and WebDesk are not particularly kind to.
Although I have found OpenTouch to be a valuble asset, I have had to do additional work as OpenTouch cannot currently handle attachments. This meant that I have had to develop web services which sit in front of the OpenTouch web services. Less than ideal but it is very effective. It has allowed me to created plugins for Outlook to allow us to bypass MailManager (which we cannot use) and to create and closed tickets for system events in a similar manner that EventManager would provide.
I have recently been looking at the 7.5 incarnation and it looks to have had some updates, if only spelling corrections . I'm yet to test it fully.
Before we looked at OpenTouch I was asking around for information on the Web Access API but didn't get very far unfortunately. That and with being on a version which has now changed considerably OpenTouch seemed the only real option to us.
If you are going to ask about Open Touch, also ask about Event Manager. While it has the same limitation on attachments as Daniel has highlighted with OpenTouch, it is likely to be marketedly cheaper than OpenTouch and the manual is pretty good. There are some considerable differences in functionality between the two and hence getting your requirements straight would be important before your boss talks money.
Also ask specifically about Mashups available from 7.4 onwards. I think this is what Andy is alluding to and is available from 7.4 onwards as a standard feature. From the 7.4 release documentation mashups were produced to allow new processes to be logged, updated and displayed via an external application. Terrific news and might be all you need. However getting any documentation on how mashups works so you can use them requires you to invest in LANDesks SI services. Now that position on mashups might have changed, so it's worth checking. You could also consider encouraging LANDesk to supply mashup documentation so you can actually use it by voting here
We are also using OpenTouch on 7.3.2 at our location. Initially I found it pretty weird working with the XML-based "scripts" that you have to build, and I thought the example document was a little weak. They could easily have made that document twice as useful, but they did not.
<@Daniel Perry, I have found 7.5 OpenTouch to run my existing scripts just fine against an 7.5-upgraded copy of our production database. The method name changes startled me at first, but probably necessary since they finally fixed the typos in the original method names!>
My thoughts on OpenTouch are:
1) Once you understand the particulars of how to write an XML "script" it works well. (I don't deal with attachments.)
2) As OpenTouch is a web service using .NET 4.0 (for LDSD7.5) on IIS, you can easily set it up as a "Service Reference" in your .NET code, if you use that. Just point to the .asmx file and it will build the proxy in your code. Then you'll just create a proxy object and call your server-side XML script, passing an array of however many parameters that you have designed that particular script to accept.
The method looks like:
Public Function ExecuteScript(ByVal fileName As String, _ ByVal user As String, _ ByVal password As String, _ ByVal parameters As OpenTouch.ScriptRunnerService.ArrayOfAnyType, _ ByVal returnParameters As OpenTouch.ScriptRunnerService.ArrayOfAnyType, _ ByVal returnLog As Boolean) As OpenTouch.ScriptRunnerService.ArrayOfAnyType
So you might have (VB) code that looks like:
3. Insulated from changes
A. Originally I hoped that I would be able to avoid having to write every table and column name in my scripts, thinking that there might be some level of abstraction with a web service, to insulate me from changes made in the database, either on our side or by LDSD upgrades. Its not the case. You actually do have to specify the database name of each object and field that you wish to query or modify.
B. However, I have found so far that I HAVE BEEN insulated, and I have not run into the type of problems that I feared. We have other process developers make changes in our system, adding attributes, etc. and I've yet to have an XML script stop working. I just query the minimum attributes needed to accomplish my goal, and update the minimum number of fields, and so far I haven't been negatively affected by any changes. This is even true with the 7.5 upgrade. My existing scripts worked fine when moved over to a test OpenTouch 7.5 server, pointing to an upgraded 7.5 database. They have left a lot of the database schema intact for 7.5, so it looks like there won't be any (OpenTouch) work for me to do when moving to 7.5.
4. You might have some difficulty FINDING the things that you wish to manipulate in the database. Designing your OpenTouch script means digging in a tiny dropdown box and scrolling through ALL available attributes and recognizing the right one, which isn't always easy. I think because our process developers often create new objects by copying existing objects and renaming them, the stuff I'm looking for is sometimes tricky to find because I'll find them in there still having their "copied" names, not their "renamed" names.
5. You will find it terribly difficult to get any support answers on it. I have been told and seen for myself that questions about OpenTouch just seem to slide off the table and into the shredder. That is, you will just hear crickets chirping, and thats it. I have had support people say, "I didn't think any customers actually used that." They all consider it a tool that the professional services team might use, but not customers. I have a feeling that they specifically withhold helpful information because they would rather charge you to build something custom.
I hope that provides some useful feedback for you.
That is some great information. Just to cover your last point on support - OpenTouch functionality is supported however we do not provide support on its usage. It is true that the most common user is our own Pro Services staff for writing bespoke integrations but if an issue came up Support can investigate to make sure the functionality itself isn't at fault.
As per Andy's posts we are pushing peopole more towards the Web Access and Event Manager APIs because they are actively developed parts of the product and OpenTouch is not. However OpenTouch is still a valid option and there is no reason to move away from it if it works for you at the moment.
I hope that helps.
I have received a lot of very useful information. The main reason for my original query was, we are looking at building a dashboard that aggragates information from a few sources including ServiceDesk. This is why we need to get an API access to ServiceDesk. Opentouch seems to be a useful product but I have been unable to make any headway with Landesk about licensing it (I am not the primary contact at my organization) also it seems like it is being deprecated by Landesk.
I did figure out how to use the WebAccess API at least for inquiring. If you are developing in Silverlight or other .Net environment you may use WebClient to invoke the Urls and seek
client.Headers["Accept"] = "application/json";
That will return the "GET" call as Json serialized data that can be parsed and used.
What gets me is why this simple information is guarded so jealously by this company to its licensed users. There is no accounting for greed after all. I know of a few comapies that withheld knowledge for short term gains and paid for it dearly with reduced market share.
Whew!! That is my rant for this year.