I just submitted another RFE <https://communities.bmc.com/ideas/3589> that I had meant to submit months ago but didn't know where to :-). This is an RFE around WSDL Operations <https://communities.bmc.com/ideas/3589> .
For your convenience I have copied the entire contents of the RFE <https://communities.bmc.com/ideas/3589> here so if you find this worthwhile, please visit the community using this link <https://communities.bmc.com/ideas/3589> and vote for it. https://communities.bmc.com/ideas/3589 Background: Over the past couple of years I have somehow managed to get a few projects that revolved around both publishing and consuming WSDL's. This particular RFE that I would like to propose is around operations contained in an AR System WSDL that is published to be consumed by host systems. Currently when a host system consumes a AR System WSDL, the AR System's Filter mechanism has no way of recognizing what operation from the list of operations defined in that WSDL, were used by the host system. Not unless you build something custom as described in the workaround below. So it becomes a little hard in case you want your Filters to evaluate data based on which operation was responsible to feed it in. Current Workaround (that I use): In the absence of a built in function (perhaps in the form of a KEYWORD) to recognize the operation that was used during the consumption of the WSDL, the AR System developer, has to create a field in on the AR System form that is exposed to the WSDL, and set that field to a value that a developer could use to identify which operation was used. The WSDL element that is exposed and mapped to that field in the Input Mappings, has to be defaulted to a value agreed upon by both the WSDL developers and its consumers. Limitations of the Workaround: While this workaround seems feasible and almost airtight when used internally within the corporate network, it falls apart if you expose the WSDL to hosts outside the control of your corporation or environment (public WSDL on the internet). When used internally, the various teams interacting with that WSDL could be made aware of the use of that element and the legal value it must contain, it is hard, probably impossible, to maintain that kind of control once you have to expose your WSDL to the outside world. Also, in at least one version if not more of the AR System, there exists a problem with the defaulted value defined for the element created for that field, may not stick with the element by the time the WSDL is published. I have had mixed results with 7.6.04 Patch 003 and 004, where at times it sticks with it and at times it looses that default value. Besides the defaulted value means nothing if while consuming that WSDL, the host system decides to write a random string into that element. Due to the nature of how WSDL's work, the host system could write any other legal value into that field. It becomes an administration nightmare (and embarrassing) to explain to all other developers of other host systems that the AR System is incapable of understanding what operation they just consumed unless they hard code that operation value into that exposed field because the AR System is simply not able to recognize what just happened at least as far as what operation was just used. Justification: Since the only feasible workaround to address this problem has an obvious weakness (wrong value input in that field), I was wondering of the possibility for the AR System WSDL mechanism to be given that ability to set that value internally using an internal mechanism. Ideally the name of that operation should be used to recognize which operation from the WSDL was used. Cheers Joe _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
