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 <stra...@unt.edu> 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: > arslist@ARSLIST.ORG] *On Behalf Of *Tommy Morris > *Sent:* Tuesday, August 02, 2011 1:31 PM > *To:* arslist@ARSLIST.ORG > *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: > arslist@ARSLIST.ORG] *On Behalf Of *Pierson, Shawn > *Sent:* Tuesday, August 02, 2011 1:07 PM > *To:* arslist@ARSLIST.ORG > *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"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
