Have you noticed the extraordinary evolution of Twitter as an entirely unique medium of communication? I have. And I've also been having daydreams (call me an OBIEE geek) about coming up with a simple and brilliant way to create a Twitter feed from a scheduled OBIEE report, using something along the lines of either BI Publisher or iBots. Looking into the Twitter API documentation, I started getting excited by the fact that their API follows the REST protocol which essentially uses HTTP requests and responses for the exchange of data. Wow, I thought, I could use the HTTP Delivery method that is new to OBIEE 10.1.3.4 ! How exciting! (OK fine, I truly am an OBIEE geek.)
So we should be able to try a quick and simple test to send a notification to my Twitter profile upon completion of a scheduled BI Publisher report! Awww, not so fast: BIP's HTTP Delivery option implements the "GET" method -- the REST protocol, and likewise the Twitter API, calls for any data update to be made using the "POST" method. Maybe in future versions of OBIEE we'll be able to configure the HTTP Delivery option, and, who knows, even the parameter/values that are sent. For now, this feature won't work with Twitter.
I wonder what iBots can do for me? Perhaps 10.1.3.4 also added HTTP Delivery to "Destinations"? Argh, no such luck -- I'm sure we'll see something interesting in 11g but until then we're out of luck. But what the heck, let's take a poke at the "Advanced" features... Well isn't that interesting! I can call another iBot, a custom script, a Workflow or -- behold -- a custom Java application! Moreover I can even call one or more of these entities in any combination, both when iBot conditions are satisfied AND when no records are returned by the conditional request. The mind reels! And look at the options I have when calling a Custom Script or Java Program -- in addition to the obvious ability to specify the program itself, but I can also specify whether to pass to this program the results of the conditional report (and what format to use) OR the content itself OR simply nothing at all. Moreover I can send any number of additional custom parameters.
Clearly, with just a little bit of work, one could achieve my original objective by writing a simple Java program that reads the incoming parameters and/or dataset and POSTs the relevant information to the Twitter API.
But the real ramifications are much more profound: By using iBots to invoke Java interfaces into external ERP or CRM systems -- many of which offer a rich set of public Java APIs -- the OBIEE platform can become a powerful and flexible system for an enlightened business to coordinate automated actions in richly nuanced response to the variety of heterogenous data made availble to the user's fingertips by OBIEE. I understand OBIEE 11g is taking active integration between OBIEE and business processes to a whole new level with its Action Framework -- but until then, the Custom Java Program feature gives us plenty of possibilities to chew on.
Now, who's ready to write that Java Twitter interface?
This is the second installment in a series of posts in which I’ve been discussing the implementation of High Availability within an OBIEE environment.Much of what we’ll be discussing was in included in an Oracle eSeminar which I recently viewed on the topic.In my original post, I gave the broad strokes in regards to HA and provided the basic overall architecture of a High Availability deployment.This time, we’ll start to dive into some of the specifics regarding configuration which will be necessary to implement a true “shared nothing” HA environment.
Each Presentation Server can be configured to talk with multiple web servers,Java hosts, BI Servers, and BI Schedulers.In this installment we’ll cover the Presentation Catalog, web server, and Java host connections to the Presentation Servers as well as how the user is affected when a Presentation Server fails. The diagram below is a subset of the one shown in my original post on the subject.This figure shows only the components of the HA architecture which we’ll be looking at today.
First, let’s discuss the web client behavior in a High Availability environment.When a user begins a session, the web client is bound to a specific Presentation Service and subsequent requests will be sent to that same service. When a Presentation Service failure occurs, the error is relayed back to the browser and any unsaved data will be lost.Upon logging in again, the user will be bound to another available Presentation Service.Two exceptions to this rule would be if the user is using SSO or if the Presentation Services plug-in is configured to automatically reconnect to another server.In these cases, there may still be a loss of session state. There will also be a time lag to recognize the failed server. This lag will be dependent on plug-in ping settings which we’ll get to eventually.
Any iBots which fail to complete as a result of a Presentation Service failure will result in an error being passed to the BI Scheduler Server and will be included in the log file. When the next available Presentation Service becomes available, the job is rerun without impact and will start again at the step in which it originally failed.
Next, we’ll look at how we would like our Presentation Services to share the Presentation Catalog. There are two basic options which can be deployed.The first option is to use a shared file system. All presentation servers have access to the same shared files.This is the simplest approach and, as I mentioned in my last post, is recommended by Oracle.Alternatively, a more complex method of catalog replication can be deployed through the use of replication agents on each instance which will monitor a single instance for changes and sync other copies as necessary.Two-way replication, which involves making changes to multiple copies of the Presentation Catalog and attempting to keep them all in sync, is highly discouraged and should be avoided.As you can imagine, this method would make maintaining data integrity much more difficult and complicated.
If you’ll be using the shared file approach, the first step necessary will be to point each presentation server to the shared file path by editing the <Catalog> element of the instanceconfig.xml file.In addition, we should also make changes the Presentation Service cache settings.Keep in mind that each instance will have its own cache, which we’ll want to configure to ensure it won’t get stale.Oracle recommends adding the following settings to each configuration file:
Another piece of the puzzle will be to configure the presentation servers to work with multiple Java hosts. Once again, we must edit instanceconfig.xml to complete this task.This will involve listing the java host instances as shown below. The default Java Host port is 9810, but you can verify this by checking the OracleBI_Home\web\javahost\config\config.xml file.Simple load balancing will be performed in a round robin fashion between all instances listed in the config file.
<JavaHostProxy>
<Hosts>
<Host address=”<Javahost Machine1>” port=”9810”/>
<Host address=”<Javahost Machine2>” port=”9810”/>
</Hosts>
</JavaHostProxy>
You may also add an optional LoadBalance/Ping element. This element specifies the criteria for determining whether a Java Host is reachable.The ping element is not necessary if you wish to keep the default, which is 5 pings at 20 second intervals.
The final component we’ll look at today is the BI pres Services plug-in, which sits on the web servers.Here I’ll outline the changes necessary on each web server instance both for IIS and Java-based servers.IIS web servers will use the ISAPI plug-in, and the config file for this plug-in can be found in the OracleBIData_Home\web\config directory.The only element you must configure is the Hosts element, in which you will list the host and port of all Presentation Service instances.You may also optionally configure the LoadBalancer element which controls the autoroute feature. The default setting is false, which means that the user will receive an error if the current Presentation Server goes down.Setting this option to true would cause the server to attempt to connect to the next available Presentation Server without impact to the user.You also have the option of adding the ping element, which is the same element we just discussed when examining the Java host configuration.
The Java Servlet changes necessary for Java-based web server configuration are very similar to the ISAPI configuration mentioned above.You’ll need to edit the config file found in the OracleBI_Home\web\app\WEB-INF directory to include all Presentation Server host and port pairs. The <oracle.bi.presentation.sawconnect.loadbalance.AlwaysKeepSessionAffiliation> element is equivalent to the <LoadBalancer> element with the ISAPI plug-in and should be set to “Y” or “N”.
Next time we’ll continue to discuss the BI Presentation Server and how it will be configured to talk with the BI Server and Scheduler…
iBots are intelligence agents or Bots. These agents are triggered by a schedule or condition that in turn generates a request to perform analytics on data based upon defined criteria.
Where do iBots originate from?
Oracle BI Delivers is the application to create, modify and manage iBots.
How do iBots work?
In order to understand how an iBot works, we should start by first creating a new iBot from scratch.
Navigate to "Delivers" ......
.....and click the link to create a new iBot.
From here, we will tackle each individual tab to get an understanding of what the process is to create an iBot.
1) Overview tab This view is a summary of the current settings for the selected iBot.
One can navigate to specific settings by clicking on the links in the summary or clicking on the tabs located at the top.
2) General tab
This is where the priority of the iBot and how to send the delivery content are set.
The priority options are low, normal, or high. The priority works with the delivery profile for a user to determine the destination for alerts of different priorities.
The following Data Visibility options affect the customization of the delivery content: Personalized (individual data visibility): - uses the data visibility of each recipient to customize iBot delivery content for each recipient. Note that The Run As field if not available.
Not personalized (use the Run As user's data visibility): - sends the iBot's delivery content to the specified recipients. All users receive the same content as if they were the user specified in the Run As field.
Not personalized (use iBot owner’s data visibility): - sends the iBot’s delivery content to the specified recipients using the data visibility of the specified user (Run As box field) who created the iBot. In other words, all recipients will receive the content that's viewable to the Run As user.
3) Conditional Request tab
This page is used to select a request to trigger the iBot. The results of the conditional request determine whether the iBot sends its delivery content and initiates any subsequent actions:
- If the request does not return any rows, the iBot is not triggered.
- If the request returns at least one row, the iBot sends its delivery content and initiates any subsequent actions.
Requests can be chained together to create complex conditional logic.
4) Schedule tab iBots can be executed based on a specified schedule. You can define a starting date and time for the iBot, a recurrence schedule, and an ending date.
5) Recipients tab Use this tab to select the users and groups to receive the delivery content of the iBot.
One has the ability to select specific individual users and groups to receive the contents of the iBot. **You can select multiple users by holding down the SHIFT or CTRL keys and selecting adjacent or nonadjacent users.**
Also, one can select which users or groups can subscribe to the iBot. This allows users the flexibility to receive and view the contents of the iBot AND customize prompted filter values for columns.
Keep in mind that in order to publish iBots, the content must be shared.
6) Delivery Content tab Use the Delivery Content tab to specify the type of content to deliver with the iBot, such as a dashboard page or a saved request. The delivery format for the content can also be selected, such as HTML, PDF, XLS, CSV, or text.
The contents of the Headline field will appear as the subject of the request.
The two field text boxes below allows one to attach a message when the iBot is delivered depending on if the iBot is delivered as an attachment or if there are no records returned by the conditional request.
7) Destinations tab The User Destinations and Specific Devices portions of this tab are pretty self explanatory.
As for System Services...
Oracle BI Server Cache is used for seeding cache.
(** To have the cache created for individual users, the Personalized option for data visibility in the General tab must be selected.)
Disconnected Application Cache is only available to companies that have licensed Disconnected Analytics.
(** To have the disconnected application cache created for individual users, the Personalized(individual data visibility) option for Data Visibility in the General tab must be selected.)
(**Nonpersonalized data is not used for Disconnected Analytics users.)
8) Advanced tab
Use the Advanced tab to specify one or more actions to execute after the iBot is finished running.
Actions include the execution of other iBots, custom scripts, custom Java programs or Workflows.
For further reading on iBots, I would suggest downloading the Oracle Business Intelligence Answers, Delivers, and Interactive Dashboards User Guide to read further about creating iBots. What I provided is just a brief glimpse of iBots.
Opinions expressed are entirely our own and do not reflect the position of BI Consulting Group, Oracle or any other corporation. Do NOT take anything written here, unless explicitly mentioned otherwise, to be BICG policy.
Posts
