EME-Guide To Manage Enterprise Metadata

Enterprise Meta>Environment
Guide to Managing Enterprise Metadata
Notice
This document contains confidential and proprietary information of Ab Initio Software

Corporation. Use and disclosure are restricted by license and/or non-disclosure
agreements. You may not read, access, copy, or print any of this document unless you or
your employer are currently obligated to maintain its confidentiality for the benefit of Ab
Initio. You may not transmit any of this document to anyone who is not obligated to maintain
its confidentiality for the benefit of Ab Initio.
September 2003 > Part Number AB0367
Ab Initio Software Corporation

201 Spring Street > Lexington, MA 02421 > Voice 781.301.2000 > Fax 781.301.2001 > support@abinitio.com
INTELLECTUAL PROPERTY RIGHTS & WARRANTY DISCLAIMER
CONFIDENTIAL & PROPRIETARY

This document is confidential and a trade secret of Ab Initio Software Corporation. This document is furnished
under a license and may be used only in accordance with the terms of that license and with the inclusion of the
copyright notice set forth below.
COPYRIGHTS
Copyright © 1999-2003 Ab Initio Software Corporation. All rights reserved.
Reproduction, adaptation, or translation without prior written permission is prohibited, except as allowed under
copyright law or license from Ab Initio Software Corporation.
TRADEMARKS
The following are worldwide trademarks or service marks of Ab Initio Software Corporation (those marked ®
are registered in the U.S. Trademark Office, and may be registered in other countries): Ab Initio®;
ABINITIO.COM; >; Co>Operating®; Co>Operating System®; Cooperating®; Cooperating System®;
Continuous Flows; Continuous>Flows; init.com; INIT®; Re>Posit; Server+Server®; Server++®; The Company
Operating System; EME; Enterprise Meta>Environment; EME Portal; From The Beginning; Co>Operation;
Co>Operative; Co>Operating Enterprise; Cooperating Enterprise.
Certain product, service, or company designations for companies other than Ab Initio Software Corporation are
mentioned in this document for identification purposes only. Such designations are often claimed as trademarks
or service marks. In all instances where Ab Initio Software Corporation is aware of a claim, the designation
appears in initial capital or all capital letters. However, readers should contact the appropriate companies for
more complete information regarding such designations and their registration status.
RESTRICTED RIGHTS LEGEND

If any Ab Initio software or documentation is acquired by or on behalf of the United States of America, its agen-
cies and/or instrumentalities (the “Government”), the Government agrees that such software or documentation is
provided with Restricted Rights, and is “commercial computer software” or “commercial computer software
documentation.” Use, duplication, or disclosure by the Government is subject to restrictions as set forth in sub-
paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or
subparagraphs (c)(1) and (2) of the Commercial Computer Software – Restricted Rights at 48 CFR 52.227-19, as
applicable. Manufacturer is Ab Initio Software Corporation, 201 Spring Street, Lexington, MA 02421.
WARRANTY DISCLAIMER
THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE. AB INITIO MAKES NO WARRANTY
OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. AB INITIO SHALL NOT BE LIABLE FOR ERRORS
CONTAINED HEREIN OR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGE IN CONNECTION WITH THE FURNISHING,
PERFORMANCE, OR USE OF THIS MATERIAL.
Contents
Preface ix
Chapter 1 > Introduction 1

Benefits of the Enterprise Meta>Environment 2
How Users Interact with the EME 5
Becoming Familiar with the Sample EME 7
Overview of Building an EME 11
Creating an EME Datastore 12
Chapter 2 > Creating and Extending the Base Schema 15

Determining Your Requirements 16
A Quick Look at the Base Schema 19
A Quick Look at the Extended Schema 23
User-defined Categories 24
Where Categories Reside in the EME 27
User-defined Annotation Rules 28
There Are Different Types of Rules 29
Examples of Creating Categories and Annotation Rules 33
Chapter 3 > Adding Metadata to an EME Datastore 37

Storing Non-built-in Members 38
Adding One Item of Metadata to an Object 39
Adding Metadata in Bulk 42
Chapter 4 > Defining What Metadata Users Can See 49

Introduction to Views 50
What Is a View? 50
Anatomy of a Rendered View 50
View Names 51
Defining Content for Views 54
What Is a View-element? 54
Types of View-elements 55
Syntax of air category add-view-element 56
Including Values from the Current Category or a Related Category 59
Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy iii

Including Views Within Views 66

Including Text 69
Tips for Creating View-elements 70
Making Views Searchable 71
Defining a View for Editing Values of a Category Member 73
How Views Are Rendered 78
Chapter 5 > Setting Up the Web User Interface 79

Installing Web Resources and Scripts 80
About the Main Page and Other Attributes 81
Setting Configuration Variables for the Web Interface 83
air web-interface Commands 83
Setting Up the Footer 83
Setting Up the Main Menu 84
Creating Navigation Bar Hyperlinks 86
Setting Up Searching 87
Setting Up Views 88
Using the Default User Interface to Build Your Own 92
Creating a Search Index 94
Allowing Users to Add or Remove Values from a Category 96
Allowing Users to Create Values and Add Them to a Category 98
Chapter 6 > Unloading Metadata from a Datastore 101

Unloading Metadata from Individual Categories 102
Creating Your Own Unload Components 107
Unloading Categories into a Relational Database 109
Chapter 7 > Accessing Metadata from Windows Applications 111
Chapter 8 > Managing EME Security 119

Managing the aiw Web Server 120
Authenticating Users 123
Attributes of a User Account 123
Changing a Password 124
Displaying Users 124
Migrating User Accounts to Another EME 124
Enabling/Disabling User Accounts 124
iv Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Contents
Setting Up User Groups 126

What Is a Group? 126
Creating Groups 126
Assigning Users to Groups 127
Assigning Groups to Other Groups 127
Removing Users or Groups from Groups 128
Removing Groups from Groups 128
Displaying Group Membership 128
Granting Permissions 129
Two Kinds of Permissions 129
Default Permissions When Access Control Is Enabled 130
Setting Permissions on Annotation Rules 131
Setting Permissions on Objects 131
How Group Permissions Combine 131
How Rule and Object Permissions Combine 132
Appendix A air Utility Commands 139

Command-line Syntax of air Commands 140
Specifying Object Names as Arguments 142
Summary of air Utility Commands 144
air annotation Group 148
air annotation add 148
air annotation document 149
air annotation dump 150
air annotation rm 151
air arule Group 152
air arule add-choice 152
air arule create 152
air arule dump 157
air arule modify 158
air arule rm 160
air arule rm-choice 160
air category Group 162
air category add-member-location 162
air category add-rule 164
air category add-view 166
air category add-view-element 167
air category clear-permissions 170
air category create 170
air category dump 171
air category inheritvia-rule 172
air category list-members 172
Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy v

air category modify-rule 173

air category rm 173
air category rm-member-location 174
air category rm-rule 175
air category rm-view 176
air category rm-view-element 176
air category set-permissions 177
air category show-permissions 179
air category unload 180
air object Group 181
air object clear-permissions 181
air object restore-permissions 181
air object set-permissions 182
air object show-permissions 183
air system Group 184
air system export users-and-groups 184
air system group add-group 184
air system group add-user 184
air system group create 185
air system group remove-group 185
air system group remove-user 186
air system group show 186
air system import users-and-groups 187
air system install categories 187
air system user change-name 187
air system user change-password 188
air system user create 188
air system user disable 189
air system user enable 189
air system user show 190
air web-interface Group 191
air web-interface clear 191
air web-interface describe 191
air web-interface set 192
air web-interface set-order 193
air web-interface show 194
air web-interface show-order 194
Appendix B Load and Unload components 195

Load Annotation Values 196
Parameters 196
Input Record Format 197
vi Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Contents
Load Category 199

Parameters 199
About Loading Edited Objects 201
Specifying Annotation Values to Load 202
Load File Dataset 203
Parameters 203
Load Mimeobj 206
Parameters 206
Load Table Dataset 209
Parameters 209
Load Type 212
Parameters 212
Remove Objects and Annotations 215
Parameters 215
Description of Input Record for Remove Objects and Annotations 217
Specifying the Objects and Values to Remove 217
Unload Category 219
Parameters 219
Record Format 220
Appendix C Base and Extended Schemas 221

Base Categories and Rules 222
Built-in Categories by Group 223
Description of Base Categories and Rules 226
Extended Categories and Rules 234
Description of Extended Categories and Rules 235
Appendix D Loading Metadata with Connectors for

Prepackaged Applications 239
General Information 240
Parameters of the Connectors 242
Structure of the Connectors 244
Connector for ERwin 247
Connector for Oracle Designer 250
Connector for DB2 252
Connector for Oracle 254
Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy vii

Connector for Teradata 257

Connector for SQL Server 259
Connector for Sybase 261
Connector for Redbrick 263
Graph for Loading Files Created on a Physically
Inaccessible System 265
Appendix E Unloading Metadata with Connectors to

Third-party Reporting Tools 267
Connector for MicroStrategy 268
Connector for BrioQuery 272
Connector for Business Objects 274
Appendix F Configuration Variables 279
Appendix G Sample Scripts 281

Script for Creating Categories and Rules 282
Script for Storing Metadata in an EME Datastore 283
Script for Defining Views 285
Index 287
viii Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Preface
Who Should Read This manual is aimed at the administrator of the Enterprise
This Manual Meta>Environment, known as EME. It is assumed you are responsible
for defining your company’s technical and business metadata
requirements. In this manual, you will learn how to extend your existing
metadata and set up the Web user interface, which allows users to view
and edit your company’s metadata.
Related Guide to Managing Technical Metadata is aimed at developers using

Documentation the EME to build graphs, and at system administrators managing EME
projects. Please request a copy of this manual, if you have not received
one.
Text Conventions We use the following conventions in general text:
Example Description
myfile.txt Bold represents file paths, DML keywords,

numerical or character values (such as abc or 1), as
well as the names of fields, functions, statements,
and parameters.
File > Open “Choose the Open command from the File menu.”
AB_HOME Small caps represent configuration, environment,

or system variables.
emphasis Italics denote emphasis, new terms, and book

titles.
Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy ix

Preface
Conventions for We use the following conventions in examples:

Examples
Example Description
source code A fixed-width font represents code fragments,
examples, and computer output.
user input A bold, fixed-width font represents entries made
by the user in an interactive command-line session.
⇒ An arrow indicates either the result of a

computation, or the fact that a command or line of
code continues on the next line.
Squares indicate blank spaces where the number of

spaces is significant.
Syntax Conventions Where DML syntax is shown, and labelled as such, we use the
following conventions:
Example Description
integer Non-bold text indicates the DML data type of an

argument or returned element.
read_xml Bold text, symbols, and punctuation represent

syntactical elements that the user must enter
exactly as they are shown.
my_file Italicized text represents values or variables that

the user must supply.
... An ellipsis indicates that the preceding item can be

repeated one or more times.
a|b|c The logical or symbol separates alternatives.
( ) Parentheses are part of the syntax.
[ ] Non-bold square brackets surround a series of

options from which you have the option of
[ ]
selecting one. Bold square brackets are part of the
syntax.
{ } Non-bold curly braces indicate a series of choices

from which you must select one. Bold curly braces
{ }
are part of the syntax.
x Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

1>
Introduction
Topics Covered You will learn about the following topics:

• Benefits of the Enterprise Meta>Environment (page 2)
• How Users Interact with the EME (page 5)
• Becoming Familiar with the Sample EME (page 7)
• Overview of Building an EME (page 11)
• Creating an EME Datastore (page 12)
Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy 1

Chapter 1> Introduction
Benefits of the Enterprise

Meta>Environment
What Is the Enterprise The Enterprise Meta>Environment (EME) provides a rich store for
Meta>Environment? applications and all of their associated information including:
• Technical metadata — application-related business rules, record
formats, and execution statistics
• Enterprise metadata — user-defined documentation of what you
deem important to track in your business, for example, job
functions, roles, and responsibilities
Metadata, or data about data, is critical to understanding and driving
your business processes and computational resources. Storing and using
metadata is as important to your business as storing and using data. By
integrating technical and business metadata, you can grasp the entirety
of your data processing — from operational to analytical systems.
This manual focuses on defining your own business metadata. To learn
about technical metadata, see Guide to Managing Technical Metadata.
It Is an Integrated The EME is a completely integrated environment. The following figure

Environment shows how it fits in to the high-level architecture of Ab Initio software.
Web
user interface
Graphical
Development
Environment ®
Ab Initio
®
Co>Operating
System
third-party
Enterprise Meta>Environment ®
connector metadata
destination
or co
ct nn
nne ec
co to
conne
r
third-party third-party
metadata
ctor
metadata
source source
third-party
metadata
destination
2 Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Benefits of the Enterprise Meta>Environment
• You construct your applications from building blocks called

components, manipulating them through the Graphical
Development Environment (GDE).
• You check in your applications to the EME. This action also stores
application-related metadata into the EME.
• The EME and GDE use the underlying functionality of the
Co>Operating System to perform many tasks. The Co>Operating
System unites distributed resources into a single “virtual
computer” to run applications in parallel.
• Ab Initio software runs on Unix, Windows NT, and MVS
operating systems.
• Ab Initio connector programs extract metadata from third-party
metadata sources into the EME, or extract metadata from the EME
into a third-party destination. You may also define metadata
directly in the EME.
• You view the results of project and application dependency
analysis through a Web user interface. You also view and edit your
business metadata through a Web user interface.
Various User The EME addresses the metadata needs of three different
Constituencies Are constituencies: business users, developers, and system administrators.
Served Business users are interested in exploiting data for analysis, in
particular, with regard to databases, tables, and columns. Developers
tend to be oriented toward applications, needing to analyze the impact
of potential program changes. System administrator and production
personnel want job status information and run statistics.
Business and The EME makes it possible to answer a wide range of questions because
Technical Metadata it integrates both business metadata and technical metadata.
Are Integrated
The EME holds the active elements that compose your applications.
This means that business concepts (such as organizational structure or
business roles) can be directly linked to associated technical entities
(such as database instances or record formats).
In-depth Analysis The EME enables deep analysis of applications and the relationships
Across the Enterprise between them. Dependence analysis answers questions of data lineage:
Where did a given value come from? How was the output value
computed? Which applications produce and depend on this data?

Impact analysis lets developers understand the consequences of

proposed modifications: If this piece changes, what else will be
affected? If this source format changes, which applications will be
affected?
In addition, all objects stored in the EME are versioned, making it
possible to examine the state of things as of last week, last month, or last
year, and to compare it with the state of things today.
The EME collects job-tracking, or execution, information which enables
trend analysis (How fast is our data growing?) and capacity planning
(How long did that application take to run? How much data did it
process, and at what rate? What resources did the application consume?
When will we need to add another server?).
Because the EME holds both technical metadata and business metadata
in an integrated store, the EME can also provide the answers to
questions like: Which groups are responsible for producing and using
this data? Who changed this application last? What changes did they
make?
Your Enterprise Is Special EME software, often called connectors, pull metadata from, and
Connected deliver metadata to, a wide variety of third-party products, including
design tools and OLAP systems. This makes it possible to maintain the
flow of metadata from business unit to business unit and from
operational systems to data warehouses to analytical systems.
Data Is Easy to The EME Web user interface provides an easily accessible view of
Access everything stored within the EME, permitting navigation, reporting,
dependence analysis, impact analysis, versioning, and differencing from
a standard Web browser from anywhere within the enterprise.

How Users Interact with the EME
How Users Interact with the EME

The following diagram illustrates how users interact with an EME.
View Metadata
Create views to display metadata
in the Web user interface.
Extract Metadata
EME Use unload components to
Store Application B1
export metadata to third-
B party reporting tools.
Metadata U U1
B3
Check in projects.
B2 U3
Enable job tracking. U2
Key: Store User-defined Metadata

B = built-in objects Extend the base, or built-in, schema by describing metadata
U = user-extended specific to your business.
objects Use load components from third-party tools or use air utility
commands to store your metadata.
Store Application-related Application-specific objects — like graphs, components, record

Metadata formats, and transformations — are stored automatically whenever a
user checks in a project or graph. Job tracking information will also be
stored automatically if a user selects Save Tracking Data to EME
Datastore in the Run Settings dialog prior to running the application.
(Check-in and job tracking are covered thoroughly in Guide to
Managing Technical Metadata.) Also, at check-in time or runtime,
metadata derived from these application objects is stored as well.
Store User-defined A major aim of the EME is to allow you to extend the application
Metadata metadata normally stored during check-in or graph execution and store
that metadata in the datastore. For example, you might want to capture
information about which group is responsible for different applications.
To this end, you must extend the default schema. Then you can use

Ab Initio’s specialized load components to import metadata from

third-party tools like ERwin or Oracle Designer. Also, you can run
scripts containing air utility commands to add these values.
For more information, see Chapter 2 >Creating and Extending the Base
Schema and Chapter 3 >Adding Metadata to an EME Datastore.
View Metadata The goal of capturing metadata is to allow end users to view and
possibly edit it in the EME user interface, currently the Web browser.
To make metadata available in a browser, you must define one or more
views, which are subsets of the metadata that you want to appear in a
Web page. Metadata that is not included in a view is not accessible to
users.
The following figure is an example of how a view on metadata relating
to personnel might look in the browser.
For more information, see Chapter 4 >Defining What Metadata Users

Can See.
Extract Metadata Finally, if you store your business-related information outside of the
EME, for example in third-party reporting tools, you can extract it using
Ab Initio’s unload components.
For more information, see Chapter 6 >Unloading Metadata from a
Datastore.

Becoming Familiar with the Sample EME
Becoming Familiar with the

Sample EME
The installation CD-ROM includes a sample EME, which you can
optionally install. We highly recommend that you become familiar with
the sample before you creating your own EME.
Complete These 1. Install the Co>Operating System, the EME/Web server software,
Prerequisites and the GDE, and configure the Web server, if you have not
already done so. For more information, see the installation section
of Chapter 1 in Guide to Managing Technical Metadata.
2. Open a Korn shell window, which you will use to verify and
update certain settings. (Note that steps 3-6 are also described in
the README file in installation-dir/examples/bmr/simple.)
3. Make sure the value of AB_HOME is the installation directory of the
Co>Operating System you are using. For example, issuing m_env
-v might return ab initio version 2.12 P251 largefile
if you are using version 2.12 of the Co>Operating System.
4. Run print -r $PATH to make sure that your path includes
$AB_HOME/bin. If it does not, append it to your path. Type:
export PATH=”$AB_HOME/bin;$PATH”
5. Set AB_AIR_ROOT to the root of the soon-to-be-created EME. Type
a fully qualified path to an existing directory.
For example, if you would like to name the sample EME
sample_eme and you would like it to reside in the sample
directory, you might type:
export AB_AIR_ROOT=c:/sample/sample_eme
Note If the directory does not exist, run mkdir directory-name to
create it, prior to setting AB_AIR_ROOT.
6. Make sure that a Web server has been installed successfully using
the install-aiw program. If not, see the introduction to Guide to
Managing Technical Metadata.
Build the Sample EME Now create the sample EME by running make_sample.ksh, located in
$AB_HOME/examples/bmr/simple. This Korn shell script creates the
EME, installs the base schema plus extensions, and defines views;
stores and annotates objects; and sets up the Web user interface,
including the main menu and a search index.

Permissions Since this script installs files into your Web server’s
html directory, you may need to run the script as root or temporarily
change the permission on your Web server directory in order to run the
script successfully. Note that if you run the script as root, you will not be
able to modify the EME until you change permissions on the EME files.
Prerequisite information The script prompts you for the following

information:
• The directory in which your Web server stores html resources. The
table lists the most common choice for each supported server.
For this software This directory is likely to be ...
IIS on Windows c:/inetpub/wwwroot
Apache on Windows c:/Program Files/Apache Group/Apache/
htdocs
Apache on Unix /home/httpd/html
• If running Windows, the domain of the users who will be logging

in to the EME’s Web user interface. The local domain is "." (dot).
To build the sample EME:
1. Change (cd) to $AB_HOME/examples/bmr/simple.
2. Launch the script. Type:
./make_sample.ksh.
The screen displays the script’s step-by-step actions.
NOTE: If the script fails, you should fix whatever caused the error and
rerun the script.
See the Sample Now you can take a look at the sample EME you’ve just built.
Metadata in the Web
1. Open a Web browser and specify the following URL:
User Interface
http://machine-name/bmr/bmr_login.html.
2. When the login page appears, type your standard user ID and
password and then click Login.

Becoming Familiar with the Sample EME
The main menu is displayed, as shown in the following figure.
The Business Scenario The Web page, shown above, presents some of the metadata of the
merged Abbot and Becket retail stores, as well as that of the consumer
demographic list from a third-party firm. (You might remember this
business situation from the Ab Initio Tutorial.)
The information you see in the figure is the subset of metadata that the
Web designer has chosen to present to you, not all the metadata stored
in the EME related to Abbot and Becket. The purpose of the Web user
interface is to coherently present information important to the business
user and to present that information in a way that it’s easy to see the
relationship between items of information.
Navigate the Web In Chapter 5 >Setting Up the Web User Interface you will learn how to
User Interface customize the elements of the Web page. We recommend that right now
you spend a little time navigating around the main menu and searching
for information.
The three blocks beneath the welcome message, from left to right, are
Steward Group members, Column members, and Business Attribute
members.
• Steward Groups present each group of data stewards, those people
who are responsible for tables or views.
• Business Attributes describe columns in various database tables
that have common meaning.
• Columns describes all table columns.

To drill down into any single object, click one of the hyperlinks. For
example, click the hyperlink “Abbot Stewards”. You can see which
Abbott employees are data stewards: Roger Koss and Diana George.
Edit hyperlink Technical view hyperlink Add/remove TableView hyperlink
Sort icon
The hyperlinks take you to related information or processing.

• Clicking the “edit...” hyperlink opens a Web page through which
you can modify values in the EME datastore. Not all metadata can
be edited by all groups and users.
• Clicking the “technical view” hyperlink takes you to the Web user
interface for technical metadata described in Guide to Managing
Technical Metadata.
• Clicking the sort icon ( ) sorts the first column alphabetically.
• Clicking a hyperlink that names a table takes you to a Web page
where you can see more about either of the tables. For example, in
this case, you can see which tables the Abbot stewards are
responsible for: a-customers and a-transactions.
• Clicking the “Add/Remove Tableviews...” hyperlink opens a new
Web page, where you can change the tables or views that the
Abbot Stewards are responsible for. Continue clicking to see
metadata related to the Abbot and Becket database, tables, views,
and columns, as well as the relationships between metadata items.

Overview of Building an EME
Overview of Building an EME

The actions taken by make_sample.ksh to build a sample EME mirror
the actions you will take to build your own EME. The following table
lists the steps you’ll complete to build your own EME.
Step Recommendations
Verify your environment, then See Creating an EME Datastore on page 12.
create a new EME datastore.
Install the base schema. The schema describes the shape of your metadata.
Install and read about the Ab Initio-provided base
schema (page 19).
Install the extended schema Install and learn about extensions to the base schema.
(highly recommended). This schema is required for running other Ab Initio
products. See A Quick Look at the Extended Schema
on page 23.
Define your own extensions. Determine your company’s metadata requirements.
Metadata is organized around categories and
annotation rules. Read about them and look at some
examples of how to define them. See User-defined
Categories on page 24, User-defined Annotation
Rules on page 28, and Examples of Creating
Categories and Annotation Rules on page 33.
Populate the EME datastore. Learn about different ways to add metadata to an
EME datastore. See Chapter 3 > Adding Metadata to
an EME Datastore.
Define what metadata users can Users can see and search for metadata only in the
see in the EME Web user EME Web user interface. You define views to set the
interface. format and content of the metadata. See Chapter 4 >
Defining What Metadata Users Can See.
We highly recommend that you install the views on
the extended schema (page 53).
Set up the EME Web user Customize the look of the Web user interface for your
interface. company. Install Web resources and scripts, then
build a search index to allow users to search for
metadata. See Chapter 5 > Setting Up the Web User
Interface.
Set up security. Decide which users have permission to see and edit
annotation values. See Chapter 8 > Managing EME
Security.

Creating an EME Datastore

The first step in using the EME is to create a new EME datastore.
Definition An EME datastore is an individual installation of the EME. It is a

named collection of files and metadata. The source of the metadata may
be Ab Initio graphs and related information, third-party data modeling
tools like ERwin, or unstructured metadata defined by users. You may
copy metadata out of the datastore, making it available to third-party
reporting tools, like MicroStrategy.
Typically, you create individual datastores for different workgroups.
For example, one datastore might be used by the Development
workgroup, which creates and modifies graphs and checks them in to
the datastore, along with application-related data transforms, business
rules, record formats, and documentation. Another workgroup might
comprise business users and developers who define enterprise metadata
related to applications and database tables, for example, information
about who has responsibility for a given application or the meaning of a
given table column. A second datastore might be used by the Quality
Assurance workgroup for running tests, while a third might be used by
Production for running jobs.
Prerequisites 1. Install the Co>Operating System, the EME/Web server software,

and the GDE, and configure the Web server, if you have not
already done so.
2. Make sure that the AB_HOME configuration variable is set to the
installation directory of the Co>Operating System you are using.
For example, issuing echo $AB_HOME might return
c:\AbInitio-2-12 if you are using version 2.12 of the
Co>Operating System. To change the value of AB_HOME, use the
export command to set the Co>Operating System version, for
example:
export AB_HOME=c:\AbInitio-2-12
3. If the directory in which the new EME datastore will reside does
not exist, create it. Run mkdir directory-name. For example:
mkdir c:\mydatastore
4. Set the AB_AIR_ROOT configuration variable to the root of the new
datastore. For example, if you would like to name the datastore
mystore and you would like it to reside in a directory called
mydatastore, you might type:
export AB_AIR_ROOT=c:\mydatastore\mystore

Creating an EME Datastore
Create a New EME Assuming you set the datastore root location through the AB_AIR_ROOT
Datastore configuration variable, you can then create a new datastore by typing:
air repository create
Otherwise, you can use the -root argument to specify the location and
name of the datastore, as in:
air -root /disk1/data/mystore repository create
Sample Datastore Installing the sample EME on a Unix platform (described on page 7)
gives you a sample datastore that looks something like the following.
/abinitio /Metadata /Projects /Users
Business Attributes user1

2.11.n sample
Customer ID
Discount user2
aiw dat
...
annotation rules Menus db
categories Main
dml
welcome.html
default mp
Steward Groups
examples run
Abbot Stewards
extensions xfr
Becket Stewards
.repository_state
hosts Marketing Stewards
.air-project-parmeters
reports .project-end.ksh
abinitio Directory The abinitio directory is created automatically whenever you create a
datastore. It contains system objects and scripts — supporting material
for making sure that the EME datastore and the Web user interface will
function. It includes categories and annotation rules, which are
necessary for capturing and representing metadata. You will learn about
categories and annotation rules in the next chapter.
You should not edit anything directly in the abinitio directory.
Projects Directory The Projects directory is created automatically whenever you create a
datastore. It contains projects, which are Ab Initio applications kept
under source control. The sample project was imported from a file
system on another machine. The files in the sample project pertain to an
Ab Initio application that was imported into the datastore. You will
import your own projects into the Projects directory. You interact with
projects through the GDE and through the command line. Projects are
fully described in Guide to Managing Technical Metadata.

Users Directory The Users directory is created automatically whenever you create a
datastore. The subdirectories are created when users log in. These
directories can be used as private work areas, where users can store
private projects or private datasets or other application-specific files.
Metadata Directory The Metadata directory stores the sample metadata. You must define
your own directory to store metadata. We recommend that you call it
Metadata, but you can call it any name you want. The Menus
subdirectory contains the main menu and welcome message displayed
in the Web user interface, shown on page 9. Metadata about business
attributes and various steward groups, shown in the figure, are stored in
the Business Attributes and Steward Groups subdirectories,
respectively. Note that the subdirectories of Metadata correspond to the
figure of the Web user interface on page 9.
Connecting to a To accomplish tasks using the EME, you must connect to a specific
Datastore datastore. You can connect to only one datastore at a time. There are
several ways to establish the connection:
• Set the location in the EME Datastore Settings dialog, available
through Project > EME Datastore Settings in the GDE.
EME datastore location
• Set the value of the AB_AIR_ROOT configuration variable to the full

datastore path, for example:
export AB_AIR_ROOT=c:\eme\mystore
• Specify the value of the -root argument to individual air utility
commands at the command line. For example, to create the phone
annotation rule (arule) in the mystore datastore:
air -root /disk1/data/mystore arule create phone \
-type string
• Log in to the Web user interface. Login to the sample EME is
described on page 8. The Web page displays some of the contents
of the sample EME datastore.

2>
Creating and Extending the
Base Schema

• Determining Your Requirements (page 16)
• A Quick Look at the Base Schema (page 19)
• A Quick Look at the Base Schema (page 23)
• User-defined Categories (page 24)
• User-defined Annotation Rules (page 28), including the various
types of rules (page 29)
• Examples (page 33) of:
• Defining categories and annotation rules
• Associating rules with categories
• Defining membership in categories

Chapter 2> Creating and Extending the Base Schema
Determining Your Requirements

We recommend that the business users, developers, and system
administrators come to consensus on what information they want to
capture and that you invite other business and technical users to review
your decisions.
Business users typically focus on metadata for analysis, particularly
with respect to databases, tables, and columns. Often, they ask: “What
does this data mean, and how was it derived?” “When was it created?”
They also often want to know the business areas associated with a
particular application and who is responsible for maintaining it.
Developers want to do impact analysis, that is, determine the effects of
proposed programming changes. For example: “What is the effect of
changing this transformation on the rest of the application?”
System administrators and production personnel are interested in job
status information and run statistics. They ask such questions as: “When
was the job run?” How long did it take — in elapsed and CPU times?”
Examine Your Firm’s The best way to determine your metadata needs is to study your existing
Applications applications and develop your own set of questions that you would like
to answer.
In the case of our example, consider the stored Ab Initio application,
JoinCustomers.mp, which combines two lists of customers and
transactions into a single list. The following figure shows the graph as it
appears in the GDE. (This graph is part of the tutorial in the Guide to
Managing Technical Metadata.)

Determining Your Requirements
Determine What The graph makes plain how the data is manipulated, but it does not
Metadata to Capture display all the information that the business needs. For example, there is
no information related to ownership and business area (marketing or
finance, for example) of the JoinCustomers application.
Therefore, the first item of information users might want to know is:
who is responsible for this application as a whole. You might want to
pose the question: “Who is the steward?” For each steward, you might
want to capture a name, contact information (phone number), and a
department.
With respect to this application, you might also want to identify which
business area this application belongs to.
You might pose the same question for the application’s data files: “Who
is the data steward responsible for these tables/files?”
It’s likely that you and your colleagues might devise many other
questions, but for the sake of simplicity, let’s consider only these two.
If you were to present this information graphically, you might draw it as
follows. Each application has a business area and a steward. Each data
file has a steward. Since each steward is an employee, you need a master
personnel list of employees that has the name and phone number of each
employee.
Application business area

steward
Personnel phone
name
department
Data Files steward
What the Metadata The goal of understanding your metadata requirements and the
Looks Like in the User relationships between metadata is to be able to present this information
Interface for viewing and editing in the EME Web user interface.
Eventually, you will build something similar to the following figure,
which suggests the interrelationship among personnel, applications, and
data files. The Web user interface in the following figure presents the
information for employee Jim Anchower.

Information about Jim, a

specific employee in the
Personnel list
Applications for which

Jim is the steward
Data files for which Jim

is the steward

A Quick Look at the Base Schema

A base schema is built-in to the sample EME. The base schema provides
definitions of the underlying structure of the metadata that will reside in
an EME datastore. We expect that you will extend the base schema to
suit the specific needs of your company.
The base schema is organized into 19 categories, presented in the
following figure as a relational model. Each box denotes a category.
These categories are described in detail in Appendix C >Base and
Extended Schemas.
mimeobj parameter
job graph project database

common
include global
phase
package type
dataset
flow_summary flow transform
input
output vertex uses dataset{s} as lookup
vertex may be a dataset
dataelement
vertex
vertex_summary
output input
Key:
one-to-many foreign-key relationship
many-to-many foreign-key relationship

Installing the Base The sample EME automatically installs the base schema. If you did not
Schema install the sample, then install the base schema manually. Make sure
AB_AIR_ROOT is set, then type:
air system install categories
What Are Categories A category is similar to a relational table.

and Annotation
Rules? relational table
columns
column 1 column 2 column 3 ... ... ...

row 1
row 2
row 3
...
It describes a class of objects. Each category comprises a set of
annotation rules. An annotation rule is equivalent to a column definition
of a table. Each row in the table holds the metadata values for each
object that belongs to a category. In the case of the database category,
for example, all database objects in the EME are members of the built-in
database category and thus have the same rules.
In the language of object-oriented programming, the database category
represents a class of database objects. Each row represents an instance
of a database and will store the values of the annotation rules (oid,
name, and so on) for that instance. We can redraw the relational table to
more closely represent a category:
annotation rules database category
oid name comment ... ... ...

database 1
database 2
database 3
...

The annotation rules are built in to the base schema. Here are the 15
annotation rules of the database category:
database
oid
name
display_name
path
db_name
dbms
dbms_version
projectOID
comment
description
created_by
created_date
modified_by
modification_date
categoryOID
For now, it is not necessary to learn the details of the base schema’s
categories and annotation rules. However, there are a few points worth
noting:
• Each category in the base schema has 11 annotation rules in
common: oid (unique object identifier), name, comment,
description, display_name, created_by, creation_date,
modified_by, modification_date, categoryOID, and path. These are
described in Common Rules on page 226.
• Each category has rules that are specific to it.
database
oid
name
display_name
path Rules common to
Rules specific to the
db_name all categories
database category
dbms
dbms_version
projectOID
comment
description
created_by
created_date
modified_by
modification_date
categoryOID
• The mimeobj category is the base category for all new user-defined
categories that cannot be derived from the built-in categories.
mimeobj has the common rules and only one annotation rule
specific to it — _value.

mimeobj
oid
name
display_name
path
_value Rule specific to the
mimeobj category
comment
description
created_by
created_date
modified_by
modification_date
categoryOID
• We recommend that you do not modify the categories in the base

schema. Instead, derive new categories from those in the base
schema.

A Quick Look at the Extended Schema
A Quick Look at the Extended

Schema
Be Sure to Install the The installation package includes the standard-schema.ksh script,
Extended Schema which installs an important extended set of categories and annotation
rules. Together with the base schema, these categories are required to
run additional Ab Initio products. For example, the EME connectors
(described in Appendix D and Appendix E) expect these categories to
be defined.
The extended schema is installed automatically when you install the
sample EME (page 7). If you did not install the sample EME, we highly
recommend that you run standard-schema.ksh manually and then
make full use of these extensions to the base schema. The script resides
in $AB_HOME/connectors/EME, where $AB_HOME is the installation
location of the Co>Operating System.
Categories of the The extended categories pertain primarily to database indexes and keys:
Extended Schema
• Column • Index
• Invalid Value Item • Key
• Logical Element • Logical Entity
• Physical Element • TableView
• Valid Range Item • Valid Value Item
• Validation Spec
For more information about the categories and annotation rules of the
extended schema, see Extended Categories and Rules on page 234.

User-defined Categories
Introduction There are no strict rules about what should become a category, but, in
general, you should create a category if you want to treat a set of data as
a unit. Every category creates a logical table in the EME.
Based on the requirements specified in our example beginning on page
17 and shown in the following figure, we might consider creating three
categories: Application, Data Files, and Personnel.

steward
Personnel phone
department
Data Files steward
Categories Have Every new category must have a name. We recommend that you choose
Names a name that clearly describes the data, since this name may appear in the
Web user interface.
We also recommend that you use case consistently when naming
categories. For example, use uppercase (DATA FILES or
DATAFILES), initial caps (Data Files or DataFiles), or lowercase (data
files or datafiles) consistently for all categories. Names can be more
than one word. Specify multi-word category names in quotation marks
("Data Files") at the command line.
Categories Have New categories must be based on an already existing category, the
Parents so-called parent category. In addition, you must choose the appropriate
parent category. A good rule of thumb is that a new category describes
an “is a” or “are” relationship with its parent. (This concept is familiar
to object-oriented programmers.) For example, a category called
Application, which we specified as a result of examining the
JoinCustomers graph, should be based on the built-in graph category. It
meets the stated criterion: An application is a graph. The correct parent
category of the new Data Files category is datasets, since data files are
datasets.

What to Do When What is the parent of a new category that is not related to a graph? Such
There’s No Built-in categories should be based on the mimeobj category, which is a
Parent container for those categories whose members cannot be derived from
built-in objects. Personnel is an example of this sort of category, as
would be categories necessary for capturing business-related metadata,
such as employee names or business systems or processes (Accounts
Receivable, Accounts Payable, and so on).
Categories Have Most categories have members. Members are objects to which the
Members category’s annotation rules apply. The members of a category are those
objects that meet both of these criteria:
• They reside in the directory or (sub)directories you specify for that
category, or are referenced by a record-type annotation rule
(page 31).
• They are of the same type as the category’s parent.
Some Members Are Some members are built-in objects specific to Ab Initio applications.
Built-in Objects For example, graphs are built-in EME objects that reside in a project’s
mp directory. This directory is automatically created when you store a
graph for the first time.
To make one or more like-typed objects members of a category, you
specify the full path (to the file or the directory) to the air category
add-member-location command.
Example. If you want the members of the proposed Application
category to be EME graphs, then you would specify the full paths to the
mp directories of your EME projects, let’s say: /Projects/project1/mp
and /Projects/project2/mp. It’s up to you how many mp directories are
included as members.
On the other hand, any non-graph object in mp or in its subdirectories is
not a member of the Application category.
For examples of using air category add-member-location, see Specify
the Location of Category Members on page 35. For more details about
fine-tuning category membership, see the command syntax of air
category add-member-location on page 162.
Some Members Are Not Category members can also be objects that are not built-in or specific to
Built-in Objects an Ab Initio application. These non-built-in objects are members of
categories whose parent is mimeobj, that is, derived from a MIME
object. Personnel is an example of this sort of category.

To specify membership in a mimeobj-derived category, you specify the

full path to the directory where the objects reside. Non-built-in members
reside in an ordinary EME directory that you must create yourself. We
recommend that these directories be defined under /Metadata. Do not
create the directory under /Projects. For example, to create both the
Metadata and Personnel directories, you would type:
air mkdir /Metadata/Personnel
You would then specify this path as the location of the members of the
Personnel category to air category add-member-location.
Since the members are not built-in objects, you would need to store
something to represent them. For example, the members of the
Personnel category might be the stored strings “John Doe”, “Jim
Anchower”, and “Mitzi Katz”. (The process of storing members is
shown in Chapter 3 > Adding Metadata to an EME Datastore.)
Some Members Do Not Categories that are referenced by record-type annotation rules do not
Need to be Specified need to have their membership explicitly specified. The members of
these categories reside in the EME datastore, but they have neither
directory entries nor names. See Record Rules on page 31.
Each Member Has the Each member of a category is associated with the annotation rules
Category’s Rules explicitly defined for the category, in addition to the rules defined for
the parent category.
For example, the annotation rules for the Application category and those
inherited from the parent category (graph) apply to each graph in
/Projects/project1/mp and /Projects/project2/mp. The following
figure illustrates this only for the graphs in project1’s mp directory
(graph1, graph2, and so on) and, for the sake of space, omits the
annotation rules common to all built-in categories (page 226).
/Projects/project1/mp
author rule
graph1 version rule
business area rule
steward rule
graph2 author rule from graph category

version rule
business area rule from Application category
steward rule
graph3 author rule

version rule
business area rule
steward rule
...

In the case of the Personnel category, we defined two annotation rules

— phone and department — and associated them with the category.
Drawing the Personnel category as a logical table with our sample
members and annotation rules would yield something like this:
columns Personnel category
oid name comment phone department

John Doe
Jim Anchower
Mitzi Katz
...
arule 1 arule 2 arule 3 ... ...
Each member — John, Jim, and Mitzi — is an instance of Personnel and
has all the annotation rules defined for the Personnel and mimeobj
categories: oid, name, comment, phone, department, and so on.
Summary To summarize what you’ve learned about category parents, members,

and annotation rules, we can redraw the figure on page 24 as follows:
Parent category = graph

steward
mp/
Parent category = mimeobj
graph1
graph2 Personnel phone
... department
Personnel/
Parent category = dataset John Doe
Jim Anchower
Data Files steward Mitzi Katz
dat/ ...
dataset1
dataset2
...
Where Categories Categories are stored in /abinitio/categories in the EME. Do not

Reside in the EME manipulate categories directly.

User-defined Annotation Rules

Definition Annotation rules are equivalent to the column definitions of a table.
They define the kinds of values that can be associated with the objects
that are members of a given category. Because the Application category
has a steward annotation rule, all members of the category, that is, all
graphs in one or more mp directories, are associated with a steward.
This point was illustrated in the figure on page 26.
An annotation rule defines a “has a” relationship with the category to
which it is assigned, in the form: A category has a rule. For example, an
application has a steward.
Annotation Rules Annotation rules must have unique names. The name must be a valid
Have Names DML identifier; see the Data Manipulation Language Reference.
We recommend that you use case consistently in rule names. Thus,
while Business_Area, BusinessArea, businessarea, and business_area
are all acceptable, we recommend that you use a single format for
names.
Names are case-insensitive; thus, steward and Steward are not allowed.
Spaces are not permitted in annotation rule names, nor are hyphens. For
example, Business-Area is not valid.
The name of the rule is not necessarily the name displayed in the user
interface. You can set a display name for the rule. For example, you can
display business_area as “Business Area” or “Business area”.
You Can Assign Rules You can assign annotation rules to more than one category. For
to Multiple Categories example, an application can have a steward; a data file can also have a
steward. Therefore, the steward rule can be assigned to both the
Application and Data Files categories.
Note You may assign the new rules you create to the categories in the
base schema; however, we recommend that you derive new categories
from the base schema and then define annotation rules for the new
categories.
Make Sure a New Rule In addition to the rules explicitly defined for them, categories also have
Doesn’t Already Exist the annotation rules of their parents. For example, the Application
in the Base Schema category has the graph category’s 14 annotation rules (see the 11 rules
listed in Common Rules on page 226 and the 3 annotation rules named
in graph Category Rules on page 229.)

Before you define a new annotation rule for a category, make sure that
the rule doesn’t already exist in the base schema. For example, the name
and comment rules are inherited from Personnel’s parent category,
mimeobj. (In fact, the name and comment rules are common to all
built-in categories, as shown in the table of common rules on page 226.)
For this reason, it would be invalid to explicitly define a name or
comment rule for Personnel. You might have noticed that the name rule
shown in the figure on page 17 was deleted from the figure on page 24.
There Are Different Not all annotation rules are alike. When you create a new rule, you can
Types of Rules constrain the number and kinds (data type) of values it can have. In
effect, you are deciding how your end users can specify values for a
given object. The types of annotation rules are:
• String
• Choice
• Reference
• Record
String Rules An annotation rule on an object can have as its value a single string or
multiple strings. The string or strings are attached to the individual
object (member) and are not shared across multiple objects.
A rule that has one string value is said to be single-valued. Example:
Each employee has a unique Social Security number. The end user must
enter one value.
String rules that have more than one value at the same time are said to
be multivalued. For example, the value of the phone rule for a given
member of the Personnel category can be one or more phone numbers.
Choice Rules An annotation rule can define choice-type rules, in which the end user is
presented with a set of values for a single member of the category to
which the rule has been assigned. Use a choice-type rule when you have
an expectation about the valid values that an annotation rule might take.
You may require the end user to select only one of a number of choices.
An example of a single-valued choice rule might be the status rule: For a
given application, an end user might have to choose from Approved,
Disallowed, or Pending.
Alternatively, you might define a multivalued choice rule that allows a
member object to have more than one value at a time. That is, end users
can specify multiple values for this object. For example, a member of
Personnel might work in two departments — Development and QA.
You might imagine, therefore, that for the department annotation rule

you might want the user to be able to choose from all your company’s
departments — Finance, Development, Operations, Documentation,
QA, and Executive. After defining the choice rule, single-valued or
multivalued, you must explicitly define the list of choices.
By default, choices are restricted to the predefined list of values you
create. Sometimes, however, you might want an end user to be able to
specify a value that is not in the predefined list of choices. For example,
for a given application you might want to allow a user to enter
Operations as the value of business_area rather than restrict the user’s
choice to the choices in the list.
derives from
When a user specifies a value that is not in the list, you might also want
them to be able to permanently add that choice to the list of valid
choices, so that other users can see it displayed in the Web user
interface. If you don’t allow users to permanently add a new choice, the
values they specify are saved in the EME datastore but are not displayed
as choices in the Web user interface.
Reference Rules The value of an annotation rule can be a reference to a member of

another category. For example, the value of the steward rule, assigned to
both the Application and Data Files categories, must be a reference to a
member of the Personnel category. Based on the following figure, the
value of the steward rule must be a reference to one of these objects:
John Doe, Jim Anchower, or Mitzi Katz.
Application business_area
steward
mp/ ref
ere Personnel phone
n ce
graph1 rul
e
department
Personnel/
graph2
John Doe
... e Jim Anchower
ru l
n ce
ere
ref Mitzi Katz
Data Files steward
dat/
dataset1
dataset2
...
Use a reference-type rule when you want to have access to the entire set
of metadata associated with an object. In this case you have access to
the steward’s name, phone number, and department. Just like string

rules, reference rules can have a single value or multiple concurrent

values.
Record Rules The value of an annotation rule can be the set of annotation values on
another category. For example, the value of the email_info annotation
rule on the Personnel category is all the annotation values defined on
Email Info. The effect is that the annotation values of Email Info are
embedded in the Personnel category members — John, Jim, Mitzi, and
so on.
Personnel phone home_email

Email Info work_email
email_info
Personnel/ record rule
John Doe
Jim Anchower
Mitzi Katz
...
The Email Info category does not need to have its membership
explicitly defined. Its members are record objects that hold the
annotation values for each member of Personnel.
“jdoe@juno.com”
value of email_info “jdoe@mysite.com“
Personnel for John Doe
Personnel/
“jima@rcn.com“
John Doe email_info value of email_info “janch@mysite.com“
Jim Anchower email_info for Jim Anchower
Mitzi Katz email_info
... “mk@hotmail.com“
value of email_info “mkatz@mysite.com“
for Mitzi Katz
The advantage of the record-type annotation rule is that you do not need
to specify a name and location for the associated metadata. A
record-type annotation rule is not directly accessible from the normal
directory tree for annotation rules.

Summary of Types of The following table summarizes the four types of annotation rules.
Rules
Type Values Example
String Strings attached to a Social Security number, because

single member object each employee has one number
Reference References to Steward, because its value is a

members of another member of Personnel
category
Choice Strings chosen from a Status, because there is a limited

list number of valid statuses:
Approved, Disallowed, and
Pending
Record Set of annotation Valid values

values for another
category
Rule Values Can Be By default, users cannot edit the values of annotation rules. However,
Edited you can define rules whose values users can edit in the Web user
interface.
Where Rules Are Annotation rules are stored in /abinitio/annotation rules. Do not
Stored in the EME manipulate annotation rules directly.

Examples of Creating Categories and Annotation Rules
Examples of Creating Categories

and Annotation Rules
Based on the categories and annotation rules discussed in this chapter,
here are some examples of:
• Creating individual categories and annotation rules
• Associating the rules with a category
• Adding members to categories
The examples use various air utility commands. We recommend that
you study these examples. In addition, Appendix G > Sample Scripts
contains a suite of scripts for creating categories and annotation rules
and other tasks.
Create Categories Use the air category create command to define the Application
category, which derives from the graph category and therefore inherits
all of graph’s rules. Similarly, define the Data Files category as derived
from dataset. The new category Personnel has mimeobj as its parent,
because Personnel is a category whose members cannot be derived from
built-in objects. Finally, create a directory to hold the members of this
category.
NOTE: Quote multi-word names of categories and rules, such as

“Data Files.”
air category create Application graph

air category create “Data Files” dataset
air category create Personnel mimeobj
NOTE: If you a enter a category name incorrectly, delete the category

using air category rm (page 173) and reissue air category
create (page 170).
Create Annotation You use the air arule create command to create all annotation rules. In
Rules the following example, the command defines the rule called
business_area. In addition, you define a set of characteristics for the
rule. For example, the rule will be displayed in the Web user interface as
Business Area (-display Business Area).

Also, business_area is a choice rule (-type choice); end users must

choose a single value (-multi-value) from a predefined list of values
(+in-list). A list of five choices for business_area is defined by the air
arule add-choice command (page 152). To define additional choices,
you would simply run the command again with the extra choices. The
choices are appended to the existing choice list.
air arule create business_area \
-display “Business Area” \
-type choice \
+can-edit \
-multi-value \
+in-list
air arule add-choice business_area \

“Accounts Payable” “Accounts Receivable” \
“Inventory” “Operations” “Marketing”
There are times when you might want users to be able to enter values
that are not among the choices presented in the Web user interface. In
that case, you would need to specify -in-list followed by the
+add-choice argument to air arule create.
In the next example air arule create (page 152) defines the steward
rule, which displays in the Web user interface as “Responsible
Individual”. The steward rule is a reference rule that points to the
Personnel category. This means that the value of the steward rule is a
member of the Personnel category, the target of the reference rule. A
user can edit the values of this rule (+can-edit).
air arule create steward \
-display “Responsible Individual”\
-type reference \
+can-edit \
Personnel
The phone rule is a single-valued string rule — the end user can enter
only one string value (-multi-value and -string) at a given time. This
rule, which displays as Work Number, has a default value of
617-555-1234.
air arule create phone \
-display “Work Number” \
-type string \
-default-value “617-555-1234”\
+can-edit \
-multi-value
Note that all types of rules can have default values: the default value of
string and choice rules must be a string; the default value of reference
rules must be a path to a member object of the target category.

Examples of Creating Categories and Annotation Rules
The department rule is a choice rule (-type choice). Users must select a
single choice (-multi-value) from a predefined list of six choices; they
may not specify additional choices (+in-list).
air arule create department \
-display “Department” \
-type choice \
-multi-value \
+in-list
Note that multi-word strings must be quoted.
air arule add-choice department \
“Human Resources” MIS Finance\
Administration Sales Marketing
NOTE: If you need to delete or make changes to a rule, use air arule
rm (page 160) or air arule modify (page 158), respectively.
To remove a choice from a choice list, use air arule
rm-choice (page 160).
Associate Rules with Using air category add-rule (page 164), you must explicitly assign an
Categories annotation rule to a category. You can assign annotation rules to
multiple categories. In the following examples, steward has been
assigned to Application and Data Files.
air category add-rule Application \
business_area steward
air category add-rule “Data Files” steward
air category add-rule Personnel \

phone department
NOTE: If you need to modify the characteristics of a category’s rules,

specifically with respect to a rule’s value, use air category
modify-rule (page 173). To disassociate a rule from a
category, use air category rm-rule (page 175).
Specify the Location The air category add-member-location (page 162) command
of Category Members associates objects with a category. These objects are said to be
members, or instances, of the category. Each member has all the
annotation rules assigned to the category. To make an object or objects a
member of a category, you specify its location in the EME. In the case
of Application (below), all the graphs in the mp directories of

myproject and myproject2 are members of Application and therefore

have the business_area and steward rules, which were assigned to
Application on page 35.
air category add-member-location Application \
/Projects/myproject/mp \
/Projects/myproject2/mp
air category add-member-location “Data Files” \

/Projects/myproject/tables
air category add-member-location Personnel \

/Metadata/Personnel
Note that /Metadata/Personnel is an empty directory; it contains no
objects. To add members to such a category, you need to store member
objects in the EME. In the case of Personnel, see Storing Non-built-in
Members on page 38.
NOTE: If you need to change a category’s membership, use air

category rm-member-location (page 174). To disassociate a
rule from a category, use air category rm-rule (page 175).

3>
Adding Metadata to an
EME Datastore
How Objects Get into Application-related objects are stored automatically when you check in
a Datastore a graph or a project through the GDE. Tracking runtime data can also be
stored by checking the Save Tracking Data to EME Datastore checkbox
in the GDE’s Run Settings dialog. (For more information, see the
chapter on using the Web to access the EME datastore in Guide to
Managing Technical Metadata.)
Users can explicitly store other objects using air utility commands or
through Ab Initio graphs.

• Defining and Storing Non-project MIME Objects That Are
Members of a Category (page 38)
• Adding One Item of Metadata to an Object (page 39)
• Adding Metadata in Bulk Using a Graph (page 42)

Chapter 3> Adding Metadata to an EME Datastore
Storing Non-built-in Members

Review In the Examples section of the last chapter (page 33), we derived
Personnel from the mimeobj category, which means Personnel’s
membership consists of objects that are not built-in. We also defined an
empty directory, /Metadata/Personnel, to store Personnel’s members,
and associated this directory with the Personnel category:
/Metadata/Personnel
We also created the phone and department annotation rules for
Personnel:
air category add-rule Personnel \
phone department
Now we are ready to add members to the Personnel category, which is
another way of saying “create instances of the Personnel class.” We
accomplish this goal by storing members in Personnel as MIME objects.
Examples To create the members of the Personnel category that represent your
employees, create and store them as text-type MIME objects in the
Personnel directory using air reposit text. For example:
air reposit text \
-string “John Doe” “/Metadata/Personnel/Doe, John”
air reposit text \
-string “Jim Anchower” \
“/Metadata/Personnel/Anchower, Jim”
air reposit text \
-string “Mitzi Katz” “/Metadata/Personnel/Katz, \
Mitzi”
This command stores each text string as a MIME object, assigning it a
MIME type of text/plain.
Follow the -string keyword with the first string to be stored, in this
case, “John Doe”. The second argument, for example,
“/Metadata/Personnel/Doe, John”, is the path to the EME
datastore location where you want the strings to reside.
The air reposit commands are described in the air utility command
reference chapter in Guide to Managing Technical Metadata.
Recommendations We recommend that the string you store to create the object be the
object name. We also recommend that you use last name, first name
format, as in “Doe, John”, to ensure the correct sort order.

Adding One Item of Metadata to an Object
Adding One Item of Metadata to

an Object
While we recommend that you add most of your annotation values
(metadata) in a batch, as described Adding Metadata in Bulk on
page 42, you can work with a single object by using air annotation add
to add or modify individual annotation values.
air annotation add You use air annotation add (page 148) to assign a value to an
Command annotation rule for a given object.
To use this command, you need to know information about the member
object, annotation rule, and annotation value. This information can be
obtained by running several air commands (page 41).
• Member object. You need to know where it resides in the
datastore and if its category has the annotation rule to which you
want to assign a value.
• Annotation rule. You need to know its name and type (for
example, string or choice) and whether it is single-valued or
multivalued.
• Annotation value. For a choice-type rule, you need to know
whether you can add a value that is not among the predefined list
of values. For a reference-type rule, you need to know whether the
value is a member of the target category.
Adding a Value for a Values for string- and choice-type annotation rules are specified as
String- or Choice-type strings.
Annotation Rule
Choice-type rules. Assume that the Mitzi Katz object is a member of
the Personnel category. This category has an annotation rule named
department, which is of type choice.
Personnel phone
department
Personnel/
John Doe
Jim Anchower Choices are Human Resources, MIS,
Mitzi Katz Finance, Administration, Sales, and
Marketing.

Let’s say you want to add a value of Sales for the department rule to the
Mitzi Katz object. In this case, you might type:
air annotation add \
“/Metadata/Personnel/Katz, Mitzi” \
department -string “Sales”
The first argument is the datastore location of the Mitzi Katz object, the
second argument is the name of the annotation rule, and the third
argument is the value specified with the -string keyword.
If department allowed multiple values at one time, then you could
specify more than one department for this employee, as in:
“/Metadata/Personnel/Katz, Mitzi” \
department -string “Sales” “Marketing”
Running the command again on the same object but with a different
department value (for example, Administration) will append that value
to the original values (for example, “Sales” and “Marketing”).
String-type rules. Assume that Personnel’s phone rule is a
single-valued string rule. To specify a phone for Jim Anchower, a
member of this category, you might type:
“/Metadata/Personnel/Anchower, Jim” \
phone -string “781 301-1234”
Adding a Value for a The value of a reference-type annotation rule is an object in the rule’s
Reference-type Rule target category. You specify the value as a full path to the object.
For example, Application’s steward rule is a reference-type rule that
points to Personnel. Therefore, the value of steward for the members of
Application must be a member of Personnel: John Doe, Jim Anchower,
or Mitzi Katz.
Application business area Personnel phone

steward
mp/ va
lue department
is
a
Personnel/
me
graph1 mb
er John Doe
of
graph2 Jim Anchower
... Mitzi Katz

Adding One Item of Metadata to an Object
Assume that the steward of graph1 is John Doe. To add John Doe as the
value of steward for graph1, you type:
add annotation add \
/Projects/myproject/mp/graph1.mp \
steward “/Metadata/Personnel/Doe, John”
Useful Related Here are several commands you might find useful when using air
Commands annotation add.
Use this command To
air arule dump See a rule’s type, default value, edit

(page 157) status, and other relevant information.
air annotation dump See the annotation rules and values for a
(page 150) given object.
air annotation rm Delete a value that you’ve entered in

(page 151) error or that is no longer applicable.
air category dump See the annotation rules associated with

(page 171) a category.

Adding Metadata in Bulk

A good way to load a great deal of metadata into the EME is to use the
GDE’s check-in feature or the air utility’s air project import
command. When you store a graph or project, a considerable amount of
metadata is stored as well. For example, when you store an Ab Initio
graph, the EME automatically creates the metadata for the graph and its
related elements (flows, vertexes, and so on). When you store a dataset,
the EME automatically creates the dataelement objects associated with
that dataset. (See Base Categories and Rules on page 222 for a
description of the built-in schema.)
Since it is much more efficient to add metadata (annotation values) in a
batch, the EME provides components for loading batch metadata into a
datastore. (These components are fully described in Appendix B > Load
and Unload components.) This section provides a sample graph that
uses two of these components to create and annotate a number of dataset
objects and load them into one of three databases in the EME. We
recommend that you use the sample graph to load metadata into your
EME datastore.
Load Components The EME provides the following five components for loading bulk
metadata into a datastore.
Two components allow you to manage the extended metadata:
• Load Mimeobj creates and loads a new MIME object into the
EME. MIME objects are the basis for all objects in the extended
metadata schema.
• Load Annotation Values creates and loads a new annotation into
the EME and connects it to the specific object. This component is
used in the sample graph on page 43.
Three components allow you to load some technical metadata objects:
• Load Table Dataset creates and loads a new table dataset. This
component is used in the sample graph on page 43.
• Load File Dataset creates and loads a new file dataset.
• Load Type creates and loads a new DML type object.
All of these components take the name of the EME datastore that you
are loading as a parameter. The main control over each component’s
behavior derives from the record format that you populate. The record
formats are documented for each component in Appendix B > Load and
Unload components.

Sample Graph The sample graph below creates a number of dataset objects in the EME
datastore and then creates and stores two annotation rules — Business
Area and Steward Group — for each dataset. For the sake of
convenience, this section concentrates on the customers and transaction
tables.
What You Need to Know To understand what happens when you run the sample graph, you need
to know that several categories and annotation rules already exist:
• The categories Table_View, Steward Group, and Business Area
have been previously defined.
• Each category has several annotation rules. Table_View has
Owner, TableOrView, Business_Area, and Steward_Group.
• Business_Area is a reference-type annotation rule that points
to the Business Area category; that is, its values must be
members of Business Area.
• Steward_Group is a reference-type annotation rule that points
to the Steward Group category.
• The members of the Steward Group and Business Area categories
are non-built-in objects that have been explicitly stored.
• The members of Steward Group are SG1, SG2, SG3, and SG4.
• The members of Business Area are Marketing, Finance, and
Operations.

Input to the Sample The input component, Example Metadata Spreadsheet, takes as its input
Graph an Excel spreadsheet, consisting of five records. Each record contains a
database name, a table name, and two annotation rules: Business_Area
and Steward_Group.
Remove Header and Remove Header is actually a renamed Filter by Expression component.
Replicate Components It selects and deletes the header, the first line of the spreadsheet. The
output is fed to Replicate, which generates two identical output streams.
Reformat to Dataset The stream fed to Reformat to Dataset Load runs first, in phase 0. The
Load Transform Reformat performs only some minor format changes, constructing a
string that points to a DML (.dml) file for each table and another that
points to a database (.dbc) file for each database. See the figure below
of the Reformat’s transform function.
Then for each input record, Load Table Dataset creates and loads a table
dataset into the datastore and links it to the database.

Normalize to Get Normalize to Get Dataset Annotations has two interesting transform
Dataset Annotations functions: length and normalize.
Transforms
Length. The length transform function sets the number of times that
Normalize runs with the same records. In this case, the length is 2, one
for the Business_Area rule, another for the Steward_Group rule.
Normalize. The normalize transform function (the figure below shows

the entire window) generates two new output records for each input
record.

Here are the details of the Transform Editor’s Business Rules pane. The
first time the transform function is called (index is 0), a record for the
Business_Area rule is generated. The second time (index is 1), a record
for the Steward_Group rule is generated.
Load Annotation loads the annotation rules into the datastore.
The Results After running the graph, you can see the results in the Web browser.
(This assumes that you have defined views for the metadata. You will
learn how to define views in Chapter 4 > Defining What Metadata Users
Can See.)
From the following figure of the Web page for the company_a database,
you can see that the customers and transactions tables are associated
with this database.
The transactions table is a member of the Table_View category.

Clicking the “transactions” hyperlink brings up more information about
that table.

For example, the following figure shows that the transactions table’s
annotation values for Steward_Group and Business_Area rules are SG1
and Operations, respectively. Compare this to the input spreadsheet on
page 44.
The customers table, also in the Table_View category, is associated

with the following annotation values: the Steward_Group is SG1 and
the Business_Area is Marketing, just as specified in the input on
page 44.
You can look at metadata from other perspectives. For example, you can
view which objects are members of a given category. The following
figure shows the Business Area category and its members: Finance,
Operations, and Marketing.

Clicking a hyperlink for a member object brings up the Web page for
that object. The following figure shows the Operations member of the
Business Area category. You can see the tables and databases with
which it is associated. The only annotation rule associated with this
member is Comment.
Scripts for Storing Appendix G > >Sample Scripts contains a suite of scripts for creating
Bulk Metadata categories and annotation rules, storing annotation values, and defining
views on the categories.

4>
Defining What Metadata
Users Can See
Once you have extended the base schema according to your business
requirements, and populated an EME datastore with metadata
(annotation values), it’s time to define what metadata users can see in
the Web user interface. This task is accomplished through views.

• Introduction to Views (page 50)
• Defining Content for Views (page 54):
• Syntax of air category add-view-element (page 56)
• Including Values from the Current Category or a Related
Category (page 59)
• Including Views Within Views (page 66)
• Including Text (page 69)
• Tips for Creating View-elements (page 70)
• Making Views Searchable (page 71)
• Defining a View for Editing Values of a Category Member
(page 73)
• How Views Are Rendered (page 78)

Chapter 4> Defining What Metadata Users Can See
Introduction to Views
What Is a View? Views allow users to see and edit metadata in the Web user interface.
Views are the only means for users to see your company’s metadata.
A view is similar to a filter on a table in that it describes a subset of the

metadata available for a given category. You decide which items of
metadata are included in the view. Given a view for a category and a
member object in that category, the renderer software translates the view
description into an HTML page for that member object.
In the following diagram the view on Personnel is applied to each

member of that category and then rendered as a Web page.
Web page with

Personnel metadata for
Paul Bergen
Personnel/
View
Paul Bergen
Web page with
Eric Smith metadata for
View Eric Smith
Jim Anchower
Web page with
View metadata for
Jim Anchower
Anatomy of a The following figure shows a rendered view — a Web page of metadata
Rendered View for Jim Anchower, a member of the Personnel category. The navigation
bar and the footer, which can be customized for your company, are not
part of the rendered view. (You will learn how to customize the
navigation bar, footer, and other aspects of the Web page in Chapter 5 >
Setting Up the Web User Interface.)

Category name Category member User-defined label Annotation value for this member
Navigation bar
Web page content

generated for the
view
Footer
View Names You can define multiple views for a category. Each view on the same
category must have a unique name, although you can reuse view names
across categories, as illustrated here.
Details view Details view

List view
List view
Data Files Steward
category category
Short view
Short view
View names can be multiple words. Multi-word names should be

quoted when specified as arguments in various air utility commands.
The name of the view does not appear in the Web user interface.
The EME includes a default Web user interface, which you can use to
build Web pages appropriate for your company. The default user
interface has two built-in views called details and list. You must define
views with these names (or names of your choosing) for every category
whose values you want to display. For more information, see Set
Default Views in the Main Menu on page 88.

First Plan Your Views We recommend that you describe your views on paper before creating
them. Look at each category to determine which annotation values you
want to appear in each of its views. Which items of metadata would you
like users to see as a unit in the browser? Which views would you like to
be included in other views? (The last two rendered view-elements in the
figure on page 54 are actually views included in another view.)
Special Views Note that there are several views with specialized purposes:
• A view that allows end users to modify annotation values. See
Defining a View for Editing Values of a Category Member on
page 73.
Its default name is edit-view. To change the default name, see Set
View for Editing Annotation Values on page 90.
• A view that displays search results.
By default, the list view is used to render search results. To change
the default name, see View to Display Search Results on page 72
and Set Default View for Search Results on page 87.
Next, Create Empty When you create a view on a category, it defines no content. It is merely
Views a blank slate associated with a category. We recommend that you create
all your views using air category add-view (page 166) before defining
content.
Example Create the Details, List, and Short views and associate them
with the Data Files category. Create like-named views and associate
them with the Steward category.
air category add-view “Data Files” Details \
List Short
air category add-view Steward Details \
List Short
Note When you customize the Web user interface for your company,
as described in the next chapter, you will need to specify the names of
your default views for displaying metadata. By default, these views are
named list and details. Either create views with the names list and
details or substitute the names of your views. (For more information,
see Set Default Views in the Main Menu on page 88.)
Finally, define content You define content for a view by creating one or more view-elements.
for the view See Defining Content for Views on page 54 for more information.

Sample Scripts for Appendix G >Sample Scripts contains a suite of scripts for creating
Creating Views categories and annotation rules, storing annotation values, and defining
views on the categories.
Views on the If you installed the extended schema included in the installation package
Extended Schema (described in A Quick Look at the Extended Schema on page 23 and in
Extended Categories and Rules on page 234), then you might want to
install the views defined on the categories of the extended schema. The
views are named list and details. You can install these view definitions
by running $AB_HOME/connectors/EME/standard-view.ksh. Note
that if you installed the sample EME, the views on the extended schema
were installed automatically.

Defining Content for Views

You define a view’s content by creating one or more view-elements for
the view. View-elements, once rendered in the Web user interface,
make the values of annotation rules visible to users.
What Is a A view-element describes the metadata that will be rendered in the Web
View-element? user interface. Each view-element consists of both a label and a
description of which annotation values to display for a given member of
the category.
The Web page in the following figure shows how five view-elements
are rendered in the browser.
Member of Personnel category
Annotation value of the
comment rule for member
Jim Anchower
User-defined label for
the comment rule
Rendered view-elements
What Should Become The following rules should be included in view-elements:

A View-element?
• Rules whose values you want your users to be able to see in the
Web user interface
• Rules that can be edited (that is, defined with the +can-edit option
to air arule create)
Label of a Each view-element must have a label, which is text describing the item
View-element of metadata. For example, in the above figure, Comment, Phone, and
Department are all user-defined labels that appear to the left of an
individual annotation value.
The bold text Applications this employee is responsible for and Data
Files this employee is responsible for are also labels, but they introduce
a group of annotation values from another view.

Defining Content for Views
Types of There are three different types of view-elements.

View-elements
Type What the Rendered View Displays
simple A single annotation value from the current category (the one on
which the view is defined)
or
A single annotation value from another category or categories
with which the current category has foreign-key relationships
(that is, reference-type rules “connect” the categories)
Example: First three view-elements in the preceding figure
view The contents of a view defined on another category with which

the current category has a foreign-key relationship
Example: Last two view-elements in the preceding figure
decorate HTML text, for example, an introduction to the Web page
You specify the view-element type as part of the air category

add-view-element command (page 56).

Syntax of air category

add-view-element
Description The air category add-view-element command describes one or more
view-elements and associates them with an existing view on the
specified category. Add the view-elements in the order in which you
want them displayed in the Web user interface. You may define more
than one view-element at a time for a given view on a category.
Syntax air category add-view-element category view element-type ⇒

[+index | -index] [+display-contents | -display-contents] ⇒
[+auto-show | -auto-show] [+can-toggle | -can-toggle] ⇒
label element-descriptor element-view ⇒
[for multiple view-elements, repeat from element-type]
category Name of an existing category.
view Name of the existing view defined on category.
element-type Specify one of the following:
• -simple specifies a view-element that
describes the value of a single annotation rule
on this or another category. See examples on
page 59.
• -view specifies a view-element that refers to
a view on a related category. See description
on page 66.
• -decorate specifies a view-element that
describes stored HTML text. See description
on page 69.
+index | -index Optional.
• +index means the values of the view-element
will be placed in a search index. Users can
search for these values in the Web user
interface.
• -index (default) means the values of the
view-element will not be searchable.
For more information, see Making View-element
Values Searchable on page 71 and Creating a
Search Index on page 94.

Syntax of air category add-view-element
+display-contents Optional. Valid only for view-elements that are

|-display-contents reference rules whose values are MIME objects.
• +display-contents means the value is a
hyperlink that, when clicked, displays the
MIME object’s contents. For example, if the
contents are a MS Word document, then the
document is displayed in your Web browser.
• -display-contents (default) means the value
is a hyperlink that, when clicked, opens a
view of that object in a new Web page.
+auto-show | Optional. Valid only for -view view-elements.
-auto-show
• +auto-show (default) means that the view
included in the current view is fully
expanded. That is, all the view-elements of
the included view are displayed in the current
view when rendered.
• -auto-show means that the contents of the
included view are collapsed.
For more information, see Display Options on
page 67.
+can-toggle | Optional. Valid only for -view view-elements.
-can-toggle
• +can-toggle means that users can switch
between the expanded and the collapsed
display of the included view.
• -can-toggle (default) means that users can
see only the current display of the included
view. The current display is determined by
the setting of the auto-show option.
For more information, see Display Options on
page 67.
label Text (string) that describes a metadata item.
Except for labels for -decorate element-types, the
label is displayed in the Web user interface.

element-descriptor Describes values associated with member objects.

The format depends on element-type. Escape
characters are required for -simple and -view
element-types (see below).
• For -simple, the format is one of these:
• | relation > or arule-name, which
describes annotation values on the
current object.
• < relation | , which describes objects that
depend on the current object.
• Combinations of these:
| relation > | relation >
< relation | <relation |
< relation | | relation >
| relation > < relation |
• relation is a category-rule pair in the
format: category.arule
• For -view, the format is the same as above
plus element-view.
• For -decorate, the format is a datastore path
to the MIME object.
element-view Required if element-type is -view; do not use with
other types. The name of the view you want to
include, in the format: category.view. Escape
characters are required.
Escape Characters in These characters must be escaped by a forward slash when used as part
Element-descriptors and of the syntax of an element-descriptor or element-view:
Element-views
• < (left angle bracket)
• > (right angle bracket)
• . (period)
• / (forward slash)
• | (vertical bar)
So the format is actually: / | category/.rule/ >/ | category/.rule/ >
For example:
“/|Data Files/.steward/>/|Steward/.phone_no/>”

Including Values from the Current Category or a Related Category
Including Values from the Current

Category or a Related Category
Simple view-elements, defined by the -simple keyword to air category
add-view-element, describe (1) the value of an annotation rule on the
current category or (2) an annotation rule on another category that
relates to the current category through one or more reference-type rules.
The exact syntax is determined by the relationship between the rules. A
number of examples follow.
Annotation Value on the Assume you have created the empty view DF-Details on the Data Files
Current Category: category and now you want the Comment label and the value of its
Example 1 comment rule (type string) to appear in the rendered view.
Data Files Comment: comment-value
dat/ DF-Details view

customers comment
transaction comment
The syntax of the element descriptor is in the | relation> format.

air category add-view-element “Data Files” \
“DF-Details” -simple “Comment” \
“/|Data Files/.comment/>”
Alternatively, you can express this more simply using the shortcut:
“DF-Details” -simple “Comment” comment
Since the comment rule is defined on the category on which the view is
being defined, you can refer to the rule by its name.
When DF-Details for customers is displayed in the browser, the page
shows the label “Comment” and the value of the comment rule for
customers. See the first rendered view-element in the following figure.

Comment
label Value of comment rule
Annotation Value on the The same syntax applies when the annotation rule is of type reference.
Current Category: Assume you want the rendered DF-Details view to show the steward
Example 2 responsible for a given data file, that is, the value of the steward
reference-type rule.
DF-Details view
Steward: steward-value
Data Files Steward
dat/ sg/
personnel
customers steward Eric Smith phone_no
comment
steward ... personnel
transactions
comment phone_no
The syntax of the element descriptor is in the | relation> format:

“DF-Details” -simple “Steward” \
“/|Data Files/.steward/>”
When DF-Details is rendered for customers, the Web page shows the
label “Steward” and the name value of the steward annotation rule for
customers. The value is rendered as a hyperlink to the Steward category.
Hyperlinks denote categories related to one another through reference
rules. See the second view-element below.
Steward
label
Value of steward rule on Data Files category

Annotation Value On In this example, you want to use the information in the previous figure,
Another Category: but now you are adding a view-element to a view on Steward. In the
Example 1 following figure, the categories have been reversed. Assume we want
the rendered S-Details view to display the data files that are the
responsibility of a given steward, that is, the value of the steward
reference-type rule.
Data Files: data-file-name S-Details view
Steward Data Files
sg/ dat/
personnel steward
phone_no customers
Eric Smith comment
Paul Bergen personnel steward transaction
phone_no comment
The syntax of the element descriptor is in the < relation | format — the
reverse of the previous example, because our perspective is reversed:
we are building the view with respect to Steward rather than Data Files.
Steward, which is pointed at by Data Files, provides a value for Data
Files; that is, Data Files has a foreign key relationship with Steward.
air category add-view-element Steward \
“S-Details” -simple “Data Files” \
/<“Data Files”/.steward/|
When the view is rendered for a given steward, the Web page shows
zero or more data files for that steward.

Annotation Value on You might need to specify a chain of one or more reference rules in
Another Category: order to access a single value. Consider the following example. You
Example 2 want the rendered DF-Details view to display the phone number of the
steward, but the information about the steward’s phone number is
associated with the Steward category.
Note in the figure that the Steward category has a phone_no rule.
Accessing the information in another category requires that a reference
rule “connects” the two categories. In this example, steward is a
reference-type rule, whose value is a member of Steward.
DF-Details view
Steward’s Phone: phone_no
Data Files Steward

sg/
dat/ personnel
steward Eric Smith phone_no
customers comment
steward Paul Bergen personnel
transactions phone_no
comment
To add phone number information to the DF-Details view of Data Files,

use an element descriptor with the | relation> | relation> format,
because the value of phone_no depends on the value of steward:
“DF-Details” -simple “Steward’s Phone” \
“/|Data Files/.steward/>/|Steward/.phone_no/>”
Tip You might find it helpful to think of the angle brackets as
pointing in the direction of the relationship.
When DF-Details for customers is displayed in the Web user interface,
the view shows the label “Steward’s Phone” and the value of phone_no
for steward Eric Smith.
Steward’s
Phone label
Value of phone_no rule on Steward category

Annotation Value on Let’s say that three categories — Steward, Data Files, and Database —
Another Category: are related through two reference-type rules. As shown in the following
Example 3 figure:
• Steward provides a value to (or is pointed at by) Data Files through
the steward annotation rule. In other words, Data Files has a
foreign key relationship with Steward.
• Data Files depends on Database by means of the database rule.
S-Details view
Database: database-name
Steward Data Files Database
sg/ dat/ db/

personnel steward
Eric Smith phone_no customers database db1
Paul Bergen personnel steward transactions database db2

phone_no
The goal is to access a value in Data Files that comes from Database and
then include that value in the S-Details view on Steward. To accomplish
this goal, the syntax must express these two relationships:
Steward is pointed at by the The database rule of Data

steward rule of Data Files Files points at Database
<relation | | relation>
Therefore, the code is:

“S-Details” -simple “Database” \
“/<Data Files/.steward/|/|Data Files/.database/>”

Annotation Value on Let’s say that three categories — Steward, Data Files, and Application
Another Category: — are related through two reference-type rules. As shown in the
Example 4 following figure:
• Steward provides a value to (or is pointed at by) Data Files through
the steward annotation rule. Another way of saying this is that Data
Files has a foreign key relationship with Steward.
• Data Files provides a value to (or is pointed at by) Application
through the input annotation rules. Application has a foreign key
relationship with Data Files.
In this example, the goal is to build the S-Details view on Steward that
includes the name of the graph or graphs that use data files for which a
given steward has responsibility.
To express these two relationships, use an element descriptor with the
<relation | <relation | format:
“S-Details” -simple “Application” \
“/<Data Files/.steward/|/<Application.input/|”
S-Details view
Application: graph-name
Steward Data Files Application
sg/ dat/ / mp
personnel steward
Eric Smith phone_no customers input JoinCustomers
Paul personnel steward transaction input LoadJoined...

phone_no

Annotation Value on The goal of this example is to include all applications that depend on the
Another Category: output of a given application in the A-Details view of Application. This
Example 5 example is unlike the previous examples in that it is built around two
relationships between the same categories: Application and Data Files.
The syntax of the element descriptor is in the | relation> <relation |
format.
air category add-view-element Application \
“A-Details” -simple “Application” \
“/|Application/.output/>/<Application/.input/|”
The syntax | Application.output > expresses the fact that the
output rule points to the data file that is the output of an application. The
syntax <Application.input | returns all the applications that use
the output files as input.
A-Details view
Application: graph-name
Application Data Files
/ mp dat/
output
JoinCustomers input customers
output
LoadJoined... input transaction

Including Views Within Views

View view-elements, defined by the -view keyword to air category
add-view-element, describe the objects that are related to the current
object and an existing view on the target category. The contents of the
view on the target category appear in the view that you are building. Use
the -view keyword when both of these conditions are true:
• You want to add the entire contents of another category’s view to
the view you are building
• An annotation rule in the current category (the one on which you
are building the view) is related to the category whose view you
want to access.
The format for specifying the descriptor of a -view view-element is the
same as that for a -simple view element (page 58 and page 59), except
that the descriptor must be followed by element-view, which is the name
of the view in the format:
category/.view
Note Periods must be escaped. See page 58 for more information
about when to use the forward slash escape character.
Including Another View in The goal of this example is to add the contents of the S-Details view on
Your View: Example Steward to the DF-Details view on Data Files. This situation is shown in
the following figure.
DF-Details view
Comment: comment-value
Steward’s Phone #: phone_no-value
S-Details view
Steward Info
Name: name-value Name: name-value
Phone #: phone_no-value Phone #: phone_no-value
... ...
Data Files Steward
dat/ sg/ name

personnel
dat1 steward s1 phone_no
comment name
steward s2 personnel
dat2 phone_no
comment

Including Views Within Views
The value of the steward rule depends on the Steward category; for
example, the value of dat1’s steward rule depends on the value s1. This
relationship is expressed as:
/|“Data Files”/.steward/>
The name of the view to be included is expressed as the name of the
target category, a dot, and the name of the view on the target category:
Steward/.S-Details
The full syntax for accessing the S-Details view on Steward and adding
it to the DF-Details view on Data Files is:
air category add-view-element \
“Data Files” “DF-Details” \
-view “Steward Info” /|“Data Files”/.steward/>\
Steward/.S-Details
When DF-Details for the dat1 object is displayed in the Web user
interface, the view will display, among other things, the name and the
phone number of the steward that points to it, in this case, the steward
s1. Note the horizontal line in the following figure that separates the
-simple view-elements from the -view view-element.
Tip To delete unwanted or redundant view-elements (for example, the

phone number in the above figure), use air category rm-view-element
(page 176).
Display Options You can control the way -view view-elements are displayed in the view
you are defining. The following figure shows a rendered view on the
TableView category. The bottom of the view displays a rendered -view
view-element. Note that all the labels, rule names, and annotation values
of the included view are displayed.
Click Hide to collapse the details
Label of -view
view-element
By default, all view-elements

When rendered, -view (labels, rules, and values) of
view-element displays the included view are displayed
this view within the
view on Tableview

Expanded or Collapsed? The auto-show option to air category add-view-element controls

whether the annotation details are expanded or collapsed. By default,
the option is turned on (+auto-show), which expands all view-elements
of the included view. To hide the details of an included view when the
current view is first rendered, set the value of this option to -auto-show.
Note the “Hide” hyperlink to the right of the Columns label in the
preceding figure. By clicking Hide, users can collapse the included
view. The annotation details are replaced by a show label hyperlink, for
example, show Columns, as in the figure below.
Show Columns
hyperlink
Toggling To allow users to toggle between the expanded and collapsed rendered
view, you must specify the +can-toggle option to the air category
add-view-element command. By default, the option is turned off
(-can-toggle). Make sure that the value is +can-toggle if you specify the
-auto-show option.
Note You can modify the toggling behavior of all -view view-elements
at once by changing the value of the show_all_views_expanded
configuration variable in the Web user interface. See Show All Views
Expanded or Collapsed on page 89.

Including Text
Including Text
Decorate view-elements, defined by the -decorate keyword to air
category add-view-element, allow you to add text to a rendered view.
For example, perhaps you want to add an introduction to be displayed at
the top of a Web page.
First you must store the text as a MIME object using air reposit mime
or air reposit text. (See Guide to Managing Technical Metadata for
details for the command syntax.) For example:
air reposit text \
-string “This view contains information about \
the tables for which stewards are responsible.”\
“/Projects/documentation/view-text”
Then add the text as a -decorate view-element. The format is:
-decorate label datastore-path-to the-MIME-object
For example:
air category add-view-element \
“Data Files” “DF-Details” \
-decorate “table-steward” \
“/Projects/documentation/view-text”
Note that the label for a -decorate view-element is not displayed in the
rendered view.

Tips for Creating View-elements

Here are some tips for creating view-elements:
• To see which annotation rules have been defined for a given
category, use air category dump on page 171.
• Add view-elements in the order that you want them to appear in
the Web user interface.
• If, when you include a view in another view, you find you have
redundant elements, you can remove unwanted elements using air
category rm-view-element (page 176).
• Labels do not need to be unique across views.
• Enclose element-descriptors in double quotes. Single quotes cause
problems.
• Remember to use the forward slash escape character before angle
brackets, periods, forward slashes, and vertical bars that appear in
element-descriptors and element-views.
• You can control the appearance of date, time, and boolean
annotation values in the Web user interface by setting various
configuration variables. See Configuration Variables on page 279.

Making Views Searchable
Making Views Searchable

View-elements determine which annotation values are displayed in the
Web user interface. Optionally, you can allow users to locate these
values by searching the Web user interface. Users enter their search
criteria by selecting a category from a drop-down list box in the
navigation bar (see figure), entering the text to search on within the
specified category, and clicking GO.
Navigation bar Categories to search Text to search for Advanced search
Alternatively, users can click the Advanced Search button to open a

search screen in which you can enter multiple search criteria.
Making View-element To make a particular view-element’s values searchable, specify the

Values Searchable +index argument to air category add-view-element. For example, the
following specification adds a view-element labeled Members to the
details view on the Steward Group. The +index argument means that
users can search for values of the members rule in the Web user
interface.
air category add-view-element “Steward Group” \
details -simple +index Members members

Making Views For view-element values to be searchable, the view to which the
Searchable view-elements belong must be defined on a searchable category. For
example, let’s say you define the A-Details view on the Steward Groups
category and make three of its view-elements searchable. For users to be
able to search for values of these three view-elements, Steward Groups
must be defined as a searchable category when you set up the Web user
interface. For instructions, see Make Categories Searchable on page 87.
View to Display The results of a search are displayed in their own view. By default,
Search Results search results are displayed in a view named list. Once you click GO to
begin the search, the results are displayed in the list view, directly
following the search criteria:
Search criteria
List view
To change the name of the view for search results, see Set Default View
for Search Results on page 87.
Initial Number of By default the search view shows 60 search results. To change the
Search Results default number, set the value of the initial_results_limit configuration
variable as described in Set Initial Number of Search Results Shown on
page 88.
Search Index By default, the EME executes a search by scanning a search index of
annotation values. (Optionally, you may disable the search index. See
Enable/Disable the Search Index on page 88.) You must build this index
yourself. For more information, see Creating a Search Index on page 94.

Defining a View for Editing Values of a Category Member
Defining a View for Editing Values

of a Category Member
Edit... Hyperlink The sample EME includes an “edit...” hyperlink. For example, the
Opens an Edit Page following figure shows the rendered view for Abbot Stewards of the
Steward Groups category. The “edit...” hyperlink appears to the right of
the category (Steward Group) and member object (Abbot Stewards).
edit... hyperlink
Clicking this hyperlink opens a new Web page, which allows users to
edit annotation values for a single member object of a given category.
For example, clicking “edit...” on the Web page for Abbot Stewards
opens the Edit Steward Group: Abbot Stewards page, shown in the
following figure. Users can edit the annotation values from this page
and save the values in the EME datastore.
Label of view-element
for comment rule
Annotation value
of view-element
for comment rule
Label of view-element
for Members rule
Annotation value
of view-element
for Members rule

Edit View Generates Much of the edit page in the preceding figure — the title and scroll bars,
an Edit Web Page the page title (Edit ...), the fields, and the controls — is created
automatically by Ab Initio software. The “edit...” hyperlink is also
automatically placed next to the category and object names.
The content of the edit page, however, is generated from an edit view.
An edit view is special in the sense that users cannot only see annotation
values in the rendered edit view, they can edit them too. All you have to
do is create a view and define view-elements that, when rendered,
become the content of the edit page. You should define an edit view for
every category whose values are modifiable.
Name of the Edit View The edit view should have the same name across all categories on which
such views are defined. The default name for this special view is
edit-view, but you may choose any name you want.
edit-view view edit-view view edit-view view
Data Files Steward Databases

category Group category
category
Enter the name, if different from that the default, as the value of the
edit_view_name variable.
Defining the Edit View First create a view for each category with editable values. For example:
air category add-view "Steward Group" edit-view
Defining Its Content We recommend that the content of the edit view — its view-elements —
closely resemble (but not necessarily be identical to) the content of the
view to which it corresponds. For example, here is the definition of a
view defined on Steward Groups:
air category add-view-element "Steward Group" default -simple \ +index
"Comment" comment
air category add-view-element "Steward Group" default -simple \ +index
Members Members
air category add-view-element "Steward Group" default -view \
"TableViews this Steward Group is responsible for"
"/<TableView/.Steward_Group/|" "TableView/.default-list"

This definition creates the rendered Web page, shown in the first figure
on page 73. Note that the last view-element, labeled “Tableviews this
Steward Group is responsible for,” does not appear in the edit page (the
second figure on page 73). Indeed, the edit page was generated from the
following edit-view definition, which excludes this view-element:
air category add-view-element "Steward Group" edit-view -simple +index
"Name" name
"Comment" comment
"Description" description
"Members" Members
Exclude View-elements We can assume that the creator of the above edit-view definition did not
or Turn On Permissions? want users to be able to modify which tables or views are managed by
the Abbot stewards. Hence, he or she excluded this view-element from
the definition of the edit view.
An alternative to excluding such view-elements from an edit view
would be to turn on EME permissions so that unauthorized users or
groups will not see annotation values to which they do not have access.
For more information about permissions, see Chapter 8 > Managing
EME Security.
Just-for-information Edit views can include view-elements for rules whose values cannot be
View-elements edited as well as those which are not present in the view on which the
edit view is based. A possible reason for including rules that cannot be
edited might be to present information useful to the user who wants to
modify another annotation value.
For example, you might want to present the date that the annotation
values related to Abbot Stewards were last modified. You would
accomplish this by adding a view-element for the modification_date
rule.
"Modification date" modification_date
When the edit view is rendered, it yields the edit page shown in the
following figure. Note that Modification date, which is defined as
-can-edit, cannot be edited in the view.

New view-elements
appear at the bottom
of the page
Reordering Newly added view-elements always appear at the bottom of the edit
View-elements page. If you are not pleased with the order of view-elements in the
rendered page, you must remove the out-of-order view-element and
re-add it. So, for example, to have Members in the previous figure
appear last, you would remove it using air category rm-view-element
and then add it again using air category add-view-element, like so:
air category rm-view-element "Steward Group" edit-view Members
Members Members
This yields the following edit page:
Members and Modification

date are now reversed

How Controls Are The EME renders the edit controls based on the definition of the
Rendered associated annotation rule, as specified in air arule create (page 152).
• If the rule’s value can be edited (+can-edit), then the controls
support editing. For example, both the comment and Members
rules can be edited. The modification_date rule, a built-in rule of
the base schema, is defined as -can-edit. Its annotation value is
displayed but cannot be modified.
• The rule type determines the type of control rendered. For
example, the Members rule is a choice rule (-type choice), and
therefore a combination text-and-drop-list field is displayed.
• If the rule is defined as +big-text, then the control is a multiline
edit field. For example, the comment rule is a +big-edit string rule,
therefore, the control is a multiline edit field.
Note You can also make the edit control 25-30% wider by setting
the use_wide_edit_controls configuration variable. See Set Width
of Edit Controls in an Edit View on page 90.
• If a choice-type rule is defined as -in-list and +add-choice, then
users can add a choice that does not appear in the drop-down list.
Conversely, if a choice-type rule is defined as +in-list, the edit
page does not accept a value that is not in the drop-down list.
• If the rule is single-valued (-multi-value), then only one value can
be saved. If the rule is multivalued (+multi-value), then the edit
page allows the user to specify more than one value.
Summary of Here’s a summary of what you need to do to make annotation values

Requirements available for editing:
• You must define an edit view for the category that defines the
annotation rules you want users to be able to edit.
• Make sure that at least one annotation rule included in the edit
view is defined with the +can-edit option.
• The current user must have write permission on both of these:
• The annotation rule defined with the +can-edit option
• The object he or she is trying to edit

How Views Are Rendered

Comparing the View The following figure shows the view that appears when you click the
with Its Specification “Jim Anchower” hyperlink in the Personnel category. Compare the code
that created the details view with the display in the Web user interface.
air category add-view-element Personnel details \
-simple Comment "/|Personnel/.comment/>" \
-simple Phone "/|Personnel/.phone/>" \
-simple Department "/|Personnel/.department/>" \
-view "Applications this employee is responsible for"
"/<Application/.steward/|" Application/.list \
-view "Data Files this employee is responsible for" \
"/<Data Files/.steward/|" "Data Files/.list"
Category name
3 simple
view-elements
2 view
view-elements
Reference-type rules are rendered

as hyperlinks, indicating that the
annotation value is a member
object of a related category
The view-elements appear in the Web user interface in the order in

which they were specified in air category add-view-element. The three
simple view-elements appear at the top followed by two view view-
elements, which are separated from other elements by a dotted line.
View view-elements describe views on categories other than the one on
which the current view is defined (in this example, Personnel). By
looking at the code specification, you can see that:
• The first -view view-element derives from the list view on
Application. The Application and Personnel categories are related
through the steward reference-type rule on Application.
• The second -view view-element derives from the list view on Data
Files. The Data Files and Personnel categories are related through
the steward reference-type rule on Data Files.
Annotation values that are member objects of related categories are
shown as hyperlinks. For example, the “transactions” hyperlink
represents the transactions member object in the Data Files category.

5>
Setting Up the Web User
Interface

• Installing Web Resources and Scripts (page 80)
• About the Main Page and Other Attributes (page 81)
• Setting Configuration Variables for the Web Interface (page 83)
• Using the Default User Interface to Build Your Own (page 92)
• Creating a Search Index (page 94)
• Allowing Users to Add or Remove Values from a Category
(page 96)
• Allowing Users to Create Values and Add Them to a Category
(page 98)
Log In to the Web After setting up the Web user interface, you can log in to your Web
User Interface browser at host-name/bmr/bmr_login.html to begin viewing business
metadata.

Chapter 5> Setting Up the Web User Interface
Installing Web Resources and

Scripts
install-bmr Script The install-bmr script automates two processes related to setting up the
Web user interface for enterprise metadata:
• Installing resources (images and style sheets, for example) into
your Web server's html directory
• Storing rendering scripts in your EME datastore
You must run the script before using the EME. During a single script
run, you can choose to install only resources, only scripts, or both, but
eventually you must install both resources and scripts.
Before You Begin You may, if you want, copy $AB_HOME/lib/bmr to a new location,
then, in the copy, customize the images, style sheets, and scripts
included with the distribution. You will specify the directory location of
the customized files in the procedure.
To run install-bmr, you will need to know the following information:
• The directory in which your Web server stores html resources. The
table lists the most common choice for each supported server.
For this software This directory is likely to be ...
IIS on Windows c:/inetpub/wwwroot
Apache on Windows c:/Program Files/Apache Group/Apache/
htdocs
Apache on Unix /home/httpd/html
• The directory where your Web server finds html resources and the
subdirectory into which the Web server should find business
metadata html resources.
• If running Windows, the domain of the users who will be logging
in to the EME’s Web user interface. The local domain is "." (dot).
• The path to your EME datastore.
Syntax To see the syntax of install-bmr, type:

install-bmr -help
We recommend that you run install-bmr at the command line without
any arguments; it walks you through the installation interactively.

About the Main Page and Other Attributes
About the Main Page and Other

Attributes
Anatomy of the Web The followinllg figure shows the main page of the Web user interface
User Interface for the sample EME. It consists of a navigation bar, a footer, and a main
menu — all of which you should customize for your company.
List of hyperlinks displayed in the navigation bar Categories that users can search
Navigation bar
Welcome message is a Customizable welcome message

double-width 1
html-style block
3
2
Main menu has 4
blocks: tiled from left
to right, from top to
bottom
4
Single-width cvs-style block of the

Column category
Single-width table-style block of the

Business Attribute category
Footer
Centered footer text, e.g., the Email address for Right-most hyperlink, e.g.,
name of your EME datastore the Support team URL for HTML-based Help
What Controls Its The appearance and contents of the main page are determined by
Appearance and
• Configuration variables
Content?
• User permissions
• Group membership
• Cascading style sheets

Configuration Variables You can set a number of configuration variables to control many aspects
of the main page and other attributes. For example, you can:
• Choose the categories to appear as hyperlinks in the navigation bar
• Control the content and presentation of the main menu
• Choose the categories users can search (shown in navigation bar),
the number of search results that are shown initially, and whether
the EME accomplishes the search through a search index or an
exhaustive linear search
• Create hyperlinks to appear in the footer, for example, Support
email address, URL for HTML help, and name of your datastore
• Change the number of initial items returned by a search
This chapter explains in detail how to set configuration variables.
User Permissions The appearance of the main page is also affected by EME user
permissions. For example, certain annotation values may or may not
appear, depending on which objects you have granted users permission
to see. For more information on permissions, see Granting Permissions
on page 129.
Group Membership You can customize the main page for the groups that users belong to.
For example, the development group can see a different main page than
the executives group. You accomplish this by setting configuration
variables for different attributes of the main page. Use the air system
group add-group (page 184) to set up groups for your company. For
background information, see Setting Up User Groups on page 126.
All users belong to the world group. The world group is the
built-in group to which every user who can log in to the EME Web user
interface belongs. The figure on the previous page shows the main page
of the sample EME for the world group.
Cascading Style Sheets The appearance of the Web user interface is determined by a built-in
cascading style sheet, $AB_HOME/lib/bmr/html/css/abinitio.css. If
you want to customize the main page for your company, create a file
called site.css and define your new CSS definitions there. Place the file
in your Web server’s html_dir/bmr_subdir/css directory. By defining
your settings in a site-specific style sheet, rather than in abinitio.css,
you preserve your custom settings, even if you rerun install-aiw or
install-bmr.

Setting Configuration Variables for the Web Interface
Setting Configuration Variables

for the Web Interface
This section describes the various configuration variables responsible
for the appearance and other aspects of the Web user interface.
air web-interface You configure all attributes of the Web user interface through a group of
Commands air web-interface commands. For a complete description of all
commands, see air web-interface Group on page 191.
Displaying Variables To see documentation for all the configuration variables, use the air
Documentation web-interface describe command:
air web-interface describe -all
Displaying Current To see the current settings of all configuration variables for a particular
Settings Of Variables user group, use the air web-interface show command:
air web-interface show group -all
You might want to run show before setting up the main page for the first
time, in order to become familiar with the initial settings of all
configuration variables.
Setting Variables The command to set configuration variables is air web-interface set,
which takes a group name, the name of a configuration variable, and a
value for the variable:
air web-interface set group configuration-setting value
Setting Up the Footer The footer has a Support Email Address Hyperlink and a Help
Hyperlink on the right of the footer as well as centered text that you can
customize.
Support Email Address The configuration variable client_support_email specifies the email
Hyperlink address for your company’s Support team. It appears as the Support
hyperlink in the footer of the Web page.
The default value is someone@example.com. To change the value
for the world group to Support@widgets.com, you would specify:
air web-interface set world \
client_support_email_address Support@widgets.com

Help Hyperlink The configuration variable client_help_url_address specifies the path to

your help file for the Web page. It appears right-justified as the Help
hyperlink in the footer of the Web page. The default value is
/Metadata/help/bmr_help.html.
client_help_url_address \
/Metadata/bmr/bmr_help.html
Centered Text The configuration variable client_footer_center_html specifies text that

appears centered in the footer of the Web page. The default value is:
Sample Business Metadata. To change
the value for the world group to Widget Metadata, you would specify:
client_footer_center_html\
“Widget Metadata”
Note that the value is enclosed in double quotes.
Setting Up the Main The configuration variable main_menu_blocks specifies the content and
Menu appearance of the main menu, which is the area between the navigation
bar and the footer. It consists of one or more blocks which are tiled from
left to right, and from top to bottom.

Blocks consist of either categories or stored HTML. For example, the

welcome message in the preceding figure is HTML; the other blocks are
categories. There are four blocks, in this order: the HTML welcome
block, the Steward Group category block, the Column category block,
and the Business Attribute category block.
To create the main menu for the world group of the sample EME you
would specify:
air web-interface set world main_menu_blocks \
"[('html', '/Metadata/Menus/welcome.html', 2),
('category', 'Steward Group', 1,'table', 'list'),
('category', 'Column', 1, 'csv', 'list'),
('category', 'Business Attribute', 1, 'table',
'list')]"
Note that the entire value is enclosed in double quotes and brackets: "[
and ]". Also, each menu block definition is surrounded by parentheses
and separated with a comma from the next definition.
Each menu block has the following fields:
Field Description
Type String. Contents of the block. Valid values are category

or html. Enlose the value in single quotes.
Category name String. Name of an existing category. Use air ls to see a

or object list of categories in /abinitio/categories.
Width Integer. Valid values are 1 (single-width block) or 2

(double-width block).
Examples: Steward Group is a single-width block, and
the welcome message is a double-width block.
Style String. Display format. Applies only to category-type

blocks. Valid values are table (tabular format) or csv
(comma-separated values).
View String. View to use when displaying information.

Applies only to table-style blocks. By default, valid
values are ‘details’ or ‘list’. For more information,
see Set Default Views in the Main Menu on page 88.
Customizng the Undoubtedly, you will want to modify the main page’s Welcome
Welcome Message message (page 81). Use air cat /Metadata/Menus/welcome.html to
copy the file from this location in the EME to your file system. (Note If
the file is not in the default location, use air web-interface show
(page 194) to see the current setting of the main_menu_blocks

configuration variable for a particular group.) Edit and save the HTML
file. Then use air reposit mime to copy the file back to the datastore. If
you copy it to a location other than the default, be sure to specify that
location in the setting of the main_menu_blocks configuration variable.
For a full description of air cat and air reposit mime, see Guide to
Managing Technical Metadata.
Creating Navigation The configuration variable navbar_links specifies category names to

Bar Hyperlinks appear as hyperlinks across the navigation bar, as shown in the
following figure.
Category and main page hyperlinks
Users can click these to navigate to the values of various categories. The
practical limit is five or six hyperlinks. Make sure that you keep the
MAIN hyperlink so that users can easily return to the main page.
To specify hyperlinks for the world group of the sample EME you
would specify:
air web-interface set world navbar_links \
“[('MAIN', '/Metadata/Menus/Main', 1),
('DATABASES', '/abinitio/categories/Database', 1),
('STEWARD GROUPS', '/abinitio/categories/Steward Group', 1),
and so on ...
]”
Each navigation bar hyperlink definition has the following fields:
Field Description
Hyperlink name String. Text marker to appear in the navigation bar, for
example, DATABASES.
EME datastore String. Path to the hyperlink target; for example,

path /abinitio/categories/Database is the path to the
Database category.
Renderer type Renderers translate the specified information into an

HTML Web page. Specify 1 for business metadata
renderer or 0 for technical metadata renderer. We
recommend that you specify 1.

Setting Up Searching To customize searching in the Web user interface, you need to:
• Decide which categories you want users to be able to search
• Decide which view should display the search results
You may also:
• Change the initial number of search results displayed to the user
• Enable the quick search index or use the exhaustive linear search
method
Make Categories The configuration variable searchable_categories specifies the names of

Searchable the categories that the Web user interface can search. For example, to
make the Database, Steward Group, TableView, Column, and Business
Attributes categories searchable, specify the names of existing
categories as strings. Enclose the entire value in brackets.
air web-interface set world searchable_categories \
“[‘Database’, ‘Steward Group’, ‘TableView’,
‘Column’, ‘Business Attribute’]”
These category names appear in the navigation bar’s drop-down list, as
shown in the following figure.
Note that the views defined on the above specified categories must
contain some view-elements that are searchable; that is, you must have
defined the view-elements with the +index option. See Making Views
Searchable on page 71.
Set Default View for The configuration variable metaview_as_search_results specifies the
Search Results name of the view in which to render search results. By default, the list
view is used to render search results. You may define your own view
with a different name. Set the value of metaview_as_search_results only
if the name of your view differs from the default.
metaview_as_search_result ‘my-list’
For an example of the list view rendering search results, see the figure
in Anatomy of the Web User Interface on page 81.

Set Initial Number of The configuration variable initial_results_limit specifies the initial
Search Results Shown number of search results to display. The default value is 60. Users can
click a hyperlink to display all search results found. Set this variable
only if you want to do not want the default value. For example:
initial_results_limit 40
Enable/Disable the The configuration variable use_search_index specifies whether the Web
Search Index user interface should do searches using a search index or do a slower
linear search. The default value is 1, which enables the search index. To
turn off the search index, set use_search_index to 0.
air web-interface set world use_search_index 0
Setting Up Views All the annotation values displayed in the Web user interface are shown
in a view. You can set up a number of attributes related to views.
Specifically, you can decide:
• The names of the default views to display annotation values in the
Web user interface
• Whether or not -view view-elements are displayed expanded or
closed
• The name of the default view for editing annotation values
• The width of the edit controls in an edit-view
• The name of the default view to display search results (see the
previous topic, Set Default View for Search Results)
Set Default Views in the Each category-type block in the main menu presents its annotation
Main Menu values in a view. The categories on the default main page and the
sample main page use the default views called details and list.
An example of a list view is the presentation of values for the Steward
Groups.
An example of the details view is shown in the second figure below.

When a user clicks a hyperlink representing a member of another
category, for example, the “transactions” hyperlink shown in the first
figure, the details view displays the annotation values related to the
object you’ve browsed to (second figure).

Click the “transactions”

hyperlink ...
... to see the metadata

displayed in the
details-style view
The Web user interface uses two settings to determine which view to
display an object in: category_list_view and details_view. By default,
these variables are set to ‘list’ and ‘details’, respectively. You must
define views with these names for every category whose values you
want to display. (For information about defining your own views, see
Chapter 5 > Defining What Metadata Users Can See.)
If you intend to use the default list and details views, you do not need to
set the category_list_view and details_view configuration variables. If
you define your own views with different names, specify the name of
your default views. For example:
category_list_view ‘my-list’
and
air web-interface set world details_view \
‘my-details’
Show All Views The configuration variable show_all_views_expanded specifies whether

Expanded or Collapsed or not -view view-elements are expanded all the time. (A -view
view-element is a view included within another view. They are
described in Including Views Within Views on page 66.) The default
value is 0, which lets users toggle between the collapsed and expanded
view-elements. A value of 1 keeps all view view-elements expanded.
show_all_views_expanded 1
Setting this variable to 1 overrides the can-toggle option of air
category add-view-element. (See Display Options on page 67.)

Set View for Editing The configuration variable edit_view_name specifies the name of a
Annotation Values special view that allows users to edit annotation values. You must
define this special view for each category that has annotation values that
you want users to be able to edit. This view must have the same name
across categories. Set the value of edit_view_name only if the name of
your editing view is different from the default, edit-view.
edit_view_name‘edit-view’
For more information about creating this special view, see Defining a
View for Editing Values of a Category Member on page 73.
Set Width of Edit The configuration variable use_wide_edit_controls specifies whether or

Controls in an Edit View not the edit controls of an edit view should be 25-30% wider than usual.
Value is 0 or 1. The default is 0. To enable the wider edit controls, set
use_wide_edit_controls as follows:
use_wide_edit_controls 1
For more information about edit-views, see Defining a View for Editing
Values of a Category Member on page 73.
Allowing Navigation to The configuration variable technical_link specifies whether or not

the Technical Metadata hyperlinks to the technical metadata Web user interface appear in the
Interface business metadata Web user interface. This hyperlink allows users to
easily navigate to the other interface. The hyperlink “technical view”
appears next to the category and object names in the business metadata
Web user interface. Set this value only if you want to change the value
from 1 (hyperlink appears) to 0 (no hyperlink).
air web-interface set world technical_link 0
Here is an example of the “technical view” hyperlink as it appears in the
Web user interface.
technical view hyperlink

Enabling Versioning The configuration variable enable_version specifies whether or not

users should be able to see multiple versions of the same object. Its
values are 0 and 1.The default is 0, or not enabled. If you enable
versioning, by setting the value to 1, a “Show Versions” hyperlink
appears next to the object. When users click the hyperlink, they see all
the versions of a given object, including the name, date, and the name of
the person who modified the object. For example, the following figure
shows four versions of the Abbot Stewards object.
To enable versioning, set enable_versioning as follows:

air web-interface set world enable_versioning 1

Using the Default User Interface

to Build Your Own
The EME includes a default user interface, shown in the following
figure. The main menu consists of a welcome message and views of two
categories in the base schema, project and database. We recommend
that you use the default user interface to build your own, rather than
starting from scratch.
First Set Up Interface First configure the interface for the world group, since this is the most
for World Group generic group in your company. The main page for world should display
metadata that is appropriate for all users. See Setting Configuration
Variables for the Web Interface on page 83 for details about how to set
individual configuration variables. Any configuration variables that you
do not explicitly set will take the value of the default interface. So, for
example, if you do not set client_footer_center_html, then the centered
footer text remains Sample Business Metadata.
If you would like users to see customized main pages, create groups for
the users in your company, and if you haven’t already done so. See
Setting Up User Groups on page 126.
Then build the interface for groups other than world. You need only set
the variables whose values are different from those you set for world.
Set the Group Order Then you need to run air web-interface set-order to set the order of
groups that the Web interface searches for settings and values. Settings
defined on groups earlier in the list override settings on groups defined
later in the list. The world group should be last in the list.

Using the Default User Interface to Build Your Own
For example, if you define a custom main menu block for the Dev group
with a special welcome message, then this setting overrides the main
menu block setting for world. Then, when a member of the Dev group
(and the Dev group only) logs in, he or she sees a main page that has a
custom menu block; all other settings derive from the world group.
Similarly, the users who are in the Exec group, and the Exec group only,
see their custom welcome message. Setting the group order for these
groups is as follows:
air web-interface set-order Dev Exec world
Assuming each user is in only one group, reversing Dev and Exec in the
list would have no effect on the rendered Web page for the users of each
group.
air web-interface set-order Exec Dev world
Note You must explicitly specify the world group, even though it is
built-in. Place world at the end of the list of groups.
If you need to reset the group order, run the command again, specifying
all groups. To see the order of your groups, run air web-interface
show-order.
When a User Is in More When a particular user is a member of two or more groups, the first
Than One Group value encountered for a particular variable is the value that is used.
Therefore, the group order you set is key to creating the correct Web
user interface for this user.
Example Assume that (1) there are three user-specified groups —

Dog, Cat, and Mammal — as well as the world group, (2) user Fido is in
the Dog and Mammal groups, (3) the Dog group has a custom message;
(4) the Mammal group has a custom message and custom centered text
in the footer, and (5) the group order is is as follows:
air web-interface set-order Dog Cat Mammal world
In this case, user Fido would see the the Dog custom message and the
Mammal centered footer. All other settings derive from the world
group. No settings derive from Cat.
Now, change the group order to Mammal, Dog, Cat, and world. In this
case, Fido would see the custom message and footer from Mammal, no
settings from Dog or Cat. The remaining settings would derive from
world.

Creating a Search Index

Searching in the Web The Web user interface supports searching within categories. Users
User Interface select a category from a drop-down list in the navigation bar and enter
text to search for within the category.
Users select a category to search Users enter text to search for
The EME software then scans a search index of annotation values and if
it finds a match between the specified text and an entry in the search
index, it displays the entry or entries. (The number of entries that is
initially displayed is controlled by the initial_results_limit configuration
variable described on page 88.)
Prerequisites for The search index feature is optional. To make searching available, you
Creating a Search must complete the following tasks:
Index
• Make sure your views contain some searchable view-elements.
Searchable view-elements are those created with the +index
argument. Only these view-elements can be searched. See Making
Views Searchable on page 71.
• Designate specific categories as searchable. The views defined on
these categories must have some searchable view-elements. See
Make Categories Searchable on page 87.
• Designate a view to display the search results. Alternatively, you
may accept the default search view named list. See Set Default
View for Search Results on page 87.
How to Build a Search 1. Create an EME for the search index. Give the “search” EME the
Index same name as your metadata EME but append _si to the name. For
example:
air -root “$AB_AIR_ROOT”_si repository create
2. Build the search index by running this python script.
python $AB_HOME/lib/bmr/bin/build-index.py

Creating a Search Index
Rebuilding a Search You must rebuild the search index whenever you make changes to your
Index views — for example, by adding or deleting searchable view-elements,
adding views, or modifying the list of searchable categories. Before
following the steps above, be sure to delete the old version of the search
EME:
air -root “$AB_AIR_ROOT”_si repository destroy
-force
Then re-create the search EME datastore and re-run build-index.py.

Allowing Users to Add or

Remove Values from a Category
Add/Remove Value... The “add/remove value...” hyperlink allows end users to be able to
Hyperlink associate annotation values (objects) with or or remove annotation
values from a given category. In the following figure, the “add/remove
TableView” hyperlink appears next to the label for the view of the
TableView category. That view, which shows two values — the
a-customers and a-transactions tableviews, is embedded in a view of
Steward Group. All the values on this Web page “belong” to the Abbot
Stewards object.
Add/remove value ... hyperlink
Clicking the “add/remove TableView” hyperlink opens a page like the

following, from which users can disassociate one or both of the
TableViews from Abbot Stewards.

Allowing Users to Add or Remove Values from a Category
Enabling the The “add/remove value ...”hyperlink appears automatically whenever

Hyperlink the following three conditions exist.
Condition 1 The view’s element descriptor must describe objects that depend
directly on the current object for a value. The format for expressing this
relationship is:
“/<category/.rule/|”
NOTE: Element descriptors are part of the syntax of air category

add-view-element. See element-descriptor on page 58.
For an example of the descriptor format above, see Annotation
Value On Another Category: Example 1 on page 61.
In the example above, category is TableView, and rule is

Steward_Group. A rule in such a descriptor must be a reference rule. In
this example, the target category of Steward_Group is Steward Group.
To see the actual descriptor in the sample EME, invoke air category
dump “Steward Group” and look at the last line of the output.
TableViews this Steward Group is responsible for:(view)
/<TableView/.Steward_Group/| list
Condition 2 The annotation rule specified in the descriptor must have been defined
with the +can-edit option to air arule create. To check this, run air
arule dump on rule to check that “can edit” is set to 1. Running the
command on Steward_Group yields the following output:
/abinitio/annotation rules/Steward_Group
reference rule ------------------
display name: Steward_Group
default value:
can edit: 1
multi-value: 1
revert-on-edit: 0
target category: Steward Group
Condition 3 If access control is enabled (that is, +access-control is set for air
repository options), then the user must have edit permission on the rule
rule in the category category. To check this, run air category
show-permissions on category. The command output must indicate that
the user has edit permission on rule.
If access control is disabled (that is, -access-control is set for air
repository options), ignore this condition.

Allowing Users to Create Values

and Add Them to a Category
Create Object The “Create Object” hyperlink allows end users to be able to create an
Hyperlink object and make it a member of a given category. The hyperlink appears
on the right side of the navigation bar, as shown in the following figure.
Create Object hyperlink
Clicking Create Object in the sample EME opens a page from which
you can choose a category.
Clicking on a category, for example, Steward Group opens an edit view

for the chosen category.

Allowing Users to Create Values and Add Them to a Category
Enabling Create The “Create Object” hyperlink appears automatically when the
Object hyperlink following conditions obtain:
• You have an edit view for the category. The edit view defines the
annotation rules that you want users to be able to edit. For
instructions on creating an edit view, see Defining a View for
Editing Values of a Category Member on page 73.
Make sure that at least one annotation rule included in the edit
view is editable; that is, the rule is defined with the +can-edit
option to air arule create.
• The user must have write permission on both of these:
• The annotation rule defined with the +can-edit option
• The object he or she is trying to edit
• The user must be able to edit the name annotation rule.
• The category must have one and only one member location. That
is, only one directory path was specified to air category
add-member-location for the category.
• The member location must have edit permission.

6>
Unloading Metadata from a
Datastore

• Unloading Metadata from Individual Categories (using air
category unload) (page 102)
• Creating Your Own Unload Components to Use in Your Graph
(page 107)
• Unloading Metadata into a Relational Database Using the Sample
Graph (page 109)

Chapter 6> Unloading Metadata from a Datastore
Unloading Metadata from

Individual Categories
You can perform unloading operations using the air category unload
command. As suggested by its name, this command is category-centric;
that is, it dumps annotation values for all objects in a given category.
The results are placed on stdout (standard output). You can redirect the
output to a file for use as input to a graph. This is described in Creating
Your Own Unload Components on page 107.
Syntax of air category The syntax of air category unload is:

unload
air category unload category [-dml |-component |-list] ⇒
[-no_inherit] [path] [-arule rule ...]
-dml | -component | Optional.

-list
• -dml displays the record format being
unloaded.
• -component creates an unload
component. (SeeCreating Your Own
Unload Components on page 107.)
• -list displays a list of rules and their
display names.
-no_inherit Optional. Ignores the annotation rules of the

category’s parent.
path Optional. Datastore path of directory.

Unloads annotation rules of objects that
reside at or below the specified location. If
omitted, default is /.
-arule rule ... Optional. One or more annotation rules to

unload. The category’s oid (object ID) rule
is always unloaded. If omitted, all of the
category’s rules are unloaded.
Without any optional arguments, air category unload generates one

data record for each member of the specified category. You can identify
the member by its oid annotation value. Regardless of which options
you specify, output always includes the oid annotation.

Unloading Metadata from Individual Categories
Field values are unloaded as strings. For those annotation rules whose
values are not easily mapped to strings, the unloaded string is the EME
datastore path to the annotation value. This is also true for the values of
reference-type annotation rules.
Displaying Record Use the -dml option to show the record format of the command’s
Formats output. The output format varies with the category and command
options specified.
Example To display the record format of the annotation rules of the Business
Attribute category, type:
air category unload “Business Attribute” -dml
The record format is shown in the following figure, with additional
explanations:
data type/length, rule name, display name of rule
record
ascii string(big endian integer(4)) oid; /* oid*/
one rule per field ascii string(big endian integer(4)) abbreviation; /* Abbreviation*/
ascii string(big endian integer(4)) approval_status; /* Approval
Status*/
ascii string(big endian integer(4)) created_by; /* Created By*/
ascii string(big endian integer(4)) creation_date; /* Creation Date*/
ascii string(big endian integer(4)) modification_date; /* Modification
Date*/
value is a single string ascii string(big endian integer(4)) modified_by; /* Modified By*/
OR record
a sized vector big endian integer(4) count;
ascii string(big endian integer(4))[count] list;
end Valid_Values; /* Valid Values*/
ascii string(big endian integer(4)) comment; /* comment*/
ascii string(big endian integer(4)) description; /* description*/
ascii string(big endian integer(4)) name; /* name*/
ascii string(big endian integer(4)) value; /* value*/
ascii string(1) newline = A"\n";
end
In general, each annotation rule in the category is mapped to a field in
the record format. Field values are unloaded as strings, as shown in the
preceding figure. If the annotation rule is multivalued (that is, created
with the +multi-value option), then the field contains a sized vector of
strings rather than a single string. Integer values in sized vectors are
always explicitly big endian integer(4), regardless of the architecture
of the host operating system.

Specifying Individual By default, annotation values for all rules in a given category are
Rules to Unload unloaded. There are two ways to modify this behavior:
• The -no_inherit option causes annotation rules inherited from a
base category to be ignored; only those annotation rules that are
native to the specified category are unloaded.
• Use the -arule rule ... option to explicitly list the names of the
annotation rules to be unloaded. Rules not specified are ignored.
Controlling the You can control the display of date, time, and boolean annotation values
Display of Some by setting various configuration variables (page 279).
Values
Error Messages An error message appears if either of these is true:

• The specified rule is not part of the given category.
• The specified rule belongs to a parent category and the -no_inherit
option was used.
Regardless of these options, all unload operations include the oid
(object ID) annotation rules for each record as a means of identifying
the object being unloaded. OIDs are described in Guide to Managing
Technical Metadata.
Example 1 To display the record format of the annotation rules of the Business
Attribute category but not its parent category, type:
air category unload “Business Attribute -dml \
-no_inherit
Note the restricted output, compared to that on page 103:
record
ascii string(big endian integer(4)) abbreviation; /* Abbreviation*/
ascii string(big endian integer(4)) approval_status; /* Approval
Status*/
record
big endian integer(4) count;
ascii string(big endian integer(4))[count] list;
end Valid_Values; /* Valid Values*/
end

Unloading Metadata from Individual Categories
Example 2 To display the record format of the Abbreviation annotation rule in the
Business Attribute category:
air category unload "Business Attribute" -dml \
-arule Abbreviation
The output is as follows. Note that the output includes the oid
annotation rule, even though it was not explicitly specified.
record
ascii string(big endian integer(4)) abbreviation; /* Abbreviation*/
end
Sample Output from Consider the relationships shown in the following figure as the source of
Example 2 sample data. Steward is a reference-type rule that points to Personnel.
Application business_area
steward
mp/
graph1 Personnel phone
graph2 department
Personnel/
...
John Doe
Jim Anchower
Data Files steward Mitzi Katz
dat/ ...
dataset1
dataset2
...
Let’s assume that you want to unload metadata about each category. In
particular, you would like to see how foreign-key relationships between
categories, expressed by reference-type annotation rules, are presented.
air category unload Application \
-arule name steward business_area
air category unload “Data Files” \
-arule name steward
air category unload Personnel \
-arule name phone department

The sample output, below, is tabulated for the sake of presentation. Note
that the value of steward for Application and Dataset is the steward’s
OID. For example, graph1 steward is @13.1.0, the OID of Mitzi Katz.
Application
oid business_area name steward
@1.1.0 finance graph @13.1. Personnel
@2.1.0 operations graph @11.1. oid department name phone
@11.1.0 MIS John Doe 617 555-1234
Dataset @12.1.0 Jim Anchower 617 555-1234
MIS
oid name steward @13.1.0 MIS Mitzi Katz 617 555-1234
@30.1.0 dataset1 @11.1.0
@31.1.0 dataset2 @12.1.0
Displaying a List of You can use the –list option of air category unload to display a list of
Rules and Display formal names and display names of each annotation rule in the specified
Names category. While similar to the -dml option, the -list option is easier to
parse and may be useful for scripting or documentation purposes.
Example 1. To display a list of annotation rules and their display names
for the Dataset category, type:
air category unload dataset –list
The output is:
oid : oid
created_by : Created By
creation_date : Creation Date
databaseOID : Database OID
modification_date : Modification Date
modified_by : Modified By
category : category
comment : comment
description : description
name : name
path: Location

Creating Your Own Unload Components
Creating Your Own Unload

Components
The air category unload command provides a -component option,
which builds components that faciliate the integration of unloading into
graphs. Specifying this option causes the output of air category unload
to be a component with the appropriate DML already embedded within
it. The component source is output through standard output; thus, you
should redirect it to an appropriate .mpc file for future use in your
graphs. To install a custom component once you’ve built it, see the
chapter on custom components in the Working with Components.
Note. The Unload Category component (page 219) supersedes the
-component functionality.
Parameters Parameters for the generated component are:
category (Required, String)

Name of the category to unload.
dml (Optional, boolean)

Indicates whether or not to unload the DML.
no_inherit (Required, boolean)

Indicates whether or not to unload the inherited values.
arule (Required, Literal)

List of annotation rules to unload.
path (Optional, Literal)

Datastore path of directory. Unloads annotation rules of objects residing
at or below this location.
The EME datastore used is the one set by AB_AIR_ROOT. If you are
using the GDE, this variable is set automatically, provided that the EME
is enabled in the EME Datastore Settings dialog. Otherwise, you can set
AB_AIR_ROOT in the start script (Edit>Script> Start).
Note The generated component is actually a light wrapper for the air
category unload command. The parameters are set as appropriate from
the original command, and, as such, are not designed to be edited later.
If you change these parameters, you may need to update the embedded
DML accordingly. Alternatively, you can create a new component.

Example To create a component for unloading the steward category, type:

air category unload steward -component
The output of the .mpc file is:
<mpcfile>
/*
This component file was automatically generated on Thu Oct 03
13:08:54 2002 with command line
air category unload steward -component
(edit with care)
*/
label: "Unload steward Category"
author: "Ab Initio Software"
version: "Built-in 2.9:"
comment: "Unloads all objects that are members of a given category"
image: "air"
parameter: positional category string "steward" "The category to
unload" required
parameter: keyword "dml" bool "False" "generate the unload record
format (doesn't unload)"
parameter: keyword "no_inherit" bool "False" "do not unload
annotation rules of the parent category."
parameter: keyword "path" literal "/" "unload annotation rules at or
below the path"
parameter: keyword "arule" literal "" "specifies a list of the annotation
rules to unload." optional
port: std out out right 0 1 "=record
ascii string(big endian integer(4)) categoryOID; /* CategoryOID*/
ascii string(big endian integer(4)) created_by; /* CreatedBy*/
ascii string(big endian integer(4)) creation_date; /* CreationDate*/
ascii string(big endian integer(4)) modification_date;
/*ModificationDate*/
ascii string(big endian integer(4)) modified_by; /* ModifiedBy*/
ascii string(big endian integer(4)) comment; /* comment*/
ascii string(big endian integer(4)) description; /* description*/
ascii string(big endian integer(4)) first_name; /* first_name*/
ascii string(big endian integer(4)) last_name; /* last_name*/
ascii string(big endian integer(4)) name; /* name*/
ascii string(big endian integer(4)) value; /* value*/
ascii string(1) newline = A\"\\n\";
end"
argument: literal "category"
argument: literal "unload"
argument: literal $*

Unloading Categories into a Relational Database
Unloading Categories into a

Relational Database
The EME provides a set of components for unloading the annotation
rules of each of the built-in categories (page 19). The components reside
in $AB_HOME/connectors/EME. Unload components follow the
naming convention Unload category.mpc. Note that category names are
case sensitive.
Sample Graph The sample graph Unload Builtin Categories.mp demonstrates the
Ab Initio standard approach to unloading annotation rules and values
from categories and loading them into a relational database.
Here’s what the graph does:
• A single table is created and populated for each category.
• A single column of the table is created for each annotation rule.
• The graph contains one phase for each category to be unloaded.
• Each phase of the graph contains the following component pattern:
unload_category reformat output table
• The Reformat component performs any necessary transformations.

In addition to any data conditioning you may like to perform, the
Reformat component may be necessary to:
• Rename fields that are valid annotation rule names but may be
reserved words in the target database. (For example,
“comment” is a reserved word in Oracle; “value” is reserved
in MS SQL Server.)
• Convert multivalued annotations to single values (for
example, by creating a comma-separated list of values).
Related Issues Recall that every annotation value is unloaded as a string, so you may
wish to do type conversion. The sample graph is set to create tables
automatically based on the output record format of the Reformat
component. If table creation is automatic, you may want to review the
size and type of the automatically generated columns.

Graph Parameters The graph has two required parameters:
DBC_FILE (Required, File name)

Name of valid database configuration file.
TABLE_OWNER (Required, String)

Namespace prefix of the target tables. For example, if DBC_FILE
points to a valid Oracle instance, TABLE_OWNER could be set to
"Scott." Running the graph would create tables Scott.job, Scott.phase,
Scott.graph, and so on.

7>
Accessing Metadata from
Windows Applications
The Ab Initio EME ODBC driver allows you to access metadata in an

EME datastore from a Windows-based OLAP application. The ODBC
driver essentially maps the categories of your object-oriented EME
schema into relational database tables. The benefit of the EME ODBC
driver is that you can visualize and analyze information in an OLAP tool
in ways different than views present it in the EME Web user interface.
See README First Install and set up the EME ODBC driver according to the instructions in
the README.htm file on the EME ODBC driver CD-ROM.
Example: Views of The following example is based on the schema of the sample EME
Steward Group and (described on page 7) and presents the Steward Group and TableView
TableView Categories categories as relational tables in a Microsoft Access database. The
example also compares the display in the browser with that in Microsoft
Access, where possible.
Take a look at the view of the Steward Group category, shown in the
following figure.
• The first view-element is comment, a single-valued annnotation
rule.
• The second view-element is members, a multivalued annotation
rule: a steward group can have more than one steward. Indeed,
Abbot has two stewards: Diana George and Roger Koss.
• The last view-element is a view defined on the TableView
category. TableViews This Steward Group Is Reponsible For
describes the name of the table or view, the associated database,
the owner of the table or view, and a description. As the view
shows, the Abbot Stewards group is responsible for a-customers
and a-transaction.

Chapter 7> Accessing Metadata from Windows Applications
View of Steward Group

category
Single-valued
annotation rule
Multivalued
annotation rule
View view-element
How Categories Are When translated through the EME ODBC driver, the Steward Group
Translated by the and TableView categories become four tables in Microsoft Access.
ODBC Driver
Take a look at the Steward Group relational database table, named after
the category whose view is shown above. The rows of the table are the
members of the Steward Group category, that is, the various steward
groups in the sample EME: Abbot, Becket, and Experts on marketing.
The columns of the table are the category’s single-valued annotation
rules. For example, the comment annotation rule, shown in the view
above, is included in the table.
Rows are category members Columns are single-valued annotation rule, for example, comment
Cross-reference Table Note that the table does not have a members column. The reason is that
members is an annotation rule that allows multiple values. Relational
database tables can have only one value in a cell so as not to violate the
uniqueness constraint on OID. To represent this many-to-many
relationship, therefore, the members column is placed in its own table,
called a cross-reference table. A cross-reference table has two columns,
both of which compose its primary key. The columns are (1) the column
that cannot be represented in the original table, in this example, the
members column, and (2) the primary key of the original table, that is,
its OID column, as in Steward_GroupOID, which uniquely identifies
the steward group.

How Categories Are Translated by the ODBC Driver
The following figure shows the Steward_Group_xref_Members. The

name of a cross-reference table is in the format:
primary-table-xref-column-name.
multiple annotation values

for each steward group
Taken together, the primary table and the cross-reference tables yield a
more complete picture of the steward groups in the sample EME. From
the Steward Group table you can see that steward group @326.1.0 is the
Abbot Stewards (see Display Name column). From the first two rows of
the cross-reference table, you can see that the Steward Group oid
326.1.0 occurs once for each member, Diana George and Roger Koss.
From the browser view (page 112), it is apparent that steward groups
have a relationship to the TableView category: Abbot Stewards are
responsible for both a-customers and a-transactions tables. The
following figure shows how the EME ODBC driver translates the
TableView category into a relational database table called TableView.
Note that in the table you cannot see any information about steward
groups. Because the relationship of tables to steward groups is
many-to-many, the ODBC driver once again creates a cross-reference
table called called TableView_xref_Steward_Group.
Abbot Stewards @326.1.0 is

Table @327.1.0 is managed by responsible for tables @327.1.0
steward groups @326.1.0 and and @328.1.0.
@325.1.0.

Several many-to-many relationships emerge from the cross-reference

table:
• A steward group can be responsible for more than one table
• A table can be managed by one or more steward groups
For example, Abbot Stewards (@326.1.0) manages tables @327.1.0 and
@328.1.0. As shown in the Display Name column of TableView, the
oid @327.10 identifies the a-customers table, while the oid @328.1.0
represents a-transactions. The cross-reference table shows that
a-customers is also managed by Becket Stewards (@325.1.0). Becket
also manages other tables: b-customers and b-transactions.
Summary of the ODBC The following table summarizes how the ODBC driver maps EME
Driver Mappings categories, members, and annotation rules.
ODBC Driver Maps a ... To ...
Category Relational database table. Its OID column is
the table’s primary key.
Category member Table row.
Single-valued annotation rule Table column.
Multi-valued annotation Row of a cross-reference table.
Reference rule OID of the target object; from a relational
database perspective, this is the foreign key
into the target object’s category.
Record rule OID of the target record.
Display Metadata The EME Web user interface is dynamic and intended as an interactive
Graphically in an tool; hyperlinks allow you to navigate and discovering the metadata in
OLAP Tool the EME. Often, however, you may simply want to generate reports
about certain predefined subsets of the metadata, for example, trending
of graph performance, exception reporting, or listings of business
atttributes without documentation. As an alternative to the EME Web
user interface, OLAP tools can display a report on a subset of the
metadata attractively and in a manner tailored to particular users.
For example, the following figure shows a view of the Customer table in
the EME Web user interface. It displays information about the table as a
whole as well as detailed information about each column — including
its name, data type, whether nulls are allowed, logical element, and a
long description. This view might be perfect for a technical user, for

Display Metadata Graphically in an OLAP Tool
example, your firm’s EME administrator or metadata architect, but it

might not be suitable for a top-level business user or a user who does not
have access to a Web browser.
Arranging and presenting selective metadata about the Customer table

in Crystal Reports yields a attractive but static picture of some of the
information shown above. The following figure presents in tabular
format only the name, data type, and description of each customer
column.

Manipulate Metadata The following figure of the EME Web user interface shows the job runs
in an OLAP Tool for the Example4 graph. It shows some information about the graph as
well as the name, status, elapsed time, and a description of each run.
A Crystal Reports table presents less metadata than the view in the Web
browser — just the job names and elapsed run times of Graph4.
However, it adds the average elapsed time in seconds of all job runs.

Manipulate Metadata in an OLAP Tool
Alternatively, the same information can be presented in a graphical

manner as a bar graph.

8>
Managing EME Security

• Managing the aiw Web Server (page 120)
• Authenticating Users (page 123)
• Setting Up User Groups (page 126)
• Granting Permissions (page 129)

Chapter 8> Managing EME Security
Managing the aiw Web Server

To make use of the security features presented in this chapter — for
example, authenticating EME users, and granting and enforcing user
permissions to see and edit metadata — you must run the aiw-server
Web server program rather than the default program, aiw. The
aiw-server program is supported only on Unix machines.
The aiw-server program manages the connections to an EME datastore,
so that the amount of system resources used by the server and its users is
roughly fixed. It also speeds up the time required for each query.
To run aiw-server, you should:
• Enable user authentication and access control
• Modify the aiw script to use aiw-server
• Start the server for a specific datastore
Enabling User At login time, the Web server checks the name and password in a user’s
Authentication account. By default, it will do so by looking in the EME, and then in the
operating system. If you want user authentication to take place only in
the EME, then you must turn it on by running:
air repository options +internal-namespace
Enabling Access To set permissions on objects and annotation rules, you must first
Control enable access control to the EME. Run air repository options to turn
on access control:
air repository options +access-control
Now users have the default permissions described in Default
Permissions When Access Control Is Enabled on page 130. If access
control is not enabled, there is no security in the EME.
Modifying the aiw After enabling user authentication and access control, you must modify
Script the aiw CGI (Common Gateway Interface) script to run aiw-server.
1. Open the aiw script, which resides in the cgi-bin directory under
the document root of the Web server.
2. Locate the last line of the script:
exec $AB_HOME/bin/Xthin-aiw
and change the name of the executed command from Xthin-aiw to
Xaiw-front.
3. Save the script and close the file.

Managing the aiw Web Server
Starting the aiw Web Only the owner of the EME datastore should start aiw-server. Use the
Server for a Specific aiw-server start command, specifying the -repo argument followed by
Datastore the path to the datastore.
For example, the following starts the dev-datastore datastore:
aiw-server start -repo /tmp/dev-datastore
You will see a message when the Web server is ready.
See also the chapter on managing the EME in Guide to Managing
Technical Metadata.
Checking Server The aiw-server program can concurrently serve any number of
Status datastores.
To see which datastores are running, execute the command aiw-server
status. For example, at the command line type:
aiw-server status
The output might be:
Status Repository Path
------ ---------------
Running /tmp/sr12145
Running /tmp/dev-datastore
Control Files The aiw-server program writes a control file for each running EME. A
typical file name is: /var/abinitio/aiw-server!custhost!178665!833.
The location of these control files is determined by the value of the
AB_AIW_SERVER_WORK_DIR configuration variable. The value must be
an existing, readable directory. If you do not set this variable, then the
value of the AB_WORK_DIR configuration variable is used.
AB_WORK_DIR’s default value is /var/abinitio.
Make sure you set these configuration variables consistently for both the
server and the aiw script running in the cgi-bin directory. You can
accomplish this by modifying the aiw script directly or by using
.abinitiorc files carefully. To verify the settings of these variables use
the m_env -describe command, as in:
m_env -describe AB_AIW_SERVER_WORK_DIR
Examples of Consistent The following is an example of consistent variable settings in the Korn
Settings shell scripts that start and stop the aiw server as well as in the aiw CGI
file. Note that the value of AB_AIW_SERVER_WORK_DIR is
/usr/local/abinitio/special_directory in all
contexts.

#============ my-start-server.ksh ============

export AB_AIW_SERVER_WORK_DIR = \
/usr/local/abinitio/special_directory
#The value of the AB_AIW_SCRIPT variable MUST match
#the name you give to the aiw CGI script.
aiw-server start -repo $AB_AIR_ROOT
#============ my-stop-server.ksh =============

export AB_AIW_SERVER_WORK_DIR =\
aiw-server stop repo $AB_AIR_ROOT
#=============== my-aiw.cgi ===================

#!/bin/ksh
Value of
#This script generated automatically on Wed Apr 17
AB_AIW_SERVER_WORK_DIR is set
#14:53:11 EDT 2002 by /usr/local/abinitio/install-aiw
in all contexts
export AB_HOME=/usr/local/abinitio/mpower
export PATH="$AB_HOME/bin:$PATH"
export LD_LIBRARY_PATH=$AB_HOME/lib
export LIBPATH=$AB_HOME/lib:/usr/lib
export SHLIB_PATH=$AB_HOME/lib
unset _CEE_ENVFILE
#Export a special version of AB_AIW_SERVER_WORK_DIR.

#The directory must exist and be readable. Also, this
#variable MUST match the setting specified in the
#shell environment where aiw-server is started.
#Note: It is NOT neccesary to export AB_AIW_SCRIPT.
export AB_AIW_SERVER_WORK_DIR = \
#Changed Xthin-aiw to Xaiw-front because we want

#to talk to aiw-server.
exec $AB_HOME/bin/Xaiw-front
Stopping the aiw Web To shut down aiw-server (and the control files), use the aiw-server
Server for a Specific stop command, specifying the -repo argument and the path to the EME
Datastore datastore. For example:
aiw-server stop -repo /tmp/dev-datastore

Authenticating Users
User Authentication Is The EME supports internal authentication of users, thereby giving you
Based on User control over which users can log in to the EME through the Web user
Accounts interface as well as what they can see, once logged in. You must enable
user authentication; see Enabling User Authentication on page 120.
User authentication is based on the notion of user accounts. User
accounts are created within a given EME datastore. It is not necessary to
have an operating system account.
When the user logs in, the Web server checks the user’s credentials
directly in the EME. If the user’s name and password match those in the
account, the user is authenticated and will be logged in.
Attributes of a User A user account specifies a set of attributes about a user in your
Account company. Each user of the EME must have an account. A user account
has a number of attributes: name, uid (user ID), password, an optional
disabled flag, and group.
• The name is a human-readable value describing the EME user.
Examples are ‘Mitzi’, ‘Mitzi Katz’, and ‘mkatz’. A name is a set of
alphanumeric characters. Spaces are allowed, but you must use
quotes on the command line around multi-word user names.
• The uid is an integer ID representing the user. The uid is used
internally for the sake of efficiency, but normally the user’s
account is administered through the name attribute.
• The password is stored internally in an encrypted form, currently
DES 56-bit one-way encryption. A valid password consists of
alphanumeric characters and should be no longer than 8 characters.
• A value of ‘*’ is assigned as the default password when you
don’t supply a password for a new user account. Note that
users cannot log in until they have a valid password.
• A value of ‘NONE’ means the this user is not required to
supply a password.
Web users will not be able to use their accounts until they or the
administrator have changed the password.
• The disabled flag can be set to TRUE when you want to forbid the
user access to the EME.
• The group specifies the groups to which this user belongs. For
more information, see Setting Up User Groups on page 126.

Creating User Create user accounts by running air system user create (page 188).
Accounts User passwords can be created on the command line, or later, by using
the air system user change-password command (page 188).
Changing a Password You might want to change a password for the following reasons:
• The user has forgotten his or her password. The EME does not
“remember” passwords; they are immediately encrypted.
• A user’s account was created without a password. This user cannot
log in to the EME.
• You want the user to enter his or her password at the command
line.
• You want a user who previously did not require a password (-none
option was specified) to have a password, or vice versa.
To change the password for an existing user account, you can use air
system user change-password (page 188). With this command, you
can change the current setting to another password, to -none (no
password required), or to no value, which means the user must enter his
current password at the command line.
Alternatively, you can allow users to change their own passwords in the
Web user interface. To do so, enable user authentication in the EME, as
described Enabling User Authentication on page 120. Then a Change
Password hyperlink will appear in the navigation bar of the Web user
interface.
Displaying Users Use air system user show (page 190) to display the account
information for a particular user or all users.
Migrating User Migrating user accounts from one EME to another is a two-step process.
Accounts to Another
• First you copy the user accounts of the source EME to a binary file
EME
using air system export users-and-groups (page 184).
• Then you import the binary file to the target EME using air system
import users-and-groups (page 187).
Migrate user accounts only when you want users of the target EME to
have access to the Web user interface through their user accounts and
not their Unix accounts.
Enabling/Disabling When you want to prevent a particular user from logging in to the EME,
User Accounts use air system user disable (page 189). For example, to prevent user
mkatz from logging in, run:
air system user disable ‘mkatz’

When you want to allow a user whose account has been disabled to once
again log in to the EME, use air system user enable (page 189). For
example:
air system user enable ‘mkatz’

Setting Up User Groups

What Is a Group? A group is a collection of users. The groups in a company usually
mirror the job roles and responsibilities of its EME users. Some
examples of groups are Data Stewards, Marketeers, Executives,
Engineers, and Data Analysts. You can assign a user to one or more
groups.
Purpose of Groups Groups make it easier for you to administer a user’s permissions to read
and write EME metadata. Read and write permissions refer to a user’s
ability to see (read) or edit (write) metadata in the Web user interface or
at the command line. Rather than assign permissions to each user in
your company, you assign each user to a group and then assign
permission to the entire group. (Permissions are explained in detail in
the next section.) For example, you might want all members of the
Managers group, but not the members of the Marketing group, to be
able to see (read) sensitive personnel metadata.
All EME users assigned to the same group have the same permissions to
access or modify metadata in the Web user interface. A user who
belongs to more than one group has the sum total of permissions for all
groups to which he or she belongs. For example, if user Mitzi is in
groups X and Y, then she has all the permissions assigned to group X
and all the permissions assigned to group Y.
Group Attributes A group has a name and a gid:

• The name is a human-readable value describing the group.
Examples are ‘Stewards’, ‘Data Stewards’, and ‘Managers’. A
group name is a set of alphanumeric characters. Spaces are
allowed, but you must use quotes on the command line around
multi-word group names.
• The gid (or group ID) is an integer ID representing the group. The
gid is used internally for the sake of efficiency; it is never
displayed in the Web user interface.
Creating Groups To create a group, use air system group create (page 185), specifying
the group name and optionally the gid. You may, if you wish, do a “test
drive” of the operation before actually creating the group by using the
-dry-run argument.
Example: To create the Data Stewards group, type:
air system group create ‘Data Stewards’

Setting Up User Groups
Assigning Users to There are two ways to assign users to groups. You can assign a user to
Groups an existing group when you create the user (air system user create).
Alternatively, you can create a new user and then add him or her to an
existing group by running air system group add-user (page 184).
Example 1. Create the group and then create the user and assign him or
her to a group:
air system group create managers
air system user create mkatz -group managers
Example 2. Create the group and the user, then add the user to the
group:
air system group create managers
air system user create mkatz
air system group add-user mkatz managers
Assigning Groups to Groups can also contain other groups. Structuring groups in this way
Other Groups makes it easier to grant and maintain widespread permissions. Let’s say,
for example, you already have defined a number of groups (Doc, Dev,
Exec, Mkting, and HR) and assigned them permissions specific to the
job responsibilities of the users in the group. However, you want to
grant certain permissions to all users in all groups. Of course, you can
always grant the permissions to each group individually, but it would be
much more efficient to create an umbrella group called Employees, add
Doc, Dev, Exec, Mkting, and HR to Employees, and then assign
permissions to Employees.
Use air system group add-group (page 184) to add a group to another
group. Assuming Employees already exists, you would invoke the
command once for each added group:
air system group add-group Doc Employees
air system group add-group Dev Employees
air system group add-group Exec Employees
... and so on
A user in Doc, Dev, and Employees has the permissions of all three
groups. If a user has permissions based on membership in multiple
groups, then the permissions combine in the least restrictive way. For
more information, see How Group Permissions Combine on page 131.

Removing Users or When a user’s job responsibilities change, you probably need to change
Groups from Groups his or her group membership. For example, if user ‘jdoe’ is in the
Analysts group, but then becomes a consultant, you probably want to
remove him from Analysts and add him to Consultants:
air system group remove-user jdoe Analysts
air system group add-user jdoe Consultants
Removing Groups Use air system group remove-group (page 185) to remove a group
from Groups that had been included within another group. This action does not delete
the group, it merely removes it from the containing group.
Displaying Group To see the user membership of a group or all groups, use the air system
Membership group show command (page 186). For example:
air system group show Consultants

Granting Permissions
You must grant permissions in order for users or groups to be able to
read and write metadata in the Web user interface or at the command
line.
• Read permission defines which users or groups can see metadata.
• Write permission defines which users or groups can edit, save,
load, or delete metadata.
Two Kinds of The permissions model gives you control over which metadata groups
Permissions or individual users can read or write:
• You can grant users or groups permission to read/write the values
of individual annotation rules in a category. These are called
rule-level permissions.
• You can grant users or groups permissions to read and write
individual members (objects) of a category. These are called
object-level, or member-level, permissions.
Consider the Personnel category drawn as a logical table with some
sample members and annotation rules. You can grant permission to an
EME user or group to read and/or write the values of annotation rules,
such as comment and department. These annotation rules are the
columns in the logical table shown below.
You can also grant permission to users or groups to read and/or write all
the values of the annotation rules associated with the member objects of
the Personnel category — John Doe, Jim Anchower, Mitzi Katz, and so
on. These member objects are the rows in the logical table.
columns represent annotation rules

Personnel category
oid name comment phone department salary

rows
represent
John Doe
member Jim Anchower
objects
Mitzi Katz object-level (member-level) permissions
...
rule-level permissions

Default Permissions When access control is enabled (as described in Enabling Access
When Access Control Control on page 120), users and groups have these default Unix-style
Is Enabled permissions:
• No read or write permission on annotation rules.
• Read permission on objects, but not write permission. Note this
exception: the object owner, the users in the same group as the
owner, and the administrator have both read and write permission.
(Unix-style permissions are fully described in the chapter on managing
the EME in Guide to Managing Technical Metadata.)
Now you can modify the default permissions.
Write Permission If you intend to grant write permission on an annotation rule, make sure
Prerequisite that the rule was created with the +can-edit argument to air arule
create (page 152). If you grant write permission on a rule that cannot be
edited, the user or group will not be able to edit the value of the rule.
To find out whether or not an annotation rule can be edited, use air
arule dump (page 157).
Read Permission If you want users or groups to be able to see the values of an annotation
Prerequisite rule in the Web user interface, make sure that the annotation rule is
defined as a view-element in a view. (Views are described in detail in
Chapter 4 >Defining What Metadata Users Can See.)
To find out whether or not an annotation rule is used in a view
definition, run air category dump (page 171).
Even if an annotation rule is not part of a view, a user or group can still
see the rule’s value, assuming read permission is granted, by running air
annotation dump (page 150) at the command line.
Work Style We recommend that you take a systematic approach to setting

Recommendation permissions:
1. For each group, set permissions on a category’s annotation rules.
2. Repeat the process until you have gone through all categories for
that group.
3. Repeat the entire process for the next group. For example, for the
Analysts group set permissions for the annotation rules on
Stewards, then Personnel, and so on.
4. Finally, for each group, set permissions on members of a category.

Setting Permissions Use air category set-permissions (page 177) to grant read/write access
on Annotation Rules to a given category’s annotation rules to a specific group or user. For
example, the following command sets permission on five annotation
rules of the Personnel category. As a result, each user in the Personnel
group now has read (+read) and write (+write) permission on the name,
comment, phone, department, and salary annotation rules of Personnel.
air category set-permissions "Personnel" "Managers" \
name +read +write \
comment +read +write \
phone +read +write \
department +read +write \
salary +read +write
Setting Permissions Use the air object set-permissions command (page 182) to grant
on Objects permissions on a member object. We expect that primarily you will set
read and write permission on a directory object. (A directory is
considered an object in the EME.) However, by using the -R option to
the command, you can set the permissions on all the objects contained
within the directory.
For example, let’s say you want to set permissions on the objects in the
Personnel directory so that the users in the Managers group have read
and write permission on personnel information about the general staff
but only read permission on each other’s information (the Execs). To set
these permissions on the following directory structure:
Personnel/
Execs Staff
6 5 4 3 2 1
+read -write +read +write
you would issue air object set-permissions like so:

air object set-permissions -R Managers \
/Personnel/Execs +read -write \
/Personnel/Staff +read +write
How Group When a user in one group also belongs to another group that has
Permissions Combine different permissions, then the user has the least restrictive permissions.
For example, let’s say that Bob, Ted, Alice, and Carol belong to the
Managers group, and Bob also belongs to the Execs group. Managers

have read permission (+read) but not write permission (-write), and
Execs have both read and write (+read +write) permissions.
Execs group +read +write

Arthur
Diane
Bob Personnel category
Arlene oid name comment phone department salary
Managers group
Bob
Ted
Alice
Carol +read -write
The result is that Bob has read and write permissions on the Personnel
category. This is called a logical OR combination of possibilities.
Consider the combinations of write permissions shown in the table:
Then user Bob in both

If Managers has And Execs has
groups has
+write +write +write
+write -write +write
-write +write +write
-write -write -write
Note that +read -write permissions set on Managers and +read +write
permissions set directly on user Bob (rather than on a group to which
Bob belongs) yields the same result shown above.
How Rule and Object When a user or a group has one set of permissions on the member
Permissions Combine objects of a category (shown as rows in the logical table) and has a
different set of permissions on an annotation rule in the same category,
then the user has the most restrictive permissions.
The following example illustrates how these permissions work. Let’s
say we want to accomplish these three goals:
1. Grant the Managers group — Bob, Carol, Alice, and Ted — read
and write permission on all the personnel information about the
general staff (objects 1, 2, and 3 in /Personnel/Staff) but only read
permission on all the personnel information about the company’s

top executives (objects 4, 5, and 6 in /Personnel/Execs). See the

figure on the next page.
2. Permit only user Bob, the company’s top manager, permission to
see and change salary information.
3. Prevent other managers from seeing or changing salary
information.
First grant read and write permission to the Managers group on all
personnel information in Staff but only read information to Execs, as
described in step 1.
air object set-permissions -R Managers \
/Personnel/Execs +read -write \
Next, give user Bob access to salary information by granting read and
write permission to the salary annotation rule.
air category set-permissions \
Personnel Bob salary +read +write
The following figure illustrates these permissions.
directory location of members of the Personnel category

Personnel/
Personnel category
oid name comment phone department salary
Execs Staff rows
1
2
6 5 4 3 2 1
3
+read -write +read +write 4
5
6
Set Permissions for the Managers Group to Personnel
air object set-permissions -R Managers
Give Bob, the CEO, permission to read and write salary ...
/Personnel/Execs +read -write
/Personnel/Staff +read +write air category set-permissions
Managers group
Bob
Ted
Alice
Carol

What is the result? Does Bob now have permission to read and write
salary information on all member objects of Personnel? The answer is
no: Bob can write the Staff rows (1, 2, and 3), but not the Execs rows (4,
5, and 6).
This is the case because row and column permissions combine
according to the logical AND combination of possibilities. This yields
the most restrictive permissions.
Consider the combinations of write permissions shown in the table:
If Managers has this And Bob has this Then user Bob
permission to OBJECT permission to RULE has
+write +write +write
+write -write -write
-write +write -write
-write -write -write
As shown in the table, Bob can acquire write permission (+write) when
both the group to which he belongs has write permission on the member
objects of the category and he (user Bob) has permission on the salary
annotation rule: +write AND +write = +write. This is shown in the first
row of the table.
Applying this to the salary annotation rule, we can see that user Bob has
write permission to the Staff objects in rows 1, 2, and 3 (+write from
Managers and +write from user Bob), but not to the Execs objects in
rows 4, 5, and 6 (-write from Managers and +write from user Bob). The
same holds true for read permission.

user Bob’s write permission on salary

Personnel/
Personnel category
salary
Execs Staff rows
1 +write +write
2 +write +write
6 5 4 3 2 1 +write +write
3
+read -write +read +write 4 -write +write
5 -write +write
6 -write +write
Set Mixed Permissions for the Managers Group to Personnel

/Personnel/Execs +read -write Give Bob, the CEO, permission to read and write salary ...
air category set-permissions
So how do we achieve the goal of granting user Bob read and write
permission to the objects (rows 4-6) related to Execs. Again, we need to
grant explicit permission to user Bob:
air object set-permissions Bob \
/Personnel/Execs +read +write
This gives user Bob permission to write these objects, because,
according to the table of logical OR combination of possibilities
(page 132), -write permission for the Managers group (to which Bob
belongs) combined with explicit +write permission for user Bob yields
write permission for user Bob.

The following figures show that Bob now has full permissions to salary.
Set Mixed Permissions for the Managers Group to Personnel objects user Bob’s write permission on salary
/Personnel/Execs +read -write
Personnel category
salary
rows
1 +write +write
2 +write +write
3 +write +write
4 -write +write
5 -write +write
6 -write +write
Give Bob Write Permissions to Execs objects (4,5, and 6)

air object set-permissions -R Bob Give Bob, the CEO, permission to read and write salary ...
/Personnel/Execs +write air category set-permissions
The third and last goal is to give Bob exclusive read and write
permission on salary information. Currently, the other users in
Managers have read and write permissions on the objects in Staff with
respect to salary as well as read permission on the objects in Execs with
respect to salary.
To change this situation, we must restrict the permissions of Managers
so that the group cannot read and write the values of the salary
annotation rule:
air category set-permissions \
Personnel Managers salary -read -write
Because object and rule permissions combine through a logical AND
(page 134), other users in Managers now cannot read or write salary.
See the following figure.

Set Mixed Permissions for the Managers Group to Personnel objects

Managers write permission on salary
/Personnel/Execs +read -write Personnel category
salary
rows
1 +write -write
2 +write -write
3 +write -write
4 -write -write
5 -write -write
6 -write -write
Restrict permissions to all other managers on the salary rule...

air category set-permissions
Personnel Managers salary -read -write

A>
air Utility Commands
The air utility provides commands for creating and managing

categories, creating and assigning annotation rules, and assigning
annotations to rules. See Guide to Managing Technical Metadata for
many additional commands.

• Command-line Syntax of air Commands (page 140)
• Specifying Object Names as Arguments (page 142)
• Summary of air Utility Commands (page 144)
• Each air utility command by group:
• air annotation Group (page 148)
• air arule Group (page 152)
• air category Group (page 162)
• air object Group (page 181)
• air system Group (page 184)
• air web-interface Group (page 191)

Appendix A> air Utility Commands
Command-line Syntax of air

Commands
Syntax All air commands have the following command-line syntax:
air [-root root] [-version version | tag-name] [-remote]
command arguments
All air commands can include the optional arguments -root and
-version.
-root Specifies the Optionally, -root root specifies the root of the EME datastore. In most
EME Datastore cases, use an absolute path name, for example, /disk3/data/datastore1.
Typically, you specify the EME datastore name by setting the
configuration variable AB_AIR_ROOT. For example, to set the root of the
datastore1 datastore and then execute the air ls command, you could
type at the prompt:
export AB_AIR_ROOT=/disk3/data/datastore1
air ls -l
Alternatively, you can specify the EME datastore name on the
command line. For example:
air -root /disk3/data/datastore1 ls -l
The EME root can be the URL of a remote file, for example,
//host/projects/warehouse/datastore1. A remote host can be specified
if the EME software and the Co>Operating System software are
installed on that host and your environment is configured to allow
access to that host by way of the Co>Operating System.
-version Specifies the Version name or number Optionally, -version version specifies
Version or Tag either the version name or number of the datastore to be accessed. For
example, to display project information for version 125, type:
air -version 125 project show /Projects/warehouse
Assuming that version 125 has been tagged QA-ready, you could
alternatively specify the preceding command as:
air -version QA-ready project show \
/Projects/warehouse
If you specify a version number that does not exist, the EME rolls back
the version number to the most recent existing version and then executes
the command. For example, assume a given object has three versions —
5, 12, and 20. You run an air command on that object and specify the

Command-line Syntax of air Commands
version number argument as -version 15. Since version 15 does not

exist for this object, the EME will use version 12, the most recent
existing version.
Note that the version may also be specified by setting the
AB_AIR_VERSION configuration variable before running the air
command. For example, to show version 125 of the warehouse project,
type at the command line:
export AB_AIR_VERSION=125
air project show /Projects/warehouse
Tag name Optionally, -version tag-name specifies a set of EME
objects to be accessed. A tag is a label, or symbolic name, that you can
associate with specific objects.
tag-name specifies the tag through which objects in the EME can be
accessed. The following command saves all the objects in the lesson
project that have the tag my_tag to the my_objects file:
air -version my_tag object save my_objects \
/Projects/lesson
For more information about versioning and tagging (configuration
management), see Guide to Managing Technical Metadata.
-remote Specifies a Optionally, -remote specifies that the air utility should start the EME
Remote Connection server remotely even if a direct connection is possible. Alternatively,
you can achieve this by setting the AB_AIR_USE_LOCAL_STORAGE
configuration variable to False.
Commands The air utility commands related to categories and annotations fall into
a number of groups. For a detailed description of each group and related
commands, see:
• air annotation Group on page 148
• air arule Group on page 152
• air category Group on page 162
• air object Group on page 181
• air system Group on page 184
• air web-interface Group on page 191
Arguments Many air commands require you to supply the name of an object as an
argument. You can refer to objects by a variety of names, as described
in Specifying Object Names as Arguments on page 142.

Specifying Object Names as

Arguments
The EME software includes “directory” objects that provide names for
other objects, including other directories. You access these objects using
Unix-like names. For example, /a/b refers to object b in directory a. As is
the case with Unix file systems, an object may have multiple names, as
described in this section.
Path Names Begin A path name must begin with one of these special characters:
with /, /~, or @
• / (slash)
• /~ (slash and tilde)
• @ (at sign)
After that, you separate elements of the path with / .
Path Names You almost always specify a name of a datastore object as a path
Beginning with / beginning with a slash ( / ).
Example The name of the graph, graph1, in the myproject project

is:
/Projects/myproject/mp/graph1.mp
Note that quotes are required for embedded spaces within a path name.
Wildcards are not supported in path names.
Specify a Prefix to In very rare circumstances name conflicts can arise. For example, it is
Disambiguate Names possible, though unlikely, that a graph could contain a layout and a
component having the same name. To avoid this problem, specify a
disambiguating prefix between elements of the path.
The following table contains the list of disambiguating prefixes.
Prefix Description
ann!rule-name Annotation value
p!property-name Property name
d!name Element of a directory
f!name Flow in a graph
l!name Layout in a graph

Specifying Object Names as Arguments
Prefix Description
m!name Metadata (record format) in a graph
v!name Component (also called vertex) in a graph
legend!number Legend in a graph
p!name Port of a component
e!name Element of a package
f!name Field of a record
Example 1: You can express /Projects/datastore/mp/mygraph.mp as:

/d!Projects/d!datastore/d!mp/d!graph.mp
Example 2: To access the value of the home_email record-type
annotation rule:
/foo/bar/Mitzi/ann!email_info/ann!home_email
Example 3: To display the details of the PROJECT_DIR parameter of
the warehouse project:
air details /Projects/warehouse/!PROJECT_DIR

Summary of air Utility Commands

The following table lists the six main groups of air utility commands.
The table also presents an alphabetical list and summary of the
commands in each group.
Group and Command Description See
air annotation Group Assigns and removes annotation values, comments, and page 148
descriptions
air annotation add Adds an annotation value to an object that is a member of a page 148
category
air annotation document Sets an object’s description and comment properties page 149
air annotation dump Displays all annotation rules and values (if any) for a page 150
member object of a category
air annotation rm Removes from an object one or more annotation values, or all page 151
annotation values of the specified rule
air arule Group Manages the creation and modification of annotation rules page 152
air arule add-choice Creates or appends a list of choices for a choice-type page 152
annotation rule
air arule create Creates an annotation rule with the specified attributes page 152
air arule dump Displays information about an annotation rule page 157
air arule modify Modifies the characteristics of an annotation rule page 158
air arule rm Deletes the annotation rule from an EME datastore page 160
air arule rm-choice Removes one or more choices, or all choices, from a rule’s page 160
choice list
air category Group Manages the creation, modification, and deletion of page 162
categories and views; also grants permissions to users and
groups to access a category’s annotation rules.
air category add-member-location Adds objects residing in a specified location to the category's page 162
membership

air category add-rule Associates annotation rules with a category, adding each rule page 164
to the category’s list of rules
air category add-view Creates a view and associates it with a category page 166
air category add-view-element Describes view-elements and associates them with an page 167
existing view on a given category
air category clear-permissions Removes the current permission settings on a category’s page 170
annotation rule
air category create Creates a category with the specified name and based on the page 170
parent category
air category dump Displays information about a category, including its location, page 171
its parent, the location of its members, its annotation rules,
and its views
air category inheritvia-rule When an annotation rule that can inherit values has no value, page 172
the value will be inherited from an object that has the
specified annotation rule
air category list-members Displays the members of a given category page 172
air category modify-rule Modifies certain characteristics of a category’s annotation page 173
rule
air category rm Deletes the specified category from the datastore page 173
air category rm-member-location Removes the specified location from the category's member page 174
locations
air category rm-rule Removes the rule from the category's set of rules page 175
air category rm-view Removes views from the specified category page 176
air category rm-view-element Removes elements from a category’s view page 176
air category set-permissions Grants permissions to the specified user or group to read and page 177
write the values of some or all of the annotation rules in a
specific category
air category show-permissions Displays the current permissions on a category’s annotation page 179
rules
air category unload Unloads the contents of the specified category to standard page 180
output

air object Group Manipulates objects and directories in the EME; the page 181
commands described here pertain to permissions
air object clear-permissions Clears permissions for objects in a directory location page 181
air object restore-permissions Restores the initial permissions on objects page 181
air object set-permissions Sets the read and write permissions on one or more objects page 182
for a single user, a single group, or all users
air object show-permissions Displays permissions for objects in an EME datastore page 183
air system Group Administers system objects, groups, and user accounts page 184
air system export Copies all EME user accounts and groups to a binary file, for page 184
users-and-groups export to another EME datastore
air system group add-group Adds a group to another group page 184
air system group add-user Adds the specified user to the specified group page 184
air system group create Creates a user group with the specified name page 185
air system group remove-group Removes a group from its container group page 185
air system group remove-user Removes the specified user from the specified group page 186
air system group show Displays a list of groups, optionally showing their page 186
membership
air system import Creates the user accounts on the target EME datastore from page 187
users-and-groups the specified export file
air system install categories Builds the base schema’s categories and rules page 187
air system user change-name Changes the user name for the specified user page 187
air system user change-password Specifies a new clear password for the user page 188
air system user create Creates an account for the specified user page 188
air system user disable Disables the account of the specified user page 189
air system user enable Enables the disabled account of the specified user page 189

air web-interface Group Administers settings for the main page and other aspects of page 191
the business metadata Web user interface
air web-interface clear Deletes the settings for a specific group of users page 191
air web-interface describe Displays descriptions of the configuration variables for the page 191
business metadata Web user interface
air web-interface set Sets a configuration variable for a specific aspect of the Web page 192
user interface for a specific group of users
air web-interface set-order Sets the order of groups that are searched for variables and page 193
values in order to build the Web user interface for a particular
group
air web-interface show Displays the current values of the configuration variables for page 194
a specific group of users
air web-interface show-order Displays the current order of groups page 194

air annotation Group

The air annotation group of commands assigns, removes, and
annotation values, comments, and descriptions.
air annotation add Adds an annotation value to an object that is a member of a category.
air annotation add rpath1 arule {rpath2 | -string s1 ...}
rpath1 Path to the object that is a member of the

category associated with arule.
arule Name of an existing annotation rule that is

associated with a category.
rpath2... | -string s1... Value of annotation rule.

• For string-type and choice-type rules,
specify one or more explicit strings using
the format -string s1...
• For reference-type rules, specify the paths
to one or more member objects in the
category associated with arule.
Usage information This command fails if:

• The object specified by rpath1 is not a member of the category that
has this annotation rule (arule).
• The object specified by rpath2 is not a member of the target
category or is not a reference-type rule. The type of the annotation
rule and target category are specified when the annotation rule is
created. See air arule create (page 152).
Running this command again on the same objects and rules but with
different values appends the values to the current values.
Example 1 To add the Finance value to the choice-type rule named

business_area to the object graph1, type:
business_area -string “Finance”
Assume that the business_area rule is multivalued. Running the
command again against business_area on graph1 appends a second
value (“Accounts Receivable”) to the original value (“Finance”).


business_area -string “Accounts Receivable”
Example 2 To add a value for the reference-type rule named steward
to the object graph1, type:
air annotation add\
steward “/Metadata/Personnel/Katz, Mitzi”
air annotation Sets the description and comment properties of an object.

document
air annotation document rpath description comment
rpath Path to an EME datastore object.
description Brief description (string) of the object rpath.

To omit, enter a null string (“”).
comment Full comment (string) about the object rpath.
Usage information The description property is displayed in the

directory listing of the Web user interface, so typically the description is
brief.
The comment property appears as the top-level description when an
object is displayed in the Web user interface. Comments are typically
longer than descriptions. Comments and descriptions can contain
HTML tags, such as those for bold and italic font face, font size, font
color, and hyperlinks to images.
Example 1 To add a description to graph1, type:

air annotation document \
/Projects/myproject/mp/graph1.mp “Inventory App”
Example 2 To add a comment for graph2, but not a description, type:
air annotation document \
/Projects/myproject/mp/graph2.mp “” \
“Loads your data into a DB2 database
Note: Before using, create table config
and record format files... ”
Shortcut The shortcut for this command is air document.

air annotation dump Displays all annotation rules and values (if any) for a member object of
a category.
air annotation dump [-reverse] rpath [-category category]
-reverse Optional. If specified, displays all the objects

that have the specified object, rpath, as an
annotation value.
rpath Path to a datastore object whose annotations

you want to display.
-category category Optional. If specified, retrieves the annotation

rules and values for category.
Usage information The output displays “permission denied” if you

do not have permission to view an annotation rule.
Because you can set annotation rule permissions on an individual
category, specifying different values of category may allow you to view
different information about an object.
You can control the display of date, time, and boolean annotation values
by setting various configuration variables (page 279).
Example To see the annotation rules and values for graph1, type:
air annotation dump \
/Projects/myproject/mp/graph1.mp
If graph1 is a member of the Application category and if Application is
based on the built-in graph category, then this command will display all
the rules and values for graph and then all the rules and values for
Application.
For example, you might see something like the following. All of these
annotation rules are single-valued. If no value follows the annotation
rule name, as in the version rule, then the value is unset.
graph: -----------------------------------
oid: 0232.1.0
name: /Projects/myproject/mp/graph1.mp
comment:
description: Accounts Receivable App
display_name: My Graph
created_by: S Finkel
creation_date: 3/1/2001 16:19:10
modified_by: S Finkel
modified_date: 5/2/2001 14:20:07
categoryOID: 0052.1.1

path: /Projects/myproject/mp/graph1.mp
author: Ab Initio Software Corp
version:
Application: ------------------------------------------------------
business_area: Finance
steward: John Doe
Alias The alias for this command is air dump annotations.
air annotation rm Removes from an object one or more annotation values, or all
annotation values of the specified rule.
air annotation rm rpath arule {-all | value ...}
rpath Path to the datastore object whose annotation value

you want to remove.
arule Name of an existing annotation rule that is associated

with the object specified by rpath.
-all | value ... Choose one of the following:

• -all removes all the values of this rule on this
object.
• value ... is one or more valid values (strings) for
the specified rule and object. Required for a
multivalued rule.
• If you omit value for a multivalued rule
(rule was created with +multi-value
argument), an error results.
• If you omit value for a single-valued rule
(rule was created with -multi-value
argument), then value is removed.
Usage information Fails if the object specified by rpath and the

annotation rule specified by arule do not exist.
Example To remove “Accounts Receivable” as a value of the

business_area rule for graph1, type:
air annotation rm \
business_area “Accounts Receivable”

air arule Group

The air arule group of commands manages the creation and
modification of annotation rules.
air arule add-choice Creates or appends a list of choices for a choice-type annotation rule.
add arule add-choice [-q] arule choice ...
-q Optional. Suppresses error if the choice already exists.
arule Name of an existing choice-type annotation rule.
choice ... One or more choices specified as strings.
Usage information The specified rule must have been created with a
-type choice argument.
The first time you run the command for a given choice-type annotation
rule, it creates the choice list. Rerunning the command against the same
annotation rule appends the choice list to the existing choice list.
Note To remove a choice, run air arule rm-choice (page 160).
Example To create a choice list for the department rule, type:

air arule add-choice department “Operations” \
Finance” “Marketing” “Research”
air arule create Creates an annotation rule with the specified attributes.
air arule create [-q] [-f] arule ⇒
[-display string] ⇒
-type {string | choice | reference | record} ⇒
[-default-value value] ⇒
[-datatype datatype] ⇒
[-size size] ⇒
[+can-edit |-can-edit] ⇒
[+revert-on-edit |-revert-on-edit] ⇒
[+big-text |-big-text] ⇒
[+multi-value |-multi-value] ⇒
[+raw-text |-raw-text] ⇒
[+in-list |-in-list]⇒
[+add-choice |-add-choice] ⇒
[target-category]

air arule Group
-q Optional. Suppresses error if another rule with the

same name and same attributes exists. However, if
arule has the same name but different attributes,
then an error occurs.
-f Optional. Suppresses error if a like-named arule

already exists with the same or different attributes.
Also, modifies the original rule to have the
attributes of the newly specified arule. Attributes
unspecified by arule take the default values.
arule Name of the new annotation rule.
-display string Optional. The rule’s display name as a string. This

name determines how the rule appears in various
displays, including the Web interface. The string
need not be unique across all rules.
-type {string | Constrains the number and kinds of values: string,

choice | reference | choice, or reference.
record}
• string: The value of the rule is one or more
strings attached to a single object.
• choice: The values of the rule are chosen
from an explicit set of values (strings).
• reference: The values of the rule are
references to members of the specified
existing category.
• record: The values of this rule are the
annotation rules of the specified existing
category target-category.
-default-value Optional. Default value of the annotation rule.

{rpath | string}
• Specify rpath for reference rules. Path to a
member object of target-category.
• Specify string for string and choice rules. For
choice rules string must be a valid choice.
Default values are not supported for record rules.
-datatype datatype Optional. The data type for this rule’s values.
datatype may be STRING (default), INTEGER,
TIME, BOOL, and FLOAT.

-size size Optional. Maximum length, in bytes, of this rule’s

values. Default is 256.
+can-edit Optional. Default is -can-edit.

|-can-edit
• +can-edit allows the end user to edit the
value of the rule in the Web user interface.
• -can-edit prevents the end user from editing
the rule’s value in the Web user interface.
+revert-on-edit Optional. Default is -revert-on-edit.

|-revert-on-edit
• +revert-on-edit causes the rule’s value to
revert to the default value, if any, when the
object is edited in the Web user interface.
• -revert-on-edit causes no special behavior.
+big-text |-big-text Optional. Default is -big-text.

• +big-text means the Web user interface
displays a multiline edit field for this rule.
• -big-text means the Web user interface
creates a single-line edit field for this rule.
+multi-value Optional. Default is -multi-value.

|-multi-value
• +multi-value means a user can specify
multiple values for a given member object.
• -multi-value means a user can specify only a
single value for a given member object.
+raw-text Optional. Default is -raw-text.

|-raw-text
• +raw-text prevents translation of annotation
values. Thus, embedded HTML codes are
interpreted as HTML.
• -raw-text enables translation of annotation
values. Thus, HTML codes are displayed as
codes in the browser.

air arule Group
+in-list |-in-list Optional. Valid only for choice-type rules. Default

is +in-list.
• +in-list means the rule’s value must be
selected from a predefined list.
• -in-list means the rule’s value can be, but is
not required to be, one of a predefined list of
choices. If you specify -in-list, you must also
specify +add-choice.
+add-choice | Optional. Valid only for choice-type rules. Default

-add-choice is -add-choice.
• +add-choice means specified values that are
not on the list will be added to the list of
displayed choices. If you specify
+add-choice, you must also specify -in-list.
• -add-choice means specified values that are
not on the list will not be added to the list of
displayed choices; however, the value will be
saved.
target-category Name of an existing category. Required and valid

only for:
• Reference-type rules. Values are member
objects of the target category.
• Record-type rules. Values are the annotation
rules of the target category.
Usage information Supply a default value whenever you have to

have a value for an annotation rule. For example, for the phone rule, you
might specify the main office number as the default. Then edit the value
for individual employees.
For the most part, the attributes you choose for an annotation rule
determine how the rule and its values will be rendered in the Web user
interface. See How Controls Are Rendered on page 77. The exceptions
are the -datatype and -size parameters; they have no effect on how
annotation values are stored or displayed.
Assign the -datatype parameter to an annotation rule when you want to
eventually unload the rule’s values to a Windows-supported application
through the ODBC driver interface. The rule becomes a column of a
relational database table. Typing the column allows you to manipulate
the data arithmetically. Note that the data type specification is not
currently enforced by the EME datastore or the Web user interface.

The -size parameter, which determines the maximum length of the

rule’s value, has no effect on the display of the value in the Web user
interface.
Example 1 You want end users to select a single department from a

list of departments for each employee. There are a limited number of
departments in your company; you do not want users to modify the
department names.
To create a department rule, type:
air arule create department \
-display “Department Name” \
-type choice
It is not necessary to specify -can-edit, -multi-value, and +in-list,
because these are the defaults. Objects that have choice-type annotation
rules have, by default, a single value at a time, and the value must be
selected from a predefined list. Also, users cannot edit annotation values
unless you explicitly allow it.
Example 2 You want end users to specify a single office phone

number for each employee. Your company supports hundreds of phone
lines and each phone number is unique. You decide to specify a default
value corresponding to the main phone number for the company. You
will then edit the numbers of department managers. To create such an
annotation rule, type:
air arule create phone \
-display “Work Number” \
-type string \
-default-value “781 301 2000” \
+can-edit
Example 3 You want to create a steward annotation rule whose value
will be a member of Personnel. You want to assign a default value for
all member objects, so that all member data files have a default steward.
More than one steward is allowed per data file. To create such a rule,
type:
air arule create steward \
-display Steward \
-type reference \
-default value “Mitzi Katz”\
+can-edit \
+multi-value \
Personnel
Remember to specify the default value as a choice in the rule’s choice
list. For more information, see air arule add-choice (page 152).

air arule Group
air arule dump Displays information about the specified annotation rule.
add arule dump arule
arule Name of an existing annotation rule.
Usage information For all annotation rules, the output displays the
rule’s display name, default value, whether or not it can be edited, and
whether or not it takes a single value or multiple values.
For choice-type rules, the output also displays the rule’s choice list,
whether or not values can be added to the choice list, and whether or not
users must choose values from a predefined list.
For reference-type rules, the output also displays the name of the rule’s
target category.
In the output, 1 means “yes” and 0 means “no.”
Example 1 To find out about the Abbreviation rule, type:

air arule dump Abbreviation
The following output shows that Abbreviation is a string-type rule, has
no default value, can be edited, can take multiple concurrent values.
/abinitio/annotation rules/Abbreviation
string rule ------------------
display name: Abbreviation
default value:
can edit: 1
multi-value: 1
raw-text: 0
Example 2 To find out about the Approval_Status rule, type:
air arule dump Approval_Status
The following output shows that Approval_Status is a choice-type rule
whose name is displayed as Approval Status, has no default value, can
be edited, and can take multiple concurrent values chosen from the
predefined list (approved, pending, and defaulted). Users cannot add
choices to the list.
/abinitio/annotation rules/Approval_Status
choice rule ------------------
display name: Approval Status
default value:
can edit: 1
multi-value: 1

in_list: 1
add_choice: 0
choices: approved
pending
defaulted
Example 3 To find out about the Steward_Group rule, type:
air arule dump Steward_Group
The output shows that Steward_Group is a reference-type rule that
points to the Steward Group target category. The rule has no default
value, can be edited, and can take multiple concurrent values. It name is
displayed in the Web user interface as Steward Group.
/abinitio/annotation rules/Steward_Group
reference rule ------------------
display name: Steward Group
default value:
can edit: 1
multi-value: 1
target category: Steward Group
Alias The alias for this command is air dump arule.
air arule modify Modifies the characteristics of an existing annotation rule.

air arule modify arule ⇒
[-display string] ⇒
[-default-value value] ⇒
[-datatype datatype] ⇒
[-size size] ⇒
[+can-edit | -can-edit] ⇒
[+multi-value |-multi-value] ⇒
[+in-list |-in-list] ⇒
[+add-choice |-add-choice]
arule Name of an existing annotation rule.
-display string Optional. The rule’s display name

specified as a string. This name
determines how the rule appears in the
Web user interface. The string does not
have to be unique.
-default-value value Optional. The value of this annotation

rule if it is not set on an object. To clear
the value, specify -default-value "".

air arule Group
-datatype datatype Optional. The data type for this rule’s

values. datatype may be STRING
(default), INTEGER, TIME, BOOL, and
FLOAT.
-size size Optional. Maximum length, in bytes, of

this rule’s values. Default is 256.
+can-edit | -can-edit Optional. Default is -can-edit.

• +can-edit allows the user to edit the
field in the Web user interface.
• -can-edit does not allow the user to
edit the field in the Web user
interface.
+multi-value | -multi-value Optional. Valid only for choice-type

rules.
• +multi-value allows multiple
annotation rules of the same name
on an object.
• -multi-value allows only a single
value.
The default is the current setting.
+in-list |-in-list Optional. Valid only for choice-type

rules. Default is current setting.
• +in-list means the rule’s value must
be one from a predefined list.
• -in-list means the rule’s value can be
entered by the user. If you specify
-in-list, you must also specify
+add-choice.
+add-choice | -add-choice Optional. Valid only for choice-type

rules. Default is current setting.
• +add-choice allows the end user to
enter a value that is not among the
predefined choices. If you specify
+add-choice, you must also specify
-in-list.
-add-choice allows the end user to enter a
predefined value.

Usage information You cannot change the type or target category of

a reference rule.
Example You want to correct a typographical error in a display name

of the business_area rule and also allow users to edit the rule’s value.
Type:
air arule modify business_area \
-display Business Area +can-edit
air arule rm Deletes the annotation rule from an EME datastore.

air arule rm [-q] arule ...
-q Optional. Suppresses error if the rule does not exist.
arule Name of one or more existing annotation rules.
Usage information This command takes the following actions:

• Deletes the specified annotation rule from the /abinitio/annotation
rules directory.
• Disassociates the specified annotation rule from the categories to
which it has been assigned.
• Deletes the annotation values from the objects that have the
specified annotation rule.
Example To delete the business_area rule, type:

air arule rm business_area
air arule rm-choice Removes one or more choices, or all choices, from a rule’s choice list.
air arule rm-choice [-q] arule {-all | choice ...}
-q Optional. Suppresses error if the rule does not exist in

this choice list.
arule Name of an existing choice-type annotation rule.
-all | choice ... Specify one of the following:

• -all clears all choices from the choice list.
• choice ... means one or more choices (strings) to
remove from a choice list.

air arule Group
Usage information This command is valid only for choice-type

annotation rules.
Example Assume that the choice list for the department rule consists
of a number of strings: “Operations” “Finance” “Marketing”
“Research”. To remove Finance and Marketing from the list of
possible values, type:
air arule rm-choice “Finance” “Marketing”

air category Group

The air category group of commands manages the creation,
modification, and deletion of categories and views. It also grants
permissions to users and groups regarding access to a category’s
annotation rules.
air category Adds objects residing in the specified location to the category's
add-member-location membership.
air category add-member-location [-q] category [depth] rpath ...
-q Optional. Suppresses error if the category does not

exist.
depth Optional. Adds various levels of descendants to the

category’s members. Valid values are:
• self adds only the object specified by rpath.
• children adds the object specified by rpath and
its immediate descendants.
• nested (default) adds the object specified by
rpath and all of its descendants.
rpath ... One or more full datastore paths specifying a file or

directory, for example, /Projects/myproj/tables.
Usage information Only objects that match the type of the parent
category and are contained in the specified locations become members
of the specified category. For example, if the parent category is graph,
then only graph objects residing in rpath can become members of graph.
The depth argument gives you fine control over which descendant
objects of rpath are candidates for membership in a category. By
default, all descendants of rpath can become members of a category,
assuming they are of the same type as the category’s parent. Therefore,
in the figure on page 163, graph1, graph2, and test will become
members of Application if you specify:
However, mime-object1 and all the documents in the Docs folder are
excluded because they are not graph objects. (Documents are MIME
objects.)

air category Group
Application
/Projects/project1/mp business_area rule
steward rule
graph1.mp
test /
graph2.mp
test.mp
mime-object1
Doc1
Docs Doc2
Doc3
The arguments children and self restrict category membership. For

example, specifying children, as follows, means that graph1, but not
graph2 or test, is a member of Application.
children /Projects/project1/mp
Specifying self in this example would not make sense:
self /Projects/project1/mp
The result would be that Application would have no members, since the
object that self refers to — /Project/project1/mp — is not a graph
object. self is useful only when you want to include a single object as a
member. See Example 2 below.
Example 1 To create the category Tableview and then include the

directory location /Projects/myproj/tables in that category:
air category create Tableview dataset
air category add-member-location Tableview \
/Projects/myproj/tables
The members of the Tableview category are all dataset objects in
/Projects/myproj/tables and its subdirectories.
Example 2 To make only graph2 (in the preceding figure) a member

of the Application category, type:
self /Projects/project1/mp/test/graph2.mp

air category add-rule Associates one or more annotation rules with the specified category,
adding each rule to the category’s list of rules.
air category add-rule [-q] [-f] category ⇒
arule [+required | -required] [+inherit | -inherit] ⇒
[arule [+required | -required] [+inherit | -inherit]] ...
-q Optional. Suppresses error if the rule is
already associated with the category.
However, if arule has the same name but
different attributes, then an error occurs.
-f Optional. If specified, associates arule with

category, even if arule is already one of the
category’s rules. arule’s values for required
or inherit overwrite the values of the original
like-named rule.
arule Name of an existing rule.
+required | -required Optional. Default is -required.

• +required means that the rule must
have a value.
• -required means that the rule’s value is
optional.
+inherit | -inherit Optional. Default is -inherit.

• +inherit means the rule’s value is
inherited from another object if a value
has not been set explicitly for this
object.
• -inherit means the rule’s value is not
inherited from another object.
Usage information You can associate more than one annotation rule
with the specified category. See Example on page 166.
+required option Use +required when you want to require a user of the Web user
interface to specify a value for this annotation rule. For example, you
might make the steward rule required, because you want to ensure that
every dataset has an owner.

air category Group
+inherit option Use +inherit when you want to increase the likelihood that an object
will have a value for a given rule. The +inherit option works in
conjunction with the air category inheritvia-rule command (page
172). If you specify +inherit, you must also issue the air category
inheritvia-rule command.
In the following figure, the steward rule is defined as +inherit.
air category add-rule Application \
steward +inherit
This means that if a member of Application doesn’t have an explicitly
set value for steward, then steward can inherit its value from the value
of the reference-type rule specified in air category inheritvia-rule.
air category inheritvia-rule Application \
business_area
In the example, the reference rule is business_area. Assume that the
value of business_area is a member of the Systems category.
Personnel
Personnel/
Application Systems John Doe
mp/ system/ Mitzi Katz
business_area Jim Anchower
graph1 finance steward
steward
graph2 business_area marketing steward
steward
business_area operations
graph3
steward
Now let’s say that the value of the steward rule for the graph1 object is
unset. (Default values are not considered.) According to the +inherit
option and the air category inheritvia-rule specification, the EME
determines whether the value of the business_area rule for graph1 refers
to a category with a steward rule and, if so, whether that steward value
has a value. In the example, the value of business_area for graph1 is
finance in the Systems category. Fortunately, Systems is associated with
a steward rule, whose value is a member of Personnel. The value of the
steward annotation rule for finance is Mitzi Katz. Therefore, the value
of steward for graph1 is set to Mitzi Katz.

In the event that Systems does not have a steward rule, or if its steward
rule has no value, then the value of steward on graph1 is set to the
default value, if any was specified when the annotation rule was created.
Otherwise, the value remains unset.
For example, graph2’s steward rule has no value. The value of
business_area on graph2 is marketing, but the value of steward on
marketing is unset. Therefore, the EME software is unable to supply a
value for steward on graph2.
Example To associate the date_deployed rule and the required

date_modified rule with the Systems category, type:
air category add-rule Systems date_deployed \
date_modified +required
air category add-view Creates a new, empty view and associates it with the specified category.
air category add-view [-q] category view...
-q Optional. Suppresses error if the view already

exists for this category.
view... Name of one or more views to be defined on

the category.
Usage information We recommend that you create your views

before creating view-elements for them. Multi-word view names are
supported. View names on a given table must be unique, but identical
view names are supported for different categories.
Example To create the DF-Details view and associate it with the Data
Files category, type:
air category add-view “Data Files” DF-Details

air category Group
air category Describes one or more elements of data (view-elements) and associates
add-view-element them with an existing view view on the specified category.
air category add-view-element [-q] [-f] category ⇒
view ⇒
element-type ⇒
[+index | -index] ⇒
[+display-contents | -display-contents]
[+auto-show | -auto-show] ⇒
[+can-toggle | -can-toggle] ⇒
label ⇒
element-descriptor ⇒
element-view ⇒
[element-type [+index | -index] [+auto-show | -auto-show]
[+can-toggle | -can-toggle] label element-descriptor element-view]...
-q. Optional. Suppresses error if the view-element

already exists. However, if the view-element has
the same label but differs in other ways, then an
error occurs.
-f Optional. If specified, suppresses an error if the

view-element is already part of view and replaces
the existing view-element with the attributes of the
new one. Two view-elements are identical if they
have the same label.
view Name of an existing view defined on category.
element-type Specify one of the following:

• -simple specifies a view-element that
describes the value of a single annotation rule
on this or another category.
• -view specifies a view-element that refers to a
view on another category. The referenced
view is included in the current view.
• -decorate specifies a view-element that
describes stored HTML text.

+index | -index Optional. Default is -index.

• +index means the values of this view- element
will be placed in a search index. Users can
search for these values in the Web interface.
• -index means the values of this view- element
will not be searchable.
+display-contents Optional. Default is -display-contents. Valid only

|-display-contents for view-elements that are reference rules whose
values are MIME objects.
• +display-contents means the value is a
hyperlink that, when clicked, displays the
MIME object’s contents. For example, if the
contents are a MS Word document, then the
document is displayed in your Web browser.
• -display-contents means the value is a
hyperlink that, when clicked, displays a view
of the object in a new Web page.
+auto-show | Optional. Valid only for -view view-elements.

-auto-show Default is +auto-show.
• +auto-show means that the view included in
the current view is fully expanded. That is, all
the view-elements of the included view are
displayed in the current view when it is
rendered.
• -auto-show means that the contents of the
included view are collapsed.
+can-toggle | Optional. Valid only for -view view-elements.

-can-toggle Default is -can-toggle.
• +can-toggle means that users can switch
between the expanded and the collapsed
display of the included view.
• -can-toggle means that users can see only the
current display of the included view. The
current display is determined by the setting of
the auto-show option.
label Text (string) that describes a metadata item. Except

for labels for -decorate element-types, the label is
displayed in the Web user interface.

air category Group
element-descriptor Describes values associated with member objects.

The format depends on element-type. Escape
characters are required for -simple and -view
element-types.
• For -simple, the format is one of these:
• | relation > or arule-name, which describes
annotation values on the current object.
• < relation | , which describes objects that
depend on the current object.
• Combinations of these:
| relation > | relation >
< relation | <relation |
< relation | | relation >
| relation > < relation |
• relation is a category-rule pair in the
format: category.arule
• For -view, the format is the same as above.
• For -decorate, the format is a datastore path to
a stored MIME object.
element-view Required if element-view is -view; do not use with

-simple. The name of the view you want to include.
The format is: category.view. Escape characters are
required (page 58).
Usage information Add the view-elements in the order in which you

want them displayed in the Web user interface.
Detailed usage information is provided in Defining Content for Views
on page 54. In particular, you might be interested in specific
information about one of these types of view-elements:
• -simple See Including Values from the Current Category or

a Related Category on page 59.
• -view See Including Views Within Views on page 66.
• -decorate See Including Text on page 69.

air category Removes the current permission settings on one or more annotation
clear-permissions rules of a category.
air category clear-permissions category {-all-rules | arule ...}
-all-rules | arule ... Choose one of the following:

• -all-rules means all rules of the category.
• arule ... means one or more annotation
rules of the category.
Usage information Clearing permissions removes read and write

permissions for all users and groups, except for the EME administrator.
air category create Creates a category that has the name category and is based on the parent
category parent.
air category create [-q] category parent
-q Optional. Suppresses error if the category already

exists.
category Name of a new category.
parent Name of an existing category from which the new

category is derived.
Usage information When you create a new category, it comes with

the annotation rules of its parent. Objects that become members of this
new category must be of the same type as the parent category. For
example, if the parent of the new Application category is graph, then the
member objects of Application must be graphs. You can build new
categories based on the categories you define.
Example To create the Application category, which is based on the

built-in category graph, type:

air category Group
air category dump Displays information about the specified category, including its
datastore location, its parent category, the datastore location of its
members, its annotation rules, and its views.
air category dump category
Example To see information about the Application category, type:

air dump category Application
The command displays something like the following:
/abinitio/categories/Application
Parent category -------------------:
graph
Member locations ------------------:
/Projects/myproject/mp
Inherit via rule------------------:
(not defined)
Annotation Rules ------------------:
steward: not required, inherit values
business_area: not required, inherit values

Views -----------------------------:
'list' elements:
Business Area:: (simple) business_area
Steward: (simple) steward

'details' elements:
Business Area:: (simple) business_area
Steward: (simple) steward
Stewards Phone: (simple) steward/phone
“Parent category” displays the name of the category from which

Application is derived — graph.
“Member locations” displays the datastore location of the objects that
are members of Application.
“Annotation rules” displays only those rules that are local to
Application. To see the rules that derive from the parent category, run
air category dump (page 171) on the graph category.
For information about the meaning of the “Inherit via rule,” see air
category inheritvia-rule (page 172).

“Views” displays the names of the views defined on Application and the
view-elements (label, type, and rule) that make up each of its view.
Alias The alias for this command is air dump category.
air category When an annotation rule that can inherit values (+inherit) has no value,
inheritvia-rule the value will be inherited from an object that has the specified
annotation rule.
air category inheritvia-rule category arule
arule Name of an existing annotation rule that is both

single-valued and of type reference.
Usage information This command is used in conjunction with the

+inherit option of air annotation add-rule to set values for unset
annotation rules. It allows the specified reference-type arule on an
object in the specified category to supply a value for another rule on that
object if the other rule has no value and is allowed to inherit values. See
+inherit option on page 165 and the accompanying figure to understand
how air category inheritvia-rule works with the +inherit option.
An error occurs if arule is multivalued or of type choice or simple. You
may specify only one arule for a given category.
Example To have the appoid reference rule in the Application

category supply a value for another rule that has no value, type:
air category inheritvia-rule Application appoid
The other rule is specified by air category add-rule (page 164).
air category Displays the members of a given category.

list-members
air category list-members category
Example To see a list of members in the package category, type:

air category list-members package
The output might be something like the following:
/abinitio/categories/package has 4 members.
/Projects/program_datasets/dml/format.dml
/Projects/pr14567/run/output_file.dml
/Projects/pr14567/dml/purchases.dml
/Projects/pr14567/dml/output_file.dml

air category Group
air category Modifies certain characteristics for an annotation rule associated with
modify-rule the specified category.
air category modify-rule category arule ⇒
[+required | -required]
[+inherit | -inherit]
arule Name of the annotation rule whose options

you want to modify.
+required | -required Optional. Default is -required.

• +required means that the rule must have
a value.
• -required means that the rule’s value is
optional.
+inherit | -inherit Optional. Default is -inherit.

• +inherit means the rule’s value is
inherited from another object if the value
is not set explicitly for this object.
• -inherit means the rule’s value is not
inherited from another object.
Usage information Use this command to change the values of the

inherit and required options, which were originally set by air category
add-rule (page 164). This command does not change the characteristics
of this rule with respect to any other category.
Example To prevent the steward rule on an object from inheriting a

value from a another rule on the same object, type:
air category modify-rule “Data Files” steward \
-inherit
air category rm Deletes the specified category from the EME datastore.
air category rm [-q] [-keep-annotations] category ...
-q Optional. Suppresses error if the category
does not exist.
-keep-annotations Optional. Retains annotation values of the
category’s members.
category ... Name of one or more categories you want to
remove.

Usage information This command takes the following actions:

• Deletes the category from the /abinitio/categories directory.
• Disassociates the category from its members. It does not delete the
members.
• Disassociates the category from the annotation rules assigned to it.
• Removes all annotation values from the category’s members,
unless -keep-annotations is specified.
Use the -keep-annotations option when you are reassigning rules from
one category to another.
Example To delete the Data Files and Application categories, type:

air category rm “Data Files” Application
air category Removes the specified location from the category's member locations.
rm-member-location
air category rm-member-location [-q] ⇒
[-keep-annotations] ⇒
category ⇒
rpath ...
-q Optional. Suppresses error if rpath does not

exist.
-keep-annotations Optional. If specified, retains the annotation

values of the category’s former members.
rpath... Path to one or more datastore locations that

contains members of category.
Usage information and example Use the -keep-annotations option

when you want to assign this member location to another category with
the same set of annotation rules. By default, the command removes the
annotation values.
This command may not remove (as members) objects in the rpath
location and in subdirectories of rpath. They may still remain members
of the specified category if you previously issued an explicit air
category add-member-location (page 162) to include them.

air category Group
For example, let’s say you ran air category add-member-location

twice, once to include all the graph-object descendants of
/Projects/project1/mp in the Application category, and again to
include just its immediate graph-object descendants:
nested /Projects/project1/mp

self /Projects/project1/mp/graph2.mp
In this scenario, both graph1 and graph2 are members of Application.
See the following figure.
Application
vertex1
graph1 vertex2
graph2 member
member
mime-object1
Doc1
Docs Doc2
Doc3
Suppose that you then decide that only graph2 should be a member. You
would run air category rm-member-location again to remove graph1:
air category rm-member-location Application \
All graph objects in this location lose their membership (that is,
graph1); however, graph2 remains a member, because it was explicitly
made a member of Application.
air category rm-rule Removes the annotation rule arule from the category's set of rules.
air category rm-rule [-q] [-keep-annotations] category arule...
-q Optional. Suppresses error if arule does not exist.
-keep-annotations Optional. If specified, retains the annotation

values of the category’s members.
arule... Name of one or more annotation rules on the

specified category.

Usage information Use this command to change the values of the

inherit and required options, which were originally set by air category
add-rule (page 164).
This command removes the annotation rule’s association with a given
category; it does not delete the annotation rule. By default, it also
removes all annotation values from the objects that have the specified
rule.
Example To remove steward from the set of annotation rules

associated with the Data Fields category, type:
air category rm-rule “Data Fields” steward
Each member of Data Fields loses the steward rule and its value.
air category rm-view Removes the specified view, or all views, from the specified category.
air category rm-view [-q] category {view ... | -all}
-q Optional. Suppresses error if view does not exist.
view ... | -all Choose one of the following:

• view ... means one or more names of existing
views of the specified category.
• -all means all views of the specified category.
Example To remove DF-Details from the list of views associated

with the Data Files category, type:
air category rm-view “Data Files” DF-Details
air category Removes the specified elements, or all elements, from a category’s
rm-view-element view.
air category rm-view-element [-q] category view {label ... | -all}
-q Optional. Suppresses error if view does not exist.
view Name of an existing view.

air category Group
label ... | -all Choose one of the following:

• label ... means one or more labels (strings) of
view-elements that you want to remove.
• -all means all elements from the specified
view.
Usage information Refer to a view-element by its label. You must

use the exact spelling and capitalization.
Example Let’s say the phone number appears twice in a rendered

view. To remove a redundant “Phone #” view-element, type:
air category rm-view-element “Data Files” \
DF-Details “Phone #”
air category Grants permissions to the specified user or group to read and write the
set-permissions values of some or all of the annotation rules in a specific category.
air category set-permissions category ⇒
{-all-users | user-name | group-name} ⇒
{{-all-rules {[+read | -read] | [+write | -write] |
{+read | -read} {+write | -write}}
OR
{arule ... {[+read | -read] | [+write | -write] |
{+read | -read} {+write | -write}} ...}
-all-users | user-name Choose one of the following:

| group-name
• -all-users means all user accounts.
• Valid user name.
• Name of an existing group.
-all-rules | arule ... Choose one of the following:

• -all-rules means all annotation rules in
the specified category.
• Name of one or more existing annotation
rules in the specified category.
+read | -read Choose one of the following:

• +read means the user or group can see
the value of the specified annotation rule.
• -read means the user or group cannot see

+write | -write Choose one of the following:

• +write means the user or group can edit
the value of the specified annotation rule,
if the rule can be edited.
• -write means the user or group cannot edit
Usage information You can set either read or write permissions, or

both, but you must set at least one.
By default, users and groups do not have read and write permissions on
annotation rules.
When you grant a user or group read permissions on an annotation rule,
make sure that the rule is included in a view definition. This ensures that
the specified user or group will be able to see the rule’s value in the Web
user interface. Note that you can still see the value of such an annotation
rule in other interfaces, such as the command line.
When you grant a user or group write permissions on an annotation rule,
make sure that the rule can be edited, that is, is defined with the
+can-edit argument.
Use -all-rules to set the same permissions on all the annotation rules in
a given category. Once you specific -all-rules, it is not syntactically
correct to specify one or more individual annotation rules within the
same invocation of air category set-permissions.
Rather than listing the permissions for one rule after another, you can
group identical permissions for multiple annotation rules. For example,
Group1 has identical permissions to arule1, arule5, and arule6 (+read
and +write) and identical permissions for arule3 and arule4 (+read):
air category set-permission “Category1” “Group1”
arule1 arule 5 arule6 +read +write
arule2 -read -write
arule3 arule4 +read
For more information, see Granting Permissions on page 129.
Example To grant permissions to all users in the Doc group to read

but not write (edit) the values of the name, comment, description, and
members annotation rules of the Steward Group category, type:
air category set-permission "Steward Group" "Doc" \
name +read -write \
comment +read -write \
description +read -write \
members +read -write

air category Group
Note that the permissions of unspecified annotation rules in Steward

Group are left unchanged.
air category Displays the current permissions on one or more annotation rules for the
show-permissions specified category.
air category show-permissions category [arule ...]
arule ... Optional. Name of one or more annotation rules

whose permission settings you want to see. If arule is
not specified, then permissions on all annotation rules
for the specified category are displayed.
Example To display permissions on all rules of Category-A, type:

air category show-permissions “Category-A”
The output might be:
Expecting permissions that match {{normal-users, +read -write},
{special-users,+read +write}}
Category: category-A
Annotation Rule: arule_A1
normal-users +read -write
special-users +read +write
Expecting permissions that match {{Joe-Blue,+read -write},
Annotation Rule: arule_A2
Joe-Blue +read -write
Expecting permissions that match {{Mary-Worker,-read +write},
{Joe-Blue,+read -write}}
Annotation Rule: arule_both
Joe-Blue +read -write
Mary-Worker -read +write
Expecting permissions that match {{Mary-Worker,+read -write},
Annotation Rule: arule_base
Mary-Worker +read -write
Expecting permissions that match
Annotation Rule: comment no access

air category unload Unloads the contents of the specified category to standard output.
air category unload category ⇒
[-dml | -component | -list] ⇒
[-no_inherit] ⇒
[path]⇒
[-arule rule...]
-dml | -component | -list Optional. You may choose one of these:

• -dml displays the record format being
unloaded.
• -component creates a component for
unloading.
• -list displays a list of rules and their
display names.
-no_inherit Optional. If specified, ignores the

annotation rules of the category’s parent
category.
path Optional. Datastore path of directory.

Unloads annotation rules of objects that
reside at or below the specified location. If
omitted, defaults to /.
-arule rule... Optional. If specified, one or more

annotation rules to unload. The category’s
OID rule is always unloaded. If omitted, all
rules on the category are unloaded.
Usage information For usage information about unloading the rules

and values on a category, see Unloading Metadata from Individual
Categories on page 102. For information about creating unload
components, see Creating Your Own Unload Components on page 107.
You can control the display of date, time, and boolean annotation values
by setting various configuration variables. See Configuration Variables
on page 279.

air object Group
air object Group

The air object group of commands manipulates objects and directories
in the EME. Most of the air object commands are described in the air
utility command reference chapter of Guide to Managing Technical
Metadata. The commands described here pertain to permissions. For
more information, see Granting Permissions on page 129.
air object Clears permissions for one or more objects in a directory location.
clear-permissions
air object clear-permissions [-R] rpath ...
-R Optional. If specified, clears permissions on the

object rpath as well as any other objects contained
within rpath (that is, objects in a directory)
recursively. If omitted, clears the permission on the
explicitly named object.
rpath ... Path to one or more objects in an EME datastore.
Usage information Running this command changes the permission

to -read and -write for the specified object(s).
air object Restores the initial permissions on one or more objects.

restore-permissions
air object restore-permissions [-R] rpath ...
-R Optional. If specified, restores permissions for the

object rpath as well as any other objects contained
within rpath (that is, objects in a directory)
recursively. If omitted, restores the permission on
the explicitly named object.
rpath ... Path to one or more objects in an EME datastore.
Usage information The default initial permission is +read and

+write for the object owner and all users in the same group as the
owner. The default permissions for everyone else, except the
administrator, are +read and -write.

air object Sets the read and write permissions for a single user, a single group, or
set-permissions all users on one or more objects in an EME datastore.
air object set-permissions [-R] ⇒
{user-name | group-name | -all-users} ⇒
{rpath ...{[+read | -read] | [+write | -write] ⇒
| {+read | -read} {+write | -write}}...
.
-R Optional. Restores permissions on the
object rpath as well as any other objects
contained within rpath (that is, objects in a
directory) recursively.
user-name | group-name Specify one of the following:

| -all-users
• user-name is the valid user account.
• group-name is a valid group name.
• -all-users means all user accounts.
rpath ... Path to one or more objects or directories in

an EME datastore.
+read | -read You may choose one of these:

• +read means the user or group can see
the value of the specified object.
• -read means the user or group cannot
see the value of the specified object.
+write | -write You may choose one of these:

• +write means the user or group can
edit the values of the specified object.
• -write means the user or group cannot
edit the value of the specified object.
Usage information We expect that you will specify a directory for

rpath. Use -R to set permissions on all objects contained within rpath.
By default, the owner of an object and the group to which the owner
belongs have read and write permission (+read and +write) on the
object. By default, all other users and groups have read permission
(+read and -write).
You can set either read or write permission, or both, but you must set at
least one.

air object Group
Example. To recursively set read and write permissions for the Data
Stewards group with respect to the A-team, B-team, and C-team:
air object set-permissions -R “Data Stewards”\
\Stewards\A-team \Stewards\B-team +read +write\
\Stewards\C-team +read -write
For more information, see Granting Permissions on page 129.
air object Displays permissions for objects in an EME datastore.

show-permissions
air object show-permissions [-R] rpath
-R Optional. Displays permissions on the object rpath

as well as any other objects contained within rpath
(that is, objects in a directory) recursively.
rpath Path to an object or directory in an EME datastore.
Example To see the permissions on all the objects contained within

/Data, type:
air object show-permissions -R /Data
The output looks something like this:
These are the permissions for everything in
/Data
Object: /Data
staff +read -write
world +read -write
mkatz +read +write
Object: /Data/mime1
staff +read -write
world +read -write
mkatz +read +write
Object: /Data/SubTwo
staff +read -write
world +read -write
mkatz +read +write
Object: /Data/SubTwo/mime4
staff +read -write
world +read -write
mkatz +read +write
Object: /Data/SubOne
staff +read -write
world +read -write
mkatz +read +write

air system Group

The air system group of commands administers system objects, groups,
and user accounts in the EME. See Guide to Managing Technical
Metadata for other air system commands.
air system export Copies all EME user accounts and groups to a binary file, for export to
users-and-groups another EME datastore.
air system export users-and-groups rpath
rpath Path name of the EME file to which the user

accounts and groups are written. Use - to have the
data written to standard output.
Usage information The format is not human-readable; it is intended

solely for subsequent import into another EME datastore using the
inverse command air system import users-and-groups (page 187).
air system group Adds a group to another group.

add-group
air system group add-group [-q] child-group parent-group
-q Optional. Suppresses error if the child group and

the parent group do not exist.
child-group Name of an existing group to be added to another

group.
parent-group Name of an existing group to which you want to

add the group child-group.
Usage information An error results if either group does not exist.

Users in child-group are automatically granted the permissions of
parent-group. In addition, they retain the permissions of child-group.
For more information, see How Group Permissions Combine on
page 131.
Example To add Dev to the Employees group, type:

add system group add-group Dev Employees
air system group Adds the specified user to the specified group.
add-user
air system group add-user [-q] user-name group-name

air system Group
-q Optional. Suppresses error if the user already

exists in the group.
user-name Valid user name.
group-name Name of an existing group.
Usage information The new group member is automatically granted

the access permissions of the group.
Example To add user mkatz to the Managers group, type:

air system group add-user mkatz Managers
air system group Creates a user group with the specified name.
create
air system group create group-name [-dry-run] [-gid]
group-name Name of a group.
-dry-run Optional. If specified, the operation does not actually

take place, but the EME displays an analysis of the
effect of issuing the command.
-gid Optional. If specified, requests that the group be

granted this gid (group ID). If the gid is in use, an
error occurs. If not specified, the system assigns a gid.
Example To create the Managers group, type:

air system group create Managers
air system group Removes a group from its container group.

remove-group
air system group remove-group [-q] child-group parent-group
-q Optional. Suppresses error if the group is not in

the container group.
child-group Name of a group to remove from another group.
parent-group Name of an existing group that contains

child-group.
Usage information If child-group does not exist or is not a

constituent group of parent-group, or if parent-group does not exist,
then an error occurs.

Example Assume that the Employees group comprises Dev, Doc,

HR, and Finance. To remove Dev from the Employees group, type:
add system group remove-group Dev Employees
air system group Removes the specified user from the specified group.
remove-user
air system group remove-user [-q] user-name group-name
-q Optional. Suppresses error if the user is not in the

group.
user-name Name of a user account.
group-name Name of an existing group.
Usage information This command does not remove or disable the

user’s account; it just removes the permissions granted to the user by
virtue of his former membership in the specified group.
air system group Displays a list of one or more groups, optionally showing the
show membership of the group(s).
air system group show {group-name | -all} -v
group-name | -all Choose one of the following:

• group-name means the name of an existing
group.
• -all means a list of all groups.
-v Optional. If specified, shows the membership of

the group or groups.
Examples Assume that the cats group contains the following users:
felix, tabitha, and sheba, and the dogs group contains fido, lassie, and
cleo. Both groups belongs to the animals group. To see the membership
of all groups, type:
air system group show -all -v
The output would be:
group
-----
animals
contains: cats dogs
cats
is in: animals
contains: felix tabitha sheba
dogs
is in: animals
contains: fido lassie cleo

air system Group
air system import Creates the user accounts on the target EME datastore from the
users-and-groups specified export file. The file was created by running air system export
users-and-groups (page 184).
air system import users-and-groups rpath [-dry-run] [-keep-ids]
rpath Path name of the EME file produced by running

air export users-and-groups. You may use - to
have the data read from standard input.
-dry-run Optional. If specified, the operation does not

actually take place, but the EME displays an
analysis of the effect of issuing the command.
-keep-ids Optional. If specified, the incoming uid or gid is

preserved; therefore, if a conflict occurs, the user
or group is not created.
Usage information The command accepts only the output from air
export users-and-groups. If a given user or group already exists, a
warning is issued and that user or group is not created.
By default, if a given user ID is already taken, a new user ID is created.
However, if the -keep-ids option is specified, then the system issues a
warning and does not create the user or group.
air system install Builds or rebuilds the categories and annotation rules of the base
categories schema. The categories are stored in /abinitio/categories. The
annotation rules are stored in /abinitio/annotation rules.
air system user Changes the user name for the specified user.
change-name
air system user change-name old-username new-username
old-username Valid existing user name.
new-username New user name for this user.
Usage information. A name is a set of alphanumeric characters.

Spaces are allowed, but you must use quotes on the command line
around multi-word user names.
Other attributes of the user account, including password and
permissions, are not modified, nor is object ownership.
Note that since the search index entries may contain the old user name,
you should rebuild the search index after executing this command.

air system user Specifies a new clear password for the user.
change-password
air system user change-password user-name ⇒
[-clear-password clear-password | -none]
-clear-password Optional. Password that will be encrypted and

clear-password set for this user.
-none Optional. User does not require a password.
Usage information If neither -clear-password or -none is specified,

then the user must specify a password at the command prompt. The
password will not be displayed on the screen and will be encrypted.
air system user create Creates an account for the specified user.
air system user create ⇒
user-name ⇒
[-dry-run] ⇒
[-uid uid-number] ⇒
[ -group group-name] ⇒
[-clear-password clear-password] ⇒
[-crypted-password crypted-password]
-dry-run Optional. Displays an analysis of what the

effect of running this command will be
without actually running the command.
-uid uid-number Optional. Integer. Grants the specified user

ID. If not specified, the system picks a unique
integer for the uid.
-group group-name Optional. Existing group. Adds user to this

group. You may specify this clause more than
once. If the group does not exist, a warning is
issued, but the account is created.
-clear-password Optional. Password. Specify only if you do

clear-password not specify -crypted-password. The
password will be encrypted and set for this
user. If not specified, password is set to ‘*’.
-crypted-password Optional. Encrypted password. Specify only

crypted-password if you do not specify -clear-password.

air system Group
Usage information You must have administrator privileges to create

a user account.
If the uid is in use, an error occurs.
We recommend that you specify the uid if you want the EME uid to
match the Unix uid. Otherwise, let the EME assign the uid.
If you have access to the contents of the passwd file on Unix, it may be
possible to create EME user accounts with the same passwords as they
have for their Unix accounts. It is useful to specify encrypted passwords
in a scripting environment when you are creating a large number of
Unix users. To accomplish this, supply the -crypted-password option.
The encryption method must match. The current method is 56-bit DES
one-way encryption.
You can create a password using either -clear-password or
-crypted-password, but not both.
If no password is specified, then the user cannot log in.
air system user Disables the account of the specified user.

disable
air system user disable user-name
Example To disable the active user account of JaneDoe, type:

air system user disable ‘JaneDoe’
air system user enable Enables the disabled account of the specified user.
air system user enable user-name
Example To enable the disabled user account of JaneDoe, type:

air system user enable ‘JaneDoe’

air system user show Displays information about the account of a given user or of all users.
air system user show {user-name | -all}
user-name | -all Choose one of the following:

• user-name is a valid user name. If specified,
the output is for this EME user only.
• -all means the output is for all EME users.
Usage information The output includes the user’s name, uid,

password, disabled status (yes for disabled, no for enabled), and group
memberships (not currently implemented). If the user has a password, it
is presented in encrypted format; otherwise * means “no password” and
NONE means “no password required.”
Here is sample output for all users produced by issuing:
air system user show -all
name uid password disabled groups
JaneDoe 10016 * yes -
JimAnchower 10015 * no -
JohnDeer 10013 * no -
JoeBlue 10014 NONE no -
NoPwdUser 10012 * no -
MitziKatz 10017 gtQU30xEuK. no -

air web-interface Group

The air web-interface group of commands administers settings for the
main page and other aspects of the business metadata Web user
interface.
air web-interface clear Deletes all or some of the configuration settings of the business
metadata Web user interface for the specified group of users.
air web-interface clear group {-all | setting...}
group Valid group name.
-all | setting... Choose one of the following:

• -all clears all configuration variable settings.
• setting is the name of one or more configuration
variables.
Usage information For the names and a brief description of

configuration variables, see Setting Configuration Variables for the
Web Interface on page 83. To see the current value of one or more
configuration variables, run air web-interface show (page 194).
world is a build-in group to which all users belong. To see the names of
your groups, run air system group show (page 186).
Example To remove the value of the variable that controls the

centered footer text for the world group, type:
air web-interface clear world \
client_footer_center_html
This action resets the value to that of the default Web user interface,
Sample Business Metadata. The default Web user interface is described
in Using the Default User Interface to Build Your Own on page 92.
air web-interface Displays descriptions of some or all of the configuration variables for
describe the business metadata Web user interface.
air web-interface describe -w {-all | setting...}
-w Displays descriptions of additional configuration

variables for expert (or wizard) users.


• -all displays descriptions of all configuration
variables, except those for expert users.
• setting... is the name of one or more
Example To see a description of the client_support_email_address

configuration variable, you would type:
air web-interface describe \
client_support_email_address
The output looks like this:
Setting Description
client_support_email_address Specifies the email address for the

Customer Support hyperlink that
appears in the footer. You should
replace the default with the correct
value for your company.
For the names, descriptions, syntax, and default values of configuration

variables, see Setting Configuration Variables for the Web Interface on
page 83.
air web-interface set Sets a configuration variable for a specific aspect of the business
metadata Web user interface for the specified group of users.
air web-interface set group setting value
setting Name of a configuration variable.
value Value of setting.
Usage information For the names, descriptions, syntax, and default

values of the configuration variables, see Setting Configuration
Variables for the Web Interface on page 83. To see a list and brief
description of the configuration variables, run:
air web-interface describe -all
To see the names of your groups, run air system group show (page
186). The world group is a built-in group to which all users belong.
If you do not set a value for a given configuration variable, it takes the
value set in the default Web user interface. For information on creating
groups, see Setting Up User Groups on page 126. The default Web user

interface is described in Using the Default User Interface to Build Your

Own on page 92.
Example To set the value of searchable_categories for the world

group to Database, Steward Group, and Column, type:
air web-interface set world searchable_categories \
[‘Database’, ‘Steward Group’, ‘Column’]
searchable_categories controls which categories users can search. The
category names appear in the navigation bar.
air web-interface Sets the order of groups that are searched for variables and values in
set-order order to build the Web user interface for a particular group.
air web-interface set-order group1 group2 ...
.
group1 Valid group name. First group searched by the Web
user interface for variables and their values.
group2... Valid group name. Specify one or more groups to be

searched in sequence after group1. Specify the world
group last.
Usage information For more information about setting group order,

see Set the Group Order on page 92.
Always specify the world group last. To see the names of your other
groups, run air system group show (page 186).
To check the current group order, run air web-interface show-order
(page 194).
Example To set the order of four groups:

air web-interface set-order Exec Dev Test \
Admin world

air web-interface show Displays the current values of some or all of the configuration variables
of the business metadata Web user interface for the specified group.
air web-interface show -w group {-all | setting...}
-w Displays values of additional configuration variables

for expert users.

• -all means all configuration variables.
• setting... is the name of one or more
Usage information For more information about setting group order,

see Set the Group Order on page 92.
air web-interface Displays the current order of groups, as set by air web-interface
show-order set-order (page 193).
air web-interface show-order
Usage information The world group should appear at the end of the
list, as in:
cats
dogs
mammals
world

B>
Load and Unload
components
Topics Covered You will learn about the following components:

• Load Annotation Values (page 196)
• Load Category (page 199)
• Load File Dataset (page 203)
• Load Mimeobj (page 206)
• Load Table Dataset (page 209)
• Load Type (page 212)
• Remove Objects and Annotations (page 215)
• Unload Category (page 219)
Related Manual If you need information about other Ab Initio components, see the
Component Reference.
Folder to Access GDE To locate the GDE components described in this appendix, expand the
Components top-level folder $AB_HOME/connectors in the GDE’s Component
Organizer, then the EME subfolder.

Load Annotation Values 8>
Components A - Z
Load Annotation Values
Load Annotation Values attaches annotation values to objects in an

EME datastore, and validates the annotation for the object to which it is
to be attached. The component can either create a link to an existing
object in the EME, store a new MIME object and create a link to it, or
set a value on an existing object.
Related Topics • Load Category (page 199)

• Load Annotation Values Command-line Syntax in the GDE Help
Parameters
EME Datastore (URL, required)

Specifies the EME datastore to load. You can set this parameter to
$AB_AIR_ROOT if you want to load the EME specified in the EME
Datastore Settings dialog in the GDE.
commit_interval (integer, optional)

Specifies the number of records to process before committing the results
to the datastore. Valid values are non-negative integers. A value of 0
(the default) instructs the component to process all records before
committing.
This parameter allows you to make incremental changes to the
datastore. In addition, the component retries the operation in the event
of a concurrency conflict. This minimizes the risk of an unsuccessful
load operation.
reject-threshold (choice, required)

The component’s tolerance for reject events.
See Working with Components, Overview, About the reject-threshold
Parameter for details.

ramp (real, required)

Rate of toleration of reject events in the number of records processed.
When the reject-threshold parameter is set to Use ramp/limit, the
component uses the values of the ramp and limit parameters in a
formula to determine the component’s tolerance for reject events.
Default is 0.0.
See Working with Components, Overview, About the ramp and limit
Parameters for details.
limit (integer, required)

A number representing reject events.
Default is 0.
logging (boolean, optional)

Specifies whether or not you want certain component events logged.
See Working with Components, Overview, About the logging Parameter
for details.
log_input (choice, optional)

Indicates how often you want the component to send an input record to
its log port. The logging parameter must be set to True for this
parameter to be available.
For example, if you select 100, the component sends every 100th input
record to its log port. For more information, see Working with
Components, Overview, About the logging Parameter.
log_reject (choice, optional)

Indicates how often you want the component to send a reject record to
For example, if you select 100, the component sends every 100th reject
Input Record Format The input record format for Load Annotation Values is fixed:

record
string("\0") project = NULL("");
string("\0") url = NULL(""); // url for object to be annotated
string("\0") rule; // name (rule) for the annotation
string("\0") annotation_url = NULL("");
string("\0") value = NULL("");
string("\0") mime_type = NULL("");
string("\0") comment = NULL("");
end
It is found in $AB_HOME/connectors/dml/annotation.dml.
project If this is specified, the datastore path for the object is

assumed to be project-relative; otherwise it is
assumed to be absolute.
url The datastore path for the object to which the

annotation is to be attached.
rule The name of the annotation rule for the annotation.
annotation_url The path to the annotation rule in the EME.

If the rule is of type reference, the EME path is
required. If the rule is of type value or choice, this
path is not required.
If a project is specified, this path is interpreted as
project-relative; if this lookup fails, the path is then
interpreted as an absolute path.
value Value of the annotation.

If the rule is of type value or choice, this field is
required. If the rule is of type reference, this field is
used as the value for a MIME object whose location
is given by the annotation_url field, and whose
mime type is given by the mime_type field.
mime_type If neither the value nor the annotation_url fields

are NULL, a MIME object for the contents of the
value field is created. The value specified by
mime_type is used as the type, and is attached to the
datastore MIME object. Frequently used MIME
types are: text/plain and text/html, but other MIME
types can be used. The software does not limit or
check the validity of the MIME type string.

8 >c Load Category
Components A - Z
Load Category
Load Category stores annotation values in EME datastores for objects

that are members of a given category. This allows you to perform bulk
edits on annotation values and then save your changes in a datastore.
Related Topics • Load Annotation Values (page 196)

• Load Category Command-line Syntax in the GDE Help
Parameters
root (string, required)

EME datastore into which you want to load the category. Default is
$AB_AIR_ROOT.
category (string, required)

Category whose annotation values you want to load. Default is “”.

committing. This parameter allows you to make incremental changes to
the datastore. In addition, the component retries the operation in the
event of a concurrency conflict. This minimizes the risk of an
unsuccessful load operation.
no_inherit (boolean, required)

Does not load the annotation rules of the category’s parent category.
Default is False.
arule (literal, optional)

One or more annotation rules to load. Default is “”, which means all
rules are loaded.

Load Category


Default is 0.0. See Working with Components, Overview, About the
ramp and limit Parameters for details.

Default is 0. See Working with Components, Overview, About the ramp
and limit Parameters for details.

for details.

parameter to be available. For example, if you select 100, the
component sends every 100th input record to its log port. For more
information, see Working with Components, Overview, About the
logging Parameter.


Load Category
About Loading Edited A common way to use Load Category is to first unload a category with
Objects Unload Category, then edit the values of user-defined annotation rules,
and finally store the updated objects in the same datastore with Load
Category. You can also use Load Category to migrate annotation values
from one EME datastore to another.
You use Load Category when you want to edit values of user-defined
annotation rules. Except for the built-in annotation rules listed below,
you cannot use Load Category to populate built-in annotation rules.
Built-in annotation rules are not editable except for the following:
• comment
• description
• display_name
• mime_type
• _value
When you are editing annotation values, the object you are editing must
exist unless it is a MIME object. If it is a MIME object, and it does not
yet exist in a datastore, Load Category creates it in the datastore and
populates its values.
If the object you are editing is a MIME object that does not yet exist, the
following rules apply:
• The directory where you are trying to create the MIME object must
already be specified as a member location for the category.
• You must populate both the path and the _value annotation rules
for the MIME object that you are creating.
Load Category can populate annotation values that are subrecords. If the
subrecord does not yet exist, Load Category can create it only if each
subrecord field contains a MIME object. If the subrecord does not yet
exist, and it contains any other kind of field, Load Category rejects that
input record.
Load Category can populate an annotation value that refers to an
annotation value in another category. That is, it can update an
annotation rule that is a reference rule.

Load Category
Specifying Annotation Based on the parameters you specify, Load Category automatically
Values to Load generates the input record format. Load Category produces the same
output as the air category unload command with the -dml option. For
an example of the record format generated, see Displaying Record
Formats in Chapter 6 of the Enterprise Meta>Environment Guide to
Managing Enterprise Metadata.
Use the arule parameter to specify the annotation rules whose values
you want to load. This allows you to load only the particular annotation
values you choose, rather than the entire object. Alternatively, if you
want to load almost all annotation values except for a few, you can
modify the DML record format that Load Category generates. Simply
remove the definitions for the annotation value you do not want to load.

8> Load File Dataset
Components A - Z
Load File Dataset
Load File Dataset creates a file dataset in an EME datastore, and

attaches its record format.
Related Topics • Load File Dataset Command-line Syntax in the GDE Help
• Load Table Dataset (page 203)
Parameters

Specifies the EME datastore to load. You can set this to $AB_AIR_ROOT
if you want to load the EME specified in the EME Datastore Settings
dialog in the GDE.

committing.
load operation.


Load File Dataset

Default is 0.0.

Default is 0.

for details.



Load File Dataset
Input Record Format The input record format for Load File Dataset is fixed:
record
string("\0") project;
string("\0") dataset_url; // project relative url for file dataset
string("\0") dml_string = NULL("");
string("\0") dml_url = NULL("");
end;
It is found in $AB_HOME/connectors/dml/file_dataset.dml.
project The datastore path for the project in which the file
dataset will be defined. Required.
dataset_url The project-relative path for the dataset to be

defined.
Typical values are: $DAT/my_dataset or
../dat/my_dataset.
Project relative paths are always specified relative to
the run subdirectory of the project, as shown in the
".." of ../dat/my_dataset.
dml_string A string containing the record definition (DML

type) for the dataset.
The context for the type is assumed to be the project.
Either dml_string or dml_url (or both) must be
provided. Only one of the fields can be NULL.
dml_url The datastore path for the dataset’s record format.

By default this path is interpreted relative to the
project specified by project; if this fails, the path is
then interpreted as an absolute path.
If neither this field nor the dml_string field are
NULL, a new type object is defined at the location
specified and used as the type of the newly defined
dataset. Typical project relative paths would be:
$DML/my_type or ../dml/my_type.

Load Mimeobj 8>
Components A - Z
Load Mimeobj
Load Mimeobj creates a MIME object in an EME datastore with the

specified MIME type.
Related Topics • Load Type (page 206)

• Load Mimeobj Command-line Syntax in the GDE Help
Parameters

dialog in the GDE.

committing.
load operation.


Load Mimeobj

Default is 0.0.

Default is 0.

for details.


Input Record Format The input record format for Load Mimeobj is fixed:

Load Mimeobj
record
string("\0") url; //URL for the object to be annotated
string("\0") value; //value of the mime object
string("\0") mime_type = NULL(""); //MIME type default = text/plain
end
It is found in $AB_HOME/connectors/dml/mimeobj.dml.
project If this is specified, the url is assumed to be

project-relative; otherwise it is interpreted as an
absolute path.
url Datastore URL for the object being created or

updated.
value Value of the contents of the MIME object being

created.
mime_type Specifies the type used in creating the object. The

string specified is stored as the MIME type attached
to the datastore MIME object.
Frequently used MIME types are: text/plain and
text/html, but other mime types can be used.
The software does not limit or check the validity of
the MIME type string. If no value is given, the
default is text/plain.

8> Load Table Dataset
Components A - Z
Load Table Dataset
Load Table Dataset creates a table dataset in an EME datastore and

attaches its record format.
Related Topics • Load File Dataset (page 203)

• Load Table Dataset Command-line Syntax in the GDE Help
Parameters

dialog in the GDE.


Default is 0.0.

Load Table Dataset

Default is 0.

for details.



Load Table Dataset
Input Record Format The input record format for Load Table Dataset is fixed:
record
string("\0") project;
string("\0") database_name;
string("\0") table_name;
string("\0") dml_string = NULL("");
string("\0") dml_url = NULL("");
end;
It is found in $AB_HOME/connectors/dml/table_dataset.dml.
project Datastore path for the project in which the table

dataset will be defined. Required.
database_name Datastore path for the database configuration file

for the database for this table. The .dbc file must
have been previously stored in the EME. Required.
table_name Name of the table dataset to be defined. The path

for the table dataset is constructed as follows:
project-name/tables/databasename-from-.dbc file
/table_name. Required.
dml_string A string containing the record definition (DML

type) for the dataset. The context for the type is
assumed to be the project. Either dml_string or
dml_url (or both) must be provided. Both fields
cannot be NULL.
dml_url Datastore path for the dataset’s record format. This

path is looked up by default relative to the project
specified by the project field. If that lookup fails,
the path is looked up as an absolute path. If both
this field and the dml_string field are not NULL, a
new type object is defined at the location specified
and used as the type of the newly defined dataset.
Typical project relative paths might be
$DML/my_type or ../dml/my_type.

Load Type 8>
Components A - Z
Load Type
Load Type creates a record format (DML type) object in an EME

datastore.
Related Topics • Load File Dataset (page 203)

• Load Type Command-line Syntax in the GDE Help
Parameters

dialog in the GDE.

committing.
load operation.


Load Type

Default is 0.0.

Default is 0.

for details.



Load Type
Input Record Format The input record format for Load Type is fixed.
record
string("\0") dml_string;
string("\0") dml_url;
end;
It is found in $AB_HOME/connectors/dml/type.dml.
project Datastore path for the project in which the type will
be defined. If the project is not defined, the path for
the type is assumed to be absolute.
dml_string String containing the DML type (record definition).

The context for the type is assumed to be the project
if the project field is not NULL. Otherwise, the
global context is used. Required.
dml_url Datastore path for the type object to be defined.

This path is looked up relative to the project
specified by the project field if the project field is
not NULL. Typical project-relative paths might be
$DML/my_type or ../dml/my_type. Required.

8> Remove Objects and Annotations
Components A - Z
Remove Objects and Annotations
Remove Objects and Annotations allows you to delete objects and

annotation values from an EME datastore.
Related Topics • Load Annotation Values (page 215)

• Load Category (page 199)
• Remove Objects and Annotations Command-line Syntax in the
GDE Help
Parameters

Specifies the EME datastore from which you want to remove objects
and annotation values. You can set this parameter to $AB_AIR_ROOT if
you want to remove values from the datastore that is specified in the
EME Datastore Settings dialog in the GDE.

committing.
load operation.



Default is 0.0.

Default is 0.
logging (Boolean, optional)

for details.



Description of Input The input record format for Remove Objects and Annotations is fixed:
Record for Remove record
Objects and string("\0") project = NULL("");
Annotations string("\0") url = NULL(""); // url for object
string("\0") rule; // annotation rule name
string("\0") value = NULL("");
end
The record format is in $AB_HOME/connectors/dml/annotation.dml.
project If the record specifies a project, the datastore path

(URL) for the object is assumed to be relative to
the project. If the record does not specify a project,
the datastore path must be absolute.
url The datastore path for the object you want to

remove or for the object that contains the
annotation value you want to remove.
rule The name of the annotation rule for the annotation

value you want to remove. If you do not specify a
value for rule, the component removes the entire
object.
value Annotation value you want to remove. If you do

not specify a value, the component removes the
annotation value regardless of what that value is.
If you specify a value, the component removes
only those annotation values that match the value
you specify.
Specifying the Objects How you define the contents of the input record for Remove Objects
and Values to Remove and Annotations determines whether you delete entire objects or
particular annotation values. For example, you can use this component
to delete
• All data stewards in a particular steward group
• Just the home phone number for each data steward
• All datasets from a particular project
The following table shows what to specify according to what you want
to delete.

To Delete This Specify These Input Fields
Object In the url field, specify the URL for the object you want to delete.
If you want to specify a relative URL, in the project field, specify the
project that contains the object you want to delete.
Do not specify values for the rule and value fields.
Any annotation value for a In the url field, specify the URL for the object that contains the
particular annotation rule annotation value you want to delete.
In the rule field, specify the annotation rule for the value you want to
delete.
Do not specify a value in the value field.
project that contains the object that contains the annotation value you
want to delete.
The component replaces a removed value with an empty string or
NULL according to the value type. If an annotation rule has more than
one value, the component removes all values.
A particular value for a In the url field, specify the URL for the object that contains the
particular annotation rule annotation value you want to delete.
In the rule field, specify the annotation rule for the value you want to
delete.
In the value field, specify the particular value you want to delete.
project that contains the object that contains the annotation value you
want to delete.
If the specified annotation rule has a single value that matches the
specified value, the component replaces the value with an empty string
or NULL according to the value type. If the specified annotation rule
has one or more values that do not match the specified value, those
values remain in the datastore.

8> Unload Category
Components A - Z
Unload Category
Unload Category unloads the annotation rules of all objects that are
members of a given category.
Related Topics • Load Category (page 199)

• Unload Category Command-line Syntax in the GDE Help
Parameters
root (string, required)

Source EME datastore. Default is $AB_AIR_ROOT.
version (string, optional)

EME version or tag. Default is “”.
category (string, required)

Category whose annotation rules you want to unload. Default is “”.
no_inherit (boolean, required)

Does not unload the annotation rules of the category’s parent category.
Default is False.
path (literal, optional)

Datastore path of directory. Unloads rules of objects that reside at or
below this location. Default is “/”.
arule (literal, optional)

One or more annotation rules to unload. Default is “”, which means all
rules are unloaded.

Unload Category
oid_as_path (boolean, optional)

When set to True, Unload Category replaces the value of the oid
annotation rule with the value of the path annotation rule. This
parameter is useful when you want to eventually load the category into a
different datastore.
This parameter works on objects you explicitly unload, but not on
subrecords. If the annotation rule to be unloaded is a reference rule, the
parameter works on the object in the target category.
Record Format There is no input record format.

The output record format for Unload Category is automatically
generated based on the parameters you specify. This component
produces the same output as the air category unload command with the
-dml option. For an example of the record format generated, see
Displaying Record Formats in Chapter 6 of the Enterprise
Meta>Environment Guide to Managing Enterprise Metadata.

C>
Base and Extended
Schemas

• Base Schema (page 222) and Its Annotation Rules (page 226)
• Extended Schema (page 234) and Its Annotation Rules (page 235)

Appendix C> Base and Extended Schemas
Base Categories and Rules

The base schema is the built-in schema provided with the EME. It is
shown in the following figure as a relational model. The metadata is
organized into 19 categories. Each box denotes a category.
mimeobj parameter
job graph project database

common
include
global
phase
package type
dataset
flow_summary flow transform
input
output vertex uses dataset(s) as lookup
vertex may be a dataset
dataelement
vertex
vertex_summary
output input
Key:
one-to-many foreign-key relationship
many-to-many foreign-key relationship

Built-in Categories by The preceding figure shows how the schema’s 19 built-in categories are
Group related to one another. To make it easier to understand the schema, we
have divided it into six groups:
• Data-manipulation, or application, categories
• Data-execution, or job-tracking, categories
• Data-description categories
• Metadata-extension category
• Project-related group of categories
• Dependency analysis group of categories
Note that there is some overlap in the figures, as some categories have
foreign-key relationships with categories in other groups. For
completeness, the figures include cross-references. Also, the graph
category appears in both the data-manipulation and data-execution
groups.
Data-manipulation Group The data-manipulation group consists of categories that relate to an

of Categories application: graph, vertex, and flow.
graph
flow
input
output
vertex

Data-execution Group of The data-execution group consists of the categories that relate to
Categories running an application.
job graph
phase
vertex_summary flow
flow_summary
Data-description Group The categories in the data-description group describe your data
of Categories structures.
database
dataset
dataelement
Metadata-extension The metadata-extension group has only one category, mimeobj. This is
Category the base category for all new user-defined categories that cannot be
derived from the built-in categories.
mimeobj

Project-related Group of The project-related group of categories describe the technical metadata
Categories within the EME.
graph parameter
database
project
common
include global
package type
dataset
transform
vertex
Dependency Analysis The dependency analysis group of categories describes data

Group of Categories dependencies.
dataelement
vertex
output input

Description of Base You cannot modify or delete the annotation rules of the base schema.
Categories and Rules Note that the names are case-sensitive.
Common Rules These annotation rules are common to all categories in base schema.
Annotation rule Description
oid EME object ID in string format (@x.y.z), unique ID

for each object.
name File name of the object, for example, graph1.mp.
comment Long comment associated with the object. Appears

primarily in lists of objects in Web user interface.
description Brief description associated with the object.
display_name Alias for the object, used to refer to the object in the
Web user interface. Default is value of name.
created_by EME user who created the original version of this

object.
creation_date Date and time that the original version of this object
was created. The date and time format can be
controlled by configuration variables (page 279).
modified_by EME user who created the current version of this

object.
modification_date Date and time that the current version was last
modified. The date and time format can be
categoryOID Unique ID in string format (@x.y.z). Refers to the

category of which object is a member.
path Full datastore path to the object, for example,

/Projects/warehouse/mp/graph1.mp.
database Category Rules Rules for the database (a mime object with a MIME type of
“text/x-abinitio-db-dbc”). See also Common Rules (page 226).
db_name Name of the database (from the .dbc file).

dbms Type of the database — such as Oracle, Informix,

or DB2 (from the .dbc file).
dbms_version Version of the database (from the .dbc file).
projectOID Project in which the .dbc file is located.
dataelement Category Dataelement field in a file or table. See also Common Rules (page 226).
Rules For more information about individual data elements, see the Data
Manipulation Language Reference.
datasetOID Dataset to which this element belongs.
dmltype Base DML type (string, integer, decimal).
dmlcode Character set used (ASCII, EBCDIC, packed).
dmlendian Endianness (big or little, or default).
dmlsigned Signed or unsigned.
dmldelimiter Delimiter for variable-length field.
is_nullable Indicates whether NULLs are allowed (1) or not

allowed (0) in this field. Use the configuration
variable AB_ARULE_BOOL_FORMAT to change the
default values (page 279).
length Length for a fixed-length field.
veclen Length of the vector.
scale Number of decimal places.
format Date/datetime format. The format can be controlled

by configuration variables (page 279).
lengthtype DML length definition for variable-length strings.

dataset Category Rules Rules for a dataset, the logical representation of a file or table. See also
Common Rules (page 226).
databaseOID If this dataset is a table, then this rule refers to the

database to which it belongs.
class Class of the dataset — file or table.
projectOID Project in which the dataset is located.
flow Category Rules Rules for the dataflow between two vertices of an Ab Initio graph. See
also Common Rules (page 226).
graphOID Refers to the outermost graph, never to a subgraph.
from_vertexOID Vertex that is the source of this flow.
to_vertexOID Vertex that is the destination of this flow.
method Type of the flow (soc, pipe, file).
stages Indicates whether two-stage routing is enabled (1)

or disabled (0).
deadlock_buffer Indicates whether deadlock buffering is enabled (1)

or disabled (0). Use AB_ARULE_BOOL_FORMAT
(page 279) to change the default values.
flow_summary Category Rules for the tracking information for a single flow in a job. See also
Rules Common Rules (page 226).
flowOID Most recent version of the flow that was run.
phaseOID Reference to the phase in which this flow appeared.
records Number of records processed on this flow.
bytes Number of bytes that were processed on this flow.
versionedFlowOID Historical version of the flow that was run.

global Category Rules Rules for global variables defined as part of a package. See also
packageOID Package in which this global variable is defined.
initial Initial value for this global variable.
definition Text definition of this global variable.
graph Category Rules Rules for an Ab Initio graph. See also Common Rules (page 226).
author Name of the author of this graph.
version Version of this graph.
projectOID Project in which the graph is located.
input Category Rules Rules for the uses of a dataelement as a source in a graph. See also
dataelementOID Data element used as input.
resultOID List of outputs that use this input to calculate their

values.
vertexOID Component in which the input is used.
job Category Rules Rules for the execution of a graph. See also Common Rules (page 226).
graphOID Most recent version of the graph that was run.
exit_status Exit code that ended the job. Code can be: starting,
running, paused, finished, error, unknown.
starttime Time the job began. The format can be controlled by

configuration variables (page 279).
endtime Time the job ended. The format can be controlled by

configuration variables (page 279).

versionedGraphOID Historical version of the graph that was run.
mimeobj Category Rules Generic object from which many user extensions to the schema are
derived. A MIME object can store the contents of arbitrary files. See the
Guide to Managing Technical Metadata for more information about
MIME types. See also Common Rules (page 226).
_value Contents of the MIME object.
output Category Rules Rules for uses of a dataelement as a target in a graph. See also Common
Rules (page 226).
dataelementOID Dataelement used in the output.
vertexOID Component in which the output is used.
package Category Rules Rules for the record format (.dml) and transform (.xfr) files as part of a
package in the EME. See also Common Rules (page 226).
projectOID Project in which this package is located.
definition Text contents of the package.
includePackageOID List of packages included in this package.
parameter Category Rules for the project parameters defined in the EME. See also Common
Rules Rules (page 226).
projectOID Project with which this parameter is associated.
_value Uninterpreted value of the parameter.
interpretation Interpretation method (for example, $ substitution or

constant) to use when evaluating the parameter’s
value.

phase Category Rules Rules for a single phase within a job. See also Common Rules (page
226).
jobOID Job in which this phase occurred.
graphphase Graph phase number.
starttime Time that this phase started. The format can be

endtime Time that this phase ended. The format can be

outcome Outcome of the job. Outcome code can be: starting,

project Category Rules Rules for the projects defined in the EME. See also Common Rules
(page 226).
commonProjectOID List of projects that are included as common project

in this project.
transform Category Rules for transforms defined as part of a package. See also Common
Rules Rules (page 226).
packageOID Package in which this transform is defined.
definition Text definition of this transform.
type Category Rules Rules for types defined as part of a package. See also Common Rules
(page 226).
packageOID Package in which this type is defined.
definition Text definition of this type.

vertex Category Rules Rules for a vertex (component) within an Ab Initio graph. Note that
subgraphs are not represented. To indicate subgraphs, the denotation “.”
is used, effectively flattening the graph, for example,
crm.prepare-accounts, where prepare-accounts is the name of the
subgraph. See also Common Rules (page 226).
graphOID Refers to the outermost containing graph, never to a

subgraph.
author Name of the author of this vertex.
version Version of this vertex.
datasetOID Dataset used by this vertex.
disabled Indicates whether the component is disabled (1) or

enabled (0). The format can be controlled by
AB_ARULE_BOOL_FORMAT (page 279).
opname Name of the underlying component.
location For file components, the URL of the file. For table
components, the name of the table. Else, blank.
transformPackagesUsed Multivalued annotation rule that points to the

OID transforms for this vertex. This includes both
embedded and file-based packages.
Note that if you select all packages from the EME (that
is, all members of the Package category), you will not
get the embedded packages listed.
lookupsUsedOID Multivalued annotation rule that points to the lookup

datasets referenced by the transforms for this vertex.
typepackagesUsedOID Multivalued annotation rule that points to the record

formats referenced by this vertex. This includes both
embedded and file-based packages.
Note that if you select all packages from the EME (that
is, all members of the Package category), you will not
get the embedded packages listed.
select_expression Select expression, if any, for this vertex.

vertex_summary Rules for the tracking information for a single vertex in a job. See also
Category Rules Common Rules (page 226).
phaseOID Phase in which this component ran.
vertexOID Most recent version of the vertex that was run.
cpu_seconds Number of CPU seconds used by this

component.
mem_size Amount of memory used (not supported).
mem_rss Resident memory size of this component (not

supported).
frac_cpu Fraction of the total CPU used by this

component (not supported).
frac_mem Fraction of the total memory used by this

component (not supported).
state Current state of component can be: starting,

num_partitions Number of partitions in this vertex.
versionedVertexOID Historical version of the vertex that was run.

Extended Categories and Rules

The extended schema comprises two groups: one logical, the other
physical. These groups are shown below as relational models.
Logical group The logical group consists of seven categories. dataelement is in the
base schema. Each box denotes a single category.
dataelement Logical Entity
is a
Physical Element Logical Element
Validation Spec
Valid Range Item Invalid Value Item Valid Value Item
Physical group The physical group consists of five categories. Physical Element
appears in both logical and physical groups; dataset and dataelement are
in the base schema.
dataset dataelement Physical Element
is a
Key
foreign
TableView Index Column

Description of This section describes all the annotation rules defined on the extended
Extended Categories categories in standard-schema.ksh. You cannot modify or delete these
and Rules rules, but you can add rules to these categories and derive new
categories from them. Note that the names are case-sensitive.
Column Category Rules Extends the Physical Element category, which extends the dataelement
category (page 234) to represent a database table.
DataType Database DDL.
DataLength Length of the data in the database.
Nullable Indicates whether this column can contain nulls.
DataPrecision Length of a decimal number in the database.
DataScale Number of decimal places.
Index Category Rules Represents an index on a table. Extends the base schema’s mimeobj
category (page 230).
Owner Database owner of this object.
DatasetID Dataset to which this index applies.
DataelementOID List of data elements that make up this index.
Invalid Value Item An explicit invalid value. Extends the base schema’s mimeobj category
Category Rules (page 230). You should not define locations for members of this
category. For information about members, see page 25 and page 26.
Value Invalid value.

Key Category Rules Represents a key on a table. Extends the base schema’s mimeobj
category (page 230). See also Common Rules (page 226).
. Annotation rule Description
KeyType Type of key. Choices are P for primary key, R

for foreign key (or referential restraint), and U
for unique key.
DataelementOID List of data elements that make up this key.
ForeignKeyOID If this is a foreign key, a reference to the

primary key to which this foreign key refers.
DatasetID Dataset to which this key applies.
Logical Element Base for logical, or business, attributes. Extends the base schema’s
Category Rules mimeobj category (page 230).
LogicalElementOID Logical Entity to which this element belongs.
ValidationSpec Optional reference to a member (instance) of

Validation Spec that describes the valid values
for this field.
Logical Entity Category Grouping of Logical Elements. Extends the base schema’s mimeobj
Rules category (page 234).
Physical Element Extends the base schema’s dataelement category (page 234) to represent
Category Rules fields and columns.
LogicalElementOID Optional reference to a member (instance) of

Logical Element that describes the “logical”
contents of this field.
ValidationSpec Optional reference to a member (instance) of

Validation Spec that describes the valid values
for this field.

TableView Category Extends the base schema’s dataset category (page 228) to represent a
Rules database table or view.
Owner Database owner of this table.
TableOrView Flag that indicates whether object is a table (T)

or a view (V).
Valid Range Item Range of valid values. Extends the base schema’s mimeobj category
Minimum First valid value for this range. Blank if the

range extends to all values equal to or less than
the maximum.
Maximum Last valid value in this range. Blank if the

range extends to all values equal to or greater
than the mimimum.
Valid Value Item An explicit valid value. Extends the base schema’s mimeobj category
Value Valid value.
Validation Spec Category Definition of the valid values for a field or logical element. Extends the
Rules base schema’s mimeobj category (page 230). You should not define
locations for members of this category. For information about members,
see page 25 and page 26.
ValidValues Set of zero or more explicit valid values.
ValidRanges Set of zero or more ranges of valid values.
InvalidValues Set of zero or more explicit invalid values.

D>
Loading Metadata with
Connectors for
Prepackaged Applications
What Are Load Load Connectors are a suite of graphs, shipped with the Co>Operating
Connectors? System, that extract metadata from various prepackaged applications
and load that metadata into an EME datastore.
This section describes the structure of each connector and also provides
some guidelines on how to modify these graphs to meet specific needs.
All of the load connectors reside in a subdirectory of
$AB_HOME/connectors.

• General Information (page 240)
• Parameters of the Connectors (page 242)
• Structure of the Connectors (page 244)
• Connector for ERwin (page 247)
• Connector for Oracle Designer (page 250)
• Connector for DB2 (page 252)
• Connector for Oracle (page 254)
• Connector for Teradata (page 257)
• Connector for SQL Server (page 259)
• Connector for Sybase (page 261)
• Connector for Redbrick (page 263)
• Graph for Loading Files Created on a Physically Inaccessible
System (page 265)

Appendix D> Loading Metadata with Connectors for Prepackaged Applications
General Information
Where the Graphs and • All but one of the graphs reside in
Scripts Reside $AB_HOME/connectors/metadata-source. Their names are in the
form metadata_source_to_eme.mp, where metadata_source is
one of these:
• ERwin — ER1 diagram
• Oracle Designer — Oracle Designer repository
• DB2 — DB2 database catalog
• Oracle — Oracle database catalog
• Teradata —Teradata database catalog
• SQL Server — Microsoft SQL Server database
• Sybase — Sybase database
• Redbrick — Redbrick database
• The graph load_eme_from_files.mp resides in
$AB_HOME/connectors/EME/Load. It loads the files that were
generated from a database catalog into an EME datastore on
another physically disconnected system.
• Expanding the $AB_HOME/connectors folder in the GDE shows
a subdirectory for each load connector. From the subdirectories,
you can find the graph you need for a given metadata source. You
can open it by right-clicking its name and selecting the Edit item.
• Complementary shell scripts (metadata_source-to-eme.ksh) reside
in the same location as the graph. These graphs have been set up to
run without modification from the command line.
Host and EME All of the graphs default to the host settings for the EME. You should
Datastore Settings change to the host settings that connect to the server where your data
source is located.
Check the EME Datastore Settings dialog to make sure that it specifies
the datastore into which you want to load the metadata. Alternatively,
override the TARGET_EME_DATASTORE parameter (page 242) at
runtime.
Korn Shell is required Since these graphs use conditional components, they require a Korn
Shell (Unix, Windows NT, or mainframe) to run.

General Information
extend-schema.ksh The graphs are designed to populate the categories of the extended
schema (page 234) for a target EME project. The extended schema is
automatically installed by the sample EME. If you did not install the
sample EME, then you must run
$AB_HOME/connectors/EME/extend-schema.ksh to install it. The
script installs the extended schema’s categories, annotation rules, and
views and then builds the directory structure for your target project so
that the metadata loaded into these directories will be members of the
following four categories of the extended schema:
• TableView extends the dataset category. Its member objects will
reside in $TARGET_PROJECT/tables.
• Column extends the dataelement category. Its member objects will
reside in $TARGET_PROJECT/tables.
• Key represents a table’s keys. Its member objects will reside in
$TARGET_PROJECT/keys.
• Index represents a table’s indices. Its member objects will reside in
$TARGET_PROJECT/indexes.
Run this script only once for each project. The script assumes that:
• You have set the TARGET_PROJECT environment variable to a
project in an EME datastore.
• The project already exists.
An alternative to running a script, you may set the EXTEND_SCHEMA
parameter (page 242) when you run the graph on the command line.

Parameters of the Connectors

sectionGraph The connector graphs have been parameterized so that when run without
Parameters modification they will populate the various objects in the specified
target project. In addition to populating the above schema, the graph
also populates the dml subdirectory with the record formats for all of
the datasets discovered in the application.
There may be additional parameters for each metadata source that
describe how to connect to the source and which metadata to unload.
(See the individual graph descriptions for further details.)
The supplied parameters for all the graphs are:
Parameter Description
TARGET_EME_DATASTORE EME datastore to load. Default is

$AB_AIR_ROOT.
TARGET_PROJECT Project to load.
DBC_FILE Database configuration file that

specifies the database to which the
metadata applies.
WORKDIR Working directory for generated error

files.
EXTEND_SCHEMA Extends the schema for this EME

project. Default is False.
LOAD_TABLES Loads table datasets and .dml files into

the EME datastore. Default is True.
LOAD_COLUMNS Loads extended column information

into the EME datastore. Default is True.
LOAD_KEYS Loads table key information into the

EME datastore. Default is True.
LOAD_INDEXES Load table index information into the

EME datastore. Default is True.
LOAD Loads the resultant changes to the EME

datastore. Default is True.

Parameters of the Connectors
EXPORT_FILES Creates files to be loaded during a

subsequent load phase using the
load_eme_from_files.mp graph
(page 265). Default is True.
FILTER_TABLES Uses tables_to_migrate.dat to

determine which tables should be
loaded. Default is True.
OWNER Owner or base schema for the tables.

The meaning of OWNER depends on
the connector.
tables_to_migrate.dat The tables_to_migrate.dat dataset file resides in the $WORKDIR

Dataset directory, and contains four fields which drive the import process. If
FILTER_TABLES is set to False, this file does not need to exist.
Conversely, if the file does not exist, FILTER_TABLES has no effect.
Field Description
Databasename Physical name of the database. This is usually set

in the database.dbc file.
Owner Owner or base schema for the tables. The owner

varies for each connector and is described in the
appropriate section.
Tablename Name of the table and view, or the string "all" to

load all tables belonging to Owner.
Generic_table_name Oracle only. Generic name that can be used to

categorize all tables with names of the form
table_yyyy-mm-dd.
The record format of the tables_to_migrate.dat file is defined as:

record
string(" | ") database_name;
string(" | ") owner;
string(" | ") table_name;
string("\r\n") generic_table_name;
end;

Structure of the Connectors

Connector Graphs All of the graphs have the same basic structure. Each graph consists of
Consist of Subgraphs several subgraphs, each of which is controlled by a specific runtime
parameter (see sectionGraph Parameters on page 242):
• Initialize EME Datastore
• Prepare Tables and Views
• Prepare Column Information
• Prepare Keys
• Prepare Indexes
• Load to EME Datastore or Export Files
Note The Export Parameters component allows a standard connector

graph to be run as a subgraph. It has no effect when the graph is run
standalone.
The following figure shows the db2_to_eme.mp graph.

Structure of the Connectors
All EME load components have their reject and error ports connected to
output files. These files are all located in $WORKDIR. Their names are
in the format: load_object_type_rejects.dat and
load_object_type_errors.dat. All of these files should be empty upon
successful completion of the graph execution.
NOTE: All EME loads are set up to run in separate phases, as they
often depend on the loading of the underlying object before
loading the annotations.
Initialize EME Datastore Initialize EME Datastore runs the extend schema script,
subgraph extend-schema.ksh (conditional on EXTEND_SCHEMA), and sets up
database name lookup. This subgraph makes sure that the EME schema
is up-to-date and that the necessary project structure is in place. This
component is optional and may be disabled once the script has been run
once for a given project.
This subgraph then analyzes the database configuration file
($DBC_FILE) passed in to determine the database name, which is
stored in a temporary file for use as a lookup in later phases.
This subgraph is the same for all metadata sources.
Prepare Tables and Prepare Tables and Views extracts dataset and record-format
Views Subgraph information (conditional on $LOAD_TABLES) from the metadata
source and prepares it for loading into the EME datastore as table
datasets.
This subgraph also sets the View/Table flag and the Owner annotations
on the dataset object created.
Prepare Column Prepare Column Information extracts extended column information

Information Subgraph (conditional on $LOAD_COLUMNS) from the metadata source and
prepares it for loading as annotations on the corresponding dataset
columns in the EME datastore.
Prepare Keys Subgraph Prepare Keys extracts primary and foreign key information (conditional
on $LOAD_KEYS) from the metadata source and builds records for
creating key objects in $TARGET_PROJECT/keys and for annotating
these objects with the columns that make up the key and the dataset to
which this key applies.

Prepare Indexes Prepare Indexes extracts index information (conditional on

Subgraph $LOAD_INDEXES) from the metadata source, builds records for
creating index objects in $TARGET_PROJECT/indexes and for
annotating these objects with the columns that make up the index
(DataelementOID) and the dataset (DatasetID) to which this index
applies.
Load to EME Datastore Load to EME Datastore or Export Files does one of these:
or Export Files Subgraph
• It loads the dataset information, objects, and annotations into the
EME if the LOAD parameter is set to True.
• It creates export files for subsequent loading if the
EXPORT_FILES parameter is set to True.

Connector for ERwin
Connector for ERwin

Read these notes if you are using ERwin 3.5.2 or ERwin 4 as the
metadata source.
To use these connector graphs, you must have ERwin installed. A
runtime program is available for ERwin 3.5.2. See the installation
instructions on page 249. For ERwin 4 you must install the full
program.
Location of the Two connector graphs exist. If you have ERwin 3.5.2 installed, use
Graphs and the Shell $AB_HOME/connectors/ERwin/erwin_to_eme.mp. If ERwin 4 is
Scripts installed, use $AB_HOME/connectors/ERwin/erwin4_to_eme.mp.
Some functionality is available only with ERwin 4; these constraints are
noted in the text below. The corresponding shell scripts are
erwin_to_eme.ksh and erwin4_to_eme.ksh, respectively. These
connectors are available only on Windows.
Parameters This graph takes an additional parameter, ERWIN_FILE, which is the

ER1 diagram from which metadata is extracted.
ERwin 4 only The OWNER parameter is optional, since ERwin does

not use this concept. If present, OWNER is used to prefix all table
names, thereby permitting those tables to be matched to similarly named
tables arising from Oracle or other databases, where OWNER must be
present.
See also sectionGraph Parameters on page 242.
Models Stored in If the models are stored in ModelMart, then you need to modify all of
ModelMart the ERwin unload components to use the ModelMart interface.
Prepare Tables and The Prepare Tables and Views subgraph runs in two phases.
Views Subgraph
Phase One The first phase identifies all of the datasets defined in the
ERwin diagram ($ERWIN_FILE) and creates the corresponding
datasets in the tables directory of the project. The load operation is
accomplished by the Load Table Dataset component. In addition, the
ERwin-to-dml utility, with the -table-as-dml flag set, creates the record
format files (.dml files) and loads them into the dml directory of the
project. You may pass additional parameters (for example, -is-valid,
-is-null, and -fixed-length) to the ERwin-to-dml utility in order to
provide additional control over the DML generated. See ERwin-to-dml
help for more information.

Phase Two The second phase unloads table and entity information
from the ERwin diagram and uses the Is Derived flag on each entity to
determine whether it is a view or an authentic table. These flags are then
converted into annotation format ready for loading by the Load
Annotation Values component.
Note To join the entities back to their corresponding tables, the graphs
use the Twin property of the table, which references the entity name.
Prepare Column The Unload ERwin component of the Load Column Information
Information Subgraph subgraph extracts the column information from ERwin. The data is
passed through a Normalize component to generate the corresponding
annotation values to be loaded. A Normalize component handles the
decomposition of the data type into its constituent pieces and
subsequently outputs four values for a single input record. To populate
additional annotations, add cases for different ERwin properties to this
component.
Prepare Keys The data emerges from ERwin at the key-column level of detail; that is,
Subgraph there is one row for every column in every key. This information is
stored in the entity/attribute part of the model. The twin attribute is used
to obtain the physical table name, as opposed to the logical entity name.
(This is accomplished by the Join to set Table component.)
The data is then split into two streams. The first stream is rolled up to
create a single key object record for each key. This flow is then split
again to load the key objects into the datastore and to normalize into the
key specific annotations to be attached. The second stream is simply
reformatted to create the individual column annotations. These two
streams are finally merged before loading into the datastore.
ERwin 3.5.2 This subgraph extracts only primary key information in

ERwin 3.5.2.
Prepare Indexes The data comes out of ERwin at the index-column level of detail. The
Subgraph Scan component makes sure that the column and index names are set
appropriately on the last record of the index. The Rollup component
then pulls out the relevant index properties from the incoming data
stream into a single record.
The data is then split into two streams. The first stream is rolled up to
create a single index object record for each index. This flow is then split
again to load the index objects into the datastore and to normalize into
the index specific annotations to be attached. The second stream is
simply reformatted to create the individual column annotations. These
two streams are finally merged before loading into the datastore.

Connector for ERwin
Prepare Logical The Prepare Logical Elements subgraph is found only in the ERwin
Elements Subgraph connector. It builds records to be used in creating logical entities and
logical elements in the EME. Logical entities will be placed in
$TARGET_PROJECT/logical_entities/entity, and logical elements
will be placed in
$TARGET_PROJECT/logical_elements/entity/element. Table
columns are then updated with a link to the logical element.
Prepare Valid Values The Prepare Valid Values subgraph is found only in the ERwin
Subgraph connector. It creates Validation Spec records that are subsequently used
to annotate Columns. The Validation Spec contains Valid Values,
Invalid Values, and Value Ranges (minimum and maximum values), as
defined in the ERwin model.
tables_to_migrate.dat ERwin 4 only The database field of tables_to_migrate.dat should

Dataset be the name of the database taken from the .dbc file. The Owner field is
not used. The tables should be listed in uppercase letters. The fourth
column may be left empty.
How to Install the To install the ERwin 3.5.2 API, you need to do the following:
ERwin 3.5.2 API
1. Connect to the following:
http://ca.com/products/alm/erwin/companion_products/
download1.htm
2. Download the Link Objects API.
3. Unzip and install this file.
4. Run regsvr32 “c:\Program Files\PLATINUM\ModelMart
3.0\ERWMMAPI\er2api32.dll” (if you have installed in the default
location).

Connector for Oracle Designer

Read these notes if you are using an Oracle Designer repository as the
metadata source.
Location of the Graph The path to the connector graph is:

and the Shell Script $AB_HOME/connectors/OracleDesigner
/oracledesigner_to_eme.mp. The corresponding shell script is
oracledesigner_to_eme.ksh.
Parameters This graph takes two parameters in addition to those described in

sectionGraph Parameters on page 242.
• DESIGNER_DB is the database configuration file for the database
containing the Oracle Designer repository.
• OWNER is the repository owner of the schema objects to be
unloaded.
Read access You need read access to the tables and views mentioned herein.
Prepare Tables and First, all column information is pulled out of the CI_COLUMNS view
Views Subgraph and database-compatible DML record formats are created using a
Rollup component and the ddl_to_dml built-in function. These record
formats are associated with their tables in records used to create datasets
in the tables directory of the project. In addition, record format files
(.dml files) are created and will be loaded into the dml directory of the
project.
Next, table and view information are unloaded from the Oracle
Designer repository (views CI_TABLE_DEFINITIONS and
CI_VIEW_DEFINITIONS). This information is merged and passed
through a Normalize component, which effectively pivots the
table/view level information into multiple records. If you want to add
more annotations for tables and views, you should create them in this
component.
Prepare Column The column information is unloaded from the Oracle Designer
Information Subgraph repository using the CI_COLUMNS view. The data is passed through a
Normalize component to generate the corresponding annotation values
to be loaded. To populate additional annotations, simply add cases for
different fields in the input record to this component.

Connector for Oracle Designer
Prepare Keys Oracle Designer holds the key information in the CI_CONSTRAINTS
subgraph view and the columns that make up the key in the
CI_KEY_COMPONENTS view.
The graph runs in two phases.
Phase One The first phase extracts the key information and builds
records for creating the key objects in the datastore in
$TARGET_PROJECT/keys. It also creates a lookup file containing
all the key definitions (which are kept in $WORKDIR).
Phase Two The second phase reads the lookup file and passes it
through a Normalize component to get the individual key annotations. It
also uses the lookup to resolve any foreign-key references. This data is
then merged with the key column details, which have been extracted
from the CI_COLUMNS and CI_KEY_COMPONENTS views. These
are then attached to the key records created in the first phase.
Prepare Indexes Oracle Designer holds the index information in the CI_INDEXES view
Subgraph and the columns that make up the columns in the CI_INDEX_ENTRIES
view. The graph runs in two phases.
First, the index information is extracted and records for creating the
index objects are built in $TARGET_PROJECT/indexes. It also
creates a lookup file containing all the index definitions (which are kept
in $WORKDIR).
Next, the lookup file is read and passed through a Normalize component
in order to get the individual index annotations. This data is then merged
with the index column details, which have been extracted from the
CI_COLUMNS and CI_INDEX_ENTRIES views. The merged
information is then attached to the indexes created in the datastore in the
first phase.

Connector for DB2

Read the following notes if you are using a DB2 database catalog as the
metadata source.

and the Shell Script $AB_HOME/connectors/DB2/db2_to_eme.mp. The corresponding
shell script is db2_to_eme.ksh.
Parameter The OWNER parameter is the database schema in which the tables
reside. See also sectionGraph Parameters on page 242.
Views Subgraph
Phase One The first phase uses the m_db gendml command to
generate the DML for all of the datasets and views for the given user.
This information is then loaded into the datastore, creating datasets in
the tables directory of the project. The load operation is accomplished
by the Load Table Dataset component. In addition, record format files
(.dml files) are created and loaded into the dml directory of the project.
Phase Two The second phase unloads table and view information
from the DB2 catalog (views SYSCAT.TABLES and
SYSCAT.VIEWS). It merges this information and passes it through a
Normalize component, which effectively pivots the table/view level
information into multiple records. If you want to add more annotations
for tables and views, you should create them in this component. Finally,
the Load Annotation Values component loads the annotations into the
datastore.
Prepare Column The column information is unloaded from the DB2 catalog
Information Subgraph SYSCAT.COLUMNS view. The data is passed through a Normalize
component to generate the corresponding annotation values to be
loaded. To populate additional annotations, add cases for different fields
on the input record to this component.
Prepare Keys Key information is unloaded from the DB2 catalog

Subgraph SYSCAT.CONSTDEP view, and the columns that make up the key are
unloaded from the SYSCAT.KEYCOLUSE view. In addition, the
foreign-key references are found in SYSCAT.REFERENCES. This

Connector for DB2
subgraph takes the records from the SYSCAT.CONSTDEP and

SYSCAT.REFERENCES views and creates key records which are
loaded using the Load Key Objects component.
This data is also passed through a Normalize component to get the
individual key annotations. The foreign-key references are computed
separately and combined with the above data. All of these key
annotation records are then merged with the key column references
(extracted from SYSCAT.KEYCOLUSE) and attached to their relevant
keys in the datastore by the Load Key Annotations component.
Prepare Indexes Index information is unloaded from the DB2 catalog through the
Subgraph SYSCAT.INDEXES view, and the columns that make up the indexes
are found in the SYSCAT.INDEXCOLUSE view. The subgraph runs in
two phases.
Phase One The first phase extracts the index information and creates
the index objects in $TARGET_PROJECT/indexes.It also creates a
lookup file containing all the index definitions (which are kept in
$WORKDIR).
through a Normalize component to get the individual index annotations.
This data is then merged with the index column details, which have
been extracted from the SYSCAT.INDEXCOLUSE view. These are
then attached to the indexes created in the datastore in the first phase.
tables_to_migrate.dat The database field of tables_to_migrate.dat should be the name of the

Dataset database taken from the .dbc file. The Owner field is the name of the
database subschema. The tables should be listed in uppercase letters.
The fourth column may be left empty.

Connector for Oracle

Read the following notes if you are using an Oracle database catalog as
the metadata source.

and the Shell Script $AB_HOME/connectors/Oracle/oracle_to_eme.mp. The
corresponding shell script is oracle_to_eme.ksh.
Parameter This graph takes one additional parameter, OWNER, which is the
database owner of the schema objects to be unloaded. See also
To reduce unload times from large Oracle catalogs, you may limit the
extract processes by adding WHERE clauses. You may set the
following parameters in the graph parameters editor:
• WHERE_CLAUSE_DBA_TABLES
• WHERE_CLAUSE_DBA_VIEWS
• WHERE_CLAUSE_DBA_TAB_COLUMNS
• WHERE_CLAUSE_DBA_IND_COLUMNS
• WHERE_CLAUSE_DBA_CONSTRAINTS
• WHERE_CLAUSE_DBA_INDEXES
Views Subgraph
the tables/db_name directory of the project. The load operation is
accomplished by the Load Table Dataset component. In addition, record
format files (.dml files) are created and loaded into the dml directory of
the project.
from the Oracle catalog (views SYS.DBA_TABLES,
SYS.DBA_VIEWS, and SYS.ALL_TAB_COLUMNS). It merges this
information and passes it through a Normalize component, which
effectively pivots the table/view level information into multiple records.

Connector for Oracle
If you want to add more annotations for tables and views, you should
create them in this component. Finally, the Load Annotation component
loads the annotations into the datastore.
Prepare Column The column information is unloaded from the Oracle catalog
Information Subgraph SYS.DBA_TAB_COLUMNS and SYS.ALL_COL_COMMENTS
views. The data is passed through a Normalize component to generate
the corresponding annotation values to be loaded. To populate
additional annotations, add cases for different fields in the input record
to this component.
Prepare Keys Key information is retrieved from the Oracle catalog through the
Subgraph SYS.DBA_CONSTRAINTS view, and the columns that make up the
key are unloaded through the SYS.DBA_CONS_COLUMNS view. The
subgraph runs in two phases.
Phase One The first phase extracts the key information, filters it for
primary, foreign, and unique keys, and then creates the key objects in
the datastore in $TARGET_PROJECT/keys. It also creates a lookup
table containing all the key definitions (which is kept in $WORKDIR).
through a Normalize component to get the individual key annotations. It
also uses the Lookup component to resolve any foreign key references.
This data is then merged with the key column details, which have been
extracted from the SYS.DBA_CONS_COLUMNS view. These are then
attached to the keys created in the datastore in the first phase.
Prepare Indexes Index information is retrieved from the Oracle catalog through the
Subgraph SYS.DBA_IND_COLUMNS view. This view holds information at the
index column level. The subgraph runs in two phases.
Phase One The first phase extracts the index information, rolls it up
to the index level, and creates the index objects in the datastore in
Phase Two The second phase takes this aggregated data and passes it
This data is then merged with the original index column details. The
merged information is then attached to the indexes created in the
datastore in the first phase.


Dataset database taken from the .dbc file. The Owner field is the name of the
database subschema. The tables should be listed in uppercase letters.
The fourth column must be populated with either a generic name or the
name of the table (in lowercase letters).
Example Here is the dataset format for tables_to_migrate.dat for Oracle:

rga | SCOTT | A_CUSTOMERS | a_customers
rga | SCOTT | A_TRANSACTIONS | a_transactions
rga | SCOTT | WAYPOINTS | waypoints
rga | SCOTT | WAYPOINT_TOTALS | waypoint_totals

Connector for Teradata
Connector for Teradata

Read the following notes if you are using a Teradata database catalog as

and the Shell Script $AB_HOME/connectors/Teradata/teradata_to_eme.mp. The
corresponding shell script is teradata_to_eme.ksh.
Parameter This graph takes one additional parameter, OWNER, which is the
database owner of the schema objects to be unloaded. See also
Handling of Spaces The data extracted from the Teradata tables is space-padded out to its
full size. All unload components are followed by a reformat operation,
which strips trailing spaces from all fields.
Views Subgraph
format files are created and loaded into the dml directory of the project.
from the Teradata catalog. (View and table information are saved in
DBC.TABLES.) This data is passed through a Normalize component,
which effectively pivots the table/view level information into multiple
records. If you want to add more annotations for tables and views, you
should create them in this component. Finally, the Load Annotation
Values component loads the annotations into the datastore.
Prepare Column The column information is unloaded from the Teradata catalog
Information Subgraph DBC.COLUMNS view. The data is passed through a Normalize
component to generate the corresponding annotation values to be
loaded. To populate additional annotations, add cases for different fields
in the input record to this component.

Prepare Keys Key information is retrieved from the Teradata catalog through the
Subgraph DBC.INDICES view, and the columns that make up the key are
retrieved through the DBC.ALL_RI_CHILDREN view. Primary keys
are defined in the DBC.INDICES view as records with an index type of
‘K’. Foreign keys are derived from the DBC.ALL_RI_CHILDREN
view. Each of these two views holds its information at the key column
level of detail. The subgraph runs in two phases.
Phase One The data from the two views are rolled up to get the
key-level aggregate information, which is loaded into the datastore in
$TARGET_PROJECT/keys. This data is also passed through a
Normalize component to get the individual key annotations.
Phase Two The column-level information is reformatted into a

load-ready format and merged with the individual key annotations. This
data is then combined with the foreign-key reference computed by
joining the foreign key and primary key data. The combined data is then
Prepare Indexes Index information is retrieved from the Teradata catalog through the
Subgraph DBC.INDICES view. (Note that primary keys are also indexes.) This
view holds information at the index column level. The graph runs in two
phases.
This data is then merged with the original index column details. These
are then attached to the indexes created in the datastore in the first
phase.

Dataset database taken from the .dbc file. The Owner field is not used. The
tables should be listed in uppercase letters. The fourth column may be
left empty.

Connector for SQL Server
Connector for SQL Server

Read these notes if you are using an SQL Server database catalog as the
metadata source.

and the Shell Script $AB_HOME/connectors/SQLServer/SQLServer_to_eme.mp. The
corresponding shell script is SQLServer_to_eme.ksh.
Parameter The OWNER parameter is the database owner of the schema objects to
be unloaded. See also sectionGraph Parameters on page 242.
Views Subgraph
the project.
from the SQL Server sysobjects and sysproperties catalogs. This data is
passed through a Normalize component, which effectively pivots the
component. Finally, the Load Annotation Values component loads the
annotations into the datastore.
Prepare Column The column information is unloaded from the sysobjects, syscolumns,
Information Subgraph systypes, and sysproperties views. The data is passed through a
Normalize component to generate the corresponding annotation values
to be loaded. To populate additional annotations, add cases for different
fields in the input record to this component.
Prepare Keys Key information is retrieved from the SQL Server catalog through the
Subgraph sysobjects and syscolumns views, and the columns that make up the key
are retrieved through the sysforeignkeys view. Each of these two views
holds its information at the key column level of detail. The subgraph
runs in two phases.


Prepare Indexes Index information is retrieved from the SQL Server catalog through the
Subgraph sysindexes, sysobjects, syscolumns, and sysindexkeys views. This view
holds information at the index column level. The graph runs in two
phases.
phase.

Dataset database taken from the .dbc file. The Owner field should be the same
as the OWNER parameter. The tables should be listed in uppercase
letters. The fourth column may be left empty.

Connector for Sybase
Connector for Sybase

Read these notes if you are using a Sybase database catalog as the
metadata source.

and the Shell Script $AB_HOME/connectors/Sybase/Sybase_to_eme.mp. The
corresponding shell script is Sybase_to_eme.ksh.
Parameter The OWNER parameter is the database owner of the schema objects to
be unloaded. See also sectionGraph Parameters on page 242.
Prepare Tables and The Load Tables and Views subgraph runs in two phases.
Views Subgraph
the project.
from the Sybase dbo.sysobjects and dbo.sysusers catalogs. This data is
passed through a Normalize component, which effectively pivots the
component. Finally, the Load Annotation Values component loads the
annotations into the datastore.
Prepare Column The column information is unloaded from the dbo.sysobjects,

Information Subgraph dbo.syscolumns, dbo.sysusers, and dbo.sysproperties views. The data is
passed through a Normalize component to generate the corresponding
annotation values to be loaded. To populate additional annotations, add
cases for different fields in the input record to this component.
Prepare Keys Key information is retrieved from the Sybase catalog through the
Subgraph dbo.sysobjects and dbo.syscolumns views. (Note that you need read
access to dbo.sysusers so that the connector can translate the owner
name to an internal user ID.) The columns that make up the key are

retrieved through the dbo.syskeys view. Both the dbo.syscolumns and

dbo.syskeys views hold information at the key column level of detail.
The subgraph runs in two phases.

Prepare Indexes Index information is retrieved from the Sybase catalog through the
Subgraph dbo.sysindexes view. This view holds information at the index column
level. The graph runs in two phases.
to the index level, and creates the index objects in the datastore.
phase.

Dataset database taken from the .dbc file. The Owner field should be the same
as the OWNER parameter. The tables should be listed in uppercase
letters. The fourth column may be left empty.

Connector for Redbrick
Connector for Redbrick

Read the following notes if you are using a Redbrick database catalog as

and the Shell Script $ab_home/connectors/Redbrick/redbrick_to_eme.mp. The
corresponding shell script is redbrick_to_eme.ksh.
Required Parameters TARGET_EME_DATASTORE points to $AB_AIR_ROOT, the location

of the EME datastore into which the metadata will be loaded.
TARGET_PROJECT is the path to the project in the EME datastore.
DBC_FILE allows users to connect to the source database tables and
system views.
See also sectionGraph Parameters on page 242.
Initialize EME The Initialize EME subgraph sets up the EME schema and loads the
subgraph database configuration file into a specified location. This subgraph also
determines the database name and creates a lookup file for components
to use in later phases. The lookup file restricts which table information
is extracted from the database and loaded into the EME.
Prepare Tables and The Prepare Tables and Views Subgraph unloads from two Redbrick
Views Subgraph views: RDW_COLUMNS and RBW_TABLES. The data streams are
then filtered based on a lookup of the tables_to_migrate.dat dataset
created in the first phase. The record format for the dataset object is
created from the ddl information extracted from RDW_COLUMNS by
the ddl_to_dml utility. To process the data from RBW_TABLES, a
Normalize component organizes the view annotations that will be
loaded into the target EME datastore. The component effectively pivots
the table/view level information into multiple records. If you want to
add more annotations for tables and views, you should create them in
this component.
Prepare Column The column information is unloaded from the RBW_COLUMNS view.
Information Subgraph The data is passed through a Filter by Expression component to remove
the table columns. Then a Normalize component generates the

corresponding annotation values to be loaded. To populate additional

annotations, you can add cases for different fields on the input record to
this component.
Prepare Keys Key information is unloaded from the RBW_CONSTRAINTCOLUMNS

Subgraph view, and the columns that make up the key are unloaded from the
RBW_CONSTRAINTS view. In addition, the foreign-key references
are found in RBW_RELATIONSHIPS. The Prepare Keys subgraph
takes the records from these views and creates key records that are
loaded using the Load Key Objects component.
This data is also passed through a Normalize component to obtain the
individual key attributes. The foreign-key references are computed
separately and combined with the above data. All of these key
annotation records are then merged with the key column references and
attached to their relevant keys in the datastore in a later phase.
Prepare Indexes Index information is unloaded from the Redbrick catalog through the
Subgraph RBW_INDEXCOLUMNS view. It also creates links between the tables
of interest and their indexes as well as the relationship between the
index and the key constraints. A Normalize component creates the
annotations for the index. You can include additional annotations in this
component.
Load EME Datastore The view dataset information as well as database objects and their
or Export Files annotations are loaded into the EME datastore and exported into files.
Subgraph The export is accomplished through conditional components, allowing
you to specify whether to write the data to files or not.

Graph for Loading Files Created on a Physically Inaccessible System
Graph for Loading Files Created

on a Physically Inaccessible
System
When the metadata source resides on a different system than the EME
and that system is also physically inaccessible to the datastore, you must
first employ the appropriate connector to generate load files, then copy
the files to the system on which the datastore resides, and finally use the
load_eme_from_files.mp graph to load the generated files into the
datastore. In general, you will not need to use this mechanism.

and the Shell Script $AB_HOME/connectors/EME/Load/load_eme_from_files.mp. The
corresponding shell script is load_eme_from_files.ksh.
Parameters The graph takes the same parameters as the other graphs. See
Set the EXPORT_FILES parameter on the connector graphs to True
(page 243). The $WORKDIR directory contains the files produced
when the EXPORT_FILES parameter is set to True.
Graph Phasing The graph runs in four phases:

• Phase 0 initializes the EME datastore and extends the schema, if
requested.
• Phase 1 loads all dataset entities.
• Phase 2 loads all objects.
• Phase 3 loads all annotations.

E>
Unloading Metadata with
Connectors to Third-party
Reporting Tools
What Are Unload Unload connectors are a suite of graphs, shipped with the Co>Operating
Connectors? System, that unload metadata from an EME datastore into third-party
reporting tools like MicroStrategy, BrioQuery, and Business Objects.
This section describes the Ab Initio connectors for integrating metadata
with each of these products.

• Connector for MicroStrategy (page 268)
• Connector for BrioQuery (page 272)
• Connector for Business Objects (page 274)

Appendix E> Unloading Metadata with Connectors to Third-party Reporting Tools
Connector for MicroStrategy

Concept of Extended The MicroStrategy metadata model is based on the concept of extended
Properties properties. Not unlike categories and annotations, extended properties
allow you to attach pieces of information to various objects that exist
within the MicroStrategy schema. Using the MicroStrategy Web
interface, you can access the extended properties as attributes in reports.
The connector for MicroStrategy, the mstr_load utility, provides a
generic interface for populating extended properties attached to
MicroStrategy Columns and Tables. Extended properties are named and
must be part of a property set, which is effectively a namespace for
properties. All properties are strings, though other types are possible.
mstr_load, which resides in $ab_home/bin, runs in three modes. Three
.mpc files make MicroStrategy functionality available as components.
mstr_load Syntax The syntax of the mstr_load utility is:

mstr_load
datasource existing-MicroStrategy-datasource-name
-project existing-MicroStrategy-project-name
-user user-name
-pass user-password
[-propertyset property-set-name]
[-property property-name]
[-delimiter delimiter]
[-file file-name]
[-dump | -schema]
Note In order to use this program, a valid MicroStrategy data source
and project must exist.
Arguments are specified as strings. Use "" to represent an empty string.
Argument order is irrelevant. All mappings are done through tableName
and columnName, not the object names. The optional arguments have
the following default values or behavior:
If you don’t specify Then
property-set-name Default is "AbInitio".
property-name Default is "Details".
delimiter Default is "\0".
file-name Default is stdin or stdout.
-schema or -dump Program operates in loading metadata mode.

Three Modes of The mstr_load program operates in one of three modes, depending on
Operation whether you specify -dump, -schema, or neither. The modes are:
• Loading metadata mode
• Unloading properties mode
• Exporting schema mode
Loading Metadata Mode If neither -dump nor -schema is specified, then the program loads
metadata. In loading metadata mode, mstr_load reads records from
stdin or the file named in the -file file-name argument. In either case,
the record format of the input data must be as it appears below,
assuming "\0" is delimiter:
record
string("\0") tableName = "";
string("\0") columnName = "";
string("\0") metaName = "";
string("\0") metaDisplayName = "";
string("\0") metaValue = "";
string(1) newline = A"\n";
end;
In general, each record of input is converted into an XML string for later
interpretation by the MicroStrategy Web interface.
The form of the generated XML is:
<metaName displayName=”metaDisplayName”>metaValue</metaName>
Interpretation of the input data follows these rules:
• If no column name is specified, the target object is the named
table.
• If no metaName is specified, the metaValue is attached literally,
rather than as an XML string.
• The first occurrence of a table or column name clears any existing
property values.
• Only one table (or column) of a given name can exist in the
MicroStrategy schema. If multiple input records name the same
table (or column), then the XML or literal value is appended to the
existing property.
• The name used for tables should be prefixed with the table’s
namespace (for example, Scott.Customers).
• The table (or column) name should be the MicroStrategy schema
name, not the MicroStrategy object name (see Exporting Schema
Mode).

Unloading Properties If -dump is specified, then the program unloads metadata. The -dump
Mode option outputs data in the following format, assuming "\0" is delimiter:
record
string("\0") propertySet = "";
string("\0") propertyName = "";
string("\0") value = "";
string("\0") useDefault = "";
end;
Specify the -dump option when it is necessary to unload the existing set
of extended properties from a project. One record for each table or
column that has a property of the given name in the given property set is
sent to stdout or to the file specified with the -file file-name argument.
Specifying " " as the property (-property property-name) causes all
properties of the given set to be dumped as separate records. Similarly,
specifying " " as the property set (-propertyset property-set-name)
causes all properties in all sets to be dumped as separate records.
Use this option if you deem it necessary to append property values over
multiple runs. This can be accomplished by unloading the given
property and merging the results with data to be loaded through
mstr_load in loading metadata mode. This is possible because there is
no way to distinguish an XML string of the form shown in Loading
Metadata Mode on page 269 that was created by mstr_load internally
from one that is of the same form loaded as a literal.
Exporting Schema Mode If -schema is specified, then the program operates in exporting schema
mode. The -schema option allows users to see the names of existing
table and column objects within the MicroStrategy schema. All table
and column objects are unloaded. The record format specifies the
internal object name and the schema name. In practice, these are likely
to be the same.
The -schema option outputs data in the following format, assuming "\0"
is delimiter:
record
string("\0") tableObjectName = "";
string("\0") columnObjectName = "";
end;

MicroStrategy Three .mpc files make the MicroStrategy functionality available as

Components Ab Initio components:
• microstrategy_load.mpc
• microstrategy_unload.mpc
• microstrategy_schema.mpc
Parameters for these components map directly to command-line
parameters, as described in the syntax presented in mstr_load Syntax on
page 268.

Connector for BrioQuery

Concept of Remarks The BrioQuery metadata model is based on the concept of remarks.
Remarks are available while viewing the database schema within
BrioQuery. Try right-clicking on a table or column to display a context
menu. Selecting the Show Remarks item from that context menu brings
up a tabbed dialog, displaying configurable labels and values from
external data sources. BrioQuery gets the information for the Remarks
tabs by connecting to configurable metadata sources through SQL
queries.
Accessing Metadata To access metadata from within BrioQuery, you must do the following:
from BrioQuery
1. Unload metadata from the EME into a relational database.
You can easily accomplish the first step by running a graph. A
sample graph has been provided, and is fully described in
Unloading Categories into a Relational Database on page 109.
2. Configure the desired remarks.
Configuration of remarks takes place within BrioQuery. The use of
SQL queries to obtain metadata makes the metadata display highly
flexible. For example, BrioQuery supports multiple values being
returned across joined tables and allows simple formatting in the
display.
(For detailed information on accessing metadata from within
BrioQuery, read about metadata definitions in the Data Model
chapter of the Brio documentation.)
brio_cfg Utility The EME includes the brio_cfg utility. This utility, which resides in
$AB_HOME/bin, adds a series of Ab Initio remark entries (in
$AB_HOME/connectors/brio/ab_meta.ini) to the BrioQuery
metadata configuration file, bqmeta0.ini, which is the source of the
default selections used for new BrioQuery connections. These remarks
display metadata based on the built-in categories and annotation rules of
the EME’s base schema (page 222). The utility makes a backup of the
original target file and names it target_config_file.bak. After you run
the utility, an "Ab Initio EME" entry appears in the metadata
configuration list.
The syntax of brio_cfg is:
brio_cfg source_config_file target_config_file

Connector for BrioQuery
Example To install the standard Ab Initio remarks into the configuration file used
by BrioQuery, type:
brio_cfg $AB_HOME/connectors/brio/ab_meta.ini
$WINDIR/bqmeta0.ini
The following shows the entries added to the bqmeta0.ini file to specify
a default remark set.
[BrioQuery Meta Data Sources]
AbInitio=Ab Initio EME
...
[AbInitio]
TableRemarkTabCount=1
ColumnRemarkTabCount=1
TableRemarkTab1=Ab Table Remark1
ColumnRemarkTab1=Ab Column Remark1
[Ab Table Remark1]

TableRemarkTabName=Table Details
TableRemarkTabSequence=1
TableRemarkSelectColumn='oid = ' || D.oid || ',
name= ' || D.name || '. Created by ' ||
D.created_by || ' on ' || D.creation_date || '.
Last modified on ' || D.modification_date || ' by
' || D.modified_by || '. Comment: ' || D.comment
|| '. Description: ' D.description
TableRemarkFrom=<Schema>.Dataset D
TableRemarkWhere=D.name=:TABLE
[Ab Column Remark1]

ColumnRemarkTabName=Column Details
ColumnRemarkTabSequence=1
ColumnRemarkSelectColumn='oid = ' || D.oid || ',
name= ' || D.name || '. Created by ' ||
D.created_by || ' on ' || D.creation_date || '.
Last modified on ' || D.modification_date || ' by
' || D.modified_by || '. Comment: ' || D.comment
|| '. Description: ' D.description
ColumnRemarkFrom=<Schema>.dataelement D
ColumnRemarkWhere=D.name=:COLUMN

Connector for Business Objects

Contents The connector for Business Objects Designer consists of:
• bo_load.exe utility program
• create_universe_from_eme.mp, an example Ab Initio graph
(page 277)
This connector allows you to create, update, document, and unload
Business Objects universes. (Please read Format of Input and Output
Data on page 276.) The example graph demonstrates how you can build
an application that extracts metadata from the EME and create a
Business Objects universe from that data.
Platform Restriction The utility and graph run only on Microsoft Windows platforms where
Business Objects Designer has been installed.
To identify that the correct module of Business Objects Designer is
installed on your machine, search the Windows registry (from regedit)
for Designer.Application. You should see the following registry entries:
\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Designer.Application
\HKEY_classes_root\Designer.Application
bo_load Syntax The bo_load utility, which resides in $AB_HOME/bin, allows you to
create, update, and unload Business Objects universes.
$AB_HOME/bin/bo_load.exe
-universe string
{-document | -create | -update | -unload}
[-user string -password string -repository string]
[-connection string]
[-delimiter string]
[-file string]
-universe string Name of the universe to use. If no path is

specified, then the universe will be found in the
Business Objects universe directory (usually,
“c:\Program Files\Business Objects\Business
Objects 5.0\Universe”).

-document | Specify one of the following:

-create | -update |
• -document sets the description attribute on
unload
classes and objects in the universe. The input
data specifies the class and object name and
the associated description. If object name is
blank, then description is set on the class.
• -create creates and populates a new
universe. The input data specifies the object
type to create: Table, Class, Column, Join, or
Object. Each record has additional values
which are used to populate the universe.
Note that objects are identified by name.
• -update updates an existing universe. The
input data has an additional column (action)
that indicates whether to add, modify or
delete a class, object, table, column, or join.
The rest of the data is the same as for the
-create option. Add causes additional
objects to be created in the universe. Modify
causes existing objects to be updated in the
universe. Delete causes existing objects to be
removed from the EME datastore.
• -unload unloads the tables, classes,
columns, objects, and joins from a universe.
Each record is unloaded with an object type
and the relevant data for that object.
-user string Optional. User name to use when connecting to

Business Objects. If specified, you must also
specify -password and -repository.
-password string Optional. Password to use when connecting to

Business Objects. If specified, you must also
specify -user and -repository.
-repository string Optional. Business Objects repository to connect

to. If specified, you must also specify -user and
-password.

-connection string Optional. Name of the data provider connection

to use when creating a new universe. Only
relevant when you also specify -create. If
omitted, the universe is created with no
connection information for linking to a relational
database. A user of the Business Objects
Designer product can supply this information
later.
-delimiter string Optional. Character to use as the field delimiter in

the input/output records. Default: "\0".
-file string Optional. Path of a file to use when

reading/writing data. By default, the utility reads
and writes from stdin and stdout, respectively.
Format of Input and This section describes the DML you must specify for documenting data,
Output Data creating and populating universes, updating an existing universe, and
unloading tables, classes, columns, objects, and joins. All fields are
strings.
Document The DML fields you must specify for documenting data in a universe:
• className
• objectName
• description
Create and Update Following are the DML fields you must specify for creating and
populating a new universe, updating an existing universe, or unloading
the tables, classes, columns, objects, and joins from a universe.
If recordtype is Specify ... Comment
Table tablename —
Column tablename columntype can be data,

columnname numeric, character, text, null,
columntype unknown.
Class classname —
description

Object classname objecttype can be numeric,

description character, data, blob, null,
objectname unknown.
objecttype
select String containing the SELECT
statement of the object’s SQL
definition. Default is
classname.objectname.
Join expression String containing join formula.
Components There are also .mpc files that make this functionality available as
Ab Initio components. These components can be found in
$AB_HOME/connectors/BusinessObjects:
• BusinessObjects_Create.mpc
• BusinessObjects_Update.mpc
• BusinessObjects_Document.mpc
• BusinessObjects_Unload.mpc
The above components all have the same parameters: Universe, User,
Password, Repository, Connection. See bo_load’s argument list on
page 274.
create_universe_from This graph reads table, column, and key information from the EME and
_eme.mp Graph uses it to create a Business Objects universe. It resides in
$AB_HOME/connectors/BusinessObjects.
The graph has the following parameters:
SRC_PROJECT Project to derive universe definition from

(required).
UNIVERSE Business Objects universe (optional).
USERNAME Business Objects login username (optional).
PASSWORD Business Objects login password (optional).
CONNECTION Business Objects connection name (optional).
REPOSITORY Business Objects repository to log into

(optional).

The graph reads metadata from the EME set by the AB_AIR_ROOT
configuration variable or in the EME Datastore Settings dialog in the
GDE. The graph creates tables and columns derived directly from the
table datasets defined in the source project (see the Reformat to Table
Record and Reformat to Column Record components in the graph). The
classes and objects are implemented as direct mappings from the
corresponding tables and columns (see the Reformat to Class Record
and Reformat to Object Record components). The joins are created
wherever foreign keys have been defined (see the Join to Get Primary
Key component).

F>
Configuration Variables
This section describes a few of the configuration variables that control

the behavior of the EME.
AB_ARULE_BOOL_FORMAT
Default value: “true:false”
Type: string
Exported: true
Details: Specifies the string values used to represent boolean annotation
values. For example, you might choose “1:0” for true and false,
respectively. Another example might be “yes:no”. This variable affects
how the boolean values of the built-in annotation rules of the base
schema are displayed in the Web user interface and in the output of such
commands as air annotation dump (page 150) and air category
unload (page 180). For a description of the annotation rules of the base
schema, see Description of Base Categories and Rules on page 226.
AB_ARULE_DATE_FORMAT
Default value: “YYYY/MM/dd hh24:m:ss”
Type: string
Exported: true
Details: Controls the date and time format of annotation values
displayed in the Web user interface and in the output of such commands
as air annotation dump (page 150) and air category unload (page
180). See datetime types in the Data Manipulation Language
Reference for more details. The built-in annotation rules of the base
schema are described in Description of Base Categories and Rules on
page 226.

Appendix F> Configuration Variables
AB_ARULE_USE_LOCAL_TIME
Default value: false
Type: bool
Exported: true
Details: Sets the display of modification and creation times to either
universal time (default) or server local time. Set the value to true if you
would like modification and creation times to be converted to server
local time.

G>
Sample Scripts
This section presents three sample Korn shell scripts that you might
peruse or run to become familiar with setting up an EME datastore.
Topics Covered You will learn about the following scripts:

• Script for Creating Categories and Rules and Defining Category
Membership (page 282)
• Script for Storing Metadata in an EME Datastore (page 283)
• Script for Defining Views (page 285)

Appendix G> Sample Scripts
Script for Creating Categories

and Rules
The following script creates the Application, Data Files, and Personnel
categories as well as a number of annotation rules (business_area,
steward, phone, and department) and choices for choice-type rules. It
then associates the rules with the categories. Finally, it adds members to
these categories by specifying their locations in the datastore. You must
run this script first. The next two scripts can be run in either order.
export AB_AIR_BATCH=true
air begin-batch
# Create categories
air category create "Data Files" dataset
# Create annotation rules

air arule create business_area -display "Business Area"\
-type choice +can-edit -multi-value +in-list
air arule add-choice business_area "Accounts Payable"\
"Accounts Receivable" Inventory Operations Marketing
air arule create "steward" -display "Responsible \
Individual" -type reference +can-edit Personnel
air arule create "phone" -display "Work Number" \
-type string -default-value 617-555-1234 \
+can-edit -multi-value
air arule create department -display "Department" \
-type choice -multi-value +in-list
air arule add-choice department "Human Resources" \
MIS Finance Administration Sales Marketing
# Associate rules with categories

air category add-rule Application business_area steward
air category add-rule "Data Files" steward
air category add-rule Personnel phone department
# Name the location of objects that are category members

/Projects/myproject/mp \
/Projects/myproject2/mp
air category add-member-location "Data Files" \
/Projects/myproject/tables
/Metadata/Personnel
air end-batch

Script for Storing Metadata in an EME Datastore
Script for Storing Metadata in an

EME Datastore
The following script stores data in an EME datastore and adds metadata
(annotation values) for some rules. Interspersed are descriptions and
comments for various objects in the datastore.
air begin-batch
air reposit text -string "unused" "/Metadata/Personnel/Jim Anchower"

air annotation document "/Metadata/Personnel/Jim Anchower" \
"Finance data expert" "Jim is responsible for most of the Finance data \
in our databases."
air annotation add "/Metadata/Personnel/Jim Anchower" phone \
-string "781-555-2388"
air annotation add "/Metadata/Personnel/Jim Anchower" department \
-string "Finance"
air reposit text -string "unused" "/Metadata/Personnel/Eric Smith"

air annotation document "/Metadata/Personnel/Eric Smith" "Marketing data \
expert" "Eric is responsible for most of the marketing data in our \
databases."
air annotation add "/Metadata/Personnel/Eric Smith" phone \
-string "781-555-2288"
air annotation add "/Metadata/Personnel/Eric Smith" department \
-string "Marketing"
air reposit text -string "unused" "/Metadata/Personnel/Paul Bergen"

air annotation document "/Metadata/Personnel/Paul Bergen" \
"Ab Initio expert" "Paul has a lot of experience with Ab Initio \
graphs. See him if you have any of the Ab Initio graphs."
air annotation add "/Metadata/Personnel/Paul Bergen" phone \
-string "781-555-4258"
air annotation add "/Metadata/Personnel/Paul Bergen" department \
-string "MIS"
air annotation add /Projects/myproject/mp/Unload-B-tables.mp steward \

"/Metadata/Personnel/Paul Bergen"
air annotation document /Projects/myproject/mp/Unload-B-tables.mp \
"Unloads company B's market data." "Unloads company B's market data."
air annotation add /Projects/myproject/mp/Unload-B-tables.mp business_area \
-string "Operations"
air annotation add /Projects/myproject/mp/Unload-A-Tables.mp steward \

air annotation document /Projects/myproject/mp/Unload-A-Tables.mp "Unloads \
company A's market data." "Unloads company A's market data."
air annotation add /Projects/myproject/mp/Unload-A-Tables.mp business_area \
-string "Operations"
air annotation add /Projects/myproject/mp/LoadJoinedCustomers.mp steward \

air annotation document /Projects/myproject/mp/LoadJoinedCustomers.mp \
"Loads the joined market data from companies A and B." \
"Loans the joined market data from companies A and B."

Appendix G> Sample Scripts
air annotation add /Projects/myproject/mp/LoadJoinedCustomers.mp \

business_area -string "Operations"
air annotation add /Projects/myproject/mp/JoinCustomers.mp steward \

air annotation document /Projects/myproject/mp/JoinCustomers.mp "Joins market \
data from companies A and B." "Joins market data from companies A and B."
air annotation add /Projects/myproject/mp/JoinCustomers.mp business_area \
-string "Marketing"
# Flesh out this example.

air annotation add /Projects/myproject/tables/warehouse/customers steward \
"/Metadata/Personnel/Eric Smith"
air annotation document /Projects/myproject/tables/warehouse/customers \
"3rd party market research" "We obtained this market data from a third \
party source. The data in this graph should overlap the customer records \
from Company A and B."
air annotation add /Projects/myproject/tables/company_b/transactions steward \

"/Metadata/Personnel/Jim Anchower"
air annotation document /Projects/myproject/tables/company_b/transactions \
"Company B's sales records" "These sales records from company B are \
organized by transaction id."
air annotation add /Projects/myproject/tables/company_b/customers steward \

air annotation document /Projects/myproject/tables/company_b/customers \
"Company B's customer data." "Customer data from Company B. Organized by \
customer id."
air annotation add /Projects/myproject/tables/company_a/transactions steward \

"/Metadata/Personnel/Jim Anchower"
air annotation document /Projects/myproject/tables/company_a/transactions \
"Company A's sales records" "These sales records from company A are \
organized by transaction id."
air annotation add /Projects/myproject/tables/company_a/customers steward \

air annotation document /Projects/myproject/tables/company_a/customers \
"Company A's customer data." "Customer data from Company A. Organized \
by customer id."
air end-batch

Script for Defining Views
Script for Defining Views

The following script defines five views: two for Application, one for
Personnel, and two for Data Files.
air begin-batch
air category add-view Application details

air category add-view Personnel details
air category add-view "Data Files" details
air category add-view Application list

air category add-view "Data Files" list
air category add-view "Personnel" list
# Application
air category add-view-element Application details \
-simple Comment "/|Application/.comment/>" \
-simple "Business Area" "/|Application/.business_area/>"\
-simple Steward "/|Application/.steward/>" \
-simple "Stewards Phone" \
"/|Application/.steward/>/|Personnel/.phone/>"
air category add-view-element Application list \

-simple "Application" "/|Application/.name/>" \
-simple "Business Area" "/|Application/.business_area/>"\
-simple Description "/|Application/.description/>"
# Data Files
air category add-view-element "Data Files" details \
-simple Comment "/|Data Files/.comment/>" \
-simple Steward "/|Data Files/.steward/>" \
-simple "Steward's Phone" \
"/|Data Files/.steward/>/|Personnel/.phone/>"
air category add-view-element "Data Files" list \

-simple "Data File" "/|Data Files/.name/>" \
-simple Description "/|Data Files/.description/>"
# Personnel
air category add-view-element Personnel details \
-simple Comment "/|Personnel/.comment/>" \
-simple Department "/|Personnel/.department/>" \
-view "Applications this employee is responsible for" \
"/<Application/.steward/|" Application/.list \
-view "Data Files this employee is responsible for" \
"/<Data Files/.steward/|" "Data Files/.list"
air category add-view-element Personnel list \

-simple Name "/|Personnel/.name/>" \
-simple Description "/|Personnel/.description/>" \
-simple Department "/|Personnel/.department/>"
air end-batch

Index
Symbols air reposit text command 38

airutility commands 148
! (bang) character in path names 142 aiw server program 120
* (asterisk) character in passwords 123 angle bracket characters in view-elements 58
. (period) character in view-elements 58 annotation rules 28
/ (slash) character associating with categories 35, 164
in path names 142 of base schema 226
in view-elements 58 and category members 26
<> (angle brackets) characters in view elements 58 clearing permissions on 170
| (vertical bar) character in view-elements 58 creating 33, 152
data types of 152
definition of 20, 28
A displaying 157
displaying information about 157
AB_AIR_ROOT configuration variable 140 displaying permissions on 179
AB_AIR_USE_LOCAL_STORAGE configuration variable examples of creating 33
141 of extended schema 235
AB_AIR_VERSION configuration variable 140 identifying associated category 171
AB_AIW_SCRIPT configuration variable 122 installing base 187
AB_AIW_SERVER_WORK_DIR configuration variable making values required for 164, 173
121 modifying 158
AB_ARULE_BOOL_FORMAT configuration variable 279 names of 28
AB_ARULE_DATE_FORMAT configuration variable 279 removing from category 175
AB_ARULE_USE_LOCAL_TIME configuration variable removing from datastore 160
280 rendered in edit view 73
AB_WORK_DIR configuration variable 121 sample script for creating 282
abinitio.css 82 setting permissions on 177
access control and table column 20
turning on 120 types of 29, 152, 158
add/remove value hyperlink 96 unloading 219
adding using to allow inheritance of values 172
annotation values, via air annotation add where stored 32
command 39, 148 See also multivalued annotation values,
comments 149 single-valued annotation rules
descriptions 149 annotation values 152
metadata 37 adding 148
air annotation add command 39, 148 adding in bulk 42
air category unload command 102, 180 adding one at a time 39

annotation values (continued) Business Objects connector 274

boolean, setting display of 279 bytes annotation rule 228
bulk updates 199
constraining number and kinds of values of 29
date/time, setting display of 279 C
displaying 150
loading 196 cascading style sheets 82
loading with prepackaged applications 239 categories 24
making required or optional 164, 173 adding members to 162
migrating to another datastore 201 associating with annotation rules 35, 164
permitting inherited values for a rule 164, 172 of base schema 222
removing from an object 151 creating 33
rendered in edit view 73 data-description group of 224
restricting user’s choices for a rule 152, 158 data-execution group of 224
sample script for storing 283 data-manipulation group of 223
time, setting display of 280 defining 24, 170
types 29 defining relationships between categories 30
unloading 102, 180 defining views on 166
annotations, prefix for disambiguating 142 definition of 20
application group of categories 223 deleting 173
arguments, specifying object names as 142 displaying information about 171
arule parameter displaying rules associated with 171
Load Category component 199 examples of creating 33
Unload Category component 219 of extended schema 234
asterisks in passwords 123 identifying views of 171
authenticating users 123 installing base 187
author annotation rule 229, 232 Load Category component 199
members of 25
metadata-extension 224
B modifying 173
parent 24, 171
bang character in path names 142 permissions 170, 177, 179
base schema 19, 222 removing members from 174
extending 15 removing rules from 175
installing 187 removing views from 176
new rules versus built-in rules of 28 sample script for creating 282
batch addition of metadata 42 searchable 87
bo_load utility program 274 similarity to object-oriented programming 20
boolean annotation values, setting format of 279 standard 23
BrioQuery connector 272 target 152, 157
build-index.py 94 unloading 102, 180, 219
built-in categories 19, 222 where stored in datastore 27

Index
category members commit_interval parameter (continued)

adding 35, 162 Remove Objects and Annotations component 215
definition 25 commonProjectOID annotation rule 231
displaying annotation values for 150 components
how non-built-in are created and stored 38 for MicroStrategy 271
identifying location of 171 load 42
listing 172 prefix for disambiguating 142
non-built-in 25 configuration variables
relationship to annotation rules 26 AB_AIR_ROOT 140
removing 174 AB_AIR_USE_LOCAL_STORAGE 141
category parameter AB_AIR_VERSION 140
Load Category component 199 AB_AIW_SCRIPT 122
Unload Category component 219 AB_AIW_SERVER_WORK_DIR 121
categoryOID annotation rule 226 AB_ARULE_BOOL_FORMAT 279
CGI script 120 AB_ARULE_DATE_FORMAT 279
choice lists AB_ARULE_USE_LOCAL_TIME 280
allowing user to add choices to 152 AB_WORK_DIR 121
defining 152 configuration variables for the Web user interface 83
removing choices from 160 clearing values of 191
choice-type annotation rules 29 displaying descriptions of 191
adding values to 39 displaying the current values of 194
creating 152 setting values for 192
defining choices for 34, 152 connectors
modifying choice list of 160 defined 239, 267
permitting new values in 152, 158 load 239
restricting choices to predefined list 158 unload 267
class annotation rule 228 control files 121
classes of objects 20 conventions, documentation ix
clear passwords, setting 188 cpu_seconds annotation rule 233
collapsing view-elements 67, 89 create_universe_from_eme graph 277
Column category 235 created_by annotation rule 226
columns, table, as represented by annotation rules 20 creating
commands for setting up Web user interface 191 annotation rules 33, 152
commands, air utility 148 categories 170
comment annotation rule 226 choice lists 34, 152
comments 149 datastore 12
commit_interval parameter groups 185
Load Annotation Values component 196 unload components 107
Load Category component 199 view-elements 56, 167
Load File Dataset component 203 views 54, 166
Load Mimeobj component 206 creation times, setting 280
Load Type component 212 creation_date annotation rule 226

cross-reference tables 112 dbms_version annotation rule 226

deadlock_buffer annotation rule 228
-decorate view-elements 69, 167
D default values of annotation rules
modifying 158
data types of annotation rules 152 reverting to 152
database category 224 setting 152
annotation rules of 226 why specify 155
databaseOID annotation rule 228 defining. See creating.
data-description categories 224 definition annotation rule 229, 230, 231
dataelement category 224 deleting annotation values
annotation rules of 227 from EME 215
DataelementOID annotation rule 235, 236 deleting objects
dataelementOID annotation rule 229, 230 from EME 215
data-execution categories 224 deleting. See removing
dataflows, prefix for disambiguating 142 description annotation rule 226
DataLength annotation rule 235 descriptions, adding 149
data-manipulation categories 223 details view 88
DataPrecision annotation rule 235 directories, prefix for disambiguating elements of 142
DataScale annotation rule 235 disabled annotation rule 232
dataset disabling
for migrating tables 243, 249, 253, 256, 258, EME security 120
260, 262 user accounts 124, 186, 189
dataset category 224 display names of annotation rules
annotation rules of 228 displaying 28, 106
DatasetID annotation rule 235, 236 modifying 158
datasetOID annotation rule 227, 232 setting 152
datasets, file display_name annotation rule 226
create in EME 203 displaying
datastore annotation rule information 157
connecting to 14 annotation values 150
creating 12 category information 171
for searching, creating 94 category members 172
how objects get into 37 descriptions of configuration variables 191
location of, specifying in shell commands 140 groups and membership 186
specifying name of in shell commands 140 names of annotation rules, setting 28
DataType annotation rule 235 permissions 179
date/time annotation values, setting format of 279 user accounts 124, 190
db_name annotation rule 226 DML types
DB2, connector for 252 creating in EME 212
DBC_FILE parameter 110, 242 dmlcode annotation rule 227
dbms annotation rule 226 dmldelimiter annotation rule 227

Index
dmlendian annotation rule 227 examples of

dmlsigned annotation rule 227 creating categories and annotation rules 33
dmltype annotation rule 227 creating views 59, 66
dumping properties mode of mstr_load program 270 examples, conventions for x
exit_status annotation rule 229
expanding view-elements 67, 89
E EXPORT_FILES parameter 242
exporting schema mode of mstr_load program 270
edit hyperlink 73 exporting user accounts and groups 184
edit status of annotation rules EXTEND_SCHEMA parameter 242
displaying 157 extended schema 234, 241
setting 152 extending the base schema 15
edit_view_name variable 90 extend-schema.ksh script 241
editing
annotation values 201
EME F
create file datasets 203
creating record format objects 212 field in a record, prefix for disambiguating 142
creating table datasets 209 file datasets
deleting annotation values 215 create in EME 203
deleting objects 215 file_summary category 224
loading annotation values 196 files, loading into datastore 265
loading categories 199 Filter by Expression component 44
loading MIME objects 206 FILTER_TABLES parameter 242
unloading categories 219 flow category 223
EME Datastore parameter annotation rules of 228
Load Annotation Values component 196 flow_summary category 224
Load File Dataset component 203 annotation rules of 228
Load Mimeobj component 206 flowOID annotation rule 228
Load Table Dataset component 209 flows, prefix for disambiguating 142
Load Type component 212 ForeignKeyOID annotation rule 236
Remove Objects and Annotations component 215 format annotation rule 227
EME datastore, definition of 12 forward slash characters 58
EME ODBC driver 115 frac_cpu annotation rule 233
EME, how users interact with 5 frac_mem annotation rule 233
enabling from_vertexOID annotation rule 228
EME security 120
user accounts 124, 189
encrypted passwords 124 G
endtime annotation rule 229, 231
ERwin, connector for 247 global category
escape characters in view-elements 58 annotation rules of 229

graph category 223 +inherit option to air category add-rule 164

annotation rules of 229 inheritance of values 172
graphOID annotation rule 228, 229, 232 initial annotation rule 229
graphphase annotation rule 231 Initialize EME Datastore subgraph 245
graphs input category
for loading metadata 247, 250, 252, 254, 257, annotation rules of 229
259, 261, 263 install-bmr script 80
prefix for disambiguating elements of 142 installing resources into html directory 80
sample 43, 109 interpretation annotation rule 230
group ID 126 Invalid Value Item category 235
groups 126 InvalidValues annotation rule 237
adding users to 127, 184 is_nullable annotation rule 227
assigning groups to other 127
creating 126, 185
definition of 126 J
displaying membership of 186
importing 187 job category 224
migrating to another datastore 184, 187 annotation rules of 229
removing groups from 128 jobOID annotation rule 231
removing user from 186 job-tracking group of categories 224
role in permissions 129
setting order of in the Web user interface 193 K
showing order of in the Web user interface 194
world 82, 92 Key category 236
KeyType annotation rule 236
H
L
hide/show hyperlink 67
HTML codes, controlling how rendered in browser layout, prefix for disambiguating 142
154 legends, prefix for disambiguating 142
html directory, installing resources into 80 length annotation rule 227
hyperlinks in Web user interface 67, 73, 78, 83, 84, lengthtype annotation rule 227
86, 90, 96 limit parameter
Load Annotation Values component 197
I Load Category component 200
Load Table Dataset component 210
importing user accounts and groups 187 Load Type component 213
includePackageOID annotation rule 230 Remove Objects and Annotations component 216
Index category 235 limit parameter
indexing for searching 167 Load File Dataset component 204
Load Mimeobj component 207

Index
list view 88 location of category members

Load Annotation Values component defining 162
description 196 removing 174
input record format 197 log_input parameter
parameters 196 Load Annotation Values component 197
Load Category component Load Category component 200
description 199 Load File Dataset component 204
loading edited objects 201 Load Mimeobj component 207
parameters 199 Load Table Dataset component 210
specifying values to load 202 Load Type component 213
load components 42, 195 Remove Objects and Annotations component 216
load connectors 239 log_reject parameter
Load File Dataset component Load Annotation Values component 197
description 203 Load Category component 200
input record format 205 Load File Dataset component 204
parameters 203 Load Mimeobj component 207
Load Mimeobj component Load Table Datase component 210
description 206 Load Type component 213
input record format 207 Remove Objects and Annotations component 216
parameters 206 logging parameter
LOAD parameter 242 Load Annotation Values component 197
Load Table Dataset component Load Category component 200
description 209 Load File Dataset component 204
input record format 211 Load Mimeobj component 207
parameters 209 Load Table Dataset component 210
Load Tables and Views subgraph 245 Load Type component 213
Load to EME Datastore or Export Files subgraph 246 Remove Objects and Annotations component 216
Load Type component Logical Element category 236
description 212 Logical Entity category 236
input record format 214 LogicalElementOID annotation rule 236
parameters 212 lookupsUsedOID annotation rule 232
LOAD_COLUMNS parameter 242
load_eme_from_files.mp graph 265
LOAD_INDEXES parameter 242 M
LOAD_KEYS parameter 242
LOAD_TABLES parameter 242 make_sample.ksh script 7
loading annotation values 196 many-to-many-relationships, how handled by ODBC
bulk edits 199 driver 112
loading annotation values with prepackaged Maximum annotation rule 237
applications 239 mem_rss annotation rule 233
loading metadata mode of mstr_load program 269 mem_size annotation rule 233
location annotation rule 232

members of categories navigating to view of technical metadata 90

adding 162 navigation bar hyperlinks 86
definition 25 no_inherit parameter
displaying annotation values for 150 Load Category component 199
how non-built-in are created and stored 38 Unload Category component 219
identifying 171 NONE, meaning in passwords 123
listing 172 Nullable annotation rule 235
non-built-in 25 num_partitions annotation rule 233
relationship to annotation rules 26
removing 174 O
members of groups, displaying 128
metadata objects
adding 37 adding and removing from category 96
deciding what to capture 16 attaching annotation values 196
See also annotation values how stored 37
method annotation rule 228 loading MIME in EME 206
MicroStrategy connector 268 loading updates 201
migrating user accounts 124 prefixes for disambiguating names of 142
migrating user accounts and groups 184, 187 specifying names as arguments 142
MIME objects unloading from EME 219
loading in EME 206 ODBC driver 115
storing text as 69, 167 oid annotation rule 226
mimeobj category 21, 224 oid_as_path parameter
annotation rule of 230 Unload Category component 220
Minimum annotation rule 237 OLAP applications 115
modification times, setting 280 opname annotation rule 232
modification_date annotation rule 226 Oracle Designer, connector for 250
modified_by annotation rule 226 Oracle, connector for 254
mstr_load program 268 outcome annotation rule 231
multivalued annotation rules output category
changing to single-valued 158 annotation rules of 230
creating 152 Owner annotation rule 235, 237
displaying 157 OWNER parameter 242
how handled by the ODBC driver 112
P
N
package category
name annotation rule 226 annotation rules of 230
names packageOID annotation rule 229, 231
of annotation rules 28 packages, prefix for disambiguating elements of 142
of categories 24 parameter category
of objects, specifying 142 annotation rules of 230

Index
parameters log_reject
arule Load Annotation Values component 197
Load Category component 199 Load Category component 200
Unload Category component 219 Load File Dataset component 204
category Load Mimeobj component 207
Load Category component 199 Load Table Dataset component 210
Unload Category component 219 Load Type component 213
commit_interval Remove Objects and Annotations component
Load Annotation Values component 196 216
Load Category component 199 logging
Load File Dataset component 203 Load Annotation Values component 197
Load Mimeobj component 206 Load Category component 200
Load Type component 212 Load File Dataset component 204
Remove Objects and Annotations component Load Mimeobj component 207
215 Load Table Dataset component 210
EME Datastore Load Type component 213
Load Annotation Values component 196 Remove Objects and Annotations component
Load File Dataset component 203 216
Load Mimeobj component 206 no_inherit
Load Table Dataset component 209 Load Category component 199
Load Type component 212 Unload Category component 219
Remove Objects and Annotations component of graphs for loading metadata from prepackaged
215 applications 242
limit of sample unload graph 110
Load Annotation Values component 197 oid_as_path
Load Category component 200 Unload Category component 220
Load File Dataset component 204 path
Load Mimeobj component 207 Unload Category component 219
Load Table Dataset component 210 ramp
Load Type component 213 Load Annotation Values component 197
Remove Objects and Annotations component Load Category component 200
216 Load File Dataset component 204
log_input Load Mimeobj component 207
Load Annotation Values component 197 Load Table Dataset component 209
Load Category component 200 Load Type component 213
Load File Dataset component 204 Remove Objects and Annotations component
Load Mimeobj component 207 216
Load Table Dataset component 210 reject-threshold
Load Type component 213 Load Annotation Values component 196
Remove Objects and Annotations component Load Category component 200
216 Load File Dataset component 203
Load Mimeobj component 206

reject-threshold (continued) R
Load Table Dataset component 209
Load Type component 212 ramp parameter
Remove Objects and Annotations component Load Annotation Values component 197
215 Load Category component 200
root Load File Dataset component 204
Load Category component 199 Load Mimeobj component 207
Unload Category component 219 Load Table Dataset component 209
version Load Type component 213
Unload Category component 219 Remove Objects and Annotations component 216
parent category raw text, controlling display in browser 154
definition 24 record formats
identifying 171 attach to EME file datasets 203
passwords 123 attaching to table datasets in EME 209
changing 124, 188 creating in EME 212
encrypted 124 of unloaded annotation values 103
setting 188 prefix for disambiguating 142
path annotation rule 226 records annotation rule 228
path names, specifying 142 record-type annotation rules 31
path parameter creating 152
Unload Category component 219 Redbrick, connector for 263
period character in view-elements 58 reference-type annotation rules 30
permissions 129 adding values for 40
clearing 170 creating 152
displaying 179 role in allowing inheritance of values 172
setting 177 reformat transformation 44
phase category 224 reject-threshold parameter
annotation rules of 231 Load Annotation Values component 196
phaseOID annotation rule 228, 233 Load Category component 200
Physical Element category 236 Load File Dataset component 203
prefixes for disambiguating object names 142 Load Mimeobj component 206
prepackaged applications, loading metadata with 239 Load Table Dataset component 209
Prepare Column Information subgraph 245 Load Type component 212
Prepare Indexes subgraph 246 Remove Objects and Annotations component 215
Prepare Keys subgraph 245 relational database, unloading categories into 109
project category relational tables
annotation rules of 231 of base schema 19
projectOID annotation rule 226, 228, 229, 230 similarity to categories 20
relationships between categories 30
remarks concept of BrioQuery 272
remote connection to the EME server 141

Index
Remove Objects and Annotations component scripts

description 215 aiw 120
input record format 217 build-index.py 94
parameters 215 extend-schema.ksh 241
specifying values to remove 217 install-bmr 80
removing make_sample.ksh 7
annotation rule from category 175 standard-schema.ksh 23
annotation rules 160 standard-view.ksh 53
annotation values 151 search EME datastore, creating 94
categories 173 searchable_categories variable 87
choices from choice list 160 searching
groups from groups 128, 185 creating view for 72, 87
hyperlinks 96 setting up index for 94, 167
members from category 174 security 137
user accounts 128 select_expression annotation rule 232
user accounts from groups 186 server local time 280
values of configuration variables 191 show/hide hyperlink 67
view-elements from views 176 showing. See displaying.
renderer, installing scripts for 80 -simple view-elements 55, 167, 59
resultOID annotation rule 229 single-valued annotation rules
root parameter changing to multivalued 158
Load Category component 199 creating 152
Unload Category component 219 displaying 157
rules. See annotation rules. site.css 82
slash character
in path names 142
S in view-elements 58
SQL Server, connector for 259
sample EME 7 stages annotation rule 228
sample graph standard extensions 23
for loading bulk annotation values 43 standard-schema.ksh script 23
for loading metadata with prepackaged standard-view.ksh script 53
applications 244 starttime annotation rule 229, 231
for unloading categories 109 state annotation rule 233
sample scripts 281 string-type annotation rules 29
scale annotation rule 227 adding values for 39
schema creating 152
base 19, 222 style sheets 82
extended 234, 241 subgraphs 245, 246
extended, categories of 235 Sybase, connector for 261
-schema option of mstr_load program 270 syntax conventions x

T unload components
creating your own 107
table datasets where they reside 109
attaching record formats 209 unload connectors 267
creating in EME 209 unloading annotation values 102, 180
TABLE_OWNER parameter 110 creating components for 107
TableOrView annotation rule 237 into relational database 109
tables_to_migrate.dat dataset 260 to third-party reporting tools 267
tables_to_migrate.dat dataset 243, 249, 253, 256, user accounts
258, 262 adding to groups 184
TableView category 237 attributes of 123
target category 152 changing name of 187
displaying 157 changing password of 188
TARGET_EME_DATASTORE parameter 242 creating 124, 188
TARGET_PROJECT parameter 242 disabling 124, 189
technical view hyperlink 90 displaying 124, 190
Teradata, connector for 257 enabling 124, 189
text importing 187
adding to a view 167 migrating to another datastore 124, 184, 187
storing 69, 167 removing from groups 186
text conventions ix user authentication
third-party reporting tools, unloading annotation creating accounts for 188
values to 267 turning on 120
time annotation values, setting format of 280 user ID 123
to_vertexOID annotation rule 228
toggling view-elements 68, 89
transform category
V
annotation rules of 231
Valid Range Item category 237
transformPackagesUsed annotation rule 232
Valid Value Item category 237
type category
Validation Spec category 237
annotation rules of 231
ValidationSpec annotation rule 236
typepackagesUsedOID annotation rule 232
ValidRanges annotation rule 237
ValidValues annotation rule 237
U Value annotation rule 235, 237
_value annotation rule 230
Unload Builtin Categories.mp sample graph 109 veclen annotation rule 227
Unload Category component version annotation rule 229, 232
description 219 version numbers, specifying at command line 140
parameters 219 version parameter
record format 220 Unload Category component 219
versionedFlowOID annotation rule 228

Index
versionedGraphOID annotation rule 229 Web user interface

versionedVertexOID annotation rule 233 building for different groups 193
vertex category 223 hyperlinks in 73, 78, 83, 86, 96
annotation rules of 232 logging in to 8
vertex_summary category 224 search index for 94
annotation rules of 233 setting up 80, 83, 99
vertexOID annotation rule 229, 230, 233 showing group order 194
vertical bar character in view-elements 58 Web user interface for the Web user interface 191
view-elements welcome message 85
adding to view 56, 167 WORKDIR parameter 242
definition of 54 world user group 82, 92
escape characters in 58
identifying view of 171
making values searchable 71
ordering of 70
removing from view 176
specifying for indexing 167
types of 55
-view type of 55, 66, 167
views
creating 52, 166
creating view-elements for 167
default 88
definition of 50
for editing values 73
identifying for category 171
making searchable 72
name of view for editing values, setting 90
on extended schema 53
removing from category 176
removing view-elements from 176
rendered in Web user interface 50, 54, 78
sample script for creating 285
for search results 72, 87
W
Web server
managing 120
starting and stopping 121

EME-Guide To Manage Enterprise Metadata

Uploaded by

Copyright:

Available Formats

You might also like

EME-Guide To Manage Enterprise Metadata

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EME-Guide To Manage Enterprise Metadata

Uploaded by

Copyright:

Available Formats

Enterprise Meta>Environment

Guide to Managing Enterprise Metadata

This document contains confidential and proprietary information of Ab Initio Software

September 2003 > Part Number AB0367

Ab Initio Software Corporation

INTELLECTUAL PROPERTY RIGHTS & WARRANTY DISCLAIMER

CONFIDENTIAL & PROPRIETARY

RESTRICTED RIGHTS LEGEND

Chapter 1 > Introduction 1

Chapter 2 > Creating and Extending the Base Schema 15

Chapter 3 > Adding Metadata to an EME Datastore 37

Chapter 4 > Defining What Metadata Users Can See 49

Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy iii

Including Views Within Views 66

Chapter 5 > Setting Up the Web User Interface 79

Chapter 6 > Unloading Metadata from a Datastore 101

Chapter 7 > Accessing Metadata from Windows Applications 111

Chapter 8 > Managing EME Security 119

iv Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Setting Up User Groups 126

Appendix A air Utility Commands 139

Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy v

air category modify-rule 173

Appendix B Load and Unload components 195

vi Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Load Category 199

Appendix C Base and Extended Schemas 221

Appendix D Loading Metadata with Connectors for

Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy vii

Connector for Teradata 257

Appendix E Unloading Metadata with Connectors to

Appendix F Configuration Variables 279

Appendix G Sample Scripts 281

viii Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Related Guide to Managing Technical Metadata is aimed at developers using

Text Conventions We use the following conventions in general text:

myfile.txt Bold represents file paths, DML keywords,

AB_HOME Small caps represent configuration, environment,

emphasis Italics denote emphasis, new terms, and book

Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy ix

Conventions for We use the following conventions in examples:

⇒ An arrow indicates either the result of a

Squares indicate blank spaces where the number of

integer Non-bold text indicates the DML data type of an

read_xml Bold text, symbols, and punctuation represent

my_file Italicized text represents values or variables that

... An ellipsis indicates that the preceding item can be

a|b|c The logical or symbol separates alternatives.

( ) Parentheses are part of the syntax.

[ ] Non-bold square brackets surround a series of

{ } Non-bold curly braces indicate a series of choices

x Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

Topics Covered You will learn about the following topics:

Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy 1

Benefits of the Enterprise

It Is an Integrated The EME is a completely integrated environment. The following figure

2 Ab Initio Software Corporation Confidential and Proprietary — Do Not Copy

• You construct your applications from building blocks called