11-08-2013 02:00 AM
Using SM 9.30
Recently I loaded some new versions of forms (layouts) for notification emails. For several days the new versions were not being used. Looking at the forms using Forms Designer they were correct, they were the new versions. The old versions had been overwritten. After a previously scheduled full system restart suddenly the new versions were used.
I now have a similar situation. I have one new version of a forms layout with a correction to a URL. The URL is in a Label field. The new version is being used some of the time, but there are notification emails still being sent out with the old version. Using Forms Designer I can see the form has been overwritten with the new version as expected.
I can't do a full system restart but I urgently need to pick up the new version of this format.
Why is the old version still being used? Why only sometimes? Is it cached somewhere? Do I need to restart a process?
11-09-2013 01:47 AM
I've faced the same problem! and a system restart used to fix my problem too. Since you don't want to do that, don't know if restarting any single process will help but might as well try restarting the processes alert and problem, and lets see if it works.
11-09-2013 11:39 AM
if web clear the browser cache and if windows rename the service manager folder to service manager old and the let the system create folder automatically.
In Windows this folder will be located in windows>users>ur id>service manager.
11-10-2013 10:37 AM
My guess would be that you are using these notifications for Alerts? Nevertheless, I believe the problem comes from the fact that there are already schedule records for these alerts/notifications which were created with the old version of your forms.
Go to the "schedule" table and search for records where the background process is "problem". Go through the records and see what is the template that has been used. The HTML text should be on the 3rd row .. I don't remember on which tab though.
11-12-2013 07:06 AM
These notifications are used when an interaction is closed, not for alerts. There don't seem to be any records for these on the schedule table.
Some of these interactions were opened after the new version of the form was released (and overwrote the old version). So where is it getting the old version from? It doesn't exist any more on HPSM, it must be cached somewhere? One of the appservers?
The change is in the caption of a label field, in this case. In the previous cases a label field was deleted from the form, but was still appearing until the full system restart.
11-12-2013 07:32 AM
I use both WIndows client and web client, but the people closing the interactions that generate these notifications are using web client. Their sessions don't persist overnight so they have to login each day, and go through a load balancer to one of 6 appservers.
Does anyone know if the forms get loaded on login, like global lists do for example? Or are they cached in the appservers perhaps?
11-12-2013 07:42 AM
Ok, so here's what's happening.
Let's pretend you're a user and you go into Service Manager and start looking at an open Incident ticket (IM.update.incident). While you're looking at that record, someone else goes behind you and modifies the form using Form Designer. Even though the form you are looking at no longer exists because of the changes the other user made, you don't see the changes until you exit that IM record and go back into it. When you go back into the IM record, the system displays the new form for you.
The same sort of thing is happening here, only, instead of a user looking at the form, the system background processors are looking at the form.
When HPSM starts up, the background schedulers - like 'problem' and 'alert' - grab copies of the forms and hold on to those copies, rather than looking them up again each time a notification needs to send.
So, what you need to do is kill the background processor that is sending the notification. That will cause it to restart and grab your fresh copy. This is essentially what happens when you recycle the whole application. But, since you don't want to do that every time you modify a notification record, it's easier to kill an individual process.
Type 'status' in the command window, and you'll get taken to the System Status window. Find the name of the schedule processor that is sending out your notifications. Put a 'k' in the start of the line for that process and click the 'Execute Commands' button. That will kill that process. If you have the anubis process running, your process should automatically restart within a few minutes. If not, then you can start a process manually by clicking the 'Start Scheduler' and selecting the process you want to restart.
And that should do it.
11-27-2013 06:40 AM
I killed the 'problem' process, anubis restarted it but that didn't fix the problem.
However, only the new version has been emailed in the last week. So that counts as 'problem gone away' as far as I'm concerned.