I've been building my own remedy tools using the .net API for a number of years now and there are days that I can't get by with out some of them.
A lot of things can be done faster in a third party app than within remedy itself. With a new customer we are working with, we had nothing but trouble trying to get the web services to work. We finally got it working after hacking the wsdl file being used. We have another integration that they are needing and were cringing at the thought. As John mentioned, the web services are version 1, which is what, 10 years old. With BMC moving to a web based only format, I thought we would have already seen a total rewrite of this section of the code. I love the ability to quickly throw an application together to do a complex set of tasks in remedy or pull/update anything in the system. If I have a complex block of remedy workflow to add, I plug it into my template builder and it builds the remedy workflow for me. You can't do that with web services. DevStudio just takes to long to get the job done sometimes. Anyways, I hope to see the .net API continue to be available in future versions going forward. Brent... Sent from my Apple device... On 2012-05-10, at 3:09 PM, John Baker <[email protected]> wrote: > Hello > > I guess I'm slightly bias, as I'm one of the founding members of Java System > Solutions, and we quite like Java :-) However, .NET isn't some kind of > obscure development platform - it's infinitely bigger than AR System - and if > one is going to integrate with other platforms, picking two of the biggest > seems to be a fairly smart plan. > > It's easy for BMC to say, "just use webservices", but that's not always the > answer. Webservices are not really the answer for many types of integration > (ie when we want guarnateed delivery), and the AR System webervices are not > modern. Indeed, I think - correct me if I'm wrong - that the AR System > webservice plugin is still using a decade old version of Axis (and the plugin > crashes a lot, too). > > The JSS XML Gateway product has been used - and I add, at no license cost in > some cases - to build integrations between products with plain XML, often > sitting between .NET and AR System. However, one could of course build their > own little XML integration tool. The benefit of such an approach is that > plain XML is popular, simple, and XML over HTTP ('REST') is easy to implement > in .NET/Java/Javascript/etc. > > Webservices are supposed to define standards and to an extent, they do, but > vendors tend to endulge in their own intepretation of a standard. There are > plenty of people who've tried consuming a .NET webservice from AR System and > had little success. Sure, the simple webservices may work, but start thinking > about lists, wsdl includes, overloading, etc, then you're stuffed. And I'm > afraid to announce that many 'enterprise' systems will be using lists, > schemas, includes, etc. > > Any standard that's open to interpretation is going to give you a headache, > and when implementations are constantly evolving (check out the Apache CXF > product, which has popular mailing lists and frequent releases), it's obvious > that the technology is moving quickly. > > > John > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
