We load people from a Peoplesoft->LDAP->SQL Server source with AIE, pushing to a custom form, then to CTM:People, User, and CTM:PeoplePermissionGroups as well as User Preferences. To get that working again on the 7.6.04.01 system (developed/used originally on ITSM 7.0) required that I overlay and disable all 39 of the filters that load and maintain BMC_Person. We will revisit them when we can control who they are injecting - less than 10,000 records for active employees versus 266,000. OOTB, it wants to try to load them all. In this version, you may be correct that what we want in Asset to User relationships can all be done without populating BMC_Person; it's on my "to-do list" to find out.
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 Garrison, Sean (Norcross) Sent: Wednesday, August 10, 2011 3:27 PM To: arslist@ARSLIST.ORG Subject: Re: Integrating with CTM:People vs. BMC_People ** We are on ITSM 7.6 patch 1 so my answers on based on that. I personally have found the BMC_Person class rather useless and a waste of time to maintain. The reason is that most of the ITSM workflow fires on the AST:AssetPeople relationships. In addition the related CIs on the CTM:People form will not show up when looking at the people record unless you go through AST:AssetPeople. I heard rumors though that in later versions of remedy that there was a design to merge BMC_Person and CTM:People into one table. Thanks, Sean From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Cook Sent: Tuesday, August 02, 2011 3:53 PM To: arslist@ARSLIST.ORG 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 <stra...@unt.edu<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Tommy Morris Sent: Tuesday, August 02, 2011 1:31 PM To: arslist@ARSLIST.ORG<mailto: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<mailto:arslist@ARSLIST.ORG>] On Behalf Of Pierson, Shawn Sent: Tuesday, August 02, 2011 1:07 PM To: arslist@ARSLIST.ORG<mailto: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<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com<http://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"
