I still think I would have liked the idea of seeing what the filter was creating in the backend as a SOAP envelop template. Obviously this does get stored in the DB as you can extract that envelope in the def. There must be minimal translations that go on before it gets into that def as if you edit that def as though you were editing a regular XML, and then import, the bad envelope gets fixed. So instead of ‘working from the outside’ it would have been nice if the dev studio had the ability to display that envelop and had a built in editor to be able to view and edit it if required..
Because that’s exactly what I ended up doing ‘from the outside’ using Notepad++... Joe From: Axton Sent: Tuesday, June 05, 2012 1:14 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... ** I don't believe the current design is flawed, it is just limited and should be expanded. Think of the types of things one should be capable of doing with web services in the following situations (which AR lends itself to): - publish simple services for outside applications to consume (e.g., return ticket details) - consume simple services from outside applications (e.g., zip code lookup) Now the current design can handle the above two scenarios for the most part, though the limitations Joe mentions are definitely... limiting. Now consider the way web services are used in a SOA implementation: - publish services to return complex constructs (e.g., incident, with relationships, with work log entries, etc.) - publish services to return lists (all open incidents, based on some search criteria) - publish services that accepts lists of data (e.g., create 20 incidents) - publish services that accept complex data (e.g., create a CI with relationships, work info records, incident relationships, etc.) In these scenarios, AR does not do so well. Now consider these scenarios: - drive the contents of a drop-down menu using data provided by an external web service - perform a lookup from an external web service using 1 of N filtering criteria, and handle the results in a way that are usable (e.g., search for a person based on last name and 20 results are returned) Whoever is driving the ship, I would encourage them to look hard at where SOA is going and how that fits into the AR and ITSM paradigms. There are a lot of things that I wish could integrate easily with ITSM through web services and it would be even nicer if ITSM could plug into a SOA framework in a way that immediately exposes the full capabilities of AR to the greater ecosystem of applications that relate to ITIL functions. The integration points have to consider the various user elements of how to consume and present information. If anything, I think that is where the current design is weak. Consider all the places where a web service could be handy: - search for data and present it as AR is accustomed to presenting lists of data (set fields list, table field) - present data in the UI (menus, type-ahead, tooltips) - and many more My 2 cents. Axton Grams On Mon, Jun 4, 2012 at 11:01 PM, Joe Martin D'Souza <jdso...@shyle.net> wrote: ** Apart from arrays which is an age old limitation with the way the AR System can handle data, there were other limitations discussed in the integration guide (unsupported constructs), which sometimes cause problems with some web services. I do understand that the limitation of arrays can only be addressed after the system is made capable of handling them, but there are other limitations that in my opinion could be addressed with the system in its current state. It is possible to overcome some of these limitations by tweaking the filters after they have been created and saved, which means that it is possible to fix these limitations. I could give you a specific example of a case I faced off the list if you are interested. I wasn’t dealing with arrays, but a single row transaction. The filter generated a incorrect SOAP envelop, which according to BMC Support was because of unsupported constructs used in the WSDL (which is documented on the integration guide). However it was possible to edit the definitions to modify that envelop and correct an incorrect namespace and resolve the problem. Personally I feel that the design on how the web service filters are created may need to be reviewed. A developer cannot see the SOAP envelop that the filter creates – he is exposed only the mappings. I think if a developer had the ability to ‘view’ the envelope (just like you can view the wsdl if when created in the developer), and tweak it if necessary, that would be one hell of an enhancement, rather than letting the app do what it does, even if that means it creates a bad envelop which results in a malformed request.. It would be nice to have the ability to ‘switch modes’ between advanced and basic when developing such workflow.. If this ability was available, I would not need to resort to a partially supported method of editing a def file and re-importing it into the system to make things work.. I’m just thinking aloud based on this one experience which I’m guessing will be quite a common experience when working with consuming external web services, given that the version of WSDL that the AR System can work with is about 5 years behind while most other systems that we generally interface with, work with the newer standards which I think is 2.0. Joe From: Easter, David Sent: Monday, June 04, 2012 10:39 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... ** For obvious reasons, futures can’t be openly discussed on a public forum, but I can say that web services will continue to be improved in future releases. The inability to interpret arrays is a known limitation that certainly is something that is desired to be addressed. There are, of course, other enhancements that we’ll be considering in the future as well. Web services is an important method for integrating applications because it insulates the calling application from version or structure changes in the target application. Because of this, it is a focus of the BSM solution and will therefore continue to receive attention and generate improvements. -David J. Easter Manager of Product Management, AR System BSM & Atrium Solutions Management BMC Software, Inc. The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Monday, June 04, 2012 2:50 PM To: arslist@ARSLIST.ORG Subject: Future of the AR System and Web Services... ** Does anyone know where this is headed to?? The current AR Systems capability or incapability rather to consume complex constructs limits a lot of what you can hope to do using web services. From hearsay, even version 8 does not have the ability to understand WSDL’s with complex constructs. Are there any definitive plans on when these would be reengineered to overcome these limitations? From my recent experience with attempting to consume complex WSDL’s, this incapability appears to be more superficial, than internal to the AR Server. It may be either at the Dev Studio level, or the actual WS plugin. It is actually in some circumstances possible to bend these limitations which shows that some of these limitations are not at the AR Server level itself. So that makes me wonder if it could be incorporated with just be a patch enhancement instead of planning it with a major release.. Also, does anyone know at what level is a WSDL interpreted when creating a Set Field filter action that uses a WSDL? Is it interpreted at the client level (dev studio) or server level (the WS plugin itself)??? What I mean to ask is when you enter the WSDL URI into the Set Fields action on a filter while creating a WSDL powered set fields filter, at what level does all the ‘magic’ happen? At the client side? Or on the server side?? I am trying to find if this is documented anywhere so if you have come across it please let me know where to look.. Cheers Joe _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
