The architecture of the repository to support multiple organizations in a hierarchy requires certain considerations when designing the repository structure for your deployment.
In the repository, each organization has its own branch, contained in a folder named after the organization. JasperReports Server automatically restricts users’ view and access to the branch of the repository in their organization’s folder. Organization admins can create any folder structure needed within the organization.
Every level of the organization hierarchy, including the system or root level, has a folder named Organizations to contain sub-organizations. The Organizations folder always contains a folder named Folder Template. When a new organization is created, the entire contents of Folder Template is copied to a new folder under Organizations and given the name of the new organization. The minimal folder structure required for new organizations includes a Topics folder under Ad Hoc Components and a Temp folder. The admins can add any folders or resources to the Folder Template that will be used in subsequently created organizations, for example data sources or a set of Ad Hoc Topics that can be modified to suit the needs of each sub-organization.
The Public folder at the root is a special folder shared with all organizations. It is visible to every organization so that the system admin can share certain resources in common, such as a data source, a company logo image, or a report template.
Careful design of the JasperReports Server repository leads to a clear and robust environment for your BI environment and easy yet secure access for users. One of the main decisions is how you want your organizations and users to access resources: which resources are shared across organizations as opposed to which are specific to a particular organization. This usually breaks down into several scenarios:
• Organizations have private resources - Organizations have separate data sources, reports, analysis views etc. This would be typical in an organization with departments. These private resources would be stored in each organization's own folders, and perhaps only a few resources such as company logos would be shared between them.
• Organizations share resources - Resources are kept in the public folders where they can be used by all organizations and users. You may have common data sources and reports across customers, but the underlying data is partitioned by organization. Data level security restricts what users see when running public reports and analysis views.
• Organization share resources, but have some customizations - For example, users in the organization create reports that are private and stored locally, but they access resources in the public folders.
• Organizations have a hierarchical organization - You can have one organization containing other organizations. By default, the parent organization can access all the resources of its child organizations. If you don't want this, you can avoid creating sub-organizations or reprogram the multi-organization filtering logic.
All resources in the repository can be reference by Universal Resource Identifiers (URIs) giving the resource name and the folder path where the resource are located. Because of the hierarchy of organizations, references are relative to the user accessing them. JasperReports Server transforms relative references into actual resource locations in the repository based on the user’s organization and the organization’s main folder. By default, folder locations are transformed in the following ways:
• For organization members, locations in /public are not transformed, but those in the organization’s main folder seen as / (forward slash) by the user are transformed to the actual location, for example, /organizations/organization_1.
• For system admins, locations throughout the repository are not transformed. They see the actual repository path names.
This transformation enables URIs to reference different resources depending on the organization of the user who accesses them. For example, a report may have a public data source and an organization-specific logo as an image. We can set up the report as follows:
• Data source URI specified in the report unit: /public/CommonDataSource. Regardless of the user’s organization, this always references the same repository resource.
• Logo URI specified in the JRXML: /images/organizationLogo. When transformed for each user, the URI will access a location relative to his organization’s main folder. The folder and image resource must have the same name in each organization.
When any user in any organization runs a report that uses a logo image from their /images/organizationLogo resource, the report gets the organization-specific image from the public data source and displays it.
There are three exceptions to references being transformed. In these cases, the references must be literal:
• In report units, references to data sources, JRXMLs, or input controls.
• In analysis views, references to OLAP connections in OLAP views.
• In OLAP connections, references to data sources or schemas.
Also, because these references are not transformed, you must observe the following:
• To do maintenance tasks on an organization’s report units, analysis views and OLAP connections, you must log in to that organization and do the tasks there. You cannot administer the resources as superuser or another organization’s admin.
• The three resources (report units, analysis views and OLAP connections) cannot reference objects across organizations or even in their own parent organization. The reference would not be transformed; it would be taken literally and would fail. For example, if the data source for a report unit is in the /dataSources folder of This_Org, users in That_Org cannot access it because their reference cannot cross organizations.
The best practices for resources in a repository shared by multiple organizations are as follows:
• The system admin must login as an organization user in order to maintain or run organization resources
• Resources with absolute references to resources in organization folders only work for users within the organization or a parent organization
• If a JRXML that accesses organization resources with URIs must run across organizations, then all organizations must have identical folders, object names, and expected object types for those resources.
• The public folder should be used for resources that are shared across organizations.