Hi,
DSO is now included.
But nevertheless, you might want to consider using RRR|Chive instead. In this
way you need not enable any DSO-fields and build filters to trigger the
transfers.
RRR|Chive can easily be configured on a form-by-form way, and you can then
just run it whenever you want to sync up your spokes from the hub.
It is also easy to do multiple sets of config files to restore the
test-environment from prod or something like that.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Good morning,
>
> I wanted to throw this out there for feedback. Most of the functionality for
> hub and spoke in ITSM seems focused on using it between various production
> environments between different groups that have their own Remedy systems
> within an organization.
>
> My company currently has one production Remedy instance and we're probably
> going to be fine with that for the next year at least. However, I was
> thinking that this may be useful from a non-Production system standpoint.
> What I'm thinking is that I set up the Production server as the hub, and my
> development and test environments as spokes. This should help keep my
> foundation data fresh between all of the systems. However, I have a few
> questions that will determine whether or not it will work:
>
>
> 1) Can you implement hub and spoke without buying DSO licenses (e.g. is
> DSO now included or is it still a separate product?)
>
> 2) Can you control what data is synchronized between the hub and spoke
> servers? (e.g. can you exclude Production notifications from the sync?)
>
> 3) Is it possible to remove the relationship temporarily, keeping the
> data on the spoke server, in such a way that you can test certain
> data/configuration changes without it being overwritten from the hub?
>
> 4) Is it possible to push data from the spoke back up to the hub?
>
> 5) Are there any other potential risks from adopting hub and spoke to
> keep non-Production systems up to date?
>
> This isn't a critical thing for me, more of a discussion point, but if it
> works it could save us all a lot of effort especially around keeping test and
> production systems similar.
>
> Thanks,
>
> Shawn Pierson
> Remedy Developer | Energy Transfer
>
>
> Private and confidential as detailed here:
> http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the
> link, please e-mail sender.
>
> _______________________________________________________________________________
> 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"