title: Profile attribute being magically set in Siebel
body: <p>We have a <em>very</em> weird issue in our Siebel 7.8 application.</p>
  
  <p>In the <code>Application_Start</code> 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:</p>
  
  <pre class="lang-js prettyprint-override"><code>if (userHasSuperpowers) {
      TheApplication().SetProfileAttr("CanFly", "Y");
  } else {
      // CanFly is not set, and GetProfileAttr("CanFly") returns ''
  }
  </code></pre>
  
  <p>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 <code>GetProfileAttr</code>... it returns <code>'Y'</code> instead of <code>''</code>.</p>
  
  <p>I've checked the code. <em>A lot</em>. I've put traces everywhere, and I'm 100% sure that when the last line of the <code>Application_Start</code> event executes, the attribute is still empty. However, in the first <code>Applet_Load</code> event after the login (in the <code>HLS Salutation Applet (HLS Home)</code> applet), its value has already changed to <code>'Y'</code>. <strong>Why!!?</strong> I've looked everywhere, but I can't find anywhere else where we'd be doing a <code>SetProfileAttr</code>. So far, I've ruled out:</p>
  
  <ul>
  <li>Every browser and server script for <em>all</em> our applets, application, BCs and business services.</li>
  <li>All the runtime business services (the ones defined directly in the application instead of the SRF).</li>
  <li>The <code>Personalization Profile</code> business component fields.</li>
  <li>SmartScripts (not that they would matter in this particular scenario, I just mention them to acknowledge that you can set profile attributes there too).</li>
  <li>Workflows: every step invoking the <code>SIS OM PMT Service</code> method <code>Set Profile Attribute</code>.</li>
  <li>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 <em>really</em> don't think Siebel is using the same name for its own profile attributes :).</li>
  </ul>
  
  <p>But wait, there is more, I left the best part for last: the problem <strong>only happens in our development environment</strong>!</p>
  
  <ul>
  <li>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.</li>
  <li>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.</li>
  <li>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 <code>'Y'</code>.</li>
  <li>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... <em>seriously</em>...).</li>
  </ul>
  
  <p><strong>Where else could I search the profile attribute being set?</strong> 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?</p>
  
  <p>Is there any way to trace profile attribute changes somehow? Maybe rising some loglevel?</p>
  
  <p>How can I find out at least what's being executed after the <code>Application_Start</code>, before loading the first applet?</p>
  
  <p>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).</p>
  
  <hr>
  
  <p><strong>Update</strong>: following Ranjith R's suggestions, I've also checked:</p>
  
  <ul>
  <li>Other vanilla business services which could be also invoked from a workflow to set a profile attr: <code>User Registration &gt; SetProfileAttr</code>, <code>SessionAccessService &gt; SetProfileAttr</code> and <code>ISS Promotion Agreement Manager &gt; SetProfileAttributes</code>.</li>
  <li>Runtime events setting profile attributes directly or using a business service (we don't have any runtime events apart from the vanilla ones).</li>
  <li>Business services being called from <a href="http://docs.oracle.com/cd/E14004_01/books/OrderMgtInfra/OrdMgtInfraValidation.html" rel="nofollow">DVMs</a> (we only have vanilla data validation rules, and none of them apply to our buscomps).</li>
  </ul>
  
  <p>Still no luck...</p>