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

• About Multiuser Development Styles

• Multiuser Development Sandbox Architecture

• Multiuser Development and Lifecycle Management Architecture

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 Oracle BI repository file (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're using the embedded policy store, you define application roles using the Console in Oracle Analytics Server, which persists them in the Policy Store in Oracle WebLogic Server. You can then use the Model 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. The developers 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 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 Model 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 artifact that contains the metadata that defines reports, dashboards, and other reporting layer objects. See Using Oracle Analytics Publisher in Oracle Analytics Server.

Migration

The completed repository is migrated to test and production systems using Fusion Middleware Control. Downtime isn't 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're 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'll 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 aren't represented by metadata objects in the repository at design time. Also, the repository doesn't 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 Set Up Security With Users, Groups, and Application Roles in Managing Security for Oracle Analytics Server.

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've 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 Understand 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 can be for security requirements, or when unrelated divisions of a business share a common 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're 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 image shows the serial development style of multiuser development.

Description of the illustration lc_serial_style.png

The image shows the shared online development style of multiuser development.

Description of the illustration lc_online_style.png

The image shows true multiuser development with branching.

Description of the illustration lc_mud_style.png

The image shows the architecture for a repository with multiple, independent semantic models.

Description of the illustration mud_dev_styles.png

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 can't 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 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 Linux or Windows server for Oracle Analytics Server. 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.

• If you choose the Linux option, you need a Windows system to run the Model Administration Tool. Use the Oracle Analytics Server Simple install type on the Linux system, and use the Client install type on the Windows system to install the Model Administration Tool.

  In online mode, the Oracle BI Server loads the repository from its local repository directory on the Linux system in:

  ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/coreapplication_obisn/repository

  The Model 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 Analytics Server. You load these schemas using the Repository Creation Utility (RCU). These schemas enable support for Oracle BI Scheduler, provide sample tables for Usage Tracking, and enable many other features. The Oracle WebLogic Server Managed Servers for Oracle Analytics Server, 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, Microsoft Analysis Services, 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 Model Administration Tool and Oracle Analytics Server 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 Import Metadata and Working with Data Sources and Set Up Data Sources on Linux.

    For Oracle Database connectivity, Oracle Analytics Server requires an instance of TNSnames.ora in BI_DOMAIN/bidata/components/core/serviceinstances/ssi/oracledb.

The image shows the architecture of the multiuser development sandbox.

Description of the illustration dev_sandboxes_linux.png

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 Administering Oracle Analytics Server.

Multiuser Development and Lifecycle Management Architecture

The overall MUD architecture contains developer sandbox systems, test, and production systems.

There are several additional major components:

• 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 Analytics Server. The Model 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 processes such as the policy store and credential store are typically not used on this platform.

  • You can use a 32-bit or 64-bit system because no Java components, system components, or other infrastructure are used on this computer.

• One or more test systems

  These systems are Linux- or Windows-based, and are used for running integrated tests of merged content. They run the full Oracle Analytics Server stack. These systems are frequently clustered.

• Oracle BI Presentation Catalog system

  You could have a system with a full Oracle Analytics Server stack for developing Oracle BI Presentation Catalog content.

• Clustered production system

  You use a clustered production system on one of the supported platforms.

• External identity store.

  Oracle assumes that you're using an external identity store such as the Oracle Internet Directory.

The image shows a sample deployment architecture for the repository lifecycle using the multiuser development environment.

Description of the illustration mud_arch-oas.png