Multiuser Development Architecture
By reviewing these topics, you can get an understanding of the multiuser development environment architecture.
This section contains the following topics:
About Multiuser Development Concepts
Learn the fundamental concepts related to developing and deploying systems for multiuser development.
Oracle BI Repository
The Oracle BI Repository 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. Repositories used in multiuser development environments must be in binary (RPD) format, not MDS XML format.
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. Oracle BI 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 repository, even if the semantic models share no objects, see About Multiuser Development Styles.
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. 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 User's Guide for Oracle Business Intelligence Enterprise Edition.
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 -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 to a Target Environment in Administering Oracle Fusion Middleware.
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 Security Guide for Oracle Business Intelligence Enterprise Edition.
About Multiuser Development Styles
You can learn about multiuser development styles and view potential workflows or architectures.
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. The table shows the multiuser development styles.
| Style | Description |
|---|---|
|
Serial Development |
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 |
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 |
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 |
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 and publish 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. |
|
MUD with Multiple, Independent Semantic Models |
You might need two or more independent semantic models, rather than a single, integrated, enterprise-wide model. The multiple model requirement is common resulting from 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 team's semantic model. When an independent semantic model's 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 |
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 model's 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. |
The images shows the serial development style of multiuser development.
The image shows the shared online development style of multiuser development.
The figure shows true multiuser development with branching.
The image shows the architecture for a repository with multiple, independent semantic models.
The table shows which multiuser development styles meet various requirements for security and availability.
| 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 |
Yes. Requires secure MUD Directory. An overall MUD administrator must still have access to all metadata from all teams. |
|
Each independent semantic model has its own MUD administrator |
No |
No |
No |
No |
Yes |
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.
You need to decide whether to use a UNIX or Windows server for Oracle Business Intelligence. You can use these guidelines:
-
If you choose the Windows-only option, make sure your system has enough memory. You 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 need a Windows system to run the Oracle BI 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/bifoundation/OracleBIServerComponent/coreapplication_obisn/repositoryThe Administration Tool on Windows also points to a local /repository directory by default, but you can use any directory for offline development.
You need to install a development database. You can set up the database as dedicated database, personal database, or share the database among multiple repository developers. Consider the following 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 the image that follows.
-
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. In addition, consider the following:
-
Test Data: You should load the data source schemas with test data. If users are testing read-only metadata, You can share the schemas among multiple development sandboxes. You can put the schemas on the development sandbox computer when the computer has enough memory.
-
Multiple Sources: Your environment can support multiple data sources needed by your initiative such as other relational sources, Essbase, Hyperion Financial Management, Microsoft Analysis Services, SAP B/W, and others. You can share the data sources or put the data sources on dedicated, local or remote servers.
-
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 Importing Metadata and Working with Data Sources and Setting Up Data Sources on Linux and UNIX.
For Oracle Database connectivity, Oracle Business Intelligence requires an instance of
TNSnames.orainBI_DOMAIN/config/fmwconfig/bienv/core.
-
The image shows the architecture of the multiuser development sandbox.
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 System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Multiuser Development and Lifecycle Management Architecture
The overall MUD architecture contains developer sandbox systems, test, and production systems.
In addition, there are several additional major components, as follows:
-
The Windows MUD administration system is maintained by the MUD administrator:
-
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.
The image shows a sample deployment architecture for the repository lifecycle using the multiuser development environment.
