8/21/2014

Transcription

1 Knowledge Article People Synchronization and the Reconciliation Engine - CTM:People to BMC_PERSON with Dependency Relationships Knowledge Article ID: KA Version: 1.0 Status: Published Published date: 01/25/2011 Problem IT Serice Management Suite 7.5, Atrium Core 7.5 Solution IT Serice Management Suite 7.5, Atrium Core 7.5 IT Serice Management Suite 7.5, Atrium Core 7.5 IT Serice Management Suite 7.5, Atrium Core 7.5 The following reference article is intended to explain the new integration architecture found in the ITSM / Atrium Core release. The data created and modified in CTM:People and BMC.CORE:BMC_Person data is now automatically synchronized and reconciled according to strict rules. This information was drafted and proided with a hotfix for defect SW This defect was to be included in IT Serice Management patch 2, but due to time constraints it has been delayed for a future patch. 1.0 People Synchronization Oeriew In the ITSM release functionality has been added to Asset Management to automate the process around Software License Management. This process makes use of the data and relationships in the CMDB to determine which software contracts software CI s should be connected to and how to calculate the compliance from a license standpoint on that software. Compliance can be calculated in many different ways based on the license contract with the software endor. One piece of information which can be used by different license models is the number of unique people who may be making use of a software title. Since the CMDB is the repository of information about CI s and also has a class which represents people and their relationships to CI s, and this class is populated by BMC discoery products, the out of the box rules make use of information from the CMDB. This new functionality will treat data from the CTM:People form as a source of discoered data in the CMDB. This means that the data will be populated into a ITSM discoery dataset for people and then reconciled with other people data already in the CMDB to proide a single representation of a person across all people data sources. By proiding this functionality we now hae a single source to build our software license compliance rules around, and will be able to proide accurate tracking of user based licensing models. 2.0 Design Considerations 2.1 Architecture There are a few different facets to the architecture of the People Sync initiatie: 1. There is an initial upgrade scenario which when run performs a bulk synchronization of CTM:People data to the CMDB BMC.CORE:BMC_PERSON class along with associated existing AST:AssetPeople relationships to the Dependency class relationships within CMDB. 2. There is an ongoing (maintenance) synchronization of CTM:People data to the CMDB BMC.CORE:BMC_PERSON class along with associated existing AST:AssetPeople relationships to the Dependency class relationships within CMDB. 3. There are three datasets that are used as a part of the solution: a. BMC.ASSET is the production (or golden dataset). BMC_Person records created are eentually reconciled to the production dataset b. BMC.ASSET.SANDBOX is the dataset used to reconcile updates to CTM:People that hae been manually generated using either the Windows User Tool or a Mid-Tier client. In this 1/7

2 case the Reconciliation Job for the sandbox can be called in-line or through the use of reconciliation schedules. c. BMC.ASSET.SANDBOX.BULK - is the dataset used to reconcile updates to CTM:People that hae been generated using any client other than the Windows User Tool or Mid-Tier client. BMC_Person records created/modified in this regard are considered to be Bulk updates and are processed using the Bulk sandbox. Any Modify operation against CTM:People are also considered to be a BULK operation and will use this dataset in the creation of BMC_Person records. In this case the Reconciliation Job for the bulk sandbox uses reconciliation schedules and does not make in-line calls to the bulk sandbox. 2.2 CTM:People Mapping to BMC.CORE:BMC_PERSON The mapping from the CTM:People form to the BMC.CORE:BMC_PERSON class is listed below: BMC_PERSON FIELD LENGTH CTM_PEOPLE FIELD LENGTH TokenId 254 NULL N/A Name (See Rules for field alue creation) 254 Remedy Login ID 15 NameFormat 80 UserName HARDCODE(8) FirstName 254 First Name 30 LastName 254 Last Name Internet 255 PersonDepartment 254 Department 60 ShortDescription 254 Remedy Login ID 15 CDIntegrationID Person ID 15 Fax 64 Phone Number Fax 50 MiddleName 254 Middle Initial 30 MobilePhone 254 Phone Number Mobile 50 OfficePhone 254 Phone Number Business 50 PagerPhoneNumber 254 Phone Number Pager 50 PersonID 255 Person ID 15 PersonRegion 254 Region 60 ITSM_Organization 254 Organization 60 Company 254 Company 254 Region 254 Region 60 ReconciliationIdentity 254 ReconciliationIdentity 38 MarkAsDeleted 254 HardCoded No HARDCODE DatasetID 254 Z1D_BMC_Person_Dataset_ID 0 NameFormat 254 HARDCODED UserName HARDCODE Site 254 Site 60 AssetID 254 Corporate ID 30 SiteGroup 254 Site Group 60 CMDBRowLeelSecurity 254 Assignee Groups 255 ShortDescription (See Rules for field alue creation) 254 Remedy Login ID CTM:People to BMC_Person Rules This section outlines the rules that dictate when a CTM:People record is moed to the BMC_Person class in conjunction with the rules goerning the dataset that is used in the creation of the BMC_Person record Rules for BMC_Person record creation CREATE - Each time a new CTM:People record is created an associated BMC_Person record is also created. See the following section for rules goerning the rules for dataset id to be used in the creation of BMC_Person class entries. DELETE - Each time a CTM:People record is deleted an associated record is generated within BMC_Person class to be reconciled with the corresponding production dataset record. Upon reconciliation the Mark As Deleted field on the production dataset entry for the corresponding record is set to Yes MODIFY - Each time an existing CTM:People record is modified a alidation check is performed to assess whether or not any of the fields that are represented within the BMC_Person class from CTM:People hae been modified. If none of the fields represented within the BMC_Person class 2/7

3 hae changed no action is taken. If any of the associated field alues hae been modified a new BMC_Person record is generated. See the following section for rules goerning the rules for dataset id to be used in the creation of BMC_Person class entries. The core fields used in the determination of a legitimate Modify which performs an associated update to the BMC_Person class include: 'Company'!= 'DB.Company') OR ('Person ID'!= 'DB.Person ID') OR ('Internet '!= 'DB.Internet ') OR ('Department'!= 'DB.Department') OR ('Region'!= 'DB.Region') OR ('Phone Number Fax'!= 'DB.Phone Number Fax') OR ('Phone Number Mobile'!= 'DB.Phone Number Mobile') OR ('Phone Number Business'!= 'DB.Phone Number Business') OR ('Middle Initial'!= 'DB.Middle Initial') OR ('First Name'!= 'DB.First Name') OR ('Last Name'!= 'DB.Last Name') OR ('Site'!= 'DB.Site') OR ('Organization'!= 'DB.Organization') OR ('Site Group'!= 'DB.Site Group') OR ('Corporate ID'!= 'DB.Corporate ID') OR ('Remedy Login ID'!= 'DB.Remedy Login ID') Rules used in the Creation of the Name Attribute The Name attribute on the BMC_Person class is constructed based on specific rules goerned by the information that is present upon the creation and/or modification of a CTM:People record. The following rules hae been applied: The rules around mapping the Login Name and Primary Domain name should follow the following rules. If Primary Domain!= $NULL$ then set TokenID and Name to $LoginName$:$PrimaryDomain$ and the NameFormat attribute is UserName If Primary Domain = $NULL$ then TokenID = 0 and Name = $LoginName$ and Nameformat = UserName For LoginName population, if a alue does not exist then make use of a combination of First + middle + last to generate a LoginName Rules for Dataset ID used in the creation of a BMC_Person Wheneer a create, modify, or delete operation occurs on the CTM:People record an associated BMC_Person record may be generated (see rules from the preceding section). The operation performed on the CTM:People record, in conjunction with the client tool used to perform the associated operation, dictates what Dataset ID will be used in the corresponding creation of the BMC_Person record. Wheneer the Windows User Tool OR a Mid-Tier client is used to perform a direct manual update to a CTM:People record, where the operation being performed is CREATE, the BMC.ASSET.SANDBOX dataset is selected and propagated to the associated BMC_Person record upon creation. Wheneer the Windows User Tool OR a Mid-Tier client is used to perform a direct manual update to a CTM:People record, where the operation being performed is SET (modify), and at least one of the associated fields that are represented within BMC_Person from CTM:People are changed, the BMC.ASSET.SANDBOX dataset is selected and propagated to the associated BMC_Person record upon creation. Wheneer the Windows User Tool OR a Mid-Tier client is used to perform a direct manual update to a CTM:People record, where the operation being performed is SET ALL (modify all), and at least one of the associated fields that are represented within BMC_Person from CTM:People are changed, the BMC.ASSET.SANDBOX.BULK dataset is selected and propagated to the associated BMC_Person record upon creation. A Modify operation is considered to be a BULK update and is treated as such. Wheneer the client tool being used to create, modify, and/or delete records within the CTM:People is anything other than the Windows User Tool OR a Mid-Tier client, performing a direct manual update, the associated records generated within the BMC_Person class utilize the BMC.ASSET.SANDBOX.BULK dataset. Bulk type operations utilize the bulk dataset to bypass in-line calls to the reconciliation engine in order to improe performance and system 3/7

4 throughput. The bulk sandbox dataset uses schedules in order to perform the reconciliation process. 2.4 Rules for BMC_Dependency Associations The primary rule for creating a BMC_Dependency relationship is that the associated CTM:People record must already hae been reconciled to the production enironment. A BMC_Dependency relationship Requires that the ReconcilitionIdentity field be completed on the associated People record in order to successfully create the dependency record. When a relationship is attempted using a People record that has not yet been reconciled to the production dataset a message is presented alerting the user to the current issue and the association is bypassed. 2.5 People Sync and Sandbox Settings The Reconciliation Engine is triggered based on existing configuration settings within the system. The following example settings are displayed as a isual context: The asset management Adanced Setting form displays the production, sandbox, and Sandbox People Sync dataset information and settings. Important settings to note include: Dataset Name Production dataset containing the golden lie data Sandbox Dataset Name the name to be used in conjunction with the Sandbox, or a dataset to be used within the reconciliation process Sandbox Job Calls for People Specifies the sandbox dataset reconciliation method. o Inline Each time a manual creation or modification to a CTM:People record is performed and the client tool used is either the Windows User Tool or a Mid-Tier client, a call is immediately made to perform a reconciliation. Prior to making a new inline call to the sandbox a pre-check is performed to ensure that an existing job run is not already in progress therefore bypassing the need to run a new job. o Schedule A schedule is used to process any records existing within a gien dataset at the times defined by the schedule. The default scheduled times for the BMC.ASSET.SANDBOX and the BMC.ASSET.SANDBOX.BULK datasets are daily at 12:00 AM. Schedules can be altered by the system administrator for any dataset to accommodate specific needs. For example; an hourly synchronization is performed from an Actie Directory (LDAP or third party source) to CTM:People. The system administrator may choose to set up an hourly schedule to run a reconciliation job at 20 minutes past the hour daily. o System Default Leerages the client tool in use, the operation(s) being performed, and the Asset Management Settings to automate the selection of dataset to be used in the creation of a BMC_Person record. The system default also allows for future growth in the eent special keywords are introduced to handle ery specific type requests. The Reconciliation Engine Jobs each has its own setting for Continuous Job. The continuous job setting details how often the Job is run. If set to Yes, the job will run eery X number of seconds based on the Continuous Job Interal (Seconds) setting found within the Reconciliation Engine settings link displayed below: If set to No the reconciliation Engine uses the schedule as setup for the indiidual job as outlined within the job setting schedules, as displayed below: 2.6 MSM:MigrationTasks Form The MSM:MigrationTasks form is used as the mechanism to trigger the initial synchronization 4/7

5 process. This action is part of the Upgrade process and fires as a part of the CFN (Remedy Common Foundation). It is meant to fire once as an upgrade to the foundation. The installer will import an.arx file containing a task used as the primary trigger. Upon import, a merge Filter fires that kicks off a Modify action against the CTM:People form. In this case there are six tasks to perform: 1. Modify CTM:People records 2. On Modify perform a Push Fields to the BMC.CORE:BMC_PERSON form using BMC.ASSET.SANDBOX.BULK as the datasetid. The BULK sandbox uses reconciliation schedule(s) to promote data to the production enironment. The default schedule for the BMC.ASSET.SANDBOX.BULK dataset is set to daily at 12:00 AM. 3. Reconciliation Engine to promote the data to the production dataset 4. Modify AST:AssetPeople records 5. On Modify perform a Push Fields to the BMC.CORE:BMC_DEPENDENCY form. Note, that the BMC_Person record must be reconciled to the production dataset (BMC.ASSET) in order for an associated BMC_Dependency record to be created. The creation of a dependency record relies on the ReconciliationIdentity field to be populated on the associated CTM:People record. The ReconciliationIdentity field is a requirement on the BMC_Dependency form. 6. Reconciliation Engine to promote the data to the production dataset 3.0 Using BMC Configuration Discoery with ITSM The CMDB reconciliation rules are setup to make use of the Token ID field and the Name and Name format fields to determine identification of instances of data between sources of data. Configuration Discoery has built the following rules around how these two fields get populated. 1. If they find login name and domain on a system, then they populate the Name attribute and the Token ID attribute with the following format LoginName:DomainName. For example jdoe:bmc.com 2. If they don t find a login name then they just make use of the login name. They also always populate the NameFormat attribute with the alue UserName. They will also populate the Token ID field with 0 The reconciliation rules work as follows: 1. They will attempt to match the Token ID across the data sources as long as Token ID is not = If the first rule fails then it tries to match based on the Name attribute where the NameFormat attribute is set to UserName. If a match is found then both instances are set to the same reconciliation id which is used later by the reconciliation engine merge actiity to moe the data into the BMC.Asset dataset. If no matches are found then the instance is auto identified and gien a reconciliation id so that it can be merged. 5/7

6 FND.zip 8.1MB 24 56k, < 1 broadband 6/7

7 Legacy ID SLN SLN Copyright BMC Software, Inc. Use of this site signifies your acceptance of BMC's Terms of Use and Priacy Policy. BMC, BMC Software, the BMC logos, and other BMC marks are trademarks or registered trademarks of BMC Software, Inc. in the U.S. and/or certain other countries. 7/7