Configuring Service Manager 7.x Knowledge Management
May 10, 2010
Knowledge Management Fundamentals in Service Manager 7:
NOTE: This document lays out, in depth, the inner workings of the Knowledge Module setup in Service Manager 7. The document covers how to perform a Full Reindex on your existing Knowledge Bases in the Service Manager system (as the process for this has been modified in the Service Manager 7 system). This document also explains all of the background items that are used to do this.
Pre discussion Notes:
- There is a table named “kmknowledgebaseupdates” in SM 7 that holds a record of all Knowledge Article updates and new Knowledge articles added (and will also temporarily hold new records that get added in when a Full Reindex is done – then these are deleted back out once the “KMUpdate” schedule record wakes up and fires the Javascript responsible for committing the KnowledgeBase indexes and deleting the records out in this table… See the discussions below for more details on this).
- What happens is when the “KMUpdate” schedule record goes in and re-indexes the knowledge articles, it goes into the records held in this table named “kmknowledgebaseupdates” (via the Javascripts that get invoked by his schedule record), indexes the knowledge articles referred to in these records, and removes these records from the “kmknowledgebaseupdates” table once that happens (This is all new in Service Manager 7).
Section I. Performing a Full Reindex of Your Knowledge Bases in Service Manager 7:
***With the above notes in Mind, this is how you would manually perform a one time, Full Re-index of any knowledgebase in the system***:
1.) Go to the “Menu Navigation” > “Knowledge Management” section on the Left Hand Side in the System Navigator and double click “Manage Updates”. Then click “Stop” on this form. This stops the “KMUpdate” schedule record from running (this is the record that indexes the knowledgebase articles automatically in the background).
2.) Then! Go to the “kmknowledgebaseupdates” table in the database manager and remove (delete) any records there.
3.) Go to the “Menu Navigation” > “Knowledge Management” section on the Left Hand Side in the System Navigator and double click “Manage Knowledgebases”. Do a Search and go to the Knowledge Base you want to full reindex (Make sure you do NOT have the Capability word named “AlwaysAdmin” in the operator record you are logging into the system with in order to have the Full Reindex Button not greyed out for these Knowledge Bases).
4.) Click the “Full Reindex” button and the “Docs Returned” may say 0 actually, this is normal. ***What happens here then is the number of docs that are in this Knowledgebase will create the SAME NUMBER of records in the “kmknowledgebaseupdates” table à These then will need to be processed by the Javascript that gets fired by the “KMUpdate” schedule record that wakes up in step 5.).
5.) Go Back to the “Manage Updates” screen (from step 1) and start back up the “KMUpdate” schedule record then (By clicking the “Start” button on this form). See Below now for additional notes on this:
Ok, so when you go to the “Manage Updates” section and click Start (this is if the “KMUpdate” schedule record needs to be restarted and it isn’t already up and running), you will see stats there about what is happening (Note – Clicking “Start” on this screen starts up the “KMUpdate” schedule record and this is how the knowledgebases are automatically reindexed in the background). You can click “Refresh” and see the knowledge docs that it is going through (NOTE!!! It will process ALL “kmknowledgebaseupdates” table records by indexing the knowledge articles referred to in these records and then deleting these records out of this table. It does this in 500 record increments until they are all processed > It looks to hang at 500 record increments > This is because if you go into the “kmknowledgebaseupdates” table and keep refreshing the record count, it is deleting these records slowly until it gets to the 500 it needs to delete and then the next 500 are processed till they are all gone).
NOTE! That this is the ONLY way to Fully Reindex your knowledgebases now in Service Manager 7… Steps 1.) – 5.) above have to be performed and then the KMUpdate sch record comes in and the Javascript it fires processes these “kmknowledgebaseupdates” table records and indexes the knowledge articles.
NOW! After this initial full re index discussed above in steps 1.) – 5.) is performed, only updates to existing knowledge articles and newly added knowledge articles will be stored in the “kmknowledgebaseupdates” table and then ONLY these records get processed by the “KMUpdate” schedule record – This is the case until another Full Re-Index of the Knowledgebase is performed by following steps 1.) – 5.) above.
LASTLY NOTE! The web services tier now (setup in the KM environment record à If this isn’t setup right in this environment record, it all fails), is responsible for using the WSDL (created by the “kmknowledgebaseupdates” “extaccess” table record à This record has the “delete” function here that is used by the system to delete out these “kmknowledgebaseupdates” table records once they have been indexed) to delete out the “kmknowledgebaseupdates” table records once they have been processed…
Section II. Sum It All Up:
So in sum, here’s how the “KMUpdate” schedule record works:
1.) KMUpdate schedule record wakes up every 5 minutes and fires its Javascript.
2.) The Javascript fired goes into the “kmknowledgebaseupdates” table and indexes EACH knowledge record that is referred to in each record in this table.
3.) And at 500 record intervals, each of these “kmknowledgebaseupdates” table records is deleted out (via this web services tier used now – see the section below for a further discussion on this).
4.) NOTE! If you want to perform a full reindex on any of your knowledgebases in SM 7… Perform steps 1.) – 5.) above in the beginning of this document and then let the “KMUpdate” sch record do the rest… This takes a while and you can monitor the progress of this in the “Manage Updates” link discussed above. You will be able to see the records in the “kmknowledgebaseupdates” table go down slowly as this processes happens (and only you will see this happening when the “Manage Updates” window appears that is has stuck at 500 record increments). After EACH run of this sch record, the “kmknowledgebaseupdates” table should have no records in it or something wrong has happened… FYI
Section III. Further Notes and KM Environment Record Setup:
Further Notes About the Above:
1.) Now! Web Services in Service Manager 7 is responsible for the deletion of the “kmknowledgebaseupdates” table records in the process explained above (so these records are deleted out of this table once the knowledge articles have been indexed). This is why the user and port number has to be correct for this web services piece on the KM environment record (see screenshot below on the KM environment record in a mock system). The user specified in the environment record below must have web services access by having the “SOAPAPI” capability word. The port number (13081 in the screenshot below) will be pointed at a servlet that should be started up just for the web services connection (If a Load Balancer is setup, extra steps will have to be taken to not have any other traffic directed to that servlet that has been started for this web services connection à There are ini file params for starting up this separate servlet that are not noted here)!
2.) In the discussion above in Section I, it explains the form that you will see when going to “Manage Updates”. When you click the “Refresh” button on this thing, it will get to increments of 500 records and look to stop temporarily and hang à That’s because at the 500 mark, the process “Commits to the Search Engine and writes the indexes for these knowledge articles” and these 500 are then removed at this point from the “kmknowledgebaseupdates” table and you can see the number of records going down in this table if you go to the records in that table and keep refreshing the Search and count (and again note that the Web Services Connection is for just this deletion of these records once the knowledge articles have been indexed).
3.) Note! There is a record out there in the “extaccess” table (name: kmknowledgebaseupdates) that should have a delete call in it à This is how the WSDL is constructed that the Knowledge Process uses to delete records out of the “kmknowledgebaseupdates” table when the time comes to do this in the process.
Example of a correctly setup Environment Record For SM 7 Knowledge Management:
SM 7 Knowledge Management Environment Record (click for large size)
Comments
Got something to say?