What's wrong with profile attributes?

As a general rule, we shouldn't allow developers to use profile attributes. Looking back, I've probably used about 1 profile attribute a year, to accomplish some pretty edgy (read: hacky) things. People normally use them to pass data around like from a business component to an applet or a from the server to the browser. Here's why they're a bad choice...

Profile attributes have no scope, and no namespace. Profile attributes are set at the session level so changes made in one piece of code can inadvertently affect code in other areas. The fact that there are no namespaces makes the problem worse, because your chances of accidentally using a name someone else used are greater (although you could come up with some namespace scheme).

Profile attributes screw your ability to debug. Because you can't find all the places your profile attribute might be set or unset, debugging becomes much tougher.

Profile attributes screw your ability to refactor. For the same reasons that your ability to debug is screwed, so is your ability to refactor. One of the basic things you need to be able to do when refactoring is finding all the places you used variable x. Well if variable x is a profile attribute, good luck!

Getting a profile attribute from the client is costly. Not everyone understands this. Your profile attributes do not exist in the client. So when you try to read them from browser script, Siebel needs to do a round-trip to the server to get it. That's a round-trip for each profile attribute you get or set.

In short, if you think you need to use a profile attribute to accomplish something, think again! If you still think you need a profile attribute, hit yourself on the head and think again!*

* The same advice pretty much applies for shared globals as well.

Java Data Bean Performance

I'm not supposed to be working on Siebel anymore, but something keeps pulling me back to do odd jobs.

One of my coworkers was complaining about the slow performance when integrating with Siebel using the Siebel Java Data Bean. He was just creating some buscomp records and setting a bunch of field values along the way.

I'm not very familiar with the Siebel Java Data Bean, but my theory is that each buscomp operation (NewRecord, SetFieldValue, SetFieldValue, SetFieldValue, etc) was triggering a round trip to post changes to the server. There aren't a lot of hard rules in my book for improving performance, but avoiding the network is one of them (avoiding the database is another). [Can anyone confirm my theory that the Java Data Bean is heavy on posting changes?]

So how can we avoid the network in this case? Two ideas immediately come to mind. Without giving it away, one of them still uses the Siebel Java Data Bean, the other uses a different solution altogether. Either of them would allow you to create a bunch of new records all in a single round-trip.

Can you guess what I'm thinking of? Any additional ideas that may help here?

[We did a quick POC and were able to get a 90% reduction in execution time with one of these approaches]