You may want to think about the SLA running on the initial source of the ticket and just DSO (ie transfer) a copy that is only for information use. That way, the SLA times would be identical and alerts would only come from the system where the SLA is truely being measured.
----- Original Message ----- From: "Jason Miller" <[email protected]> To: [email protected] Sent: Wednesday, September 12, 2012 3:49:11 PM Subject: Re: Integrating 2 or more remedy systems and non remedy systems ** That will make things much more interesting. That part is beyond my experience. I have never had the requirement to sync SLAs in a large distributed environment. In the Help Desk 6 system I referred to the time lag was surprising small (and there was an intermediate Remedy system between mine and many of the others). Of course there are a number of variables that factor into to this so maybe I was just really lucky :) Will you be in a position to upgrade to ITSM 8 when it comes out? There is a new Hub and Spoke technology that will be available that may help. (David referenced it on 3/5 to the List and it is published on a non-BMC web site so at this point I think mentioning it is fair game ( http://wwrug12.com/breakouts.html ) Continuing with what is currently available... Are you talking about all SLAs or just some? Are they things like resolved in x days or responded to in x minutes? I think the approach will depend on how many SLAs are being synced and how time sensitive they are. Is it at all possible to have a single authoritative system that attaches SLA as requests work through the system? It seems to me that there is just too much complexity trying to pass SLA data between different systems. Likewise I think it would be pretty large initiative to configure each system's SLAs exactly the same and keep them that way (to give the illusion SLA data is synced). And even then you have time inconsistencies between attached SLAs on different systems. What about SLA notifications? I don't think you would want a breached SLA to trigger a notification from each system? Just briefly thinking about this I think the best bet is to keep the SLA server centralized. You may need to propagate a few types of SLA records out to the other servers so the SLA indicators work correctly in the UI but really just for display purposes (still assuming this is BMC's ITSM). Are all of these Remedy systems identical? If they are and there is a need for a really large number of forms/records/objects to be synchronized I am wondering if a DB synchronization technology would be more appropriate? Jason On Wed, Sep 12, 2012 at 11:47 AM, Karthik < [email protected] > wrote: ** 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"_ _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"
