IMPORTANT NOTE :: THE TIME HAS FINALLY ARRIVED. WITH THE RECENT UPDATES TO 11.5.10 (RUP7 AND POSSIBLY ONE PATCH RELEASE BEFORE THAT), THE PROPOSED METHOD HERE NO LONGER WORKS. IT WAS EXPECTED TO COME AT SOME POINT IF FOR CERTAIN WITH R12 WHERE MOD_PLSQL IS RETIRED FROM THE EBS ENVIRONMENT ENTIRELY. SO FOR A POINT OF HISTORY AND INTEREST, I WILL LEAVE THIS UP, BUT AGAIN IT WILL CEASE TO WORK PRIOR TO ARRIVING AT R12. I HAD HOPED FOR DIFFERENT, BUT THATS OKAY.

If you are looking for a way to build your own Single Sign On to Oracle Self Service Environment, here is an idea that you might like to try (Note : This solution requires 10g RUP patch instance or greater) :

Note: There is a remote chance that the authentication method used here will not function properly under an R12 environment. My guess right now is that R12 will leverage some form of LDAP. However, this is not to be considered a detractor. Reason I say that is because I think that the redirect logic will continue to be valid... only the authentication process would be non-applicable. So, I am suspecting that under R12, I will only need to comment out the authentication logic and leave the redirect logic in place... since under LDAP environments, I would already be pre-authenticated when entering the direct connect logic discussed here. Of course I will have to wait till sometime next year (2008) to find that out, which is when we will start looking at what impact R12 will have to our environment.

I am presuming that if you are reading this, you have some working knowledge of Oracle Applications and how you log into the application. Given that, most everyone knows that we can post the following values to the https://your domain/OA_HTML/fndvald.jsp :

username this is the username your wanting to login with
password this is the password your wanting to login with
rmode this will always be 2
home_url this is the url you wish to be returned to when exiting

Now you might ask yourself, where do I get my password from... you will need to take the responsibility of people maintaining their password on their own, and generate it for them via provided APIs. We store keys which when run against an algorithm match a password associated to that individuals user account. You could build your own encryption algorithm, or you could use Oracle's DBMS_OBSUFUCATION package. However, I won't digress into that any more than what I have said already.

Pages: 1 · 2

Link: http://gettingreal.37signals.com/ch02_Build_Less.php

Underdo your competition

Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they're spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It's an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can't think ahead, they can only think behind. They don't lead, they follow.

If you want to build a company that follows, you might as well put down this book now.

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

We'll cover the concept of less throughout this book, but for starters, less means:

Less features
Less options/preferences
Less people and corporate structure
Less meetings and abstractions
Less promises

Something else that might be worthy of adding to 37Signals essay...

One of the suggestions I would add to the essay is:

“Keep less data”

Keeping a lot of data is a pain. Indexing, partitioning, tuning, backup and recovery – everything is more painful when you have terabytes instead of gigabytes. And when it comes to cleaning data out, it always causes endless debates on how long to keep the data (3 month? 7 years?) and different life-cycle options (move to “old data” system? archiving? how to purge? What is the process?).
What’s more, a lot of the time customers would really prefer we won’t keep the data. Maybe its privacy concerns (when we keep a lot of search history) or difficulty in generating meaningful reports or just plain confusion caused by all those old projects floating around.
Google taught us that all the data should be stored forever. But perhaps your business can win by keeping less data.

Pages: 1 · 2

Link: http://oradbdev.mathiasmagnusson.com/2010/01/the-case-for-case.html

By Mathias Magnusson, November 2009

The CASE keyword was introduced in 8i (9i for PL*SQL) and essentially replaces DECODE. I confess to never liking decode, though it is powerful, it is also ugly and sometimes close to unreadable. Case introduces a few things decode cannot do, but it makes it more accessible to those who write SQL occasionally.

In this document we will look closer at the keyword CASE in SQL. While it often is treated just as a
readable replacement for decode, it has a few more uses. Readability is a feature in itself, but the most misunderstood part of case among developers is how flexible it is.

This article will only look at the basic use and not try to dig into every aspect of it. Thus it is geared more towards the intermediate SQL user than to the experts.

A case for CASE

Link: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::NO::P11_QUESTION_ID:54226589195717#PAGETOP

Interesting running thread on Asktom.oracle.com regarding datamasking. I provided my two cents into the picture.

Does Oracle provide a package or function for data masking ? For example, in a
development environment, for data protection purposes, the information of the table
customer needs to be masked.

create table customer (last_name varchar2(25), first_name varchar2(25), address
varchar2(25));
insert into customer values('Doe', 'John', '10 someroad st');

In the production environment, if we do a select on customer, the result would be without
any surprise:

select *
from customer;

LAST_NAME FIRST_NAME ADDRESS
-------------- -------------- --------------------
Doe John 10 someroad st

In the development environment, the same information needs to be masked for something
like:

LAST_NAME FIRST_NAME ADDRESS
-------------- -------------- --------------------
Ahd Uiea 55 xxxx ue

It doesn't really need to make sense, it doesn't need to be readable. Just needs to be
masked. Does Oracle supply anything for that purpose at all ? I tried to find but didn't
have much success. I found a third party software that will do the job. If you want to, I
can post its name here.

Thanks Tom and happy 2006.

Gleisson Henrique

and we said...

No, we can "hide" the information (Oracle 9i provides for row hiding and Oracle 10g
provided for row and/or column hiding)

But data obfuscation - no, it cannot do that. You actually need to physically obscure
the data itself prior to storage (and it had better be a one way obfuscation). Think
about things like indexes and such.

Don't forget, as soon as you start obscuring data, you start to loose the natural
distribution of data. Do not be surprised when your obfuscated system behaves entirely
differently from your "clear text" system - clustering factors, data lengths,
distributions of values - all will be radically different.

I'll post to see if anyone has a suggestion on a tool to use sparingly on names/addresses
and the like.

Link: http://venturehacks.com/articles/minimum-viable-product

I recently say down with Venture Hacks for an interview. Part one is up on their site today, in text, audio and slide format. Here are some topics and excerpts of what we covered, edited lightly for how I wish I'd said it at the time. To hear full audio and a complete transcript, click through to Venture Hacks.

Is "release early, release often" enough?
The issue there is, if you just follow the release early, release often mantra, you find yourself running around in circles, because you ship code, you get some feedback from people, you do a focus group.

Customers say,”Give me feature X,” “Give me feature Y,” and sometimes you do what they want, maybe sometimes you’re going to do what you want, and then they get mad at you. Pretty soon you’re chasing your own tail a little bit because you’re not operating against a clear, long-term vision of what you’re trying to accomplish.

The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

Solving the chicken-and-egg platform problem
Developers don’t want to develop unless there are customers who are there to buy their products, and customers don’t want to come on the platform unless developers are there selling them something useful.

What we did is we took early adopter developers and we told them a story about how IMVU was going to take over the world and be this really powerful product for mainstream customers ... and we gave them an economic incentive that said, the earlier you get on board with the platform, the bigger your take is going to be for derivative products that get created down the road.

We shipped a product that had almost no customers — certainly no mainstream customers — but, because we had told that story effectively and we really understood those early adopter developers, we got a ton of them on the platform developing. They felt like they were in the middle of a gold rush, despite the fact that there was really no evidence to support that belief yet.

Starting with just a landing page

What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

What we would have found out if we were doing that experiment is 0% of people would have clicked through, which means it doesn’t matter what is on the second page.

The first page is so bad, not because it is badly designed, but because the features are wrong that you don’t need to go through the effort of building out the product. So we wished we had done that, and we did make that mistake really

Overcoming the fear of the false negative

As long as you’re not afraid of the false negative, that is, if you don’t get discouraged because you’ve built your first paper prototype of it and shown it to people and nobody wanted it. That can’t mean that like you give up because,”Oh, forget it, we’ll never make it.” You’ve got to say, "OK, well then let’s iterate some more.”

If you keep iterating at it, you keep making it a little bit more sophisticated, at a certain point after you’ve been through 10 iterations, that you still got no uptake whatsoever, and the feedback you’re getting from customers is still a yawn, you might say to yourself,”You know what? We’re not moving in the right direction. In fact, we’re past the point of minimum viable product. This just isn’t a viable product.”

Read the rest of the interview at Venture Hacks.