[Obiee Admin Tool For Mac
Betty Neyhart
The other day I was playing with getting OWB11gR2, which at the time of this writing, has only been released under Linux and Solaris, to run under Windows. In the pursuing comments Jon Mead threw down the gauntlet and asked if I could figure out a way to run the OBIEE Administration tool under Linux. Like many of you might know, most everything in the OBIEE stack runs on Windows as well as various Unixes, but the Administration tool however is only available on Windows. The reason for that being that the tool is written using Microsoft Foundation Classes.
So I set out to give it a go. I picked a random Ubuntu VM image I had laying around and installed Wine (sudo apt-get install wine). After some failed attempts on trying to figure out which DLLs the admintool.exe uses I figured out that the Dependency Walker tool was just what I needed (I still would have preferred to have a proper Windows equivalence of the Unix tool ldd ). Looking at the dependent DLLs I quickly saw that most all of these libraries are contained in the %BIHOME%\server\bin directory. The tricky bit would be to get the MFC libraries in place. A quick Google search suggested to use the Winetricks gadget to install the .NET 2.0 libraries in to Wine
Now, we also need to have the software in place. So grab a complete copy of both the OracleBI and OracleBIData directories from a working Windows installation. Make sure to note the full path of your installation as you want to match the correct path (including drive letters) in Wine. Use the winecfg utility to map a Wine drive letter to the folder where you copied the OBIEE installation to. In my case I had OBIEE installed on E:\BI. I copied my installation to /mnt/hgfs/BI and configured Wine to map E: to /mnt/hgfs/
This seems to behave OK and I am happy with what we got. But I still want to be able to connect to an Online server. My Ubuntu has already a working OBIEE installation so I am keen to get the Oracle BI Server ODBC driver set up on my Wine. This is where the winetrick comes in handy again.
This gives me a working Microsoft ODBC for Oracle. A quick Windows Registry hack to register the e:\BI\OracleBI\server\Bin\NQSODBC.dll with the Wine Registry and we are on our way. First I exported the following key from my working Windows XP VM image: [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Oracle BI Server]. (Make sure to export it using a Win95 format). Import this key in to your wine installation, using wine regedit. Then create a new string value, called Oracle BI Server, in the [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\ODBC Drivers] key, and give it the value Installed. This will tell Wine where to look for your .DLL.
When you are reverse engineering tables in Oracle ODI, especially from large systems like EBS, you can hit an issue where the reverse engineering operation is successful but the table you import has no columns.This is caused by the access you have to the source system. If you are
Best practices are like a good guidebook that helps anyone work with a tool with ease. Industry standards in general provide what we should do and how we should do it and these are generally advice that comes from experts that have been time tested over a period of time.
The ContextIn my last blog post, we successfully loaded image data into an Oracle database table. Now, we will focus on building an Oracle function to connect this data with the OpenAI GPT-4o model for analysis. We will adapt the framework from a previous blog post where we used
This tutorial covers using the Oracle Business Intelligence (BI) Administration Tool (12.2.1.0.0) to build, modify, enhance, and manage an Oracle BI repository. You learned how to import metadata from a data source, simplify and reorganize the imported metadata into a business model, and then structure the business model for presentation to users who request business intelligence information via Oracle BI user interfaces. You learn to create calculated measures, hierarchies, aggregates, and time series measures.
This tutorial shows you how to build an Oracle BI metadata repository using the Oracle BI Administration Tool. You learn how to import metadata from data sources, simplify and reorganize the imported metadata into a business model, and then structure the business model for presentation to users who request business intelligence information via Oracle BI user interfaces.
To complete this tutorial you must have access to the BISAMPLE schema that is included with the Sample Application for Oracle Business Intelligence Suite Enterprise Edition Plus. There are two options for accessing the BISAMPLE schema:
The Physical layer defines the data sources to which Oracle BI Server submits queries and the relationships between physical databases and other data sources that are used to process multiple data source queries. The recommended way to populate the Physical layer is by importing metadata from databases and other data sources. The data sources can be of the same or different varieties. You can import schemas or portions of schemas from existing data sources. Additionally, you can create objects in the Physical layer manually.
When you import metadata, many of the properties of the data sources are configured automatically based on the information gathered during the import process. After import, you can also define other attributes of the physical data sources, such as join relationships, that might not exist in the data source metadata. There can be one or more data sources in the Physical layer, including databases, flat files, XML documents, and so forth. In this example, you import and configure tables from the BISAMPLE schema.
Enter user name and password for the data source. In this example the user name and password are both BISAMPLE. Recall that BISAMPLE is the name of the user/schema you created in the prerequisite section.
Close the View Data dialog box when you are done. It is a good idea to update row counts or view data after an import to verify connectivity. Viewing data or updating row count, if successful, tells you that your connection is configured correctly.
It is recommended that you use table aliases frequently in the Physical layer to eliminate extraneous joins and to include best practice naming conventions for physical table names. Right-click SAMP_TIME_DAY_D and select New Object > Alias to open the Physical Table dialog box.
Right-click one of the highlighted alias tables and select Physical Diagram > Selected Object(s) Only to open the Physical Diagram. Alternatively, you can click the Physical Diagram button on the toolbar.
Click the F1 Revenue table and then the D1 Time table. The Physical Foreign Key dialog box opens. It matters which table you click first. The join creates a one-to-many (1:N) relationship that joins the key column in the first table to a foreign key column in the second table.
Click No when prompted to check global consistency. Some of the more common checks are done in the Business Model and Mapping layer and Presentation layer. Since these layers are not defined yet, bypass this check until the other layers in the repository are built.
There are two main categories of logical tables: fact and dimension. Logical fact tables contain the measures by which an organization gauges its business operations and performance. Logical dimension tables contain the data used to qualify the facts.
Drag the four alias table from the Physical layer to the Sample Sales business model in the Business Model and Mapping layer. The tables are added to the Sample Sales business model. Notice that the three dimension tables have the same icon, whereas the F1 Revenue table has an icon with a # sign, indicating it is a fact table.
Because you dragged all tables simultaneously from the Physical layer onto the business model, the logical keys and joins are created automatically in the business model. This is because the keys and join relationships were already created in the Physical layer. However, you typically do not drag all physical tables simultaneously, except in very simple models. Later in this tutorial, you learn how to manually build logical keys and joins in the Business Model and Mapping layer. The process is very similar to building joins in the Physical layer.
Double-click any one of the joins in the diagram to open the Logical Join dialog box. In this example the join between D1 Time and F1 Revenue is selected.
Expand the D1 Time logical table. Notice that logical columns were created automatically for each table when you dragged the alias tables from the Physical layer to the BMM layer.
On the General tab, rename the D1 Time logical table source to LTS1 Time. Notice that the logical table to physical table mapping is defined in the "Map to these tables" section.
Rename BEG_OF_MONTH_WID to Beg of Mth Wid. This is the manual method for renaming objects. You can also rename an object and select Rename to manually rename an object.
Repeat the steps for the three remaining logical tables so that all logical columns from the Sample Sales business model are added to the right pane. Only the columns from F1 Revenue are shown in the screenshot.
In the Physical layer, expand the alias tables and confirm that all physical columns have not been renamed. The point here is you can change object names in the BMM layer without impacting object names in the Physical layer. When logical objects are renamed, the relationships between logical objects and physical objects are maintained by the logical column to physical column mappings.
795a8134c1