18-18 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
To enable or disable an initialization block: 1.
In the Administration Tool, select Manage, then select Variables. The Variable Manager appears.
2. In the left pane, select Initialization Blocks under Repository or Session,
depending on whether you want to enable or disable repository initialization blocks or session initialization blocks.
3.
In the right pane, right-click the initialization block you want to enable or disable.
4. Choose Enable or Disable from the right-click menu.
5.
Close the Variable Manager and save the repository.
A
Managing the Repository Lifecycle in a Multiuser Development Environment A-1
A
Managing the Repository Lifecycle in a Multiuser Development Environment
This appendix provides best practice information for managing the lifecycle of the Oracle BI repository when you are using a multiuser development environment.
Building your Oracle BI repository using the multiuser development environment enables you to do the following:
■
Build large, interrelated semantic models
■
Independently build multiple, independent semantic models to run in the same Oracle BI Server and Presentation Services server
■
Develop several branches on different schedules, in parallel, while fixing urgent bugs or enhancement requests on the production version
■
Incrementally design and test at the individual and team levels
■
Enable individual developers to design and test manageable subsets without impacting each other, yet share their changes with other developers in a
controlled, incremental fashion
■
Migrate changes to test and production systems in bulk, or incrementally This appendix covers the development lifecycle of the Oracle BI repository RPD. It
does not cover the development lifecycle of the Oracle BI Presentation Catalog used by Presentation Services. This appendix also does not cover how to use the multiuser
development environment for Independent Software Vendor ISV organizations building portable BI applications for sale as products.
See also Appendix B, MUD Case Study: Eden Corporation
for detailed examples of how the multiuser development environment is used in a typical business scenario.
This appendix contains the following topics:
■
Planning Your Multiuser Development Deployment
■
Multiuser Development Architecture
■
Understanding the Multiuser Development Environment
■
MUD Tips and Best Practices
■
Troubleshooting Multiuser Development
Planning Your Multiuser Development Deployment
This section describes tasks you need to perform as part of the planning phase before beginning multiuser development.
A-2 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
This section contains the following topics:
■
About Business Organization and Governance Process Best Practices
■
About Technical Team Roles and Responsibilities
About Business Organization and Governance Process Best Practices
You need to provide a strong, effective governance process to make decisions about shared resources and to resolve conflicts among the many stake-holders. As in any
business process, you must have a strong business sponsor, and the steering committee must be staffed with strong business people who can negotiate effectively
and make good decisions that will not change over time. Having an effective governance process has proven to be the single most important factor in achieving
successful multiuser development with Oracle Business Intelligence.
Before you begin your multiuser development project, you must first lay out the business value, priorities, roadmap, and requirements, as well as lower level details of
the design, as described in Table A–1
.
About Technical Team Roles and Responsibilities
This section describes the hands-on roles involved in repository development and its lifecycle. Depending on the size of your company and team, some of these roles might
be served by one person.
Table A–1 Tasks to Accomplish During the Planning Phase
For... You must...
Strategic requirements
■
Determine which business processes to measure
■
Determine which data sources and subject areas to access Business requirements for
repository objects
■
Select and define metrics, dimensions, and hierarchies
■
Identify objects that will be shared between development teams
■
Resolve conflicts between teams
■
Define Presentation layer subject areas Security requirements
■
Define Application Roles and corresponding privileges for your user base
■
Define which repository developers can access which metadata and data
Development
■
Determine the styles of multiuser development to use
■
Define areas to break down into MUD projects
■
Determine the owners for metadata objects Project management
■
Set initiatives - purpose, goals, requirements, scope, schedule, budget
■
Define phases - scope, schedule
■
Allocate resources - hardware, software, databases, developers
■
Decide on a strategy for development branching
■
Prioritize and schedule production updates from different development teams
Operations
■
Negotiate service level agreements
■
Coordinate schedules for updates and downtime
Managing the Repository Lifecycle in a Multiuser Development Environment A-3
Repository development roles include:
■
MUD administrator one for each development team, plus backup
– Assigns repository password
– Sets up and maintains MUD projects
– Manages the master repository shared directories
– Manages branches and branch merges
– Manages repository migrations
– Manages test and production connection pools
– Manages independent semantic models has metadata readwrite privileges
for all models
■
Repository developer many per development team
– Knows the repository password
– Owns, operates, and maintains a personal development sandbox that includes
all necessary Oracle Business Intelligence components
– Manages user and application role provisioning on their sandbox stack
– Creates functional and data authorization content in the repository
– Performs unit testing
– Performs check-outs, and check-in merges and publishing, as required
■
Production Operations staff
– Knows the repository password for managing connection pools and applying
patches
– Applies updated repositories, and applies XML patch updates to the running
BI Servers repository
– Can log in to production computers and readwrite the Oracle Business
Intelligence directories or run programs
– Manages the production file system, including the repository directory, logs,
and configuration files
– Manages the production servers Administration Server, Managed Servers
with Java components, and Oracle Business Intelligence system components like Oracle BI Server and Presentation Services
– Manages production security, including provisioning users, groups, and
application roles
– Manages and migrates application roles in production
– Manages production connection pools in the case where the MUD
administrator does not have security privileges for production connection information
People in other roles outside the repository development team are also involved. These include people administering the test environment and running the tests, and
also the Oracle BI Presentation Catalog developers.
A-4 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
Multiuser Development Architecture
Before you can understand best practices for MUD and repository lifecycle management, you need to understand the architecture of the development
environment.
This section contains the following topics:
■
About Multiuser Development Concepts
■
About Multiuser Development Styles
■
Multiuser Development Sandbox Architecture
■
Multiuser Development and Lifecycle Management Architecture
About Multiuser Development Concepts
This section explains fundamental concepts related to developing and deploying systems for multiuser development.
Repository RPD The repository, or RPD file, is the fundamental artifact under development. It defines
all the metadata used by the Oracle BI Server for interpreting user requests, applying role-based security, generating queries to data sources, and post-processing the
results.
Application Roles and the Policy Store A secondary artifact under development is the set of application roles. User object
permissions, data access filters, and query limits governors are defined against these application roles in the repository logic. Presentation Services also uses application
roles for assigning its privileges and permissions.
You can use the default policy store embedded in Oracle WebLogic Server, or you can use a separate external policy store. If you are using the embedded policy store, you
define application roles in Fusion Middleware Control, which persists them in the Policy Store in Oracle WebLogic Server. You can then use the Administration Tool in
online mode to add application roles from your policy store to your repository at design time. At run time, the Oracle BI Server uses the application roles provisioned to
each user to apply the correct security privileges to user requests.
Sandboxes, Projects, and Branches An instance of the repository is usually edited by only one repository developer at a
time. Multiple developers work in parallel on subset instances of the repository, called projects. They work in separate sandbox environments, and merge their changes into
a master repository instance frequently to distribute changes and pick up changes made by others in the team. This approach enables the creation of very large enterprise
applications. It also enables independent semantic models to be developed by separate teams and merged into the master repository for production hosting in a single Oracle
BI Server cluster. Finally, it enables branching and merging so that teams can work on major projects in parallel, and can even make emergency fixes to the main code line in
production without disrupting ongoing development projects.
You typically use the Simple install type when installing a development sandbox.
Single, Shared Repository Presentation Services connects to just one repository that has been uploaded to the
Oracle BI Server. The metadata for all semantic models must reside in this single
Managing the Repository Lifecycle in a Multiuser Development Environment A-5
repository, even if the semantic models share no objects. See About Multiuser
Development Styles for more information about semantic models in a repository.
Repository Password The repository file is protected by the repository password. The Oracle BI Server needs
this password to open and load the repository at startup. It stores the repository password in the secure Credential Store. You must also enter this password when you
open the repository in the Administration Tool or other utilities and line commands. Note that user logon credentials are stored in the identity store, not the credential
store.
Oracle BI Presentation Catalog The Oracle BI Presentation Catalog is an important BI application artifact that contains
the metadata that defines reports, dashboards, KPIs, scorecards, and other reporting layer objects. The Oracle BI Presentation Catalog is outside the scope of this document.
See Managing Objects in the Oracle BI Presentation Catalog in Oracle Fusion Middleware Users Guide for Oracle Business Intelligence Enterprise Edition for more
information about Oracle BI Presentation Catalog development.
Migration The completed repository is migrated to test and production systems using Fusion
Middleware Control. No downtime is necessary, because you can refresh clustered production Oracle BI Servers with a rolling restart.
Deployment Parameters During Migration Some repository parameters must change when migrating a repository between
development, test, and production systems, such as connection pool settings. These parameters must change because they are based on the deployment, not the
application logic. You can automate these updates using the Oracle BI Server XML API biserverxmlexec.exe -B. During multiuser development, developers merging in
content are automatically prevented from overwriting the master repository test connection pool and database parameters with their local unit test parameters.
Application Role Policy Store Migration There are several options for migrating application roles between development, test,
and production systems. For simplicity, this document assumes you will re-key a small number of application role names by hand. For full information about migrating
application roles, and other migration considerations, see Moving Oracle Business Intelligence Components to a Production System in Oracle Fusion Middleware
Administrators Guide.
Users and the Identity Store As a best practice, users are not represented by metadata objects in the repository at
design time. Also, the repository does not manage or store their credentials. Instead, users must always be provisioned to application roles in the run-time environment to
receive privileges. Their credentials, as well as their mapping to application roles through groups, are managed in an external Identity Store. See Oracle Fusion
Middleware Security Guide for Oracle Business Intelligence Enterprise Edition for more information.
Setting the Environment for the Administration Tool and Utilities The current directory structure generalizes the location of metadata, data, and
configuration files. For this reason, each program or utility you launch requires an
A-6 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
initial setup of the configuration for the Oracle instance to which that program belongs. For command-line utilities, you must first launch the bi-init utility to set the
parameters, and then launch the utility from a command line inside the bi-init window. Most Oracle BI Server tools, including the Administration Tool, run the
bi-init utility transparently. If you run a command without setting the instance environment first, the program will typically fail to find external files.
About Multiuser Development Styles
Choose your style of development based on the size of your team, the number of teams and parallel initiatives, and your requirements for security and availability.
Table A–2 shows the multiuser development styles.
Table A–2 Styles of Multiuser Development
Style Description
Serial Development Figure A–1
You can use this method if you have a small number of developers and low concurrency. Development users share a
repository file through e-mail, a shared directory, or on a shared development system, and only one of them makes changes at a
time. They must coordinate with each other on the development schedule.
Serial Development with Patch Files
Figure A–1 As a variation on serial development, you can share a base
binary repository, and ship changes only between users using patch files.
Shared Online Development
Figure A–2 The best practice is for only one developer at a time to develop
metadata in online mode against a single Oracle BI Server and its repository. However, multiple online users are an option for
development situations where communication among the team members is frequent, a higher risk of conflicts is acceptable, and
minimum administrative overhead is a goal.
MUD Figure A–3
The Multiuser Development feature enables over one hundred development users to work in parallel on a shared, enterprise
repository. Each user can develop and unit test in a separate sandbox environment, using only manageable-sized subsets of
the metadata. When a unit of work is complete, they can automatically merge it into the branch, where other users can
pick up those changes and integrate them with their own metadata. When a project phase is ready for promotion, the
MUD administrator migrates it to the test environment, and eventually, production. The MUD administrator manages
branches and sub-branches to enable parallel development of independent initiatives or fixes, and merges them into the main
branch to incrementally migrate them to test and production environments. The MUD administrator also manages
fine-grained projects, which are the manageable-sized repository subsets individual developers check out to their local
sandbox environments. See
Understanding the Multiuser Development Environment
for additional information.
Managing the Repository Lifecycle in a Multiuser Development Environment A-7
Figure A–1 the serial development style of multiuser development.
Figure A–1 Serial Development
Figure A–2 shows the shared online development style of multiuser development.
MUD with Multiple, Independent Semantic
Models Figure A–3
and Figure A–4
There might be cases where you need two or more independent semantic models, rather than a single, integrated,
enterprise-wide model. This is common due to security requirements, or when unrelated divisions of a business share a
common Oracle Business Intelligence infrastructure. The MUD administrator creates a branch for each model, which enables
parallel development and integrated testing for each teams semantic model. When an independent semantic models
branch is ready for promotion to production, the MUD administrator simply merges the branch into main. The MUD
administrator can set security on the branches so that each developer can only see the semantic model to which they are
assigned, and so that only the MUD administrator and selected production operations staff can access the integrated main
model.
MUD with Delegated Administration
Figure A–3 and
Figure A–4 When the independent semantic models are developed by
different organizations on different schedules, a centralized MUD administrator might not provide the desired level of local
control. In this case, you can provide a dedicated MUD administrator for each independent semantic models branch.
The branch administrator operates in the same way as an ordinary MUD administrator.
In this scenario, the MUD super-administrator defines a branch for each organization, checks out the subset repository, and
provides it to the branch administrator. When the model is ready for promotion to production, the branch administrator
passes the repository back to the super-administrator, who merges it into the main branch for promotion, and then
migrates the combined repository to production.
Table A–2 Cont. Styles of Multiuser Development
Style Description
A-8 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
Figure A–2 Shared Online Development
Figure A–3 shows true multiuser development with branching.
Figure A–3 Multiuser Development
Figure A–4 shows the architecture for a repository with multiple, independent
semantic models.
Managing the Repository Lifecycle in a Multiuser Development Environment A-9
Figure A–4 Repository with Multiple, Independent Semantic Models
Table A–3 shows which multiuser development styles meet various requirements for
security and availability.
Multiuser Development Sandbox Architecture
When using MUD, each developer works on their own, fully dedicated sandbox Oracle Business Intelligence system. You should set up your sandbox to contain all the
components you need for development and unit testing.
Table A–3 Requirements Met by Multiuser Development Styles
Requirement Serial
Shared Online
MUD with Single
Semantic Model
MUD with Multiple
Semantic Models
MUD with Delegated
Administration No administrator
Yes No
No No
No Up to five concurrent
developers No
Yes Yes
Yes Yes
More than five concurrent developers
No No
Yes Yes
Yes Work on manageable subsets
of a large repository, such as Oracle BI Applications
No No
Yes Yes
Yes Built-in checkout, merge, and
rollback No
No Yes
Yes Yes
Host independent semantic models in single repository
Yes Yes
No Yes
Yes Incremental migration of
units of work to production No
No Yes
Yes Yes
Developers of independent semantic models cannot see
each others metadata No
No No
Yes
1
1
Requires secure MUD Directory. An overall MUD administrator must still have access to all metadata from all teams.
Yes
1
Each independent semantic model has its own MUD
administrator No
No No
No Yes
A-10 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
First, you need to decide whether to use a UNIX or Windows server for your Oracle Business Intelligence stack. Follow these guidelines:
■
If you choose the Windows-only option, make sure your system has enough memory. Note that you will need additional resources if you choose to host your
database on the same hardware. See System Requirements and Certification
for information about minimum hardware requirements.
■
If you choose the UNIX option, you still need a Windows system to run the Administration Tool. Use the Oracle Business Intelligence Simple install type on
the UNIX system, and use the Client install type on the Windows system to install the Administration Tool.
In online mode, the Oracle BI Server loads the repository from its local repository directory on the UNIX system in:
ORACLE_INSTANCE bifoundationOracleBIServerComponentcoreapplication_
obisnrepository Note that the Administration Tool on Windows also points to a local repository
directory by default, but you can use any directory for offline development. You also need to install a development database. This database can be a dedicated,
personal database, or it can be shared among multiple repository developers. Note the following considerations about the development database
■
Platform: You can choose to host your development database on your sandbox
computer if you provide enough memory, or you can host it on a centralized, shared server. Both scenarios are shown in
Figure A–5 .
■
RCU: The database must contain the schemas required by Oracle Business
Intelligence. You load these schemas using the Repository Creation Utility RCU. These schemas enable support for Oracle BI Scheduler and annotations for Oracle
Scorecard and Strategy Management, provide sample tables for Usage Tracking, and enable many other features. The Oracle WebLogic Server Managed Servers for
Oracle Business Intelligence, and all the services that depend on it, require access to a running database with the required RCU schemas in order to operate.
■
Data Source Schemas: You also need data source schemas for the metadata under
development. You can optionally include some data source schemas in your RCU database, or they can be in other databases. Note the following additional
information about data source schemas:
– Test Data:
The data source schemas should be loaded with test data. If users are testing read-only metadata, the schemas can be shared among multiple
development sandboxes. They can be located on the development sandbox computer if enough memory is available.
– Multiple Sources:
Optionally, your environment might include multiple data sources needed by your initiative, such as other relational sources, Essbase,
Hyperion Financial Management, Microsoft Analysis Services, SAP BW, and others. These sources can be shared or dedicated, local or remote.
Note: The Client install type does not include Catalog Manager, so if
you plan to develop the Oracle BI Presentation Catalog in this environment, you should use the Simple install type on the Windows
computer rather than the Client install type.
Managing the Repository Lifecycle in a Multiuser Development Environment A-11
– Connectivity:
You must set up connectivity from your Administration Tool and Oracle Business Intelligence stack to each data source. This configuration
can include installing the required drivers or clients, setting up ODBC DSNs, setting up native connectivity, and other steps. See
Chapter 4, Importing Metadata and Working with Data Sources
and Chapter 15, Setting Up Data
Sources on Linux and UNIX for full information.
Note that for Oracle Database connectivity, Oracle Business Intelligence requires an instance of TNSnames.ora in ORACLE_HOMEnetworkadmin.
Figure A–5 shows the architecture of the multiuser development sandbox.
Figure A–5 Multiuser Development Sandbox Architecture
Multiuser Development and Lifecycle Management Architecture
The overall MUD architecture contains the developer sandbox systems described in the previous section, as well as any test and production systems. In addition, there are
several additional major components, as follows:
Note: Most developers prefer to disable caching in the development
sandbox. This makes it easier to validate and debug physical queries using the log. When the cache is enabled, the physical SQL might not
appear in the log, because the request might get fulfilled by the cache. In this release, you must disable caching using Fusion Middleware
Control. See Using Fusion Middleware Control to Enable and Disable Query Caching in Oracle Fusion Middleware System Administrators
Guide for Oracle Business Intelligence Enterprise Edition for more information.
A-12 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
■
Windows MUD administration system. This system is maintained by the MUD
administrator. Note the following about this system:
– It provides one shared network MUD directory for the main branch, and
additional shared network MUD directories for each side branch. The Windows permissions on each shared directory only allow access to the
developers for that branch. Each shared directory stores the master repository for that branch, as well as various control and history files for MUD functions.
– It has a client installation of Oracle Business Intelligence. The Administration
Tool and Oracle BI Server utilities are used for creating and managing MUD projects, performing merges, creating patches, and other MUD administrator
tasks. Other Oracle Business Intelligence processes like the Oracle BI Server, as well as the policy store and credential store, are typically not used on this
platform.
– A 32 bit or 64 bit system can be used, because none of the Oracle Business
Intelligence Java components, system components, or other infrastructure are used on this computer.
■
One or more test systems. These systems are used for running integrated tests of
merged content. They run the full Oracle Business Intelligence stack, and can be either UNIX- or Windows-based. These systems are frequently clustered.
■
Oracle BI Presentation Catalog system. Optionally, you might have a system with
a full Oracle Business Intelligence stack for developing Oracle BI Presentation Catalog content.
■
Clustered production system. Eventually, you will have a clustered production
system on one of the supported Oracle Business Intelligence platforms.
■
External identity store. This appendix assumes you are using an external identity
store like Oracle Internet Directory. Figure A–6
shows a sample deployment architecture for the repository lifecycle using the multiuser development environment.
Managing the Repository Lifecycle in a Multiuser Development Environment A-13
Figure A–6 Example Multiuser Development Deployment Architecture
Understanding the Multiuser Development Environment
MUD is a set of features that enables teams of developers to work in parallel on projects of any size, despite the complex interrelationships and dependencies in the
repository model. With MUD, you can:
■
Divide the repository file into subsets
– Enables users to work with manageable subsets when the repository is very
large
– Enables independent testing for each subset by each developer or team
– Makes it easier to manage merges later after checking out a branch subset
– Enables you to separate independent semantic models into secure branches for
development
■
Incrementally develop, test, and migrate
■
Merge subsets and branches, handling conflicts between user changes
■
Apply Oracle updates to a packaged BI Application you have modified
■
Merge separately developed applications into a single repository
■
Access history logging and audit information
■
Roll back to historical repository states
A-14 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
The multiuser development feature also provides the following other useful capabilities:
■
Coordinates merging into the master, including tracking original repository files
■
Provides locking for reliable updates
■
Logs changes
■
Automatically backs up repositories before each potentially destructive operation This section contains the following topics:
■
About Multiuser Development Environment Task Flow
■
About Multiuser Development Projects
■
How to Create Branches
■
Which Merge Utility Should I Use?
About Multiuser Development Environment Task Flow
The basic flow of working with multiple users is as follows:
1.
A developer defines the starter Physical layer, as well as basic facts and subject areas. This provides some basic objects to anchor the MUD projects.
2.
The MUD administrator defines projects and puts the RPD into the main branch MUD directory. Note that the MUD directory where the master repository is
stored cannot be the same as the Oracle BI Server local repository directory.
3.
A developer can now check out one or more projects, do development work, and then check back in by merging the changes into the master, and then publishing it
back to the MUD directory.
4.
Meanwhile, other developers check out and do development on the same or other projects note that projects are for subsetting, not for enforcing security. Because
check-in uses a three-way merge, users can check out, develop, and check in their changes in any order. Even property changes to a single object from multiple users
are merged. If conflicts do occur between users, the three-way merge feature provides a way for the developer to choose which objects to keep. Communication
between users is a key to avoiding and resolving conflicts, and you should have your governance process assign ownership of major objects in order to avoid such
conflicts.
5.
When a development phase is complete, the MUD administrator can migrate the content to a test system. There might be several iterations back through check out,
bug fix, check in, and retest. When the repository passes the testing phase, the MUD administrator can migrate it to the production environment.
6.
The MUD administrator can create and manage multiple development branches as large MUD projects. A branch can be secured to ensure that only one development
team can work on it. A branch can even be treated recursively as a main, with its own, delegated MUD administrator.
About Multiuser Development Projects
The multiuser development feature is built around a metadata object called a project. The project is the unit of check-out from the master repository, and the subsequent
check-in merge and publish. When a master repository becomes very large, a project is a manageable-sized subset that a developer can check out to work on. It is also
designed to be self-consistent, so that you can run the consistency checker analogous
Managing the Repository Lifecycle in a Multiuser Development Environment A-15
to compile-time code checking and then test it on the Oracle BI Server with a client such as Answers at run time. When you are satisfied with the results, you can merge it
back into the master repository so that it becomes part of the larger application. Meanwhile, history is logged and repository backups are automatically created at key
points.
MUD features in the Administration Tool streamline this flow for fine-grained developer projects. Similarly, superset projects streamline the management and
merging of branches.
The project subset contains a set of metadata objects. You define a project to include a minimum set of objects explicitly, but many others are included implicitly. Having
objects implicitly added to projects simplifies your project management task.
The following objects are explicitly specified by the MUD administrator as members of a project:
■
Logical fact tables
■
Presentation layer subject areas
■
Application roles
■
Users although the best practice is to only use application roles in RPD logic
■
Initialization blocks
■
Variables All other objects are implicitly included in a project and are found by the
Administration Tool during the check-out process. For example:
■
Descendents of the explicitly defined objects. For example, when a logical fact table is included explicitly, all its logical columns are included in the project
implicitly.
■
Logical dimension tables that join to the selected logical fact tables, and the join objects themselves.
■
Logical table sources for the included logical fact and dimension tables.
■
Physical tables that map to the logical tables included in the project, and the joins between them.
■
Marketing target levels and list catalogs. Note that objects that are in the list of explicitly defined objects are sometimes
included implicitly. For example, if a logical column contains an expression that includes a variable, the variable is implicitly included in the project, even if the MUD
administrator does not explicitly add it.
It is normal for projects to overlap. An object that appears in one project can also appear in another project. For example, some customers prefer to create an overall
project for each independent semantic model, as well as smaller projects within each independent model for checking out individual units of development work. You can
also check out multiple projects simultaneously to work on a larger set of metadata.
[placeholder for diagram of how a project draws in some dimensions and physical objects]
See also Setting Up Projects
for additional information.
A-16 Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition
How to Create Branches
This section explains how to create main branches, side branches, and delegated administration branches.
This section contains the following topics:
■
How to Create a Main Branch
■
How to Create a Side Branch
■
How to Create a Delegated Administration Branch
How to Create a Main Branch
The ultimate master repository is usually source-controlled in the main branch, out of which all branches and ultimately all development projects check out. The main
branch usually stages the repository in production. That is, to migrate content to production, you merge it into the main branch, and then migrate the main repository
to the production system.
Similarly, to fix a production bug, a developer typically checks out of the main branch. The developer then fixes the bug, and then merges it back into the main branch for
migration to test and production. Meanwhile, parallel development in side branches is not affected.
To create the main branch as the MUD administrator, you must first create a shared directory and copy the master repository file to it. The directory can be on either
Windows or UNIX, but the UNIX share must be accessible by Windows users.
Set the security on the share to only allow access by the appropriate developers. Depending on your requirements, you might only allow developers to access the side
branch master repositories, not the main branch master repository.
If this is a new project, you typically have a developer seed the repository with initial content that can be easily split into branch projects.
How to Create a Side Branch
The best practice for branching is to start with a superset MUD project, and then use the MUD check-out, merge, and publish features. Then, individual users or
sub-branches use finer-grained projects and check out of the branch master. Using MUD for this functionality provides automatic back-ups at the check-out points, tracks
original repositories to ensure correct merges, uses more optimistic merge assumptions that require less user intervention, and provides history and roll-backs.
To create a side branch as the MUD administrator: 1.
In the main master repository, create a project that extracts all content required for the branch. Follow these guidelines to create the project:
■
If little or no metadata has been designed in the repository, it is a best practice to seed it with content that can anchor the project. This makes it easier to
ensure the project extracts the physical content you need to support the logical fact tables. Usually, this means one or more logical fact tables are created, with
at least some representative columns. The columns should be mapped to the physical tables and joins needed to support the fact tables. Finally, create the
project and define the objects that belong to it.
■
If content already exists, create the project and define the objects needed in that branch. The branch can overlap with other projects, if necessary.
Managing the Repository Lifecycle in a Multiuser Development Environment A-17
■
It is also possible to create an empty project for check-out. However, the developer who checks it out must ensure that all the physical objects that need
to be implicitly added to the project are mapped to the logical fact table before check-in. Similarly, the developer must ensure dimensions are joined before
check-in to ensure their inclusion, and must explicitly add any subject areas, variables, initialization blocks, application roles, and users. This method is
more prone to errors than seeding the project before defining it.
■
Typically, connection pools for environments such as production must be secured. Ensure that the connection pool settings in the master repository are
acceptable for the developers to access. Note that developers typically change the settings to match their local test databases. At check-in, connection pool
and database settings are not merged, to prevent overwriting the settings in the master repository.
Use the Oracle BI Server XML API to automate connection pool changes required during migrations to production and other environments. See
Moving from Test to Production Environments in Oracle Fusion Middleware Integrators Guide for Oracle Business Intelligence Enterprise Edition for more
information.
2.
Create a shared MUD directory for the branch. Every branch should have its own MUD directory. Set the permissions so that only the developers working on that
branch have access to it.
Note that you can use branch permissions combined with project subsetting to prevent developers from seeing metadata that belongs to other teams. Design the
projects carefully so that they only extract metadata related to one team. This goal is easiest to achieve if the teams use different business models, subject areas,
physical models, variables, initialization blocks, and application roles.
It is also a best practice to use a consistent system of naming and numbering your branches.
3. Check out the branch project using File Multiuser Checkout. You can check
