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
<incident>
<id>INC1234</id>
<related_items>
<related_item_1>
<type>CI</type>
<id>12345</id>
</related_item_1>
<related_item_2>
<type>work_order</type>
<id>9874</id>
</related_item_2>
<related_item_3>
<type>incident</type>
<id>654</id>
</related_item_3>
</related_items>
<work_information>
<info_id>1</info_id>
<info_id>2</info_id>
<info_id>3</info_id>
<info_id>4</info_id>
</work_information>
</incident>
-----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):
<incident id=INC1234>
<related_items>
<related item 1 type=CI id=12345/>
<related item 2 type=work_order id=9874/>
<related item 3 type=incident id=654/>
</related_items>
<work_information>
<info id=1>
<info id=2>
<info id=3>
<info id=4>
</work_information>
</incident>
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 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
-----Original Message-----
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.
-----Original Message-----
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"
