Reactivating the My Oracle Support autocomplete

This post is an updated version of the original one here (in Brazilian Portuguese).

I'm a Siebel CRM certified professional and I use My Oracle Support some couple of times during a week.

That said, it would be required that I type my login and password every time that I want to go in the website. Well, that is not very fun because even if you want your browser will not remember those values.

I strong disagree with such website configuration: if I want to keep my credentials saved within the browser, that's my problem, not Oracle's. A simple "remember me" check box would be far more polite.

In the meantime, Oracle's website is still HTML with steroids at the end of your HTTP request. Even if they disable the browser login reminder it is still possible to enable it. And that's the trick I'm posting here.

The restriction applied by Oracle is an HTML tag called autocomplete. What it does is tell to the browser if it can or cannot save values from form fields and automatically fill them in again when you come back. If the autocomplete=off, the web browser will not even try to save those values for you.

Nowadays several browsers have tools to access the HTML of the HTTP response and enable the user to change it in memory. Mozilla Firefox, my preferable web browser, has such tools.

There are some bookmarklets that would, theoretically, change those configurations automatically, but the ones that I tried didn't work. But it is still possible to change them manually.

First, install the Firebug plug-in into Firefox.

Then, after restarting Firefox, go to the My Oracle Support website login page and click the "sign-in" button.

The login form will be shown to you (mine is in Brazilian Portuguese, but that doesn't matter). Open the Firebug (use the F12 keyboard shortcut if you can't find the related menu option). You will see something like the screen-shot below:

Just ignore that the form shown has a value for the login field.

In the lower window the Firebug plug-in will show you the source of the HTML. Press CTRL+F and type "autocomplete" as shown in the screen-shot and press the next button. The value of the property will be "off", disabling Firefox for trying to save the login and password.

After that, select the value of the property by left clicking on it: Firebug will offer to change this value. Go ahead and replace "off" with "on".

Now it is just a matter to type your login and password and access the My Oracle Support as you would do normally.

Testing time: logout and go back to the login page.

In the form, double click with the left button in the login field. Firefox will offer to you the login typed previously even though the form from My Oracle Support has the autocomplete=off again.

Finally, select the suggested login and Firefox will fill in both form fields for you. Yes, it is that simple.

Get Siebel Tools 8.1 working with Windows 7

Alright boys and girls... all you know that Microsoft is always innovating: they keep creating new annoyances for each new MS Windows version they release. Today is the day to be annoyed by Windows 7 default file system permissions.

Some couple of days ago I got my old notebook replaced by a shinny new one. The downside is that I had to reinstall and reconfigure a lot of stuff, including Siebel Tools.

I know Siebel Tools 8.1 does not officially supports Windows 7, but there is no way I'll be able to go back to Windows XP (unfortunately in this case).

After running the Siebel Tools setup program as administrator, I got a non-working Siebel Tools: I could not even find out what was going on because I didn't have any permission to create log files under \Log directory.

After fixing that, it was also necessary to change permissions to the sse_data.dbf file since my user got no write rights on it. Obviously I got some permissions issue (maybe because I executed the setup program as Administrator?) even my user being part of the group Administrators of my notebook. I tried the not so fancy solution trying to give me full permissions for all files/directories under the Tools directory.

I didn't work... don't ask my why. Looks like the permission dialog does not work as expected. I tried to grab permissions several times, even tried to put my user as owner of all objects... no results.

I was able to open Tools but take a look of what I got after trying to "Edit Web Layout" of a applet:

Not cool. Probably more permissions issues. This is what I got in the respective log file:

2021 2013-03-25 17:07:28 0000-00-00 00:00:00 -0300 00000000 001 003f 0001 09 siebdev 9796 4412 C:\Siebel\8.1\Tools\log\siebdev.log 8.1.1.6 [21233] ENU
ObjMgrLog    Error    1    0000000251502644:0    2013-03-25 17:07:28    (filetransport.cpp (495)) SBL-GEN-10116: Error acquiring file lock
 
ObjMgrBusServiceLog    Error    1    0000000251502644:0    2013-03-25 17:07:28    (eaixmlprtsvc.cpp (348)) SBL-EAI-04261: Error getting XML from file 'standard.xml'.
 
ObjMgrLog    Error    1    0000000251502644:0    2013-03-25 17:08:45    (filetransport.cpp (495)) SBL-GEN-10116: Error acquiring file lock
ObjMgrBusServiceLog    Error    1    0000000251502644:0    2013-03-25 17:08:45    (eaixmlprtsvc.cpp (348)) SBL-EAI-04261: Error getting XML from file 'C:\Siebel\8.1\Tools\bin\expression_builder.xml'.

ObjMgrBusServiceLog    Error    1    0000000251502644:0    2013-03-25 17:08:45    (ebservice.cpp (3326)) SBL-DEV-61159: No valid Expression Builder could be found for the field Name on business component Repository Applet.

As always, going down to a terminal give me some more powerful options.

First I used the program Takeown from Microsoft itself: it just put everything under my user as proprietary by using it's recursive argument.

takeown /f C:\Siebel\8.1\Tools /r

After that, I went to a Windows Powershell prompt and did the following:

$newACL = Get-Acl C:\Siebel\8.1\Tools
Get-ChildItem C:\Siebel\8.1\Tools -Recurse -Force | Set-Acl -AclObject $newACL

If you know a bit of Powershell you will notice that I got a "ACL model" from the Tools directory itself: at least this directory I could put my desired permissions, the problem was to replicate this configuration for it's children objects. That's why I used it's ACL to replicate the configuration with the Get-ChildItem and Set-Acl cmdlets.

That's it: Siebel Tools was back to work. Of course I probably gave much more permissions to the folders than it was necessary, but anyway, life is too short to go looking for all necessary permissions on a not-available-for-users document from Oracle telling me what is required or not.

Improving bulk inserts on SQLite

One of these days I decided that I needed to have a way to transport data from Siebel SQLAnywhere local database to anything that I could review information without having to install any Siebel application for it. My choice to go was SQLite and Perl to extract the data.

SQLite is far more "transportable" than SQL Anywhere, specially if you don't need all the fancy features it has when compared with SQLite.

First I checked if SQL::Translator wouldn't do the job, but it seems SQL Anywhere syntax is not supported by now. Then, after playing around with Perl DBI, DBD::ODBC (yes, Siebel local databases still uses ODBC, don't ask me why) and DBD::SQLite, I got something working that could check all SIEBEL schema tables DDL, create the tables into SQLite database and populate those tables with data. After all I got something like a "data dumper".

Unfortunately, performance was not that good. Specifically talking about the computer that I used for that (a old notebook with encrypted HD), the I/O was a performance hog: perl interpreter was not getting even 20% of all processor power available but the insert steps where really slow.

First thing when doing bulk inserts with DBI is to be sure to use binding parameters, which in fact was already applied:

my $dest_insert =
    'INSERT INTO '
  . $table . ' ('
  . join( ', ', @quoted_columns )
  . ') VALUES('
  . join( ', ', ( map { '?' } @quoted_columns ) ) . ')';

my $insert_sth = $sqlite_dbh->prepare($dest_insert);
$select_sth->execute();

while ( my $row = $select_sth->fetchrow_arrayref() ) {

    for ( my $i = 0 ; $i < scalar(@columns) ; $i++ ) {
        $insert_sth->bind_param( ( $i + 1 ),
        $row->[$i], $columns[$i]->sql_type() );
    }

    $insert_sth->execute();
    # and code goes on
}

With my homework done, I went to another basic step: check the storage back-end.

The thing is, the notebook was "plagued" with disk encryption: this means that everything in that HD that needs to be read/write must pass through the trouble to be encrypted/decrypted. While quite secure, doing I/O in these conditions are really bad for bulk inserts.

I decided then to go with a RAM disk: such solutions are uncommon in Microsoft realm, but after some configuration I got some good improvement. The problem is, the notebook didn't have enough RAM to have a RAM disk size that could hold the complete database file and keep everything else running... I ended exhausting all RAM memory available.

Next steps where taking a look about features of SQLite that could help on that... and the little database didn't let me down. Here is a quick list of the features that needed to be turned on:

• cache_size pragma
• synchronous pragma
• Autocommit (disabled at SQLite connection): SQLite oficial documentation and DBD::SQLite POD
• Create INSERT batches and COMMIT control

By enabling those features I was able to get something in the middle of good performance and not exhausting the notebook resources.

One observation: COMMIT control in SQLite is really weird. I finished by using a combination to disabling Autocommit during database connecting and disabling it again after each COMMIT executed.