HP Delivers Patch 1 Hot Fix 1 for Service Manager 9.20
November 9, 2010
Just got the download links from support for the HP Service Manager 9.20 patch 1 hot fix 1 that should fix our licensing issue in horizontal scaling mode. I’ll report back the results. Hopefully this will complete our upgrade from HP Service Manager 7.11 to 9.20
HP Service Manager and MySql
November 1, 2010
HP Service Manager is a database driven application and currently supports IBM DB2, Oracle and Microsoft SQL Server. I prefer SQL Server because of the myriad of fixes that come out for Oracle every release of Service Manager and the ‘late-to-the-game’ support of IBM DB2.
HP should seriously consider including binary drivers for MySQL. MySQL is a perfectly good platform for the enterprise and HP Service Manager is uniquely positioned to use it, even the older versions. Two simple reasons…
- HP Service Manager does not use stored procedures, triggers, views or any of the other database specific programming techniques that would add a lot of development time or complexity to subsequent HP Service Manager releases.
- Many customers are already looking at running on Linux because of the low cost to purchase and support it, MySQL is the perfect compliment. Runs on Linux, free and easy to support.
For these two reasons alone HP should build drivers into Service Manager for MySQL. In fact, any MySQL only customers or even customers who may only run Linux may exclude HP Service Manager from their lists of possible software specifically because it does not support MySQL. Because of the current un-ease between HP and Oracle, HP really needs to consider another database platform. Please HP, consider MySQL.
Upgrading to HP Service Manager 9.20 from HP Service Manager 7.11 Part 3
October 29, 2010
HP has determined that Patch 1 for HP Service Manager 9.20 does have a defect regarding licensing in horizontal scaling mode and is releasing a hot fix to remediate that. When it comes out, I’ll post the results.
Upgrading to HP Service Manager 9.20 from HP Service Manager 7.11 Part 2
October 26, 2010
Well, we moved our upgrade to HP Service Manager 9.20 from HP Service Manager 7.11 into our Test environment.
I decided that we would not use the custom upgrade, but rather, would build our own upgrade unload package that contains only the objects that we touched post-upgrade. The list was rather short and revolved mostly around the changes we made when we cleaned up the datadict records. I felt that building the custom upgrade would:
- Be too complex and take too long to run.
- Not get all the objects that we modified anyway and we’d end up building our own unload script.
- Be unneccessary as we are already tracking all of our changes on our ‘build documentation’ and it is very easy to build an unload script from that.
- Possibly be a waste of time as we may find things that we need to move into Test from Dev that we missed and would have to end up re-building the entire thing over again.
We did build a purge script to get rid of NEW920xxx triggers and display options, because those fire or show up no matter what the name. All of the triggers that were renamed NEW920 were triggers that we had tailored using JavaScript to set some of the updated by, closed by, etc fields to store both the name and id of the specific user.
So far, we haven’t run into too many issues, other than the ones that are fixed by HP SM 9.20 patch 1.
However, we did find a problem with HP SM 9.20 patch 1 in a horizontally scaled environment. The application servers are validating their licenses against the local machine’s IP address instead of the load balancer’s IP address. Because we are on a *.*.42.* IP address license and our app servers run on a *.*.47.* license, the license was failing on the app servers. HP did notifiy us that it is a defect in Patch 1 and will be fixed with Patch 1 Hot Fix 1. We probably have a very unique environment and I’m guessing most customers would not have this issue. But if you are Horizontally scaled and thinking about going to Service Manager 9.20, I would hold off until this Hot Fix is released.
Upgrading to HP Service Manager 9.20
October 20, 2010
Since one of our clients decided to be an early adopter of HP Service Manger 9.20, I decided it would be interesting to track our upgrade process. We are mostly completed with the upgrade and it went suprisingly well. We hit a snag early on, but it was due to moving the upgrade files to the linux server accidently in ASCII mode, instead of Binary mode. The load transfer produced some strange errors which lead us down the path of Oracle issues (which are another story entirely).
I am happy to relate that the upgrade from HP Service Manager 7.11 to HP Service Manager 9.20 is much easier and smoother than previous upgrades, at least for this client. No messing around with old SCDB files, no major architectural changes, a much improved web experience, etc, etc, etc.
Did we have any issues? One major one, but it is fixed by HF 1 (we’re on Oracle, which I don’t normally recommend, but it is really up to the client’s overall architecture team what the enterprise is standardizing on). Other than that, because we planned well when we implemented our tailoring, we had very little code-merging to do. The biggest issues have been the extra display options and triggers that were added as NEW920*, but we just created a purge script to rid ourselves of those. We have about 3 weeks of work so far invested in this upgrade x 3 full time developers, but to be honest, 75% of what we’re doing is clean-up of datadicts for the advanced search capability which was needed pre-upgrade and we used this opportunity to clean them up.
This week we’ll be upgrading our Test system and next Tuesday, the testing team will hammer away at our relase for two full weeks of regression testing.
Our biggest question right now is: “Do we build a custom upgrade?”
I’m leaning towards no. I’ve had issues building custom upgrades in the past. Two reasons:
1. Sometimes it just crashes building it for no apparent reason (older versions).
2. The custom upgrade doesn’t always include everything you change in the system and there’s no good way to know what it included until you test it, which necessitates making a note of every object you changed during the upgrade and re-checking that they all made it anyway!
So, the plan is (for right now anyway) to build a custom unload containing our merged/updated objects, and loading that into the Test system once we’ve run the standard upgrade. We’ll see how that goes. It’s how we’ve pretty much had to do most of our upgrades in the past for our clients, and we’ve done dozens of them! We seem to have the best luck doing it this way and I don’t believe 9.20 has enough changes for it to change our strategy.
We have tried to install SM 9.20 patch 1 and have run into a problem with licensing in our Horizontal scaling environment. We’re working with support to try to resolve, so we’re stuck with a couple known issues that may plague us until we get that installed:
1. Random oracle errors. HF1 resolves them, but we decided to wait around for patch 1 to apply it all at once. They only show up in the log, but really make themselves apparent when you try to select records out of Views that are grouped. Yuck.
2. Checkboxes and DVD conditions in the web client. They simply don’t work in 9.2 web client. If you have any checkboxes with DVD, the web client doesn’t apply the logic properly. We’ve verified patch 1 fixes this issue in a sandbox environment.
Stuff we’re happy that HP Service Manager 9.20 fixes:
1. Choose Selected. When selecting multiple records in HP Service Manager 7.11 or earlier versions, you are stuck with their terrible ‘multiple selection’ off/on switch. This works, but it’s very cludgy and you can’t really tell what you’ve already selected. This really hurts us in places like our tailord screlation functionality, that allows the user to select multiple records at the same time to relate to a single record (i.e. selecting 25 incidents to relate to a problem record all in one action). Thank goodness this is finally fixed! Now, you can just select all the records in your result set, then choose ‘Choose Selected’ and it copies them all to your array of combo box. It is a great improvement and one of the main reasons we upgraded to 9.20
2. The web client. It’s much improved. Faster, nicer looking, compressed javascript, no more inset scrolling! If you look at the code base on the web server, it’s much larger now, which is a very good thing. Service Manager 9.20, meet Web 2.0! Finally!
3. Views and inboxes. There were some strange inconsistencies when using this, especially for power users. Most of those issues seem to be cleared up.
HP Service Manager SLA – Defining SLA’s (Part Two)
September 28, 2010
Defining Service Level Agreements in HP Service Manager – Part Two
This is a two-part post. The first part can be found here.
Now, the four screenshots above are basically the “plumbing” that must be setup in order to setup the SLA module to work with the incidents module (or any module that you want SLA to be setup for). Let’s take a look at now how this actually will work in practice on an actual incident ticket when this plumbing is setup:
So, let’s assume that we would open up a Priority 1 Incident ticket:
 Click for full size |
So, since we opened up a Priority 1 Incident Ticket in the screenshot above, AND since we coded the SLA module to work with the Incidents Module, we note now (in the screenshot below) that our incident has been opened with the base SLA that we setup (named “Base Monitoring SLA for IT services”) and since we coded the “P1 Incident” SLO to be active on the incident when a Priority 1 Incident has been opened, the “P1 Incident” SLO (taken from the base SLA on every ticket) is shown and is now Actively Running (as seen by the Status of “Running” below). Now, note the “Expiration” time below. This is the calculated expiration time of this SLO on this incident ticket based on the 02:00:00 time interval we defined on the SLO in the 2nd Screenshot above and based on the calendar we defined on that SLO for when the clock should be active. Also, this “Next Expiration” time is the time that the ticket must go from “Open” to Closed” that is based on how we setup the SLO in the system – this is the way we defined this SLO on the backend:
 Click for full size |
FURTHER NOTES ABOUT THE SCREENSHOT ABOVE:
- So wrapping this all up then, we can code SLOs similar to this to be based on many different fields than just the priority field. We could key off of the severity field, the category field, or both, the business service field, or other fields and then those SLOs would be the active ones.
- Note the “Upcoming Alerts” section in the screenshot above as well. These are those same alerts that we coded into the SLO record to be sent out at various points in the lifecycle of our SLO. Please note that on these alerts, we can also code other things to happen as well like setting certain values in fields on the incident ticket and etc etc when those alerts fire.
- Please also note that if the defined time limit for this SLO is not reached (meaning the ticket has not gone to “Closed” by the listed expiration date determined by the SLO), the Status (currently seen as “Running”) for that SLO goes to “Breached” and a checkbox on the Incident ticket becomes visible and it is checked. This is very key for reporting as reports can be written to show which incidents are in a breached status.
- Lastly, we can have more than one SLO running on these incident tickets (or tickets from any module you want SLA running with) as well if you so choose. We just would have to code them to do this. For instance, we could have one SLO be active to time from a status of say, “Open” to “Work In Progress”. Once that status is reached on the ticket, you could have another SLO go into effect to time “Work in Progress” to “Closed”. Many other combinations like this can be arranged as well.
Finally, If we were to close our incident from our example:
 Click for full size |
We would then be able to look at our SLA section on that same incident ticket and see that the SLO has been “Achieved” (Again, this would say “Breached” if this ticket was not closed in the allotted time interval given for this SLO on this incident ticket):
 Click for full size |
adsf
REASONS FOR USING THE SLA MODULE
Here are a couple reasons for using the SLA module:
- As you have seen from the above example, the base SLA on the ticket is just the holder from which the correct SLOs are pulled on those tickets based on the criteria that those SLOs have to meet in order to be active on the ticket. This means that the SLOs and not the SLA do the timing and measuring in SM 9.20. In this regard, those SLOs are the mechanisms that effectively time and measure the given time limits that have been defined for each ticket to go to a status of “Closed” (or to whatever status we define at the SLO level). In doing this, users have a clear cut area on the ticket to see how much time they have to work the ticket and when exactly they are expected to have that ticket worked.
- SLOs on these tickets are/can be cleanly setup to send out alerts to key users, managers etc at all times throughout the lifecycle of the given SLO time limit allotted on any given ticket. This allows key persons in an organization to keep tabs on all tickets that are out there and if they are being completed in a timely manner.
- SLOs give key users in the organization a clean look into which tickets are in a “breach” status. In this regard, key users are able to easily tell which tickets are being worked in a timely manner and which ones are not.
- Finally (this kind of merges into the next topic), there is a central area inside of SM 9.20 where all SLO data is held. This gives administrators and developers the ability to accurately and easily report on the SLA statistics gathered for every ticket generated in the system that is setup with the SLA module.
SLA Reporting
There is a table in Service Manager 9.20 named “sloresponse.” This table holds a record of every “Active” and “Inactive” SLO attached to a ticket in the system. The screenshot below is an example of the SLO Response record that has been pulled up from our SLO example used in Section 1 above. Note first the “Related Table Name” and “Related ID” fields. The values in these two fields in the screenshot below are “probsummary” and “IM10149” respectively. These field basically give the information about the ticket that the SLO is tied to. In this case in the screenshot below, this SLO is tied to an incident ticket (as incident tickets are stored on the backend in the “probsummary” table in SM 9.20) with the unique number of “IM10149.” So, this allows a report writer to tie the “sloresponse” table to the probsummary table in order to effectively join these two tables. Also, pay attention to the “Active” checkbox seen circled in the screenshot below. This tells whether the SLO is active or not active on the ticket. Finally, note the “Current Status” field. This tells what is happening / what has happened with the SLO whether it was “Achieved”, is still “Running”, or if it was “Breached”. There are other fields below as well that can be used in an effective SLA report like “Expiration”, “Start Time”, “End Time”, etc etc. In this regard users have a central area where they can retrieve very useful information about the SLOs in their system.
 Click for full size |
NOTES ABOUT THE ABOVE:
- Please note that a report writer would most likely connect to these tables on the backend in SQL via an ODBC driver. The “probsummary” table in SM 9.20 is mapped out to the “PROBSUMMARYMX” table(s) (where “X” is a number) on the backend in SQL. Likewise, the “sloresponse” table in SM 9.20 is mapped out to the “SLORESPONSEMX” tables (where “X” is a number) on the backend in SQL. These two tables would be joined together by the unique ticket number field like I explained above in order to pull info back on the report for the tickets and the SLOs that are tied to these tickets.
- Please also note that due to performance concerns, we at Stratacom have seen many times in the past an external reporting database setup and created that will house mirrored information from the Prod database. This will allow a broad set of reporting users (if that is the case for your implementation) the ability to run multiple reports on a non live Production database. Direct reporting connections to the Prod database do not present performance issues unless multiple reports by multiple users are taken throughout the work day.
If you would like a free PDF version of this document for distribution within your organization please contact us.
HP Service Manager SLA – Defining SLA’s (Part One)
September 28, 2010
Defining Service Level Agreements in HP Service Manager
This document is intended to help guide you toward defining your Service Level Agreement Module Setup in Service Manager.
1. DEFINING SLA (IN SM 9.20); DEFINING SLO (IN SM 9.20) .
In Service Manager, an SLA (Service Level Agreement) becomes the “holder” of various SLOs (Service Level Objectives) that we can define based on many different sets of criteria. The way we at Stratacom have always setup the SLA module is to have one default SLA on every ticket of every module that SLA is being implemented with. The ticket then will pick out the correct SLO(s) to use from that Base SLA based on the information found on the incident ticket. For example, if your organization wanted to implement the SLA module to work inside the Incident Module, we would code the SLA module to make sure that we get the same Base SLA on each of the tickets opened inside the incident module. ***What this then allows us to do is have access to the full listing of that base SLA’s SLOs. So, defining SLO then: (Service Level Objective) An SLO is the mechanism that we would use on an incident ticket to measure the given time limit that is allotted to “work” that ticket based on the items in that ticket like severity, category, business service etc. (basically the time that is allotted to push that ticket from “Open” to “Closed” – or from “Open” to any incident status that is wanted based on the ticket criteria.). We can code any amount of SLOs based on any given criteria on any ticket in the system (not just incident tickets, but through to any ticket for any module that we would setup SLA for). See the rest of this document for a further outline of this principle.
Example of the Base SLA setup in Service Manager:
This is an example of a Base SLA (named “Base Monitoring SLA for IT services” below) that will be found on every incident ticket (or ticket from any module that SLA is setup for). Notice this SLA has all of the SLOs we would want for any incident ticket defined (Note however, that we could define SLOs for any ticket from any Module here other than just incidents). Pay particular attention to the SLOs circled in Red on the bottom of the screenshot:
 Click for Full Size Image |
Now, if we were to double click on the “P1 Incident” SLO record from the SLA in the screenshot above, you will see this SLO record in the screenshot below. Things to note from this screenshot are: ***The Condition Field – This is the field where we define what criteria the incident ticket must meet for this SLO to become active on an incident ticket. We can code this field to key off of a priority or a severity, a category, a business service, or any criteria at all on any incident ticket (or for any ticket from any module that you would setup SLA for). The example below then, based on the condition field, just says, make this SLO active on an incident when that Incident ticket is opened with a priority of 1. Note below the value for the “Service Area” field is “Incidents’” – this is where we define what type of ticket this SLO will be active for. Therefore, in the case below based on the contents of the “Condition” field and the “Service Area” field, this SLO will go into effect when a Priority 1 Incident ticket is opened. Now, note the “Initial State” and “Final State” fields below and the “Duration Field”. These fields have the values “Open”, “Closed”, and “02:00:00” in them respectively. So! This means that when a Priority 1 Incident ticket is opened, this SLO will go into effect on that incident ticket and a 2 hour (02:00:00) time limit will be given for the ticket to go from a status of Open to Closed. So, wrapping this all up then, in this regard, we can code many different SLOs to be active in different situations on incident tickets (or on any ticket from any module for that matter). Finally, note the “Alerts” array below – this is an area where can code alerts to go out to certain users, managers etc. at different percentages of the total time limit given for that SLO. Below, we have coded an Alert to be sent out to various users when 50% of the time limit has been reached on the incident and when the SLO has been breached from a time limit perspective on the incident:
 Click for full size |
Now, if we were to look at the “Schedule” field in the SLO– we can tie what’s called a “Calendar” record to this SLO – this Calendar record indicates when the clock should be timing our given time interval and when it should be inactive. In the screenshot below, we note the value in this “Schedule” field is “day”:
 Click for full size |
Now, clicking on the “Lookglass” Button to the right of that schedule field (in the screenshot above) takes us to the “day” calendar record. This calendar record is the actual record that tells the clock on the incident when to time and when not to time that time interval we are measuring on the incident ticket for that SLO:
 Click for full size |
This article is continued in Service Level Agreements Overview Part Two.
How to Track Structured Arrays in Activity Actions
September 17, 2010
Tracking structured arrays in activity actions
Since structured arrays are more complex than a character or number field, adding this information to the activity actions requires additional javascript coding. We will use an example of work effort data to demonstrate how to accomplish this.
Here is the work.effort structure from the dbdict.
 Work effort structure from db dict |
Once we have put all the pieces together, the activity actions will display all the entries from the work.effort array before and after the change. First, lets take a look at the javascript code that is used to manipulate the array data. This function can be added to an existing javascript library or you can create a new one to house it. We have put this in a script library called General. Editor’s note – due to formatting the items below may not be completely readable. Contact us for a complimentary full copy of this article
function formatStructArray(oldrecord, newrecord, structure) {
var oldStructure = eval("oldrecord."+structure); // Create a variable to house the name of the structure
var newStructure = eval("newrecord."+structure);
var oldDataOutput = "";
var i = 0;
for (i in oldStructure) { // Loop through the old structure to get each individual array line
var arrayLine = oldStructure[i];
var ii = 0;
for (ii in arrayLine) { // Loop through and format each line of the array
var sepii = ii; sepii++;
if (sepii == system.functions.lng(arrayLine)) {var separator="";} else {var separator=" | ";}
var oldDataOutput = oldDataOutput+arrayLine[ii]+separator;
}
oldDataOutput = oldDataOutput+"\n"; // Insert a line break after each array line.
}
var newDataOutput = "";
var i = 0;
for (i in newStructure) { // Loop through the new structure to get each individual array line
arrayLine = newStructure[i];
var ii = 0;
for (ii in arrayLine) { // Loop through and format each line of the array
var sepii = ii; sepii++;
if (sepii == system.functions.lng(arrayLine)) {var separator="";} else {var separator=" | ";}
var newDataOutput = newDataOutput+arrayLine[ii]+separator;
}
newDataOutput = newDataOutput+"\n"; // Insert a line break after each array line
}
var finalDataOutput = structure+" has changed from \n"+oldDataOutput+" to \n"+newDataOutput;
return finalDataOutput; // Return the entire string
}
Next we need to call the javascript from the activityactions table that corresponds to where the structured array is located. In our case it is the cm3r table and we are evoking it when the record is updated. This will call our javascript code which returns our formatted information to be placed in the activitycm3r table.
|
After adding this code, whenever we make changes to the work.effort structured array, these changes will be logged for future use.
 |
Unlocking the Service Manager Database
September 10, 2010
How to Unlock the HP Service Manager Database
Moving your Service Manager (SM) database from one instance of the application to another is an important process for any SM developer/manager. It can be used to keep your all your environments (PROD, DEV, TEST, etc) in sync. It can also be used to switch from your main application server to a backup one with minimal downtime.
When SM is first installed, it creates a record (“scdb.system”) in the INFOOLDM1 table. This record is tied back to the machine on which the install was originally performed. This may cause problems if you copy or point the database to another instance. Fortunately there is a parameter for SM that resets the scdb.system record. This will basically remove the scdb.system record from the INFOOLDM1 table, and as a result, remove the potential for any machine name errors.
This command will also be useful to those who are using a cluster setup and have encountered scdb.system lock issues with one or more of the nodes trying to access the database. By running this command, it will allow all the nodes access to the database information that they need, thus eliminating the errors.
Syntax: sm -unlockdatabase
Run Location: RUN directory of the new install of SM 7.11 or higher
Adding Conditions to a Link Record in HP Service Manager
July 28, 2010
How to add conditions to your link record.
Lets say that you always want to always keep the phone number that is entered by the user for a particular ticket regardless of what is in the contact record. This may come about if you have a telephone number for a contact that is only applicable to that ticket. Lets take a look at how to do this.
First we want to save the old values, so in the pre fill expressions we will add:
$save.field=field in $File;
We would repeat this step for all the fields we are going to check if they have changed.
Next we need to add the conditional expressions in the post fill expressions. Don’t forget to cleanup your variables when you are finished:
if (field in $File ~= $save.field) then (field in $File=$save.field);
cleanup($save.field);
This will leave the fill value in the record unless it is different from the initial value, in which case it will replace the fill value with the saved value from the previous step.
Or you could use this technique to tie a particular type of telephone number to the priority of the ticket. Lets use the office number for low priority, and the cell for high priority. First we add variables in place of the “fill to” values (where the field on the form would usually be located) for all the phone numbers we might use.
fill to fill from
$work.num contact.work.phone
$cell.num contact.cell.phone
Then in the post fill expressions we need to add code to use the correct telephone number based on the value of priority (always cleanup your used variables)
if (priority in $File=”low”) then (contact.phone in $File=$work.num);
if (priority in $File=”high”) then (contact.phone in $File=$cell.num);
cleanup($work.num);cleanup($cell.num);
This same technique could be used in a variety of ways including conditional fill of other fields based on certain fill values or even modifying the values that are being generated by a fill. Although the code we used is rather simple, it is powerful and indeed a valuable tool in Service Manager.