I would agree with the 3 separate staging form approach. It gives you the versatility of being able to update features on one set without having to re-test all the other scenarios associated with the other set(s). It is also more "modular" and can be upgraded/taken off line separately.
Terry -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tauf Chowdhury Sent: May-17-13 12:05 AM To: arslist@ARSLIST.ORG Subject: Re: ITSM Web services Like Joe said, It is a matter of opinion and preference. Personally, I'd like the versatility of having 3 separate staging forms. Your processes may mature differently and raise the need to increase and decrease the number of fields or workflow for each. I'd rather do development per module/staging form then always go back to modify a so for form and web service. Sent from my iPhone On May 16, 2013, at 9:30 PM, Joe D'Souza <jdso...@shyle.net> wrote: > I think this is a matter of 'personal preference' of a developer. > There is no good and bad practice if you ask me as long as you have a > clear visibility of your mappings between your web service staging or > integration form and the underlying application data form. > > For the purpose of cross application manageability, I personally > prefer the approach of a signle staging form for web services as this > would mean a single URI that you publish with n number of operations within it. > > This is because very often developers of other system would rather > deal with a single URI than multiple URI's. > > Each operation within that web service then should use a flag to > indicate where that data would be headed to. > > The con of this method obviously is that if you have even a single > operation that requires you to get list, this method basically will > fail and you would need to go old school with multiple web services.. > > So as long as it is only create or update, a single URI solution > should pretty much work. > > Cheers > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Jim Coryat (jcoryat) > Sent: Thursday, May 16, 2013 10:33 AM > To: arslist@ARSLIST.ORG > Subject: Re: ITSM Web services > > Personally I would go with three staging forms. Keeps the number of > fields low and succinct to the web service you are consuming. Putting > everything on one web service/form to me would be increasing the > potential for cross application contamination as well as creating > possibilities for incorrect workflow based on the targeted application > type. I tend to rely on the KISS principle. Keep It Simple Stupid. > :^) > > Jim Coryat > Micron Technology Inc. > > > -----Original Message----- > From: Jiri Pospisil [mailto:pospi.arsl...@gmail.com] > Sent: Thursday, May 16, 2013 3:58 AM > Subject: ITSM Web services > > Hi all, > > We are integrating ITSM modules (incident, problem and change) with > another Remedy system instance through web services. > The plan is to create a staging area in front of OOB integration forms. > Now, the question we are discussing and I would like to ask other > people's opinion on is: > > Would you consider creating just a single web service with one staging > form behind for all modules using an attribute to distinguish which > module the call relates to OR Would you mimic the OOB approach and > create three web services with three separate staging forms (one for > each module)? > > What pros/cons can you think of for each of the approaches? > What other aspects would you consider to choose between the two? > > Thanks > Jiri Pospisil > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
