PK
*Aoa, mimetypeapplication/epub+zipPK *A iTunesMetadata.plistZ
This chapter contains sample scripts that are appropriate in the context of a single OMB*Plus command statement. These examples provide the series of steps for using particular Warehouse Builder functionality.
This chapter includes sample scripts for the following tasks:
One possible use case is to perform mass update on repository metadata. Users can write the following script to add a primary key with local column ID for each table with name beginning in EDW inside the module MY_MODULE:
OMBCC MY_MODULE; foreach tableName [OMBLIST TABLE EDW*] { \ OMBCREATE TABLE '$tableName' \ ADD PRIMARY_KEY '$tableName_PK' SET REFERENCE COLUMNS ('ID');}
We can build even more powerful and useful script using if-then-else:
foreach tableName [OMBLIST TABLE EDW*] { \ set columnList [OMBRETRIEVE TABLE '$tableName' GET COLUMNS]; # Use lsearch to search for a name in a list if {[lsearch $columnList 'ID'] == -1} { OMBCREATE TABLE '$tableName' \ ADD COLUMN 'ID' \ SET PROPERTIES (DATATYPE, LENGTH, NOT_NULL) VALUES \ ('NUMBER', 10, 'true'); } }
The preceding script checks the list of tables which name begins with EDW whether each of them contains an ID column. If not, it will create an ID column for that table. Hence, executing the preceding script will guarantee that all tables with names beginning in EDW will have the ID column defined.
Another common use is for reporting purpose. The following script displays the properties of the table T1 and its column definitions on standard output:
#Displaying metadata of a table puts -nonewline "Please enter the table name: " gets stdin tableName puts "" puts "Report on $tableName" puts "=======================================" puts "Physical name = $tableName" puts "Logical name = [lindex [OMBRETRIEVE TABLE '$tableName' GET \ PROPERTIES(BUSINESS_NAME)] 0]" puts "Description = [lindex [OMBRETRIEVE TABLE '$tableName' GET \ PROPERTIES(DESCRIPTION)] 0]" puts "---------------------------------------" set columnList [OMBRETRIEVE TABLE '$tableName' GET COLUMNS] set i 1 foreach colName $columnList { set dt [lindex [OMBRETRIEVE TABLE '$tableName' COLUMN '$colName' GET \ PROPERTIES(DATATYPE)] 0] if { $dt == "VARCHAR2" } { set prop [OMBRETRIEVE TABLE '$tableName' COLUMN '$colName' GET PROPERTIES(LENGTH, NOT_NULL)] puts "Column $i: $colName datatype=VARCHAR2 length=[lindex $prop 0] \ not_null=[lindex $prop 1]" } elseif { $dt == "NUMBER" } { set prop [OMBRETRIEVE TABLE '$tableName' COLUMN '$colName' \ GET PROPERTIES(PRECISION, SCALE, NOT_NULL)] puts "Column $i: $colName datatype=NUMBER precision=[lindex $prop 0] \ scale=[lindex $prop 1] not_null=[lindex $prop 2]" } elseif { $dt == "DATE" } { set prop [OMBRETRIEVE TABLE '$tableName' COLUMN '$colName' GET \ PROPERTIES(NOT_NULL)] puts "Column $i: $colName datatype=DATE not_null=[lindex $prop 0]" } # end else incr i }
A sample output is like the following:
Physical name = T1 Logical name = Table 1 Description = This is my first table. ===================================== Column: ID datatype=NUMBER precision=0 scale=0 not_null=1 Column: NAME datatype=VARCHAR2 length=30 not_null=1 Column: VALUE datatype=VARCHAR2 length=100 not_null=0
Users can also take advantage of the validation service provided by scripting, like this:
set tableList [OMBLIST TABLES]; foreach tableName $tableList { if { [OMBCOMPILE TABLE '$tableName]' == "Invalid." } { set context [OMBDCC]; puts "Table $context/$tableName is invalid."; } }
The preceding script will tell users which table is invalid under the current module.
Another scenario we present is for a disabled user that relies on OMB*Plus interactive shell (and also some screen reading software for the disabled) to navigate through a Warehouse Builder repository:
OMB+> OMBCONNECT owb/owb@localhost:1521:dev901 Connected. OMB+> OMBLIST PROJECTS DIM_TEST_PROJ MY_PROJECT PROJ_ENDTOEND PROJ_RELATIONAL TEST_DIM_PROJ OMB+> OMBLIST PROJECTS .*RELATION.* PROJ_RELATIONAL OMB+> OMBCC 'PROJ_RELATIONAL' Context changed. OMB+> OMBDCC PROJECT /PROJ_RELATIONAL OMB+> set OMBPROMPT ON ON OMB+> OMBDCC PROJECT /PROJ_RELATIONAL /PROJ_RELATIONAL> /PROJ_RELATIONAL> OMBLIST ORACLE_MODULES WH /PROJ_RELATIONAL> OMBCC 'WH' Context changed. /PROJ_RELATIONAL/WH> OMBLIST TABLES PRODUCT PO /PROJ_RELATIONAL/WH> OMBRETRIEVE TABLE 'PO' GET COLUMNS OID PROD_ID ORDER_DATE CUSTNAME /PROJ_RELATIONAL/WH> OMBCC '..' Context changed. /PROJ_RELATIONAL> OMBCC '..' Context changed. /> /> OMBDISCONNECT Disconnected.
If you are an advanced Warehouse Builder user, you can design solutions that simplify routine tasks and implement best practices. You can develop these solutions, called experts, in the Expert Editor.
Experts are solutions that advanced users develop to automate routine or complex tasks using best practices.
For example, a common activity is extracting data from a flat file and loading that data into a table in Oracle Database. To accomplish this activity, users might take the following steps, in which they navigate a variety of user interfaces in Warehouse Builder:
Define a flat file module.
Identify the source file.
Specify the data format.
Define an external table.
Define an Oracle database module and location.
Define a mapping.
Validate, generate, and deploy all objects.
Execute the mapping.
To help users with this activity, you could design an expert that calls all the necessary user interfaces, provides customized instructions, and prompts users for input. In an expert, the steps are defined by tasks and the order of execution is defined by transitions.
Experts are reusable, shareable, and can access all areas of Warehouse Builder including user interfaces and the OMB*Plus scripting language. Experts can also call Java programs.
Figure 5-1 shows how an expert might look to a user. Three separate windows are displayed:
Progress Graph: Displays the expert in the same format as it appears on the editing canvas, but the executed transitions and the current task are highlighted. This window serves the same purpose as bread-crumbs, tracking the user's progress through the expert. It can also be a helpful debugging tool. You can set a property on the expert that controls whether the progress graph is displayed or hidden.
Task Assistant: Displays the name of the current task, its goal, and instructions for using it. You provide this information on the property sheets for the task as part of its definition. You can set a property on the expert that controls whether the task assistant is displayed or hidden.
Task Display: Tasks that obtain information from the user display various types of graphical user interfaces. Among these tasks are those that display Warehouse Builder components, such as the Object Editor, and those that provide basic functions, like the file selector shown in the figure. In this example, the user selects a file, and the filename is passed as an input parameter to the next task. You can also store the value in a variable to use later.
The Expert Editor provides the canvas and the palette that you need to create, modify, and deploy experts.
Figure 5-2 shows the Expert Editor with a sample expert. Tasks appear as icons on the canvas. The arrows connecting the tasks are transitions. Transitions identify the order in which the tasks are executed.
The Expert Editor is very similar to the Process Flow Editor. If you have created process flows, you will be able to adapt your knowledge very quickly to developing experts. However, there are important differences as well as important similarities.
Unit of Work: In a process flow, the unit of work is an activity. In an expert, the basic unit of work is a task.
Transitions: Both process flows and experts use transitions to connect the basic units of work. Transitions can be conditional.
Variables: Both process flows and experts enable you to define local variables to pass values from one task to another.
End tasks: Process flows have success, warning, and failure end activities, but experts have a single End task.
Subprocesses: You can design a process flow to open other process flows, and you can design an expert to open other experts. In this use, they are called nested experts.
Code: A process flow generates XML that conforms to the XPDL workflow standard. An expert generates Tcl.
The Warehouse Builder provides a set of pre-built views for both the design and runtime environments. These views are called the Warehouse Builder public views and are the API alternative to using the Repository Browser described in the Oracle Warehouse Builder Data Modeling, ETL, and Data Quality Guide.
Use these views to access to metadata and data stored in Warehouse Builder repositories.
You can access public views by logging in to SQL*Plus with default workspace@set
. When you login to SQL*Plus, you can access public views (design-time public views or runtime public views) from your default workspace.If you try to access public views from any workspace other than the default, then you must call: WB_workspace_management.set_workspace
(<wksp_name>, <wksp_owner>). If you want to switch to a workspace other than the default one, then you can call the WB_workspace_management.set_workspace
procedure. You must have the ACCESS_PUBLICVIEW_BROWSER
system privilege to retrieve useful information from the pubic views. Otherwise, you will get "0 rows returned." You may need to ask the workspace owner or workspace admin to grant the system privilege ACCESS_PUBLICVIEW_BROWSER
.
This chapter contains a catalog of the public views for the runtime environment.
The Runtime Repository contains all of the deployment and execution audit data. Use these public views to access this data. These views are used by Runtime Audit Browser to provide audit reporting.
Table 1-1 ALL_RT_AUDIT_LOCATIONS
Column Name | Data Type | Description |
---|---|---|
LOCATION_AUDIT_ID |
NUMBER (22) |
Internal primary key to audit_location |
RUNTIME_VERSION |
VARCHAR2 (64) |
Runtime version number |
CLIENT_VERSION |
VARCHAR2 (64) |
Design client version number |
CLIENT_REPOSITORY |
VARCHAR2 (30) |
Name of the client repository |
CLIENT_REPOSITORY_VERSION |
VARCHAR2 (64) |
Client repository version number |
REPOSITORY_USER |
VARCHAR2 (30) |
Username of the design repository |
GENERATION_TIME |
DATE |
When the deployment was generated |
DEPLOYMENT_AUDIT_ID |
NUMBER (22) |
Internal audit ID of the deployment |
DEPLOYMENT_SEQUENCE_NUMBER |
NUMBER (10) |
Sequence number of this location in the deployment |
DEPLOYMENT_AUDIT_NAME |
VARCHAR2 (64) |
Audit name of the location |
DEPLOYMENT_AUDIT_STATUS |
VARCHAR2 (4000) |
INACTIVE, READY, or COMPLETE |
LOCATION_AUDIT_STATUS |
VARCHAR2 (4000) |
INACTIVE, READY, BUSY_PREPARE, BUSY_UNPREPARE, BUSY_DEPLOY, BUSY_UNDO, BUSY_FINALIZE, or COMPLETE |
LOCATION_UOID |
VARCHAR2 (32) |
Client UOID of the location |
LOCATION_NAME |
VARCHAR2 (64) |
Name of the location |
LOCATION_TYPE |
VARCHAR2 (64) |
Type of the location. (ODB, OWF, OEM) |
LOCATION_TYPE_VERSION |
VARCHAR2 (64) |
Version of the target |
NUMBER_SCRIPT_RUN_ERRORS |
NUMBER (10) |
Number of errors detected |
NUMBER_SCRIPT_RUN_WARNINGS |
NUMBER (10) |
Number of warnings detected |
CREATED_ON |
DATE |
The time audit data was created |
CREATED_BY |
VARCHAR2 (30) |
Database username |
UPDATED_ON |
DATE |
The time audit data was updated |
UPDATED_BY |
VARCHAR2 (30) |
Database username |
Table 1-2 ALL_RT_AUDIT_LOCATION_MESSAGES
Column Name | Data Type | Description |
---|---|---|
MESSAGE_AUDIT_ID |
NUMBER (22) |
Internal key to audit_location_message. Primary when used with message_line_number. |
LOCATION_AUDIT_ID |
NUMBER (22) |
Internal key to audit_location |
MESSAGE_SEVERITY |
VARCHAR2 (4000) |
INFORMATIONAL, WARNING, ERROR, or RECOVERY |
MESSAGE_LINE_NUMBER |
NUMBER (10) |
1 for single line messages >0 for multiple line messages (Forms primary key when used with message_audit_id) |
MESSAGE_TEXT |
VARCHAR2 (4000) |
plain_text or nls_key |
CREATED_ON |
DATE |
The time audit data was created |
CREATED_BY |
VARCHAR2 (30) |
Database username |
Table 1-3 ALL_RT_AUDIT_LOCATION_FILES
Column Name | Data Type | Description |
---|---|---|
FILE_AUDIT_ID |
NUMBER (22) |
Internal primary key to audit_location_file |
LOCATION_AUDIT_ID |
NUMBER (22) |
Internal key to audit_location |
FILE_TYPE |
VARCHAR2 (64) |
SQLLoaderLogFile, ShellOutputStream, ShellErrorStream, FTPOutputStream, or FTPErrorStream |
FILE_TEXT |
CLOB |
Contents of the file |
FORMAT |
VARCHAR2(4000) |
TEXT or HTML |
CREATED_ON |
DATE |
The time audit data was created |
CREATED_BY |
VARCHAR2 (30) |
Database username |
Table 1-4 ALL_RT_AUDIT_OBJECTS
Column Name | Data Type | Description |
---|---|---|
OBJECT_AUDIT_ID |
NUMBER (22) |
Internal primary key to audit_object |
PARENT_OBJECT_AUDIT_ID |
NUMBER (22) |
Internal key to parent audit_script_run |
LOCATION_AUDIT_ID |
NUMBER (22) |
Internal key to audit_location |
LOCATION_SEQUENCE_NUMBER |
NUMBER (10) |
Sequence number of this object in the location |
OBJECT_UOID |
VARCHAR2 (32) |
UOID of the deployed object |
OBJECT_NAME |
VARCHAR2 (64) |
Name of the deployed object |
OBJECT_TYPE |
VARCHAR2 (64) |
Type of deployed object. (PLSQLMap, Table, Dimension, SQLLoaderControlFile) |
CLIENT_VERSION_TAG |
VARCHAR2 (80) |
Client version identifier of this object |
NUMBER_SCRIPT_RUN_ERRORS |
NUMBER (10) |
Number of errors detected |
NUMBER_SCRIPT_RUN_WARNINGS |
NUMBER (10) |
Number of warnings detected |
STATUS_WHEN_DEPLOYED |
VARCHAR2 (4000) |
VALID, INVALID, REMOVED, or UNCERTAIN |
CREATED_ON |
DATE |
The time audit data was created |
CREATED_BY |
VARCHAR2 (30) |
Database username |
UPDATE_ON |
DATE |
The time audit data was updated |
UPDATED_BY |
VARCHAR2 (30) |
Database username |
Table 1-5 ALL_RT_AUDIT_SCRIPT_MESSAGES
Column Name | Data Type | Description |
---|---|---|
MESSAGE_AUDIT_ID |
NUMBER (22) |
Internal primary key to audit_script_file |
SCRIPT_RUN_AUDIT_ID |
NUMBER (22) |
Internal key to audit_script_run |
MESSAGE_SEVERITY |
VARCHAR2 (4000) |
INFORMATIONAL, WARNING, ERROR, or RECOVERY |
MESSAGE_LINE_NUMBER |
NUMBER (10) |
1 for single line messages >0 for multiple line messages (Forms primary key when used with message_audit_id) |
MESSAGE_TEXT |
VARCHAR2 (4000) |
plain_text or nls_key |
CREATED_ON |
DATE |
The time the audit data was created |
CREATED_BY |
VARCHAR2 (30) |
Database username |
Table 1-6 ALL_RT_AUDIT_SCRIPT_RUNS
Column Name | Data Type | Description |
---|---|---|
SCRIPT_RUN_AUDIT_ID |
NUMBER (22) |
Internal primary key to audit_script_run |
LOCATION_AUDIT_ID |
NUMBER (22) |
Internal key to audit_location |
OBJECT_AUDIT_ID |
NUMBER (22) |
Internal key to audit_object |
SCRIPT_RUN_AUDIT_STATUS |
VARCHAR2 (4000) |
BUSY, COMPLETE, UNCERTAIN, FAILED or INACTIVE |
OPERATION |
VARCHAR2 (4000) |
DEPLOY, or UNDO |
SCRIPT_ACTION |
VARCHAR2 (4000) |
CREATE, DROP, UPGRADE, or REPORT |
SCRIPT |
CLOB |
Script used to perform the action | <