Yes... Most of what you mentioned will most likely be used. Definitely create a interface form(s) where the actual integration takes place. Each integrated Remedy system should have this same "middle" form. This is a huge help in:
1. Allowing each system to customize/enhance their user facing forms as appropriate for their environments. As long as the interface form still works the same there is no impact on the integration (BMC also provides interface forms for ITSM) 2. It allows you to massage the data as appropriate for your system as it comes in or for the other integrated systems as it is sent out. 3. It allow a place to capture errors without flat out rejecting the transaction. When there is a error you can create an Incident to research the error, email somebody or run a schedule report of errors depending on the volume of errors//transactions and their criticality. DSO should work fine between different version AR Systems. I haven't used DSO for a few years but last I did we were using it between 7.1 and 6.3. I don't think DSO has change much in recent releases. The non-Remedy apps should also use interface form with some Remedy API method (web service, java API, arimport, Meta-Update, etc.). This isolates your user facing forms the same as using DSO. You could conceivably even allow SQL integration in the interface form but then you need an escalation to get records/updates from the non-Remedy systems up to the API layer to trigger workflow. Possible but no ideal. I think the biggest challenge is not so much the technology but coming up with the rule and the requirements for the shared components that every system adheres to. There will need to be very well thought out rules for how data can flow and how it cannot flow. Just assuming here... It is likely that one system should "own" a request. The other systems would have a read-only copy of the request that is updated by the owning system. Of course ownership can be transferred from one system to another. By having one owner there are no conflicts regarding updates. If a record is updated in a non-owning system (shouldn't be allowed) it will be overwritten by the owning system. If you need to allow updates from any system to be replicated then things get much more difficult. You didn't mention if this is ITSM. Now that Work Infos are now separate records it might be pretty easy to allow Work Info records to be created from any system without conflict. When I worked with such a architecture it was Help Desk 6 and a custom app that used diary fields for the Work Log so ownership rules had to be enforced. HTH, Jason On Wed, Sep 12, 2012 at 9:34 AM, Karthik <[email protected]> wrote: > ** > Correcting the subject of the email. > Thanks > Karthik > On 12 September 2012 22:02, Karthik <[email protected]> wrote: > >> I have a requirement to integrate 2 or more remedy systems and other >> ticketing tools built on different technologies like Java . >> >> Scenario: Remedy servers A, B, C, D are on different versions of remedy >> ranging from 7.1 to 7.6. When incidents are assigned to a particular >> assigned group, an incident should be created on a remedy server E on 7.6. >> Once a ticket is created on Remedy server E, the integration should be >> birectional. i.e. status updates should flow through between the servers. >> Similar should happen even when incidents are raised and assigned on >> different ticketing tools built on various technologies. >> >> Assumption: >> - Remedy servers are DSO enabled >> - Other ticketing tools support web services. i.e. can expse and consume >> web services. >> >> Below are few approaches, i have thought of and need suggestions on these >> approaches or please feel free to recommend any other approaches as well: >> >> 1. Build staging forms on both soure and target systems to handle >> transactions. >> 2. Data to this staging form can be populated in following different >> manners: >> >> a. Integrate remedy servers using DSO and integrate with other systems >> using web services so that same staging form handles the transactions using >> same workflows >> >> - I need to understand if DSO is backward compatible. say for ex: can >> we establish DSO between 7.1 and 7.6? >> >> b. Integrate all the systems(remedy/non remedy) using web services >> c. Use an orchestrator tool like BMC Atrium Orchestrator >> >> Thanks >> Karthik >> >> >> >> >> > > _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"
