Creating Alerts Using Siebel or OBIEE (OracleBI)

Delivers
you need to configure a database account to store data that the Siebel Scheduler uses.
This can be in an Oracle database, and therefore I created an account called
S_NQ_SCHED (the recommended account name) and ran some provided scripts to
create the necessary tables:

SQL> conn system/password@ora10g

Connected.
SQL> create user s_nq_sched
2 identified by password
3 default tablespace users
4 temporary tablespace temp
5 quota unlimited on users
6 /
User created.
SQL> grant connect
2 , create table
3 , create view
4 , create procedure
5 to s_nq_sched
6 /
Grant succeeded.
SQL> conn s_nq_sched/password@ora10g
Connected.
SQL> @c:\SiebelAnalytics\Schema\SAJobs.Oracle.sql
Table created.
... #d6dae5

Commit complete.
SQL> @c:\SiebelAnalytics\Schema\SAACCT.Oracle.sql
Table created.
Index created.
Index created.
Index created.

Next I need to set up a TNSNAMES entry to point to the user account I’ve just set up,
like this:
Now, I set up an ODBC System Data Source to point through to this user, using the
TNSNAMES.ORA entry I just created
The next step is to open your Job Manager. Go to File - > Configuration Options and
enter the schema and connection details for the scheduler schema. In my case it would be
S_NQ_SCHED schema.
4. Go to the General tab. If you had followed the default install, then leave everything
the same. Just enter in the Administrator usernames and passwords.
5. Go to the Mail tab and enter in your mail server details.
6. Open your instanceconfig.xml and add in the scheduler details. This step basically
lets the presentation server know about the machine and port details of the scheduler. By
default the scheduler port is 9705.

7. The next step is to run a cryptotools utility that would basically store the username
and password of the scheduler into an XML file called credentialstore.xml.

8. Go to {OracleBI}/web/bin from command prompt. Then enter in the following

command.

cryptotools credstore -add -infile OracleBIData_HOME/web/config/credentialstore.xml

D:\OracleBI\web\bin>cryptotools credstore -add -infile D:\OracleBIData\web\confi

g\credentialstore.xml

>Credential Alias: admin

>Credential "admin" already exists. Do you want to overwrite it? y/n (y):

>Username: Administrator

>Password: *************

>Do you want to encrypt the password? y/n (y): n

>File "D:\OracleBIData\web\config\credentialstore.xml" exists. Do you want to ov

erwrite it? y/n (y): y

9. The next step is to add the details of this credentialstore.xml file into the
instanceconfig.xml.
Once this is done you should be able to schedule and create new ibots. The best and quick
way to check whether the configuration has been done properly is to save a sample ibot.
If you are able to properly save one then your configuration has been properly set. For
more details refer the docs here.
This report tells me which warehouses have sold less than 20,000 units; I’m now going to
set up an alert that runs this report, and if any warehouses fall below the 20,000 limit,
have the scheduler send the report out to anyone who subscribes to the alert.

The next step then is to click on the “Delivers” link at the top of the page, and create
what’s called an iBot. An iBot is a process that runs to a schedule and performs a task,
which can be as simple as running my alert, or as complex as anything I can put together
as a script. iBots are also the way you pre-seed the cache - you run iBots that then run
commonly accessed reports after you’ve done a data load, and then the data your users
will require will be in the cache when they come to run their reports;

Once Delivers is running, it’s time to create the iBot. The Delivers home page gives you
a list of availalble iBots on the left-hand side, and options to create new iBots, customise
subscriptions and so on in the main area of the page.

The obvious next step then is to create a new iBot, and so I click on the first link. I’m
then presented with the elements that make up an iBot process.
For this simple example, I leave the priority as standard, and the data visibility as
personalised, so that the alert subscriber will only see the data they’re scoped for, as
opposed to the data the iBot creator can view. The interesting bit is the “Conditional
Request” section though, as this is where we create the test condition for the alert.
The way you accomplish this is to select a Siebel Answers report (or a “request” in Siebel
Analytics jargon) which will be run when the iBot executes. If the report returns one row
or more, the iBot condition is satisfied and the process runs. Therefore, like the report I
picked earlier, you want one that runs and has a filter that corresponds to the alert you
want to create.

Once the request has been defined, the next step is to define the iBot schedule, the
recipients (the default is just you), the delivery content, which is usually the request that
you selected earlier, and the destinations.
Then, after waiting for the iBot to start up, I check back on my dashboard page, and yes,
the alert is there, just under the tabs and also up on the top right-hand side of the page,
along with the other Siebel Analytics application names:

When I click on the alert, I first get a page that lists out all of my current alerts, and then
when I click on one, I can see the figures that triggered the iBot.
If I’d got a mail server set up, I could have delivered the alert as an email, but for the time
being, this will do. It wasn’t all that difficult to set up (once you’ve gone through the
scheduler configuration process) and as long as you’ve got the reports on hand on which
to base the alerts, it doesn’t take all that long to get up and running.