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.
What is a good or recommend alternative?
ReplyDeleteDitto. While I don't condone Profile Attributes as the first option, they are helpful because they can be referenced in calculated fields, whereas global variables cannot. This comes in handy when an integration process needs to avoid read-only and required fields set by BC or field User Properties. Just set a profile attribute in the integration workflow, then have the BC User Properties evaluate the value of that attribute as a part of its decision to enforce the read only or required attributes.
ReplyDeleteI think the only other alternative is to set a temporary value on the record itself, or to store the value on the user's employee or position record.
If there is a better alternative, let us know!
Thanks for the post.
ReplyDeleteCheck out this website for the largest Collection of Siebel Interview Questions and Answers
Siebel Interview Questions and Answers
Thanks
Joya
Some previous comments have requested alternatives, I like the author don't really have any. As such I'll provide a few alternatives to the issues raised by Mike.
ReplyDeleteDocumentation:
This is a great tool that can be used to note what Profile Attributes are being used, and where they are being used. You can also document a naming convention for your Profile Attributes to ensure logical & functional naming so that re-use or cross-use becomes highly unlikely.
Debugging:
You're writing Siebel code, so I'm SURE the first thing you did was create a logging script that you could turn on and off with a system property so that you could always track what your variables were and what your code was doing, right? Otherwise, it won't matter WHAT alternative you choose, you'll be dead in the water when you need to debug.
Browser Script:
I very rarely used browser script, but the cost of passing in or even retrieving a Profile Attribute would be less costly than a trip to the data level, or alternatively carrying around an extra data element for the off-times it IS being called by your browser script. What's that? Your browser script is called too frequently? Time for a redesign to get that code to the server level.
Hi Darstard,
ReplyDeleteWhat is that tool to note Profile attributes being used?? Pls give details.
Thanks.