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:[email protected]] On Behalf Of Abhishek Chaturvedi
Sent: Thursday, November 24, 2016 10:51 PM
To: [email protected]
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"

Reply via email to