[Date Prev] [Date Next] [Prev in Thread] [Next in Thread] [Date Index] [Thread Index]

Re: Modification Source of CI



Abhishek,

Our strong suggestion would be to not use the approach you are using for the CMDB.   It leads to inconsistent data and a lack of integrity.  What you are describing is just that the last person to write something into the CMDB -- regardless of quality of the source -- is the winner and their data is the one that should be recorded and shown -- and their ID put into the source field.

What is you have multiple sources but they don't get all attributes so that the full CI is loaded from multiple sources, some having 1/2 the attributes and others having the other 1/2?   Who is the source now?  There are two or more sources...   And, you have to be careful to only update the right fields from each source.

What if you have a source that is more reliable than another source?  But, the less reliable source writes last?  Should it's updates win?

NOT A RECOMMENDED STATEGY -- but answering the question (see below for 

Although it is strongly NOT RECOMMENDED that you perform the work and use the CMDB in this way, you can accomplish what you asked simply....  You just have one dataset.  It is the production dataset.  You write to it and you read from it.  You don't use Normalization.  You don't use Reconciliation.  You just have everyone write to it and last write wins.   Now, the last modified has the data you want.   And the CMDB works in the way you have described you desire.

Again, this IS NOT a good strategy for managing the CMDB.



What you really need is a different data set for each source.  Your sources load data into their datasets.  You then reconcile WITH PRECEDENCE all values from those sources into production.   It doesn't matter who last updates as their data may or may not have even been the data that is promoted into production.  What you have in production is THE BEST data from all the sources merged ready to go.

This is the best practice.

If you did need to know what source was updated when, you can always look at the source datasets (items linked by reconciliation ID) to see who loaded most recently.  You could even have a button on the screen that goes out and looks up dates on all the items to see who updated most recently.



But, now you run into more trouble....   What if the object has not changed.  Best practice is that you don't reload the CMDB with data that is not changed.  Or, you just drive the system wild constantly reprocessing data that is not changed into the same target data.  So, if your source doesn't reload as the data has not changed, then you end up with only the source with who knows if it is accurate data that does think there is a change updating so that would then win over data that is from a source where there was no change detected.

You solve this only by reloading all data every day -- but then you have a timing issue based on whether data source A loaded item Q first or data source B.   They were both updated, but which one first and then the problem just keeps growing......

Some things to think about.   The overall issue here is much more involved with many more details and decisions than it first seems.....

Doug Mueller

-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Abhishek Chaturvedi
Sent: Thursday, November 24, 2016 10:51 PM
To: arslist@ARSLIST.ORG
Subject: Modification Source of CI

Hi Team,

I have multiple data sources in my environment and I want to capture the the source which is modifying a CI to be captured in OOB design the Last Modified field is Remedy App Service. Customer don't want to use getattributesourcelist field.

For Example if I have a CI C which is modified by multiple datsources D1 D2 D3 i wish to capture latest source in a field any ideas ??

Sent from my iPhone

_______________________________________________________________________________
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"