Search code examples
siebel

Profile attribute being magically set in Siebel

We have a very weird issue in our Siebel 7.8 application.

In the Application_Start event we define a bunch of profile attributes, which determine if the logged user will be allowed to perform certain operations or not. The code is something like this:

if (userHasSuperpowers) {
    TheApplication().SetProfileAttr("CanFly", "Y");
} else {
    // CanFly is not set, and GetProfileAttr("CanFly") returns ''
}

Everything works fine, except for one of these profile attributes. The conditions are not met, so we don't set its value. But when we check it using GetProfileAttr... it returns 'Y' instead of ''.

I've checked the code. A lot. I've put traces everywhere, and I'm 100% sure that when the last line of the Application_Start event executes, the attribute is still empty. However, in the first Applet_Load event after the login (in the HLS Salutation Applet (HLS Home) applet), its value has already changed to 'Y'. Why!!? I've looked everywhere, but I can't find anywhere else where we'd be doing a SetProfileAttr. So far, I've ruled out:

  • Every browser and server script for all our applets, application, BCs and business services.
  • All the runtime business services (the ones defined directly in the application instead of the SRF).
  • The Personalization Profile business component fields.
  • SmartScripts (not that they would matter in this particular scenario, I just mention them to acknowledge that you can set profile attributes there too).
  • Workflows: every step invoking the SIS OM PMT Service method Set Profile Attribute.
  • Siebel magically setting its value. The profile attribute name is custom made, in Spanish, and it contains our project name and a row_id. I really don't think Siebel is using the same name for its own profile attributes :).

But wait, there is more, I left the best part for last: the problem only happens in our development environment!

  • It's not an SRF issue: if we promote the same SRF to our testing or production environments, it works and returns the expected value.
  • It's not a data problem: still with the same SRF, I can use my local thick client, connecting to our development database with the same login and password, and it works fine too.
  • It's not a concurrency problem: we are testing with only one user logged in. And even if we had more, they wouldn't share sessions. And even if they did, the value wouldn't be always 'Y'.
  • It's not a temporary glitch, or something due to a wrong incremental compilation or a corrupted SRF: we have been experiencing this for at least 6 months (obviously, in that time frame, we've had dozens of different SRF files... all of them having the same problem, but only in development, and only if you use the server and not the dedicated client... seriously...).

Where else could I search the profile attribute being set? I've read that they can be persisted to the DB, but in order to do so, you have to define them as a field in a BC based on an S_PARTY extension table, right?

Is there any way to trace profile attribute changes somehow? Maybe rising some loglevel?

How can I find out at least what's being executed after the Application_Start, before loading the first applet?

Any other ideas? I tried checking the SQL spool file too, but didn't find anything suspicious there either (i.e., any of the queries we use to check the conditions, being run twice with different parameters).

Update: following Ranjith R's suggestions, I've also checked:

  • Other vanilla business services which could be also invoked from a workflow to set a profile attr: User Registration > SetProfileAttr, SessionAccessService > SetProfileAttr and ISS Promotion Agreement Manager > SetProfileAttributes.
  • Runtime events setting profile attributes directly or using a business service (we don't have any runtime events apart from the vanilla ones).
  • Business services being called from DVMs (we only have vanilla data validation rules, and none of them apply to our buscomps).

Still no luck...

Solution

  • Ok... finally we found what's happening:

    1. We access the URL to our server and get to the login page. This triggers a first Application_Start event, for the SADMIN user.
    2. We set the profile attributes in that session. SADMIN is the Siebel administrator user, so yes, he hasSuperpowers and therefore we do TheApplication().SetProfileAttr("CanFly", "Y");.
    3. The Application_Start event finishes.
    4. We enter our username and password in the login screen to access into Siebel. This triggers a second Application_Start event, this time for our user. This is the one I was monitoring with the trace files.
    5. We set the profile attributes again in the new session. Our user doesn't hasSuperpowers, so we don't set any value for the CanFly attribute.
    6. The Application_Start event finishes, and CanFly is still empty.
    7. Siebel merges both sessions into one before loading the first screen!! Or at least, it transfers over the profile attributes we had set for SADMIN.

    I'm sure it happens that way, for two reasons. First, we changed the profile attribute name to include the username too. And second, instead of storing just an "Y", we are storing now the current date:

    var time = (new Date()).getTime();
TheApplication().SetProfileAttr("CanFly_" + TheApplication().LoginName(), time);

    We end up having CanFly_SADMIN, but no CanFly_USER, and the time value stored is the same we see in the log file for step 2... which is smaller than any of the values for the *_USER attributes.

    So that's what happening. I still don't know why Siebel behaves this way, but that would be matter for another question. According to the Siebel bookshelf:

    The Start event is called when the client starts and again when the user interface is first displayed.

    ...but it doesn't say anythign about it being called from two different sessions, different users too, and then merging them together. It must be something misconfigured in our dev environment, considering it doesn't happen in the other ones.