The record created in BMC_People is very basic and keys off the login id. This could be beneficial for integrations. You could tie multiple people source systems into the CMDB, reconcile the information, and then push the info into CTM:People. This could provide you a way of having virtually unlimited pointers into unlimited systems for people data.
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Cook Sent: Tuesday, August 02, 2011 3:53 PM To: [email protected] Subject: Re: Integrating with CTM:People vs. BMC_People ** This isn't based on anything but educated guesses, so with that in mind let me see if I have the structure down: In pre-7.6 versions, relationships between People and CIs were dealt with by querying the CTM:People form. That was ok, but a case can be made for managing specific people (not necessarily all) in the CMDB. So the 7.6 way we're talking about now is at least a transitional shift away from the standard people forms toward using the CMDB BMC_People form for setting relationships between CIs. That makes a cleaner relational model as well as a more flexible one. It also has the benefit of allowing customers who use a CMDB apart from ITSM the ability to easily do so without giving up the ability to track people/CI relationships. Seems a sound strategy to me. Thoughts? Rick On Tue, Aug 2, 2011 at 12:38 PM, strauss <[email protected]> wrote: ** Does this filter pick or choose which CTM:People entries to populate into BMC_People? I am about to re-develop my integration that takes LDAP data from a SQL Server and shoves it into CTM:People, User, and CTM:PeoplePermissionGroups and maintains those records with a live feed. There are currently about 266,400 people and user records, of which 336 are support staff (that generates about 341,000 CTM:PPG recs). When we upgraded to 7.6.04.01 we saw 475 records created in the BMC.CORE.BMC_Person table; three more have "appeared" since then. We have made no effort to deal with these, having no experience with the CMDB or reconciliation. After the upgrade we turned off all of the integration filters and AIE jobs, although RRR|Chive updates the individual tables from production nightly. Personally, I can only see adding the IT staff initially, but it will probably be easiest to filter to the active faculty/staff records (14,170 recs including student employees - they have a custom role flag in CTM:People that is set by the integration). Has anyone already tackled this, and able to shed some light on the process?? Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Tommy Morris Sent: Tuesday, August 02, 2011 1:31 PM To: [email protected] Subject: Re: Integrating with CTM:People vs. BMC_People ** An OOB filter triggers off of CTM:People that creates/ updates BMC_PERSON just push to CTM:People and set 'z1d Action' to "PEOPLESYNC_CREATE" or "PEOPLESYNC_UPDATE". You will be able to see a new record create in BMC.Sandbox and the reconcile into your CMDB. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pierson, Shawn Sent: Tuesday, August 02, 2011 1:07 PM To: [email protected] Subject: Integrating with CTM:People vs. BMC_People ** Good afternoon, As I'm upgrading from ITSM 7.0.3 to 7.6.4, one thing I'd like to do is continue to have my People data updated from Active Directory. For 7.0.3, I built an integration where some escalations run and dump the People data into a staging form that then goes into CTM:People. However, now that I have the BMC_People class in the CMDB, I'm considering if it would be better to put the data there instead, and use that to update the People data. I'd like to know what your thoughts are on this. It's obviously easier for me to take my pre-existing code and migrate it to my 7.6.4 servers, but if there is an advantage to loading it into BMC_People first, I'm open to going that route instead. Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here <http://www.sug.com/disclaimers/default.htm#Mail> . If you cannot access hyperlink, please e-mail sender. _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
