Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

SD4.5 - a good SP

Highlighted
David Borojevic
Frequent Visitor

SD4.5 - a good SP

We are currently SD4.5 sp17 and have decided not to migrate to 5.1. So we are now interested in progressing to a later SP. I can see the latest is SP23 dated 25th of May.

Have those upgraded found this stable? Any newly discoveredissues? And should we jump via any interim SPs (eg SP18 first?).

Thanks for any feedback.
7 REPLIES
George M. Meneg
Honored Contributor

Re: SD4.5 - a good SP

Hello David,

SP23 was released two weeks ago, it's kinda early for deployment to production systems. At the test systems it behaves nicely and till now have find no issues but we have not began extended testing yet.

About the second question, the SPs are cumulative, so really you need only to install the latest SP.
menes fhtagn
De Naeyer Robby
Super Collector

Re: SD4.5 - a good SP

Hi David,

My advice is to migrate your testing environment directly to SP23 and start testing.

I have several customers already running SP23 in there testing environment and no issues yet.

And as George mentioned do not directly migrate your production environment to this SP, first do some intensive testing your self and check back here on the forum to see if anybody else has any problems.
David Borojevic
Frequent Visitor

Re: SD4.5 - a good SP

Thanks,

I since found that a Java upgrade is required for SP19 and above. I'll continue with the wade through the doco and posts.

Most of the info on SP23 looks like bug fixes so hopefully if not too much functionality introduced maybe fewer bugs introduced?

ITSM008978 is interesting. There was a work around for using UI notification messages on value changed where you start the rule as a "Before Item is changed", set the User Notification then go back and change to "When Value has changed". I believe SP18 or 19 stopped this from working? Do I read ITSM008978 correctly - it is now OK if the message is "informational" (versus "Error/Warning"). Currently we have a few UI rules done using the old workaround and would not like to lose them.

Cheers
Mark O'Loughlin
Honored Contributor

Re: SD4.5 - a good SP

HI

SP 20 contains the last of the "new" features to be introduced via an SP. After that you get fixes with the additional packs (which all incluce the SP 20 features.

Go straight to the latest SP (no interm jump) but as always test, test and test.

Gerry Allardice
Honored Contributor

Re: SD4.5 - a good SP

David,

Not sure if you have any rules which sent emails when a fields it updated. eg. Customer Update.

e.g.Rule is
When Customer Update is not empty
Send Email
Clear Customer Update.

After SP21 the sending of email becomes asynchronous and there is no guarantee it is sent before the next line in the rule clears the field.

I have had to modifiy this type of thing to use an extra field and an extra rule.
The first rule copies the Customer Update to the new field and then clears Customer Update. The Email rule fires off the new field not being empty and sends the email, but unlike the original rule does not clear the field.

Also note that ServicePages go to Tomcat 5 somewhere between SP17 and SP23. This is described in one of the PDFs.

Regards
Gerry
David Borojevic
Frequent Visitor

Re: SD4.5 - a good SP

Hi Gerry,

Thanks Heaps for a heads up on that one. We do have one (or more) rules that do exactly that. I reckon lots of people would get caught out on that.

I understand your solution but how about this alternative:

1) First Rule fires when "Email Caller" field is modified and not empty. Action=send email and set Boolean Field EmailCallerClearItNow=True

2) Second rule fires when EmailSent boolean changes and = true. Actions: Clear Email Caller field, and set EmailCallerClearItNow=False

Does this sound OK or have I missed your point. We also Audit our EmailCaller field - but I suspect this would not be impacted in anyway?

Cheers
Gerry Allardice
Honored Contributor

Re: SD4.5 - a good SP

David,
I think you could still get caught with this as the email sending is asynchronous and does not require any rules to wait for it. If it gets delayed for any reason (e.g slow resonse from SMTP server) the rules will fire independantly and could complete before the email gets sent.

Regards
Gerry
//Add this to "OnDomLoad" event