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"
