Re: Future of the AR System and Web Services...
Not ever using ITSM (I have always used pure custom Remedy) I am guessing some here The Related Items section could be from separate sub-forms or if you know there are always the 3 you could use an On-Get filter to pull the data into temporary Display Only fields. I would assume the Work Information is from a sub form so you would map the sub form to the Info_id element to get the ID INC1234 CI 12345 work_order 9874 incident 654 1 2 3 4 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Tuesday, June 05, 2012 11:21 PM To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... ** I do not think you can do that directly at least.. you would need two different web services, one get list that returned a single get entry, and another a get list that returned a get list. Wouldn’t be able to do it in a single WS function Joe -Original Message- From: Axton Sent: Tuesday, June 05, 2012 4:14 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... ** Maybe I am missing something then. How do I go about creating a web service that provides the following information (for arguments sake, let's say that it takes an input parameter of incident id): Not necessarily in that exact format, but containing that type of content. I was able to do those kinds of things with JSS XML Gateway, but not with the native Remedy web services. Axton Grams -Original Message- On Tue, Jun 5, 2012 at 1:08 AM, Grooms, Frederick W wrote: Axton, I have created services that accept lists of data for creation of data. Instead of mapping the primary form to the root you map it to the first element (just like you map a sub-form to a service). I have also done ones that return lists and complex constructs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, June 05, 2012 12:14 AM 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 -Original Message- On Mon, Jun 4, 2012 at 11:01 PM, Joe Martin D'Souza 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 limi
Re: Future of the AR System and Web Services...
I do not think you can do that directly at least.. you would need two different web services, one get list that returned a single get entry, and another a get list that returned a get list. Wouldn’t be able to do it in a single WS function Joe From: Axton Sent: Tuesday, June 05, 2012 4:14 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... ** Maybe I am missing something then. How do I go about creating a web service that provides the following information (for arguments sake, let's say that it takes an input parameter of incident id): Not necessarily in that exact format, but containing that type of content. I was able to do those kinds of things with JSS XML Gateway, but not with the native Remedy web services. Axton Grams On Tue, Jun 5, 2012 at 1:08 AM, Grooms, Frederick W wrote: Axton, I have created services that accept lists of data for creation of data. Instead of mapping the primary form to the root you map it to the first element (just like you map a sub-form to a service). I have also done ones that return lists and complex constructs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, June 05, 2012 12:14 AM 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 -Original Message- On Mon, Jun 4, 2012 at 11:01 PM, Joe Martin D'Souza 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 inc
Re: Future of the AR System and Web Services...
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 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..
Re: Future of the AR System and Web Services...
Maybe I am missing something then. How do I go about creating a web service that provides the following information (for arguments sake, let's say that it takes an input parameter of incident id): Not necessarily in that exact format, but containing that type of content. I was able to do those kinds of things with JSS XML Gateway, but not with the native Remedy web services. Axton Grams On Tue, Jun 5, 2012 at 1:08 AM, Grooms, Frederick W < frederick.w.gro...@xo.com> wrote: > Axton, > I have created services that accept lists of data for creation of data. > Instead of mapping the primary form to the root you map it to the first > element (just like you map a sub-form to a service). > > I have also done ones that return lists and complex constructs. > > Fred > > -Original Message- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Axton > Sent: Tuesday, June 05, 2012 12:14 AM > 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 > > -Original Message- > On Mon, Jun 4, 2012 at 11:01 PM, Joe Martin D'Souza 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
Re: Future of the AR System and Web Services...
Hmmmpoor project definition/scheduling/timeline control? Seems if you ain't got no idea what you want/need to do you ain't got no idea when/if it will be done -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, June 05, 2012 10:25 AM To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... For oneif they say 'in version x this will happen', and it ends up either not being version X, or it ends up not being in there...it creates public relations nightmares because of people saying 'but you said, and I was counting on it, blah blah blah'this type of thing happened a few years ago when they gave a future looking comment that said v8 will be the last version to have a native client, with the thought that v8 was going to be the next version releasedwell, it wasn't...the next version ended up being 7.6.3...and then 7.6.4 was called a maintenance release of it...and THAT is the final version with a clientso this caused TONS of documentation problems all over the place...so in general, they try not to state to the public things like 'this will happen by x' and such because it causes expectations that may or may not be met. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of pritch Sent: Tuesday, June 05, 2012 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... Pardon my ignorance, but what are the obvious reasons? - Original Message - From: "David Easter" To: arslist@ARSLIST.ORG Sent: Monday, June 4, 2012 10:39:28 PM 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 _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archiv
Re: Future of the AR System and Web Services...
For oneif they say 'in version x this will happen', and it ends up either not being version X, or it ends up not being in there...it creates public relations nightmares because of people saying 'but you said, and I was counting on it, blah blah blah'this type of thing happened a few years ago when they gave a future looking comment that said v8 will be the last version to have a native client, with the thought that v8 was going to be the next version releasedwell, it wasn't...the next version ended up being 7.6.3...and then 7.6.4 was called a maintenance release of it...and THAT is the final version with a clientso this caused TONS of documentation problems all over the place...so in general, they try not to state to the public things like 'this will happen by x' and such because it causes expectations that may or may not be met. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of pritch Sent: Tuesday, June 05, 2012 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... Pardon my ignorance, but what are the obvious reasons? - Original Message - From: "David Easter" To: arslist@ARSLIST.ORG Sent: Monday, June 4, 2012 10:39:28 PM 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 _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.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" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Future of the AR System and Web Services...
Primarily because I am a BMC employee and futures are considered BMC Confidential, requiring a mutual Non-Disclosure Agreement to discuss as well as several legal and revenue recognition disclaimers. -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. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of pritch Sent: Tuesday, June 05, 2012 6:58 AM To: arslist@ARSLIST.ORG Subject: Re: Future of the AR System and Web Services... Pardon my ignorance, but what are the obvious reasons? - Original Message - From: "David Easter" To: arslist@ARSLIST.ORG Sent: Monday, June 4, 2012 10:39:28 PM 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 _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.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" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Future of the AR System and Web Services...
Pardon my ignorance, but what are the obvious reasons? - Original Message - From: "David Easter" To: arslist@ARSLIST.ORG Sent: Monday, June 4, 2012 10:39:28 PM 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 _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.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"
Re: Future of the AR System and Web Services...
Axton, I have created services that accept lists of data for creation of data. Instead of mapping the primary form to the root you map it to the first element (just like you map a sub-form to a service). I have also done ones that return lists and complex constructs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, June 05, 2012 12:14 AM 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 -Original Message- On Mon, Jun 4, 2012 at 11:01 PM, Joe Martin D'Souza 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
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 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
Re: Future of the AR System and Web Services...
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
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 _attend WWRUG12 www.wwrug.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"
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"
