The architecture of the commercial version of JasperReports Server is built on organizations, which are logical entities within JasperReports Server that have their own users, roles, and branches of the repository. As with any business structure or hierarchy, organizations may have suborganizations, which in turn may have suborganizations, and so on.
In the default JasperReports Server installation, there is a single organization that mimics the simple structure of older versions of JasperReports Server. If you want to deploy multiple organizations, there are certain design considerations you must be aware of.
Organizations are not available in the community version of JasperReports Server.
After a default installation, JasperReports Server contains a single organization in which you can deploy your reports. For example, if you install the sample data, you see a single organization that holds all sample resources, users, and roles.
Single organizations are designed to handle most business cases and are straightforward to administer. Even in a single organization, there is a system admin and an organization admin that share administrative duties. If the needs of your business call for more organizations, you must manage several levels of administrators and possibly create shared resources in the repository. The following sections provide use cases and explain the functioning of multiple levels of administrators.
|An application provider, such as a software-as-a-service (SaaS) company or a computer department, has a hosted application being offered to many customers. It integrates JasperReports Server in its application in order to offer dashboards, reports, and analysis. There are a number of common reports and data sources that are useful across customers, but there are customer specific reports, as well. Machines and databases are shared by customers, according to the provider’s own architecture, but within the functionality provided by JasperReports Server, each customer is a separate organization. Customers can manage their own users in the hosted application, and JasperReports Server maps the application’s authentication scheme to the correct organization. The organization mechanism provides the full power of JasperReports Server to each of the provider’s customers, while ensuring that their data and reports are secure.
|A company has many departments but wants to consolidate the BI environment so that all departments are sharing a common BI infrastructure. Corporate IT only needs to deploy and maintain a single instance of JasperReports Server, and each department is represented by an organization that manages its own users. For security and simplicity, the departments do not share databases, except in the case of sub-departments, such as Accounts Payable being a sub-department of Finance. Users access JasperReports Server directly, logging in with their department name and user name. Organization administrators have defined the data sources and Domains specific to the needs of their department’s users.
The organization feature is flexible enough to accommodate any combination of these scenarios and many like it. In all cases, administrators can configure secure environments for any number of organizations, and end-users experience a powerful BI platform that is tailored to their needs.
Each organization or hierarchy of organizations co-exists independently in the same instance of JasperReports Server, which isolates neighboring organizations from each other but allows parent organizations to have full control over their suborganizations. Users may access only the data and resources in their organization or a suborganization, and administrators may define roles and set permissions to further restrict access.
Each organization has an administrator who can manage users, roles, and repository permissions in that organization. The administration of organizations is hierarchical, meaning that the administrator can also manage all users and roles in suborganizations of any level.
|The administrator of a suborganization – Functionally equivalent to an organization admin, but due to the hierarchy of organizations, manages a limited set of user, roles, and repository objects and may be overridden by a top-level organization admin.
The most important distinction is between the system admin and organization admin. Even in the case of a single default organization, there is a system admin for server settings, and an organization admin for the single organization. The system admin can manage all users and the entire repository, but sometimes it is more convenient to use the organization admin to do this because the organization admin sees the repository in the same way as the organization users.
When there are suborganizations, the administrator of the parent organization can either manage their users and roles, or delegate those tasks to an administrator in each suborganization. The administrator of a suborganization is limited to accessing resources and managing users and roles in the suborganization, thereby maintaining the security of the parent organization and any of the parent’s other suborganizations.