Shawn,
The only "advantage" that I can think of for "DSO over Web
Services" is that ARS DSO is designed to deal with the case of "the
other side is down right now... try again later" while ARS Web
Services is only designed to be a real time process. So if the other
side is down, then the working side will see errors and could prevent
normal functionality if the integration is designed in a very simple
manor. However if the Web Services integration is done in a more
"non-trivial" way, then that functionality can also be achieved. It
just takes more than a single set field action to get the job done. (
Like involving a queue form[interface] and maybe an external process
to keep moving the data back and forth. Not a trivial task for most
shops to do. )
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On Tue, Jun 24, 2008 at 2:22 PM, Pierson, Shawn <[EMAIL PROTECTED]> wrote:
> **
>
> You know, the same thing applies to web services, and I'm not aware of any
> advantages of DSO over web services at this time if you're building an
> integration form that is used on both sides, with workflow to push to each
> separately.
>
>
>
> Shawn Pierson
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
> Sent: Tuesday, June 24, 2008 1:08 PM
> To: [email protected]
> Subject: Re: Integrating with another company's ARSystem
>
>
>
> **
>
> John,
>
>
>
> It is much easier to create a DSO form for each integration point. This form
> would become part of both systems. Changes should only be made to this form
> on both sides. You would then push data from your main form to the DSO form
> to the other DSO form where the other system would push the data to their
> main form. There are special DSO fields that will let you know when
> transfers succeed or fail. If you look at the DSO configuration book that
> will give you an idea.
>
>
>
> HTH,
>
>
>
> Roger A. Nall
> Manager, OSSNMS Remedy
> T-Mobile, USA
> Desk: 813-348-2556
> Cell: 973-652-6723
> FAX: 813-348-2565
> sf49fanv AIM IM
> RogerNall Yahoo IM
>
> ________________________________
>
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Reiser, John J
> Sent: Tuesday, June 24, 2008 1:53 PM
> To: [email protected]
> Subject: Re: Integrating with another company's ARSystem
>
>
>
> Roger, Rick and Robert,
>
>
>
> Thanks for the replies.
>
> Yes it is vague.
>
> Yes it will be a challenge.
>
> Especially since the other system is a US Navy system and I am sure security
> will be tight.
>
>
>
> Right now this is "pie-in-the-sky" but that never stopped them before;^>
>
>
>
>
>
> Robert, I have a question about your DSO statement. I thought the idea
> behind DSO was also to allow you to connect to a different form structure
> and still pass relevant data.
>
> We are purchasing DSO for another project and they use ITSM, we use our home
> grown Helpdesk. We just need to pass Ticket ID's as reference data as well
> as problem summary and user info. This was suggested to us by the Developers
> on the ITSM site.
>
>
>
> Thanks,
>
> John J. Reiser
> Software Development Analyst
> Remedy Administrator/Developer
> Lockheed Martin - MS2
> The star that burns twice as bright burns half as long.
> Pay close attention and be illuminated by its brilliance. - paraphrased by
> me
>
>
>
>
>
> ________________________________
>
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
> Sent: Tuesday, June 24, 2008 11:31 AM
> To: [email protected]
> Subject: Re: Integrating with another company's ARSystem
>
> ** Excellent point about DSO. I think the key here is being able to
> establish either a secure gateway between the two AR servers or a common
> middle ground (which means server, forms, etc.). Since you have zero
> dollars to spend on hardware, it looks like you should be investigating how
> to tunnel from one AR server to the other in some way, like Robert said,
> using some common data forms, assuming that the data is common enough to
> make that possible. Do you know anything about the other AR System and it's
> applications? If not, now would be a great time to start finding out, so
> that you have the answers before anyone asks more questions and defines
> unrealistic expectations for you.
>
> Or, you could bypass AR System altogether, and create SQL views into the
> DBs, and view them from a web page or something. Like I said, until you are
> given a better definition of what they want, it's really premature to design
> the solution for it.
>
> From a business perspective, there are two tacks you can take:
> 1) Tell them that "Yes, it's probably possible", then toss it back to them
> for a better definition of what they want.
> 2) Define the rules yourself by telling them the means by which this can
> most likely be done, and then ask them to fit what they want into that.
>
> Rick
>
> On Tue, Jun 24, 2008 at 8:11 AM, Robert Molenda <[EMAIL PROTECTED]>
> wrote:
>
> **
>
> I agree with Rick... Could be easy - could be next to impossible...
>
>
>
> DSO is OK provided that the systems are configured the same - same fields -
> same configuration data - same-same...
>
>
>
> Web Services is probably the best method to do "Ticket Passing" which is
> what I have to assume you are referring to between the two companies. Works
> fine over a secure vpn tunnel as well. Only issue is host-name-resolution...
>
>
>
> You must create a common "interface" that will be used on 'both sides' to
> send / receive the data and then custom workflow on each end to 'store the
> data' in the appropriate form + format + field definitions.
>
>
>
> More 'details' would be helpful - you could actually get away with not even
> transfering the tickets - however using web-services to create a remote view
> into the other system, etc. All depends upon the requirements.
>
>
>
> HTH
>
>
>
> Robert Molenda
>
> On Tue, Jun 24, 2008 at 7:50 AM, Rick Cook <[EMAIL PROTECTED]> wrote:
>
> ** John, "integration" is, as you said, pretty vague. Perhaps once you have
> a better idea of its scale and definition, we might be able to give better
> answers. Could be anything from very simple to you-gotta-be-kidding.
>
> Rick
>
>
>
> On Tue, Jun 24, 2008 at 7:40 AM, Reiser, John J <[EMAIL PROTECTED]>
> wrote:
>
> Hello Listers,
>
> Current configuration
> ARS 6.3 Patch 014
> Midtier 6.3 Patch 021
> MS SQL Server 2000
>
> Upgrade path
> ARS 7.1
> Midtier 7
> MS SQL Server 2000 maybe higher
>
> I know this is a long shot but has anyone put together an integration
> between two different ARSystem servers in two different companies?
> I'm guessing the only real solution would be to use webservices. I don't
> have anymore details other than " we must be able to transfer
> information between systems.
>
> Oh, did I mention that we can only spend labor dollars to accomplish
> this?
>
> I am just getting a taste of webservices inside one company and haven't
> gotten too far.
> Are there any issues with webservice publishing/consuming through the
> security firewalls?
>
> Sorry to be so general and I understand that the basic answer is
> probably "yes". I need to get a rough order of magnitude for such a
> requirement.
>
> TIA,
>
>
>
> John J. Reiser
> Software Development Analyst
> Remedy Administrator/Developer
> Lockheed Martin - MS2
> The star that burns twice as bright burns half as long.
> Pay close attention and be illuminated by its brilliance. - paraphrased
> by me
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>
>
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>
>
> --
> If it were not for the gutter, my mind would be homeless! __Platinum
> Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers
> Are" html___
>
> Private and confidential as detailed here. If you cannot access hyperlink,
> please e-mail sender.
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
