Thanks Jason. This helps. Customer also wants to maintain SLAs on all the systems in sync. I am thinking there would be time lag during transaction processing in the integration layer. How do we handle the time lag?
Regards, Karthik On 13 September 2012 00:05, Jason Miller <[email protected]> wrote: > ** 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"_ > > > _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"
