Unlimited Session Timeout2014-07-24T09:21:00.001-07:00
There are a lot of security admins out there that are going to hate me for this post. There are a lot of system administrators, developers, and users, however, that will LOVE me for this post. The code I'm about to share with you will keep the logged in PeopleSoft user's session active as long as the user has a browser window open that points to a PeopleSoft instance. Why would you do this? I can think of two reasons:
Before I show you how to keep the logged in user's session active, let's talk about security... Session timeouts exist for two reasons (at least two):
We can "lock the door" without timing out the server side session with strong policies on the workstation: password protected screen savers, etc.
What values should you use for the warning and timeout? As low as possible, but not so low you create too much network chatter. If the browser makes an ajax request on the warning interval and a user has 10 windows open, then that means the user will trigger up to 10 Ajax requests within the warning interval window. Now multiply that by the number of logged in users at any given moment. See how this could add up?
PeopleCode Coding Discipline2014-07-16T10:23:00.000-07:00
How does all of this fit into PeopleCode? Forget about code formatting preferences. Application Designer has its own code formatting ideas. But there are other best practices that can help you write better code with fewer defects (fewer defects = better code). By following best practices your code will be easier to read, you will be more productive, and your users will be happier because you deliver better solutions faster.
Even though best practices usually result in code that is more efficient to process, that isn't really the point. Computers can interpret just about anything. Compilers and interpreters are really good at eliminating useless words and resolving seemingly incomprehensible logic. I love Martin Fowler's quote, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." Best practices are really about writing code that humans can easily comprehend. For example, avoid complex logic (including double negatives, or any negative logic, for that matter), keep your method and function code short, etc. If you write some code, leave it for a night, and then come back the next day and either need to read lots of comments to figure it out or spend a few minutes "remembering" what that code does, then the code is probably too complex. The problem with complex code is that it is easily misinterpreted by humans. Another problem with complex code is we actually ignore it when trying to resolve problems. We know it takes time to digest complex code, so we avoid it, preferring to test simple code first. Why waste time trying to understand complex code if it might be functioning properly?
Today's Quest Newsletter contained a link to 10 Bad Coding Practices That Wreck Software Development Projects. These are language agnostic practices that we can easily apply to PeopleSoft development.
If I were to summarize Coding best practices, I think I would do it like this: two.sentenc.es. Now, arguably, short does not equal comprehensible. There are programmers that err on the terse side because it is clever. This is true, often short code is clever. It is also hard to read. Most of us, however, err the other way. E. F. Schumacher said, "Any fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction." Schumacher died in 1977, so this problem is not new.
Computer programming is about communication. As programmers we have two audiences:
Here is why I think discipline and best practices are critical for good PeopleCode:
We use PeopleCode to create business rules, but PeopleCode is NOT a business rules language. PeopleCode is a Metadata manipulation language. (Note: this is purely my opinion)
Here is why I believe PeopleCode is for metadata, not business rules: PeopleCode only has Metadata objects: records, fields, SQL, components, menus, etc. These are all metadata. These are the low level API's we use to write business logic. Consider the following PeopleCode:
Local record &rec = CreateRecord(Record.PSOPRDEFN);Local field &descr;&rec.SelectByKey("jimsoprid");&descr = &rec.GetField(Field.OPRDEFNDESC);&descr.Value = "Jim Marion";&rec.Update();
This code implements business logic, but does so by manipulating metadata objects. PeopleCode metadata objects are building blocks for business logic. If we were to rewrite this using a business logic language, it would probably look something like this:
Local User &u = GetUser("jimsoprid");&u.descr = "Jim Marion";&u.Update();
And this is why discipline and best practices are SO important for PeopleCode developers: We are trying to speak business logic with a metadata vocabulary. We start with a communication deficit. It is like trying to teach advanced weaving using an automobile mechanics vocabulary. The two subjects have different vocabularies. But if you combine the words correctly, you can communicate the same meaning.
PeopleTools 8.54 is GA!2014-07-14T13:28:00.002-07:00
To learn more read the PeopleTools announcement or visit the hosted 8.54 PeopleBooks. I can't wait for the new demo images!
Collaborate 2014 Schedule2014-03-21T16:48:00.000-07:00
I am just getting caught up after HEUG Alliance. What a great conference! As always, it was a lot of fun visiting with customers, partners, and colleagues. I heard some amazing stories and learned a few new tricks. Now it is time for the next conference: Collaborate 2014 is only a couple of weeks away. I love hearing your stories and challenges. Hunt me down and share your stories with me. Besides the demo grounds, here are two places you will find me:
I fly out Thursday night, but if I can make it, I plan to attend Mike Doyle's session Advanced PeopleSoft Development Techniques, which contains examples based on my book PeoleSoft PeopleTools Tips & Techniques.
Alliance 2014 Agenda2014-02-24T20:44:00.000-08:00
It is hard to believe it has been a year since the HEUG Alliance 2013. We had a lot of fun in Indianapolis. I have been reviewing the 2014 session lineup and it looks pretty exciting. I must say that I am very pleased to see several sessions on REST, iScripts, and User Experience. With Alliance 2014 just a couple of weeks away, I wanted to make sure I posted my schedule:
I also plan to spend some time in the PeopleSoft demo grounds. Please stop by and visit with me or one of my colleagues. We would love to say hello and show you some new ideas for configuring PeopleSoft applications.
If you are presenting at Alliance, please feel free to promote your session in the comments below.
Quest Technology Series PeopleTools Presentation2013-12-17T17:30:00.001-08:00
If you are a Quest member and missed my PeopleTools Tips and Techniques presentation last week, you can watch the recording on Quest's site at http://www.questdirect.org/learn/2629061/.
Copyright © 2013 McGraw-Hill Global Education Holdings, LLC Any